Fork me on GitHub
#shadow-cljs
<
2021-10-16
>
cjmurphy02:10:04

I'm getting the message SHADOW-CLJS FAILED TO LOAD! which goes on with "You are using shadow-cljs version: 2.11.4". The problem is that I shouldn't be on that version. These are the commands that let to the error:

cjmurphy02:10:34

yarn remove shadow-cljs
yarn add --dev [email protected]
yarn shadow-cljs server
Notice should be at 24 now, not 4.

cjmurphy02:10:56

My problem is that the upgrade doesn't seem to be working. Could I have a global version of shadow that is overriding this? By the way going to the latest version (2.15.12) by leaving out the @ and what comes after gives the same result. I've even tried getting rid of cache directories, but after upgrading, no matter to which version, always get "You are using shadow-cljs version: 2.11.4".

Apple02:10:47

could shadow have been installed globally?

Apple02:10:52

previously

Apple02:10:03

find / 2>/dev/null | grep shadow

cjmurphy02:10:01

Every result from the command find / -name shadow-cljs 2>/dev/null ends up being under /home/chris. I'm not even sure what a global install of shadow would look like. I'll do some research in the docs, that will hopefully include how to get rid of the global install. (As it seems like the concept exists!).

cjmurphy02:10:20

Looking promising. yarn global remove shadow-cljs said it worked.

cjmurphy03:10:55

Nope. Still says "You are using shadow-cljs version: 2.11.4", when I want it to say "You are using shadow-cljs version: 2.11.24". (I'm just moving the version on a little bit to diagnose the upgrading problem).

Apple03:10:15

$ ls -al /usr/bin/shadow-cljs 
lrwxrwxrwx 1 root root 45 Oct 15 22:43 /usr/bin/shadow-cljs -> ../lib/node_modules/shadow-cljs/cli/runner.js*

Apple03:10:54

-name shadow-cljs is probably fine to go through the system

Apple03:10:43

echo $PATH what do you have

cjmurphy03:10:28

/home/chris/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl:/var/lib/snapd/snap/bin:/home/chris/.nvm/versions/node/v16.3.0/bin/

cjmurphy04:10:20

Running yarn shadow-cljs info returns the correct version:

=== Version
jar:            2.11.24
cli:            2.11.24
deps:           1.3.2
config-version: 2.11.24

cjmurphy04:10:35

Hmm - just noticed is in deps.edn as 2.11.4, so that's where it is picking up the wrong version.

cjmurphy05:10:47

Yeah :face_palm:. If it could just be defined in one place that would of course make it 'more full-proof'.

thheller06:10:41

@U0D5RN0S1 yeah the package.json version is only used if you actually only use shadow-cljs.edn. if you use deps or lein the version needs to be managed there. that is quite intentional since "magic" injection doesn't work and only causes issues (eg. tools not recognizing it)

cjmurphy06:10:37

On another project you encouraged me to use shadow-cljs.edn for all cljs only deps, to get rid of a dependency conflict (something Datomic needed, forget what). So I might convert to that way here too. Then perhaps I can get rid of the shadow-cljs mention in deps.edn? If so then that's another win for only using shadow-cljs.edn.

thheller06:10:30

that is entirely your choice. many people prefer to manage dependencies via deps.edn or project.clj

thheller06:10:42

tools such as Cursive don't support shadow-cljs.edn so that is one reason for many to use deps.edn instead

cjmurphy07:10:57

Good news. Seems like that's the best way. But I think the documentation does lead people towards using deps.edn, just by the order of explanations. I use Cursive but surely shadow-cljs.edn can just be a text file for me.

thheller07:10:41

its not about editing shadow-cljs.edn, that works fine but Cursive doesn't recognize dependencies in it

thheller07:10:12

so it won't find dependencies when you edit your code and display these red squigly lines for code it doesn't know about

cjmurphy07:10:15

I see. I didn't notice the problem in the other project. I'll still convert and see how it works out. Thanks. I'll stick with shadow-cljs.edn till this gets answered: https://github.com/cursive-ide/cursive/issues/1804#issuecomment-314916994. Regardless the fix does seem a long way away.

geraldodev14:10:37

@p-himik Hi, have you been able to solve the "`_system.keyframes is not a function" . I'm getting this too with material-ui 5 and don't know what is the root cause.`

thheller14:10:37

as a temporary workaround/fix try setting :js-options {:entry-keys ["module" "browser" "main"]} in your build config. otherwise the code doesn't seem to be rewritten properly due to a bug in GCC

😀 1
👀 1
Benjamin17:10:57

in cider repl I get this

No available JS runtime.
See 
I also saw it working once though. What can go wrong? Cider also deosn't seem to connect my apps buffers with the repl

chaos18:10:43

Hi, you most probably need to load your app on the browser for the REPL to connect to (via the shadow server). There should be an *nrepl-server xxx :localhost* buffer in emacs telling you the address of the development server to connect to in your browser for loading the js runtime. You should see something like shadow-cljs - server version: 2.15.12 running at if you are running the browser-repl special build or shadow-cljs - HTTP server available at if you have declared a :dev-http server in shadow-cljs.edn.

Benjamin07:10:17

shadow-cljs - server version: 2.10.22 running at 
yea I opened this in the browser and now it works. Not sure if I also need to click compile there once? Either I was daft about it or the user guide could be more explicit about how to have the parts. (like with a warning > you should connect these 2 things or sth) shouldn't it say it here as well because I did the steps and then was stuck https://shadow-cljs.github.io/docs/UsersGuide.html#cider but yea thanks a lot 🙂 🎉

chaos07:10:22

Didn't cider prompt you to connect to that address with a Visit in a browser? (y or n) message?

thheller08:10:35

you do not need to open the thing on 9630 for the REPL to work. just your code needs to be loaded somewhere. I don't know why cider is even offering to open that

chaos11:10:05

It appears that cider will prompt the user to open on the default browser the server configured in :dev-http or the url when no :dev-http entry is configured in shadow-cljs.edn; If the user selects to run the browser-repl, then cider will also open, without prompting, in the default browser. Thus cider will make an effort to open the user code/browser-repl on the default browser hence loading the "js runtime".