Anyone here using shadow-cljs in an ubuntu 20.04 environment under WSL2 on WIndows 10? After upgrading from WSL1 to WSL2, shadow-cljs doesn't recognize diffs in my files so it doesn't recompile. Basically hot reloading doesn't work. Force compile from the server doesn't generate new files either. Anyone know what to do to fix this?

stick with wsl1. thats a known problem on the wsl2 side, nothing shadow-cljs can do about that

https://github.com/microsoft/WSL/issues/4739

wsl1 actually is better anyways if you work on the files from the windows side anyways. network also becomes quite annoying since the wsl2 container gets its own IP and stuff. IMHO WSL1 is still better and I use that still.

I had to upgrade to WSL2 because nginx didn't work properly in WSL1. And unfortunatly I need this to work since we want dev and prod environments to be as similar as possible. I will try to move my projects to the linux filesystem and see if that maybe helps.

pretty sure that doesn't help but let me know if it does

I use shadow-cljs in wsl2 ubuntu

At least I thought that's what I am doing.

But yeah, I do everything from inside the wsl, even the editor runs from there (using X, kitty, nvim or alternatively vscode with their very good wsl support)

@thheller I fixed the issue. Changes to the file now does trigger recompile. 1. I git cloned all my repositories to /home/user/src in the linux filesystem. 2. I mapped the linux filesystem network folder to a normal drive foler. Follow this short guide: https://support.microsoft.com/en-us/windows/map-a-network-drive-in-windows-10-29ce55d1-34e3-a7e2-4801-131475f9557d 3. Then I opened my repository folder with Intellij (also works with VS Code). 4. Make changes in intellij to the file -> shadow-cljs compiles and nginx serves the new file. Probably works without nginx too.

BTW. The compilation time seems to be faster too now. But this is just a feeling I have now, no hard data behidn that statement. 😛

thanks for the info

@thheller I notice that shadow-cljs fails to connect to the websocket when the server is serving the files over 127.0.0.1 instead of localhost. Is it possible to perhaps have the reconnection logic try both? I know it is possible to specify the host in the config file, so it is a minor issue. I just think it might lead to a bit of confusion for some?

thats not something that is fixable I think. I mean if you connect to 127.0.0.1 that would need to map to the container ip

dunno how that is handled for localhost, maybe thats another adapter or has some forwarding logic

by default the browser websocket connect logic will use the host you used to open the page

if you do nginx, you have to forward the ports imho

and the reason it works with localhost I think is some OS level magic related to WSL

tell me if I am wrong 🙂

Ah really?

server {
    listen 127.0.0.1:80;
    include /home/dev/src/locations.conf;
}

but do you have something extra on the windows side?

last time I checked it didn't automagically forward ports but it has been a while

otherwise the 9630 port should also just work

I checked and I have nothing about the 9630 anywhere and it works

Nothing special on the windows side. The locations is just:

location /client/ {
    alias /home/dev/src/client/resources/public/;
}

the ws server and webui

but obviously not with 127.0.0.1

neat, guess I should test that again. dealing with network ports was very annoying last time I tried

Yeah

:http {:port 9630
       :host "127.0.0.1"}

do you absolutely need the 127.0.0.1?

NAME            STATE           VERSION
* Ubuntu-20.04    Running         2

Hehe I don't think so. I will check things on my side.

have you tried searching for shadow-cljs in the WSL github issues?

No, I haven't 😮

because this had some TIL for me https://github.com/microsoft/WSL/issues/4851

a quote, because sometimes I am surprised that a vague memory turns out to be resonant > Tag needs-investigation in the sense this needs a ruling on whether the current (circa 19640) behavior of the magic WSL localhost tunnel is by-design (by fiat), or should route ipv4 `127.0.0.1` to ipv6 `::1` automatically like it does on Linux.

shadow-cljs defaults to binding to whatever address is returned by localhost

oh wait no, it defaults to 0.0.0.0

but you can control this via the :http :host

I haven't changed anything like this. I set a dev-http and an nrepl port

I upgraded to 2.12.5 and get the following when running a watch:

[2021-04-21 10:03:22.948 - WARNING] :shadow.cljs.devtools.server/nrepl-ex
Note: The following stack trace applies to the reader or compiler, your code was not executed.
CompilerException Syntax error compiling at (clojure/tools/reader/edn.clj:75:9). #:clojure.error{:phase :compile-syntax-check, :line 75, :column 9, :source "clojure/tools/reader/edn.clj"}
	clojure.lang.Compiler.analyze (Compiler.java:6808)
	clojure.lang.Compiler.analyze (Compiler.java:6745)
	clojure.lang.Compiler$InvokeExpr.parse (Compiler.java:3820)
	clojure.lang.Compiler.analyzeSeq (Compiler.java:7109)
	clojure.lang.Compiler.analyze (Compiler.java:6789)
	clojure.lang.Compiler.analyze (Compiler.java:6745)
	clojure.lang.Compiler$IfExpr$Parser.parse (Compiler.java:2837)
	clojure.lang.Compiler.analyzeSeq (Compiler.java:7107)
	clojure.lang.Compiler.analyze (Compiler.java:6789)
	clojure.lang.Compiler.analyze (Compiler.java:6745)
	clojure.lang.Compiler$BodyExpr$Parser.parse (Compiler.java:6120)
	clojure.lang.Compiler$LetExpr$Parser.parse (Compiler.java:6436)
Caused by:
RuntimeException No such var: err/throw-no-dispatch
	clojure.lang.Util.runtimeException (Util.java:221)
	clojure.lang.Compiler.resolveIn (Compiler.java:7388)
	clojure.lang.Compiler.resolve (Compiler.java:7358)
	clojure.lang.Compiler.analyzeSymbol (Compiler.java:7319)
	clojure.lang.Compiler.analyze (Compiler.java:6768)
	clojure.lang.Compiler.analyze (Compiler.java:6745)

wrong tools.reader version

lein deps :tree shows that shadow-cljs depends on org.clojure/tools.reader "1.1.3.1"

and AFAICT that's the only version present

looking at the source on github, throw-no-dispatch exists

if nothing else shows up on the deps tree depending on it, how do I know what's pulling in the wrong tools.reader version?

do you use profiles? did you active those that would be activated when starting shadow-cljs?

try lein repl (with profiles if needed) and ( "clojure/tools/reader/edn.clj")

I don't use any profiles

user=> ( "clojure/tools/reader/edn.clj")
#object[java.net.URL 0x440076b6 "jar:file:/Users/lilactown/.m2/repository/org/clojure/tools.reader/1.1.3.1/tools.reader-1.1.3.1.jar!/clojure/tools/reader/edn.clj"]

thats the wrong version? https://clojars.org/thheller/shadow-cljs

org.clojure/tools.reader 1.3.3

where did you get the impression that shadow-cljs uses 1.1.3.1?

lein deps :tree shows the following output:

[thheller/shadow-cljs "2.12.5" :exclusions [[fipp] [edn-query-language/eql] [com.wsscode/pathom]]]
   [cider/piggieback "0.5.0" :exclusions [[org.clojure/clojure] [org.clojure/clojurescript] [nrepl]]]
     [javax.xml.bind/jaxb-api "2.3.1"]
       [javax.activation/javax.activation-api "1.2.0"]
   [com.bhauman/cljs-test-display "0.1.1"]
   [com.google.javascript/closure-compiler-unshaded "v20210302"]
   [expound "0.8.5"]
   [hiccup "1.0.5"]
   [org.clojure/clojure "1.10.1"]
     [org.clojure/core.specs.alpha "0.2.44"]
     [org.clojure/spec.alpha "0.2.176"]
   [org.clojure/clojurescript "1.10.844" :exclusions [[com.google.javascript/closure-compiler-unshaded] [org.clojure/google-closure-library] [org.clojure/google-closure-library-third-party]]]
   [org.clojure/core.async "0.3.465"]
     [org.clojure/tools.analyzer.jvm "0.7.2"]
       [org.clojure/core.memoize "0.5.9"]
       [org.clojure/tools.analyzer "0.6.9"]
       [org.ow2.asm/asm-all "4.2"]
   [org.clojure/data.json "1.0.0"]
   [org.clojure/google-closure-library-third-party "0.0-20201211-3e6c510d"]
   [org.clojure/google-closure-library "0.0-20201211-3e6c510d"]
   [org.clojure/tools.cli "1.0.194"]
   [org.clojure/tools.reader "1.1.3.1"]

I would expect tools.reader to appear elsewhere in the tree as well if something else depended on it?

odd

do you have it in managed-dependencies or so?

core.async is also the very wrong version?

😐 yes

I'm in a monorepo that uses lein-monolith, and both tools.reader and core.async are in managed-dependencies in the root project.clj

I didn't even know about managed-dependencies

thanks for the help

I am trying to compile a serverless project with shadows-cljs which it was working until i add mongodb library from node. it seems the compilation process skip some dependency requiered by mongodb import. Someone have fall down into this before?

not enough info to comment. what is the actual problem?

can shadow hot-reload css files that are @imported from the top-level css file, which is the only one explicitly included in the html?