I'm trying to import an ES module (https://github.com/otakustay/react-diff-view — via :require [react-diff-view :refer [parse Diff Hunk]]) that shows up as empty (i.e. (js/console.log react-diff-view parse Diff Hunk) gives me {__esModule: true} undefined undefined undefined). Any idea what's causing this or what could be done about it?

is it possible, (using the support for git in NPM) to rely on a git repo SHA rather than a published package?

[ I can’t find it in the book ]

Are Shadow-cljs builds intended to be deterministic? I read that the Google Closure Compiler itself is deterministic, but my builds always seem to include large-%age changes to files which haven't changed from release to release (eg cljs.core.js). Looking at the first example in a diff, the differences can be something so trivial as: var p=$CLJS.zh;this.ri=p instead of this.ri=$CLJS.zh 😕 So I'm wondering where the extra entropy in my builds is coming from!

@raymcdermott whatever npm installs will be used and I think you can use something like github:foo/bar#commit instead of a version number. whether that works entirely depends on the npm package though. most of them require a build step so using them from source-only usually doesn't work.

@mel.collins builds are not really deterministic and really can't be if you factor in DCE. any change you make may lead to something in cljs.core staying alive or being removed. :advanced output must be used as one contained unit and cannot be mixed with output from other builds.

@thheller My intent isn't to split builds in this case - the compiled JS gets committed to git (primarily to enable using the git repo as a dependency elsewhere), and it bothers me that every release has so many changes to the compiled source. Even running shadow-cljs release npm twice in a row produces different output each time, so it's definitely not (only) a DCE thing. It would be nice to have IMO, but if reproducible builds isn't a design goal for shadow-cljs then I can stop concerning myself with it!

well here it comes to definitions. reproducible of course that is a goal. 100% binary identical is not. half of the "blame" here also goes to the closure compiler so not much to do about that. the CLJS compiler and macros also use gensym quite frequently so thats also not deterministic.

Fair enough, thanks for the info

Hi everyone! I'm currently working through Dmitry Sotnikov's book on Luminus: His approach is to distinguish builds (production, development) by varying the source-paths in order to load code selectively. For ClojureScript he accomplishes this by integrating shadow-cljs with Leiningen. Since I'm using boot (and the shadow-cljs guide seems to discourage integration with lein/boot/cli anyway) I'd like to achieve the same thing using shadow-cljs separately. The guide, however, states “the source path is only specified once in the entire configuration.” So I guess there's no way to include different versions of namespaces for different builds using standalone shadow-cljs. If I want, say, three different flavors of my app with different environment settings, where would I start?

you can only do so by using lein or deps.edn. shadow-cljs.edn does not and will not support it.

I personally don't like that approach and have never used it myself

Many thanks for the quick reply! Given what I've been able to piece together on the Internet I'm not even all that surprised (or disappointed ). Seems this is more opinionated than I thought… Is there any other native way to distinguish between more environments than just :dev and :release? (I know how to set variables for these with :closure-defines, but wouldn't know how to define a third one)

first you need to differentiate between BUILD configuration and RUNTIME configuration. you are most likely talking about runtime configuration which IMHO should not be in the build config at all.

that is my approach and that is how shadow-cljs is set up basically

so I never had a need to define anything other than :dev or :release and as such is not supported

you can always use --config-merge to override stuff if you want though which sort of gets you whatever you might need with regards to :closure-defines etc

Alright, I have read that chapter in the guide… in any case: I'm much clearer now as to what's in the cards. (Actually I've never used a build tool prior to my Clojure days, so I'm still trying to figure out the best way of doing things… so far shadow-cljs is the one one I understand best…) Many thanks for your swift help on this occasion (and previous ones)…

don't get sucked into too many configuration details. most of the time simple configs are enough for even complex projects.

Thanks I'll try to keep that in mind!

Any way to ignore The required JS dependency "<npm-package>" is not available, it was required by ..., I’m porting pretty large js codebase and they seem to be not having using the code in <npm-package> ...

btw. <npm-package> is a transitive dependency somewhere, I tried to add it by hand, but that leads to another issue with incompatible react versions required by different packages

ah, nevermind, it looks like yarn did the right job and installed all npm packages from transitive dependencies, not sure why npm didn’t do that

it kinda sounds like the dependency set is unsatisfiable if trying by hand gives incompatible react versions. i wonder if npm is doing the right thing and yarn is doing a thing that is wrong but relied upon?

now, I have a different problem, shadow-cljs complains The required JS dependency "use-cannon" is not available but I’m sure it is in node_modules/use-cannon, and package.json there properly points to compiled index.js file

uhmm, I’m not familiar with npm stuff, turned out the package.json contains only module key and has no main key[1]. I renamed module to main and shadow-cljs started working as expected. Quickly googled this[2] Maybe shadow-cljs should warn and fallback to module? [1] https://github.com/pmndrs/use-cannon/blob/cf8a7482ed9eb8dfc2f39a58bec5b8027caee542/package.json#L16 [2] https://stackoverflow.com/questions/42708484/what-is-the-module-package-json-field-for