[2023-12-27 10:13:39.133 - INFO] :shadow.build.classpath/jar-cache-read-ex - {:file #object[java.io.File 0x34a53af9 "target/.shadow-cljs/jar-manifest/riddley-0.1.12.jar.033bd1610a8ef50a6347cd571eaef76182ca50b0.manifest"]}
RuntimeException java.io.EOFException
	com.cognitect.transit.impl.ReaderFactory$ReaderImpl.read (ReaderFactory.java:114)
	cognitect.transit/read (transit.clj:323)
	cognitect.transit/read (transit.clj:319)
	shadow.build.cache/read-cache (cache.clj:49)
	shadow.build.cache/read-cache (cache.clj:33)
	shadow.build.classpath/find-jar-resources/fn--23022 (classpath.clj:543)
	shadow.build.classpath/find-jar-resources (classpath.clj:542)
	shadow.build.classpath/find-jar-resources (classpath.clj:528)
	shadow.build.classpath/find-resources (classpath.clj:699)
	shadow.build.classpath/find-resources (classpath.clj:690)
	shadow.build.classpath/index-path* (classpath.clj:919)
	shadow.build.classpath/index-path* (classpath.clj:916)
Caused by:
EOFException
	com.cognitect.transit.impl.JsonParser.parse (JsonParser.java:44)
	com.cognitect.transit.impl.ReaderFactory$ReaderImpl.read (ReaderFactory.java:112)
	cognitect.transit/read (transit.clj:323)

can be ignored I guess. it'll just recreate it on next start

how are you checking if they are "found"? I mean this is just an unused def and :advanced will have removed that because it is not used?

I use it for other things. So I know it’s empty in release mode only.

I mean the namespace names just aren’t there when release mode. I use this var to do other things and I see them missing at runtime.

what does that mean. please be more precise. :advanced collapses all namespaces and vars, so are the names missing or the things they are supposed to look up?

a repro would help for sure

the above is fine and should work without issue

whatever else you might be doing might not be

The analyzer gives me the ns i expect when in dev but not when in advanced.

I figured if it isn’t obvious would need to try to recreate a mini example. Will try it out in a bit.

I’ve debugged this sort of stuff with cljs compiler before. But shadow does things differently. So didn’t know where to really start

the analyzer data is the same in release, no difference to dev. so everything should be fine.

I’m seeing differences. 😢

Hopefully it can be recreated in a minimal way.

if you have a repro I'm happy to take a look

accessing the analyzer data in macros is weird, so there are a couple gotchas

one thing that might be relevant is caching

since the my.stuff maybe isn't always recompiled the analyzer data just may be incomplete

you can try (ns ^:dev/always my.stuff) to prevent that cache

Been working on recreated. A bit tricky to setup. I think what I’ve found is that it isn’t that the namespaces are missing perhaps, instead it is that I am filtering the namespaces from the analyzer based on details of their :defs.

In one case, I was looking for test vars, by doing something like (-> ns-entry val :defs vals (filterv :test)) for example.

I don’t think any caching is going on. I am clearing the whole .shadow-cljs every time with this

tests aren't included in release builds?

unless you set :compiler-options {:load-tests true} (or this is any of the test targets, which set this by default)

It’s a test runner thing. What is excluding tests?

I use lein for source paths

that doesn't matter for anything

And my main export is in a test path in this case

and with which build target is this?

So shadow removes deftest vars?

cljs removes deftests ...

I have all of this basically in my “main app” in this case. It’s test helper stuff for something complicated.

I didn’t have any issue here with cljs and figwheel main.

This is me switching to shadow

yes, and which build :target do you use?

I'm guessing your config in figwheel had :load-tests true .. which you are probably just missing in shadow

otherwise figwheel removes tests too

Only way that could be is if fig did so implicitly .

Oh browser target too

yes :browser is not a test target, so test are removed unless configured not to

:browser-test would keep them

just checked and it is definitely a CLJS thing to remove tests unless told not to https://github.com/clojure/clojurescript/blob/e596c355dbecec58beffc3eafc3f7f86fb4ddbb6/src/main/cljs/cljs/test.cljc#L242

that binding is controlled by the :load-tests compiler option

Weird. I don’t know how I never had trouble with fig main. I’ll have to look. I’ll try this out though soon. Thanks for the pointers

Mentioned here https://github.com/bhauman/figwheel-main/blob/eea4d680ff30d958da01ffb3aa0c9af57250093f/src/figwheel/main/schema/cljs_options.clj#L400

So makes sense. Shadow sets this flag to false sometimes while fig and cljs did not

shadow in general sets many defaults that you otherwise need to set manually. easy to forget something like load-tests and then have tests in your optimized browser build where you'd never use them normally

I thought :load-tests defaulted to false but I guess that was wrong

I was surprised to learn that this feature even existed in deftest. What makes test vars any different than other test sources you wouldn’t want to include? I thought DCE would be the mechanism being relied on for all of that if you were compiling with this sort of thing in the source paths being compiled.

Is there something special about why deftest wouldn’t be DCE’d the same as other things?

Anyways, in this specific case. I’ll just look into changing this flag in shadow for this sort of build - hopefully it allows it

hmm? I told you how to change it

:compiler-options {:load-tests true}

Sorry. Didn’t see that one.

in theory DCE will take care of the tests ... that is however just theory. even if it removes all the tests it can still leave more code alive than it otherwise would

best not having to worry about it in the first place

My preferred approach is to just not have test stuff on the same compilation path. I don’t rely on DCE for these things really.

For test builds, I just have an entry point that ends up requiring more stuff.

well that problem doesn't exist in the first place in shadow

https://code.thheller.com/blog/shadow-cljs/2018/02/08/problem-solved-source-paths.html

you are fine to keep all source files on the classpath at all times, even tests and stuff

it won't affect the builds in any way, unless specifically required by the build namespaces

I think I did read this one. I’ll read again though. And coming from lein, we just used different :source-paths for different profiles - still will for clj. For cljs though, we did have an alternative app entry point anyways that loaded things we wouldn’t do in the prod app.

also the test builds can require namespaces by regexp, so that you don't need a specific namespace to require them all https://shadow-cljs.github.io/docs/UsersGuide.html#_testing

Yeah, I read this. Seemed like you had an alternative philosophy on this. I think for cljs that is fine from what I can think of.

I saw that testing docs too. I’m not sure if I can smoothly switch to shadow testing right now. We have something pretty crazy going on.

I still have src/main src/test etc for my projects too, I just don't worry about having them active and that affecting my project 😛

separating them is still useful, just not build affecting

I think in clj it matters more to me. We don’t want our jars having dependencies that we only need for test in them. We don’t want things on the classpath that shouldn’t be there, etc. We don’t want source files in the jar included if we don’t need them (eg. they were for tests). In cljs for this type of compilation, you are just coming away with the DCE js and don’t bring along other potential baggage of sources existing.

thats not at all what I'm talking about. you should not rely on DCE for stuff that shouldn't be in the build in the first place.

I know. I think I already agreed with where you were coming from.

One downside to the shadow approach I think is it is easier to mistakenly require a ns that you didn’t want to - or didn’t plan out well.

If your source-paths just didn’t have it on the classpath to begin with - it’d be more of a red flag

I work with larger teams a lot. I see a lot of mistakes.

thats what https://shadow-cljs.github.io/docs/UsersGuide.html#build-report is for, so you can actually verify what you have in your build

that’s pretty cool. Never got to that section.