I'm loading the modules via a combination of shadow.lazy and shadow.loadable and specifying the modules in shadow-cljs.edn Our main client.js bundle is cachebusted via appending a client.js?<GIT_SHA>, but the lazy-loaded modules are referenced by only their <module_name>.cljs without a hash. Based on what you described above, the issue could've been a result of the updated client.cljs?<GIT_SHA> bundle loading cached, out-of-date modules (due to browser cache). Is that right? I don't think we're currently setting any cache-related headers. Sounds like we can either modify those or utilize :module-hash-names . Thanks!

:module-hash-names is the safest option yeah. you should look into setting proper headers as well though. never hurts, especially with :module-hash-names you only get the full benefit with proper headers

Say a client has loaded version A of the app, and we deploy/release version B. We replace the module hash names on the server with those from version B. We prompt the user to update their version of the app by refreshing the page -- however, they sometimes ignore this If they continue browsing with version A of the app, version A continues to attempt to load A-bundled modules. Since we've replaced those files in the server, would you expect requests for version A hashed modules to fail? Since the hashes are contained in the file names themselves, rather than appended as a query string parameter, those resources for A need to exist, otherwise those requests will fail. Am I understanding that right? How do folks usually work around this? Do they keep older deployed versions of files on the server? Am I missing something fundamental about caching?

I have 5 years or so of :module-hash-names builds still live on my server

I'm not deleting them ever basically

this is much better than the alternative of ending up with 2 separate versions of builds loaded at the same time. there is a very slim chance they are actually compatible

Great, thanks so much for confirming that piece. Makes sense!

Is there an option that tells shadow-cljs to append module-hash-names builds but not delete them? I recall the build process replacing the files each time, but I will double-check this

Probably it'll have to replace the manifest each time but want to keep keep the module-hash-names files themselves

it doesn't delete or replace the hashed files if the hash changed

it'll replace the manifest yes but thats what you want

Shadow-Cljs 2.17.4

it is not. probably just a version conflict on tools.reader

should be [org.clojure/tools.reader "1.3.6"]

Yeah, as always you're right.

$ lein run -m shadow.cljs.devtools.cli compile app
WARNING: boolean? already refers to: #'clojure.core/boolean? in namespace: clojure.core.typed.contract-utils, being replaced by: #'clojure.core.typed.contract-utils/boolean?
2022-02-23 16:28:48,959 [main] DEBUG org.jboss.logging - Logging Provider: org.jboss.logging.Slf4jLoggerProvider 
[:app] Compiling ...
The required namespace "project.core" is not available.
"project/core.clj" was found on the classpath. Should this be a .cljs file?

but from command line:

$ npx shadow-cljs compile app
shadow-cljs - config: /path/to/project/shadow-cljs.edn
WARNING: boolean? already refers to: #'clojure.core/boolean? in namespace: clojure.core.typed.contract-utils, being replaced by: #'clojure.core.typed.contract-utils/boolean?
16:20:38.929 [main] DEBUG org.jboss.logging - Logging Provider: org.jboss.logging.Slf4jLoggerProvider
[:app] Compiling ...
[:app] Build completed. (340 files, 6 compiled, 13 warnings, 6.31s)

Im not using any lein-shadow, Im just trying to run it as a lein target (so I can hook it into the uberjar build)

if you use lein project.clj then :source-paths or :dependencies in shadow-cljs.edn do not apply

so they need to be configured in project.clj. likely your :source-paths are just incorrect or missing

right, so its equivalent to doing :lein thing in your shadow cljs?

yes

source-paths for cljs is added in old cljsbuild section

I will add it to main source-paths

I recommend a :cljs profile in project.clj, but top level is fine too

yep. profile it I will.

works great. Thanks.

Do you have :source-map true added to your build's compiler options? That might help w/ producing a useful stack trace and/or pointing you to the code that's getting mangled https://shadow-cljs.github.io/docs/UsersGuide.html#compiler-options Ah actually that shouldn't be an issue if you're only using whitespace and simple optimization

i tried source map but that doesn't point me to soemthing useful

just to be sure the whitespace optim, i add the :release {:compiler-options {:optimizations :whitespace}} right?

Unexpected identifier is not a externs issue. seems like there is something wrong with the output

are you sure compilation completed successfully? sometimes some CI systems kill the shadow-cljs JVM during :advanced for using too much memory or so

could end up with half written files

[:app] Build completed. (1896 files, 0 compiled, 0 warnings, 11.17s) i'm getting that at the end

and what is the full error trace?

I'm assuming this is a :browser build? are you maybe testing in a really old browser?

or something that is not actually a browser?

Thinking back on this... I've intermittently seen this issue altho not in a while (would sometimes occur after installing an npm dep). Back then, I would rm -rf .shadow-cljs , then run the build again to get an entirely fresh build

that's the full error trace, i'm on latest chrome macOS

thats literally the same excerpt. I mean the full trace 😛

it should point to a location

on the right? there is no reference to a location?

why does it fail to load the source map?

are you maybe not actually loading the JS? just some webserver serving something else? like html?

check the network tab to see what you actually get

yes there is but it's a long line ... source map not giving anything

which shadow-cljs version is this? did you set a custom :output-feature-set? it doesn't seem to like the yield

which should be find in modern browsers?

yeah i though it could be yield but it should be supported everywhere, and the dev build is not giving an error

can i add you to the repo maybe?

could be the closure compiler transpiling away the function* which would make yield invalid

ah i see

so should i set a :output-feature-set?

normally not no

I mean assuming the default is good enough for you

but you can try :compiler-options {:output-feature-set :es-next} in the build config

(that basically disables all polyfilling, just to rule that out)

ok

i do it

Oh!

seems to be working now :shocked_face_with_exploding_head:

issue now that some browser might not like it...

you can then try to go down until it doesn't work anymore

:es2021 :es2020 etc

i see -- so the issue was the transpiling for yield not giving correct js?

and upgrade shadow-cljs if it isn't the latest (2.17.4)

that includes the latest closure compiler

(thanks a lot for that faster-than-typing live debugging!!)

that is my guess yes

ok i had 2.12.5

i'll bump up and then try without the es-next

shadow updated but still need a output-feature-set

es2020 is fine

i wouldn't be surprised that one of this library is just using weirdly generators, so that's tricking the compiler...

default output-set is which one?

:es6

:thumbsup:

it appears with advanced yes, i tried with simple and whitespace and it appeared as well... which is weird so i'm questioning if i was actually setting properly the optimization