Fork me on GitHub
Pavel Klavík23:12:49

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"}}

Pavel Klavík23:12:23

When I run the release version, I get the following error: Uncaught DOMException: Failed to execute 'importScripts' on 'WorkerGlobalScope': The script at '' failed to load. at

Pavel Klavík23:12:09

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 and


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

Pavel Klavík23:12:04

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

Pavel Klavík23:12:25

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

Pavel Klavík23:12:59

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)

Pavel Klavík23:12:15

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

Pavel Klavík23:12:01

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

Pavel Klavík23:12:41

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