Clojurians Log v2
helix
Right. If you’re just analysing and not compiling, then you don’t need the foreign libs (generally, not sure if that’s always true). Here’s a change that Thomas made to codox, which was the original code cljdoc was based on: https://gist.github.com/thheller/5bc57a7571cf83fd12190ab7165cdb46#file-codox-cljs-clj-L87-L91
So my understanding is that the code required to populate the js libs in the compiler state from node_modules is not called when using the analyser API, only when using the build API.
One potential problem (that doesn't affect helix) is that it's perfectly valid to require [react]
For my purposes, that shouldn’t affect analysis, I just need the analysis not to fail.
The external deps are hardly ever used in e.g. calculating var metadata.
No string required
I thought I had to use strings. Damn I am still such a newb, now I have to go back and read this again.
You do (did?) in shadow, but not in clojurescript.
isn't shadow just a builder for cljs+js?
afaik it doesn't add new functionality, so it would be new information if it takes away existing ones
haven't read it yet, it's saturday noon, I don't want to work yet
It does add new functionality. I believe it is a custom compiler, using the analysis data from clojurescript.
I think there's a terminology gap. Maybe shadow technically is a build tool that uses the analysis differently? Maybe :default isn't syntax, but something else? I'm not sure.
You can do things in shadow requires which aren't possible with a normal clojurescript main build. If you use those features in a library, then your library users must use shadow too.
so strings are needed because npm module names are not simple symbols, they have weird characters in them. This is something I am very curious how this approach: https://clojurescript.org/guides/webpack solves.
https://code.thheller.com/blog/shadow-cljs/2019/03/01/what-shadow-cljs-is-and-isnt.html
This is not true > It does not introduce new “syntax” for require I can think of two instances (:default and "./") where there's differences.
> It interfaces directly with cljs.analyzer and cljs.compiler and does some minor modifications since there are no “official” hooks into the namespace aliasing required for npm dependencies and such. Compilation of actual CLJS is unchanged and only the parts that involve interop with npm are changed. I'm very careful about introducing new stuff and want to remain 100% compatible, any new features are opt-in and have “fallbacks”.
This is really the key thing, it adds stuff, it's not comparable to Figwheel.
Yeah, but then you must understand how confusing this is to me. Are you saying that the creator of this tool is either lying or mistaken? Not sure which is worse in this case 🙂
Figwheel is also a build tool? Before shadow-cljs I couldn't use clojurescript, mostly because of the impossibility to use npm modules (and since clojurescript and clojure are much more different from each other than js in the browser and node.js, this meant that while a js module was usable anywhere, you couldn't really use the same libraries both on the frontend and on the backend in cljs/cljs). I am stating this because I tried many many many times, first with lein, then with boot, to have a usable dev env, but it never worked out. Shadow-cljs was and still is the only way I can use clojure for production. It never occurred to me to compare it to figwheel before.