Fork me on GitHub
#shadow-cljs
<
2022-02-23
>
thheller05:02:24

@rahx1t just forgot to git push. updated now. I did bump the closure compiler version in 2.17.4 but I'm not aware of any problems related to that. I do use module lazy loading myself and have no issues?

thheller05:02:01

how do you load the modules? is this maybe a cache issue? ie. having modules from different builds loaded? you cannot mix modules from different builds or different versions of builds. this can happen easily if your cache settings are not set properly and the browser caches too much by default. if you are not using :module-hash-names that is. works fine without too, just requires telling the server to send proper headers so cache is validated properly

馃挕 1
alex16:02:45

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!

thheller17:02:33

: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

alex15:03:59

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?

thheller15:03:05

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

thheller15:03:14

I'm not deleting them ever basically

thheller15:03:15

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

alex15:03:54

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

alex15:03:58

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

alex15:03:15

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

thheller15:03:44

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

thheller16:03:00

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

orestis07:02:47

We recently started seeing this error on our console:

react_devtools_backend.js:4061 shadow-cljs - failed to load module$node_modules$react_popper$lib$cjs$index
<snip>
react_devtools_backend.js:4061 TypeError: Cannot redefine property: Popper
    at Function.defineProperty (<anonymous>)
    at Object.shadow$provide.module$node_modules$react_popper$lib$cjs$index (VM20697 module$node_modules$react_popper$lib$cjs$index.js:1:165)
    at Object.shadow.js.jsRequire (js.js:66:18)
    at Object.shadow.js.require (js.js:113:20)
    at eval (VM20698 nosco.ui.popup.js:7:62)
    at eval (<anonymous>)
    at Object.goog.globalEval (base.js:503:11)
    at Object.env.evalLoad (base.js:1564:12)
    at eval (VM20252 main.js:45:12)
    at eval (<anonymous>)
It was working but we changed the order of some imports and now we're seeing this. We unfortunately have two version of Popper in our node_modules (v1, v2), they use a different npm artifact. But it seems that if you load them in one order, they work, but not in another order. Other than scouring our deps and removing the old version, could there be any other way to troubleshoot/fix this?

thheller07:02:46

hmm not sure. reproducible example would help. don't have enough information otherwise. dunno why it would be redefining the property. this is only in watch I assume? not release

orestis07:02:03

I haven't seen it on release yet, no.

orestis07:02:49

I'm scouring our generated code and I see a reference to global.Popper and also a reference to Object.defineProperty(exports, "Popper", function()...)

thheller07:02:12

its only defining the property on exports which is never global

Karol W贸jcik07:02:15

This looks like internal shadow-cljs error:

[2022-02-23 08:42:12.108 - 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:6812)
	clojure.lang.Compiler.analyze (Compiler.java:6749)
	clojure.lang.Compiler$InvokeExpr.parse (Compiler.java:3824)
	clojure.lang.Compiler.analyzeSeq (Compiler.java:7113)
	clojure.lang.Compiler.analyze (Compiler.java:6793)
	clojure.lang.Compiler.analyze (Compiler.java:6749)
	clojure.lang.Compiler$IfExpr$Parser.parse (Compiler.java:2841)
	clojure.lang.Compiler.analyzeSeq (Compiler.java:7111)
	clojure.lang.Compiler.analyze (Compiler.java:6793)
	clojure.lang.Compiler.analyze (Compiler.java:6749)
	clojure.lang.Compiler$BodyExpr$Parser.parse (Compiler.java:6124)
	clojure.lang.Compiler$LetExpr$Parser.parse (Compiler.java:6440)
Caused by:
RuntimeException No such var: err/throw-no-dispatch
	clojure.lang.Util.runtimeException (Util.java:221)
	clojure.lang.Compiler.resolveIn (Compiler.java:7392)
	clojure.lang.Compiler.resolve (Compiler.java:7362)
	clojure.lang.Compiler.analyzeSymbol (Compiler.java:7323)
	clojure.lang.Compiler.analyze (Compiler.java:6772)
	clojure.lang.Compiler.analyze (Compiler.java:6749)
08:42:18.498 [main] INFO io.undertow - starting server: Undertow - 2.2.4.Final

Karol W贸jcik07:02:48

Shadow-Cljs 2.17.4

thheller07:02:50

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

thheller07:02:49

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

Karol W贸jcik08:02:59

Yeah, as always you're right.

Crispin08:02:45

Hi. Trying to update an old figwheel/lein project to shadow. What could be the reason for shadow working from the npx command line fine, but not from inside lein run?

Crispin08:02:24

$ 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?

Crispin08:02:37

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)

Crispin08:02:24

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)

thheller08:02:10

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

thheller08:02:27

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

Crispin08:02:41

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

Crispin08:02:34

source-paths for cljs is added in old cljsbuild section

Crispin08:02:42

I will add it to main source-paths

thheller08:02:22

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

Crispin08:02:58

yep. profile it I will.

Crispin08:02:13

works great. Thanks.

teawaterwire16:02:27

hi, i have this build that's working properly in dev mode and then when i build it for release, when the compiled js is loaded i get a console error:

Uncaught SyntaxError: Unexpected identifier
i've tried a simple or whitespace compilation, i've tried to release with -debug, i've tried to check externs... but i'm really stuck now and don't know where to look... what can i do to get more info about this error?

alex16:02:44

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

teawaterwire16:02:40

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

teawaterwire17:02:21

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

thheller17:02:20

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

thheller17:02:06

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

thheller17:02:14

could end up with half written files

teawaterwire17:02:53

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

thheller17:02:16

and what is the full error trace?

thheller17:02:34

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

thheller17:02:43

or something that is not actually a browser?

alex17:02:58

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

teawaterwire17:02:26

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

thheller17:02:48

thats literally the same excerpt. I mean the full trace 馃槢

thheller17:02:04

it should point to a location

thheller17:02:27

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

thheller17:02:41

why does it fail to load the source map?

thheller17:02:59

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

thheller17:02:16

check the network tab to see what you actually get

teawaterwire17:02:21

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

thheller17:02:10

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

thheller17:02:46

which should be find in modern browsers?

teawaterwire17:02:25

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

teawaterwire17:02:47

can i add you to the repo maybe?

thheller17:02:28

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

teawaterwire17:02:50

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

thheller17:02:00

normally not no

thheller17:02:11

I mean assuming the default is good enough for you

thheller17:02:27

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

thheller17:02:05

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

teawaterwire17:02:41

seems to be working now :shocked_face_with_exploding_head:

teawaterwire17:02:31

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

thheller17:02:47

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

thheller17:02:54

:es2021 :es2020 etc

teawaterwire17:02:28

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

thheller17:02:29

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

thheller17:02:34

that includes the latest closure compiler

teawaterwire17:02:49

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

thheller17:02:55

that is my guess yes

teawaterwire17:02:26

ok i had 2.12.5

teawaterwire17:02:40

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

teawaterwire17:02:53

shadow updated but still need a output-feature-set

teawaterwire17:02:16

es2020 is fine

teawaterwire17:02:49

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

teawaterwire17:02:00

default output-set is which one?

isak16:02:41

Does the error only appear with :advanced? Try turning setting :pseudo-names true in the compiler options, that may help locate the problem. @teawaterwire

teawaterwire17:02:11

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

Sam Ritchie19:02:14

hello! Is there a way to disable what are, I presume, shadow-specific compiler errors? Here is what I鈥檓 seeing:

cljs.user=> (require '[sicmutils.env :refer [+ ->infix]])
nil
cljs.user=> (let [f +] (->infix (f 'x 'x)))
"x + x"
cljs.user=> (->infix (+ 'x 'x))
------ WARNING - :invalid-arithmetic -------------------------------------------
 Resource: <eval>:1:10
 cljs.core/+, all arguments must be numbers, got [cljs.core/Symbol cljs.core/Symbol] instead
--------------------------------------------------------------------------------