Hi, there seems to be a problem when using both Web Workers and Module hash names. I have the following shadow-cljs.edn:

{:target            :browser
                         :output-dir        "resources/public/js/compiled"
                         :asset-path        "/js/compiled"
                         :module-hash-names true
                         :modules           {:shared {:entries []}
                                             :main   {:init-fn    orgpad.client.core/init
                                                      :depends-on #{:shared}}
                                             :layout {:entries    [orgpad.client.layout.webworker.core]
                                                      :depends-on #{:shared}
                                                      :web-worker true}}
                         :compiler-options  {:infer-externs :auto}
                         :devtools          {:after-load  orgpad.client.core/mount-root
                                             :before-load orgpad.client.core/stop-web-workers
                                             :watch-dir   "resources/public"}}

When I run the release version, I get the following error: Uncaught DOMException: Failed to execute 'importScripts' on 'WorkerGlobalScope': The script at 'https://reorgpad.herokuapp.com/js/compiled/shared.js' failed to load. at https://reorgpad.herokuapp.com/js/compiled/layout.2C8E9F9F47AB1338B6ABF2B8D798D22B.js:1:1

Where the actual name is shared.0A18608384A13578DC44FDC090CF8CC5.js

yes :module-hash-names doesn't work when using workers

that is known and can't really be fixed 😛

adding the hash of something to a file changes its hash

adding it also messes up the source map

so kinda no idea how to do this cleanly

I've been thinking about adding something like shadow-cljs release app --config-merge '{:module-fingerprint "foo"}'

so that would produce shared.foo.js and layout.foo.js

so in theory you could provide a version number or git sha or whatever

not really using a hash

@pavel.klavik did you report the source maps not working or was that someone else? in any case I reproduced that myself and :devtools {:loader-mode :script} seems to fix that

Couldn't the hash problem be solved by first compiling shared.js, this would produce the hash, then add it into layout.js and then computing hash for it?

its all compiled in one go by the closure compiler

I guess it could prepend the importScripts after the compilation though

The source maps are fixed by what you suggested, thx.

dunno the whole hash-names thing isn't solved very cleanly currently

but the web-worker case should be fixable I think. please open an issue so I don't forget

sure

the stuff with module-fingerprint does not work yet?

no its just an idea

but I like it more than all the hashing stuff

since you don't really get reusable files anyways between compiles

seems better to use something a human can actually recognize (eg. version number or even using the git sha to lookup commits)

makes sense, both solutions would be fine, at least as an alternative

of course, I can imagine that I will make commits only changing the server (which I have in the same repository) and it will change the client js name, but it does not seem like a big problem

well then you shouldn't trigger a CLJS build in the first place probably 😛

you'll very likely get different hashes currently already

ya, currently it is not a big problem if the filename changes more often, but it is a big problem if someone uses old client version due to caches

indeed