hm... and now I can't get rid of the wasm.js error even if I rollback to 2.25.2. This is weird

the plot thickens: cleaning up .shadow-cljs doesn't help (I know, I know, it should never be done anyway)... I'm still stuck with the error in 2.25.2... but, if I revert to 2.24.1 the error goes away, and I can then upgrade to 2.25.2 again (and if I stay monolithic go all the way up to 2.25.7). Now the question is, does shadow-cljs (or the closure compiler underneath) maintain any form of state between compilations that could justify this behaviour?

all state/cache is kept in .shadow-cljs/builds, so if you wiped that and restarted shadow-cljs all state is gone. changing shadow-cljs versions also automatically invalidates all the caches

my main suspect is always not actually shadow-cljs but npm

do you keep a proper package-lock.json file, or is that gitignored or deleted?

without a lockfile it is pretty much random which sort of npm package setup you get

nothing related to :par-compile has changed in many years, so I'm not sure what would cause that

about the .wasm error, what do you do in line 49 in that file 😛

the :par-compile thing was reported a few days ago, so I'm curious https://clojurians.slack.com/archives/C6N245JGG/p1696419053913689

I don't have any guess though, but willing to help you diagnose. normally the exception thrown should give enough info to tell whats going on

well I have one guess .. that is macros. if you use any kind of weird macros, those that keep state outside the compilation in a atom somewhere, then shadow-cljs doesn't know about it and all cache guarantees go out the window

👀

hm, interesting. I don't have many macros, but I do have one that I use everywhere to log, there shouldn't be much state there but let me check

still waiting for #{app.events.icloud app.fx.dom app.fx.icloud} means that compilation of those namespaces is preventing the others from getting compiled

the wasm.js error is very odd: I actually don't have anything in line 49 of that file, I thought that maybe it's looking at a sourcemap. Anyway, one problem at a time, I'll go check those macros

so check those namespaces first 😛

will do :saluting_face:

line numbers may be off by 1 or 2, so check those too

yeah, that file is all assignments, the closest to that line all look like:

NodeType[NodeType["ICE_TABLE_NODE"] = 40] = "ICE_TABLE_NODE";
    NodeType[NodeType["ICE_TABLE_PIPE_MARKER_NODE"] = 41] = "ICE_TABLE_PIPE_MARKER_NODE";
    NodeType[NodeType["ICE_TABLE_DELIMITER_MARKER_NODE"] = 42] = "ICE_TABLE_DELIMITER_MARKER_NODE";

but I'll focus on those macros now

@U05224H0W right... found the issue with par-compile: I have no idea how it got there, but I had one namespace :require itself 😊 so that's solved now

(the amazing thing is how it manage to work before up till 2.25.2! 😄 )

hmm that still shouldn't be legal.

indeed

as in I mean that should throw an error

yes I understand. Maybe it doesn't because it happens in the web worker module instead of the main one?

hmm nope, just accepted as is. I will add a check for that

this is the relevant part of shadow-cljs.edn, in case it can help you contextualise:

:builds
 {:app
  {:target :browser

   :modules
   {:shared
    {:entries []}

    :app
    {:init-fn app.core/init
     :preloads [day8.re-frame-10x.preload]
     :depends-on #{:shared}}

    :docker
    {:init-fn app.docker/init
     :depends-on #{:shared}
     :web-worker true}}

   ;; :module-hash-names 8
   :build-hooks
   [(shadow.hooks/index)
    (shadow.hooks/svg)
    (shadow.hooks/robots)]

   :compiler-options
   {:output-feature-set :es6
    :optimizations :advanced
    :infer-externs :auto}

   :js-options {:js-provider :shadow}

   :devtools {:loader-mode :eval}

doens't matter at all. just a namespace requiring itself blows up in any context

🤷 😄

now I can joyfully turn to the wasm.js issue. Fun!

make sure you are looking at the actual node_modules/my_cool_webassembly_component/wasm.js, not the file that may produce this

yeah that's what I though too. I'm using yarn and it does have a habit of keeping a cache of the modules...

thanks for all the precious advice!

by serve you mean http server?

https://shadow-cljs.github.io/docs/UsersGuide.html#dev-http :dev-http takes a map, so you just add a second map entry

:dev-http {8000 "public" 8001 "foo"}

In the watcher command, both builds are specified:

npx shadow-cljs -d cider/cider-nrepl:0.28.5 watch :app :portfolio

{:source-paths ["src" "portfolio"]

 :dependencies [[binaryage/devtools "1.0.7"]
                [reagent "1.2.0"]
                [no.cjohansen/portfolio "2023.07.15"]
                [fork "2.4.3"]]

 :dev-http     {9800 ["public" "classpath:public"]
                8080 "public"}

 :builds       {:app
                {:target     :browser
                 :output-dir "public/js"
                 :asset-path "/js"
                 :modules    {:main {:init-fn forked.core/init}}}

                :portfolio
                {:target  :browser
                 :output-dir "public/js"
                 :asset-path "/js"
                 :modules {:main {:init-fn portfolio/init}}}}}

shadow-cljs doesn't care what you serve where. it all depends on where you put your JS files

in general you should not use the same :output-dir for two builds

Gotcha, that's where I went astray.

say you put :output-dir "public/portfolio" in one config

then you only need one server and access the /portfolio/main.js in the one html and /js/main.js in the other

also need to adjust :asset-path "/portfolio" accordingly

Thanks @U05224H0W! I've set it up as follows, which yields the desired result:

{...

 :dev-http     {9800 {:roots            ["public" "classpath:public"]
                      :push-state/index "portfolio.html"}

                8080 "public"}

 :builds       {:app
                {:target     :browser
                 :output-dir "public/js"
                 :asset-path "/js"
                 :modules    {:main {:init-fn forked.core/init}}}

                :portfolio
                {:target     :browser
                 :output-dir "public/portfolio"
                 :asset-path "/portfolio"
                 :modules    {:main {:init-fn portfolio/init}}}}}

I'd personally just use a different folder altogether, but that is up to you.

{...

 :dev-http {9800 ["portfolio" "classpath:public"]
            8080 "public"}

 :builds {:app
          {:target :browser
           :output-dir "public/js"
           :modules {:main {:init-fn forked.core/init}}}

          :portfolio
          {:target :browser
           :output-dir "portfolio/js"
           :modules {:main {:init-fn portfolio/init}}}}}

so everything portfolio related goes into the portfolio dir, the rest is in public