Fork me on GitHub

I’m using the re-frame template where shadow-cljs is integrated within lein’s project.clj. Anytime I run lein dev something is running npm install --save --save-exact [email protected] [email protected] which is deleting all my deps I added in package.json How can I install an npm dependency without it getting deleted?


dont use lein-shadow is my recommendation


@thheller Ah thanks. I’ll use shadow-cljs.edn

Chris McCormick12:05:29

hello, i have run into a weird situation. when i run my shadow-cljs compiled SPA on iOS 9 Safari, the first time the page loads it doesn't run the main.js . if i change the code it live-reloads it successfully. i narrowed the problem down to a single dependency, which if i eliminate it, this problem goes away. has anybody ever seen anything like this and have any suggestions?

Chris McCormick12:05:22

i seem to have solved this with a very small wrapper called zxingwrap.js:

module.exports = {
  "lib": window["RTCPeerConnection"] ? require("@zxing/library") : null,
when i do this and then require ["zxingwrap" :as zx] i can then use zx/lib.InstanceName and it works great on both platforms. Very curious. Any ideas as to why this works I would love to hear them!


@chris358 impossible to tell without more info. you should get an error when you load the page. that error will tell you whats wrong. just look at the browser console?

Chris McCormick02:05:18

unfortunately i cannot look at the browser console on this device. i tried catching window.onerror but got nothing.


can't you use safari to debug remotely?

Chris McCormick06:05:15

i do not have a mac osx computer

Chris McCormick06:05:51

all i have is a safari 9 tablet and the greatest software development tooling known to humankind

Chris McCormick06:05:29

it's ok, this workaround is fine for now and nobody else in the world has a safari 9 ipad


hmm. yeah thats rather old. you can try :compiler-options {:imul-js-fix true} in your build config


there used to be a rather old iOS bug with Math.imul. thought nobody was using version that was affected by that anymore

Chris McCormick06:05:11

thank you, will try this!


don't think 9 is affected either but might be

Matt Jacobus16:05:27

Hi all. I’m having trouble getting devcards working with shadow-cljs and wondering what I’m doing wrong. I’m a novice, so apologies if this is obvious to others. I’ve added devcards and shadow-cljsjs to my deps.edn, but the build continues to complain failed to load devcards.system.js ReferenceError: React is not defined. Is there something obvious I’m missing? Thanks in advance!


@mjacobus for some reason devcards does not declare its dependency on React so in the namespace where you require devcards first require cljsjs.react


(:require [cljsjs.react] [devcards.core :as dc] ...) or so


don't need to add shadow-cljsjs manually btw. shadow-cljs already depends on it so it will be available regardless.

Matt Jacobus16:05:32

Thanks! I’ve been wrestling with that for a while. Really appreciate the quick reply. Very nice of you.

Matt Jacobus16:05:51

It looks like same situation with ReactDOM.


yeah, I think thats cljsjs.react.dom

Matt Jacobus16:05:31

Yes, thank again.


I get the following error when I start shadow-cljs. I get it for the two versions that I have tried: 2.8.58 and the latest one. Any hint? Syntax error (NoSuchFieldException) compiling . at (shadow/build/closure.clj:68:5). getRegisteredGroups


dependency conflict


when using project.clj/deps.edn you must ensure that you get the correct shadow-cljs + clojurescript + closure-compiler versions


Thanks. I’ll check my versions then.


@thheller Sorry but I have tried everything and I still get the error. I moved my code to the latest version of shadow and clojurescript: org.clojure/clojurescript {:mvn/version "1.10.758"} thheller/shadow-cljs {:mvn/version "2.9.2"}


I tried with removing ‘node_modules’ but I get the same error.


node_modules is not involved in this


check clj -Stree (with the aliases you need)


you should be getting [ "v20200504"]?


Hmm, right, I get v20180805


This might be the problem: com.fulcrologic/fulcro 3.2.3 cljsjs/react-dom 16.13.0-0 com.cognitect/transit-cljs 0.8.256 com.cognitect/transit-js 0.8.846 org.clojure/clojurescript 1.10.597 org.clojure/google-closure-library 0.0-20170809-b9c14c6b org.clojure/google-closure-library-third-party 0.0-20170809-b9c14c6b org.mozilla/rhino 1.7R5 v20180805


you also shouldn't be getting that older CLJS version?


are you sure you have the dependencies declared in the correct spot? with the correct profiles?


ooops, really sorry, I used the wrong alias. I indeed have the right closure version: v20200504


But the same error is still there.


well do you have shadow-cljs configured to use those aliases?


if yes then there shouldn't be a problem?


Unless I am missing something, I think so. My shadow-cljs.edn starts as follows: {:deps {:aliases [:dev]}


And in deps.edn I have: :dev {:extra-paths ["src/test" "src/dev" "src/workspaces"] :jvm-opts ["-XX:-OmitStackTraceInFastThrow"] :extra-deps {org.clojure/clojurescript {:mvn/version "1.10.758"} thheller/shadow-cljs {:mvn/version "2.9.2"}


so clj -A:dev -Stree does give you all the correct versions?


thheller/shadow-cljs 2.9.2 org.clojure/clojurescript 1.10.758

grischoun18:05:31 v20200504


hmm then I don't really know? which clojure version do you have configured?


that should be fine. The error you see is 100% caused by an incorrect version on the classpath. maybe some old AOT classes or something?


ok, thanks anyway for your help. I’ll try to investigate more, especially with regard to the classpath then.


hey I’m trying to fight the dragon that is storybook today


Cannot assign to read only property 'exports' of object '#<Object>'
    at Module.<anonymous> (main.1d63ab3fd8c0aad6bcda.bundle.js:5638)
    at Module../out/cljs_env.js (main.1d63ab3fd8c0aad6bcda.bundle.js:5639)
    at __webpack_require__ (runtime~main.1d63ab3fd8c0aad6bcda.bundle.js:849)
run into this when using :npm-module with webpack before?


looks like it’s some babel config bs. ugh


was a matter of telling babel to emit commonjs modules I guess


:npm-module already emits commonjs, don't need babel?


I was able to get an example shadow-cljs + storybook v5 project up and running here:


I could fix the export issues so that only exported things are visible in dev as well


feel free to open an issue for that if you feel thats useful


@thheller it might be worthwhile highlighting that shadow-cljs is sensitive to things like clojurescript / closure-compiler versions? Just looking at the github readme I don’t see anything obviously there that prompts me to dig in and work it out. I only really clocked it when you told me when I was having problems =)…


doing that right now. tired of explaining that almost daily 😛


Perhaps a warning + link to a section in the user guide (if that exists) talking through it in more detail?


Sorry, it’s just most libs you just require and go, so it’s not something the average clojure dev knows to look for =)…


well nobody would have to if they'd just use shadow-cljs as intended. 😛


but everyone wants to stick with lein or deps.edn so you shadow-cljs can't fix those issues for you


Is there a way to use git deps and/or private repos with shadow without deps.edn? IIRC that was the reason we switched to deps


for that you need deps.edn for now yes

👍 4

I think that would be useful, as I can imagine wanting to put things like fixtures inside of the story as well


I ran into one other puzzling thing where occasionally webpack would throw an error about reloading goog.math.Long at runtime


reloading seemed to fix it


I believe it was due to starting the shadow-cljs compile process after storybook. I would guess this was causing a reload of all of cljs.core + google closure library


@lilactown just released 2.9.3. storybook should no longer see non-exported defs

❤️ 4

I’ll take it for a spin in a bit 🙂

David Pham21:05:39

Is there any bug with core.async? I am using 2.9.2 and the latest core.async version, for nodejs and the server complain that take! is not defined.

David Pham21:05:35

(defn take! [state blk ^not-native c]
TypeError: c.cljs$core$async$impl$protocols$ReadPort$take_BANG_$arity$2 is not a function

David Pham21:05:39

For the error message...


are you calling take! somewhere with something that is not a channel?

David Pham21:05:40

I use it on a sliding buffer?


a buffer is not a channel?

David Pham21:05:55

guess coding at 23:15 is not optimal 🙂

David Pham21:05:17

@thheller thanks a lot, I would have kept looking for the solution for hours.

👍 4
David Pham21:05:50

How did you know it would be that mistake by the way?


well the ^not-native hint makes the compiler use the "direct" call to the take! protocol impl instead of going through the dispatch method


so the error clearly points at something not implementing that protocol


^not-native is a compiler optimization. it gains a bit of performance but loses a better error message in the process 😉


new thing I added in the new release

$ shadow-cljs server
shadow-cljs - config: /mnt/c/Users/thheller/code/tmp/error-test/shadow-cljs.edn
shadow-cljs - starting via "clojure"
--- SHADOW-CLJS FAILED TO LOAD! ----------------------

This is most commonly caused by a dependency conflict.
When using deps.edn or project.clj you must ensure that all
required dependencies are provided with the correct version.

You are using shadow-cljs version: 2.9.3

The important dependencies are:

  org.clojure/clojure "1.10.1"
  org.clojure/clojurescript "1.10.758" "v20200504"

Please verify that you are loading these versions.
You can find all required dependencies here:


Please refer to the Guide for more information:



The error encountered was:

Syntax error compiling at (shadow/cljs/devtools/api.clj:1:1).
        at clojure.lang.Compiler.load(
        at clojure.lang.RT.loadResourceScript(
        at clojure.lang.RT.loadResourceScript(
        at clojure.lang.RT.load( ...

❤️ 4

hopefully provides some help when using the wrong dependency versions via deps.edn or project.clj


still writing the guide part though

David Pham21:05:12

so if we do not specify tthe dependencies, we should be fine?


message only appears when it fails to load the code


which usually only happens with dependency conflicts