This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-04-17
Channels
- # announcements (2)
- # babashka (52)
- # beginners (10)
- # calva (9)
- # cider (2)
- # clj-kondo (7)
- # clojure (63)
- # clojure-europe (26)
- # clojuredesign-podcast (5)
- # clojurescript (13)
- # datalog (2)
- # datomic (6)
- # defnpodcast (1)
- # fulcro (46)
- # incanter (4)
- # integrant (5)
- # jobs-discuss (12)
- # kaocha (1)
- # lsp (31)
- # malli (10)
- # meander (1)
- # off-topic (6)
- # podcasts-discuss (1)
- # polylith (20)
- # rewrite-clj (6)
- # shadow-cljs (23)
- # tools-deps (9)
- # xtdb (13)
- # yada (10)
Hello folks! I’m pretty new to shadow-cljs, but I’m curious - is there a way to add a preamble to the generated js file? https://shadow-cljs.github.io/docs/UsersGuide.html#compiler-options, but I’m curious if I’m missing something. My use case is that I’d like to add a link to a file with the licenses of the OpenSource libraries I’ve used
Thank you @thheller
Hello I've been struggling with some type inference:
(let [^js data (.data author-post)
postRef (.-post data)]
)Cannot infer target type in expression (. inst_51072 -post)
but if I do this
(defn get-data
[^js o]
(.data o))
(let [data (get-data author-post)
postRef (.-post data)]
)Is the let inside a go block?
Type hints in clojurescript can get lost in go blocks. The best thing to do is extract things out into functions like you have here. I believe it is an issue with the go block macro
I will try to find a source of this for you
Here is one: https://increasinglyfunctional.com/2021/01/28/clojurescript-type-hinting-core-async-gotcha.html
Hi all, investigating migrating to shadow-cljs for our builds and in the processes of piecing together our previous workflows. Specifically, we we had one project that depended on another. Previously we would use webpack to produce a js bundle, and then include it as a :foreign-lib, telling the cljs-compiler what namespace it :provides. We could then put this bundle in in the dependency jar, and then have access to those same foreign libs in the dependent project. The shadow browser target operates on the node_modules folder. Is there some recommended approach to coordinating these kinds of transitive js dependencies with shadow?
@zalky if you want to continue using webpack I'd suggest using :js-provider :external as described here https://code.thheller.com/blog/shadow-cljs/2020/05/08/how-about-webpack-now.html#option-2-js-provider-external
Thanks @thheller for the link! Giving it a read now. I don't suppose it makes any sense to package node_modules itself into the jar file, and have shadow access it from the depedent's classpath?
Ok, just to see if I've understood the implications of your blog post in the context of a dependent project, I could try something along the lines of:
1. Configure the dependency project with :js-provider :external
2. Generate libs.js via webpack
3. Package libs.js in the dependency jar
4. Configure the dependent project with :js-provider :external
5. Include the libs.js along with the depedent's main.js
Have I got the right idea?
first of all: why webpack? do you include other non CLJS stuff or is it purely for bundling npm dependencies for use by CLJS?
@thheller, purely for bundling npm dependencies. Doesn’t have to be webpack, but before shadow it was the simplest approach to managing the npm dependencies between our two projects. Our dependant project didn't really have to worry about any npm workflows. It could just rely on the bundle to have the correct version of everything. Definitely open to other workflows that shadow may enable.
well just letting shadow-cljs handle the npm dependencies will be straightforward (well depending on which packages you use). letting webpack do that will require much more configuration
That would be ideal but would that require introducing a package.json into the dependant project and ensure all the transitive npm dependencies are installed in the dependant project?
A bit more context if it helps: we have a full-stack clojure application with backend, frontend and sass that is all bundled as a framework and deployed in different domain specific contexts. These domain specific applications extend the core one. The core app is really easy to bring into a new project as a dependency, the biggest pain point was the npm modules that the core app requires. Bundling these with webpack, and then including the bundle in the jar meant that anyone working the domain specific applications would not have to worry about npm workflows. You do have to declare your foreign libs :provides in the dependent project, but this seemed easier than having package.json track transitive dependencies and then having to manually sync npm installs.