no goog/base.js
{}
ExceptionInfo: no goog/base.js
	shadow.build.output/closure-defines-and-base (output.clj:58)
	shadow.build.output/closure-defines-and-base (output.clj:53)
	shadow.build.targets.graaljs/flush-dev (graaljs.clj:127)
	shadow.build.targets.graaljs/flush-dev (graaljs.clj:111)
	shadow.build.targets.graaljs/process (graaljs.clj:168)
	shadow.build.targets.graaljs/process (graaljs.clj:160)
	clojure.lang.Var.invoke (Var.java:384)
	shadow.build/process-stage/fn--26795 (build.clj:161)
	shadow.build/process-stage (build.clj:158)
	shadow.build/process-stage (build.clj:150)
	shadow.build/flush (build.clj:494)
	shadow.build/flush (build.clj:488)
	shadow.cljs.devtools.server.worker.impl/build-compile (impl.clj:364)
	shadow.cljs.devtools.server.worker.impl/build-compile (impl.clj:344)
	shadow.cljs.devtools.server.worker.impl/do-config-watch (impl.clj:563)
	shadow.cljs.devtools.server.worker.impl/do-config-watch (impl.clj:556)
	shadow.cljs.devtools.server.util/server-thread/fn--28186/fn--28187/fn--28195 (util.clj:269)
	shadow.cljs.devtools.server.util/server-thread/fn--28186/fn--28187 (util.clj:268)
	shadow.cljs.devtools.server.util/server-thread/fn--28186 (util.clj:241)
	java.lang.Thread.run (Thread.java:833)

let me know if you want an issue or a minimal repro

in what context? just a regular watch?

any custom build-hooks by chance? IIRC this could happen if a build hook doesn't return the proper build state?

yes regular watch, I do have a build hook, let me see…

actually, no, I had one but dropped it a while back

dunno what else then. this is fairly standard code touched by multiple targets (and working fine for me locally)

anything else look wrong in the config?

{:deps {:aliases [:sci]}
 :dev-http {7778 {:roots ["public" "classpath:public"]}}
 :nrepl false
 :builds {:browser {:target :graaljs
                    :output-to "public/js/viewer.js"
                    :output-dir "public/js"
                    :build-options {:ns-aliases {nextjournal.devcards nextjournal.devcards-noop}}
                    :modules {:viewer {:entries [nextjournal.clerk.sci-viewer
                                                 nextjournal.clerk.static-app]}}

                    :dev {:compiler-options {:optimizations :simple}}
                    :release {:output-dir "build/"
                              :compiler-options {:source-map true}}

                    :js-options {:output-feature-set :es8}}}}

seems fine

:dev {:compiler-options {:optimizations :simple}} does absolutely nothing since dev never does any optimizations at all

but also won't affect this issue in any way

ah yeah, just added this, I meant release 🙃

since optimizations are not applied in dev regardless of what you set, you can just put it in normally

so just :compiler-options {:optimizations :simple} without nesting in :dev/`:release`

not really sure what could cause your issue besides a bad build hook

which shadow-cljs version? haven't really touched any of this in years though

2.16.7

let me try the very latest

uhm hang on

:target :graaljs didn't support :modules?

didn't it just have :entries [...]?

trying…

YES, thank you!

tiny thing I noticed, should :graaljs be added to this list?

Target ":node" for build :browser was not found. The built-in targets are:
  - :browser
  - :browser-test
  - :node-script
  - :node-library
  - :npm-module
  - :karma
  - :bootstrap

well I don't know of anyone using it besides you 😛

hehe

never made it an official target since its somewhat sketchy 😉

IMHO graal isn't a viable JS runtime at this time

well viable but rather limited

how so? Think its quite powerful with the polyglot stuff

but the data transfer is so limited (eg. no passing a CLJ map to CLJS or back)

so might as well just use a regular remote RPC mechanism and launch a node process

things can access the same memory, so pretty sure passing a map can be implemented if you'd like to avoid going through json

you really can't, since CLJS calls entirely different functions on maps than CLJ

can't you implement the map interfaces like ILookup etc on both sides?

then you end up with "proxies" and not real maps. at which point it would be better to serialize transit back/forth to get actual real maps

these are indistinguishable from real maps

and if one performs better than the other depends on if you'll need all data in the map or just parts

not really, can't assoc for example

also last time I checked graaljs was horribly slow compared to node

so even if you did all that the node solution with serialization is faster

after jit warmup the difference to node becomes less

same ballpark last time we checked

true but even the startup time is enough for me to now want to use it 😛

In the shadow-cljs user guide promises are only mentioned twice. Nothing in connection with testing.

do you use clojure.test/async correctly? async tests need to be marked as such. otherwise the runner won't know about them and won't wait for their completion

ah, pretty sure I'm not since I haven't met clojure.test/async. Going to investigate now.

Made the necessary changes and my assertions are running. Thanks for the pointer! 🙂

yeah I get that. I meant syntactically/mechanically -- once the .then in the promise triggers, the namespace is now available to be used as if it were :required? I agree it's not the smartest way to split code.

https://code.thheller.com/blog/shadow-cljs/2019/03/03/code-splitting-clojurescript.html

https://clojureverse.org/t/shadow-lazy-convenience-wrapper-for-shadow-loader-cljs-loader/3841

makes things a little more usable

also covers how to use stuff after its loaded

#(example.other/mount-root) technically works but not great

Interesting. You're not using shadow.loader at all in that example

because its API is annoying to use and just a direct mirror of cljs.loader for compatibility reasons

I thought it was pretty good!!

Wow, that is a real eye-opener. I am always late to the party, in this case thinking only about massive CPUs and GPUs running Web browsers vs mobile. When mobile is taking over the world! Plz help a dummy: is this another argument for the Flutter/Dart platform, because it eschews JS? Or should those apps likewise sweat over chopping up functionality so it loads JIT? :thinking_face:

apps don't really have the issue of trying to keep code size small, so its entirely different area