@swiseman108 when using lein to manage dependencies you need to make sure you are using the correct versions of everything. so make sure you are using the proper versions for the shadow-cljs version you are using. I do not have any issues with the closure compiler and I don't have guava at all either

see the dependencies listed here https://clojars.org/thheller/shadow-cljs

or as I always recommend let shadow-cljs.edn manage your dependencies. you only gain headaches by mixing your CLJ dependencies with CLJS ones

(or use profiles/aliases for backend/frontend)

Thanks @thheller. Moving to shadow-cljs.edn for dep management is definitely in the plans. Separating out frontend and backend deps would also be a solution to this particular issue as the lower version of guava is only in the dependency tree of a backend dependency.

Hi there, running into an issue with cljs hot-reloading and trying to identify the point of failure using shadow's verbose output. I have three namespaces a > b > c, with a macro defined by b. So far hot reloading a seems to work though changing a does not seem to reload transitive dependency c (which seems odd, but maybe there's some optimized decisions or something). However, if I introduce an additional dependency between c and a , changing a reloads c before b, which is confusing to me: c relies on the macro in b, and results in an undefined var warning. Are my expectations about what gets reloaded and when, off? Let me know if it would help to post a simplified version the actual requires.

@zalky namespace reload always works by reloading the namespace that was modified plus all namespaces that have a direct require for it. nothing else by default.

reload order should happen in dependency order but I don't quite follow your description. macros are kind of tricky since they can technically do everything, so without an actual example I can't say much

@thheller, thanks, I think I see. So a really simplified version of what it looks like is the following:

(ns p.a)
(defn f
  [])

(ns p.b) ; .clj
(defmacro macro
  []
  '(p.a/f))

(ns p.b ; .cljs
  (:require [p.a])
  (:require-macros [p.b]))

(ns p.c
  (:require [p.a]  ; <-- this line causes p.c to be compiled before p.b
            [p.b]))
(p.b/macro)

incorrect. that line causes p.c to be compiled at all when p.a is changed. without that it won't

what causes it to compile c before b is whatever requires those

Yes, my mistake.

but why is that a problem in the first place? is the macro doing some side effecting stuff that is causing a problem?

otherwise it really shouldn't matter at all?

Are you asking in the sense of why do the undefined var errors matter?

Warnings I should say.

again without an actual reproducible example I cannot comment

macros can do too much stuff to know what exactly you are describing

That's fair, they can be. This particular macro just produces some runtime code inside component render functions. I don't think it does any compile time side-effects. Do you know what part of the system, shadow or the cljs compiler, that does the dependency graph resolution? ie: resolves the dependency order?

shadow

fwiw I took your example code and things compile in the expected order (ie. modify a compiles a->b->c)

the only way I can see this not happening is p.c using p.b without requiring it

in which case yes all bets are off on the order part

Ok, much appreciated, the actual code is part of a fairly large framework, and I wasn't immediately clear that only immediate dependents are recompiled. I think actual example has another namespace between p.a and p.b, and so p.b is not actually being reloaded in either case.

p.c is indeed requiring p.b

the reasoning behind only recompiling direct dependents is that in theory thats the only namespaces that can "break". macros kinda break that assumption in certain cases so absolutely possible that things behave weirdly but most of the time that is due to macros doing some side-effecty stuff looking at analyzer data or so

Ah, hmm, the macros is indeed looking at &env to determine if a particular symbol is a bound local

locals should be fine?

ah if it calls resolve then that may trigger the warning, not the compile itself

It does not call resolve, it just looks up whether a symbol is locally defined, and if it is not, provides a default binding.

Can I also ask, during the compilation, I'm seeing output like the following:

1:49:52 PM cljs.1 |  -> Compile CLJS: a.cljs
1:49:52 PM cljs.1 |  -> Compile CLJS: c.cljs
1:49:52 PM cljs.1 |  <- Compile CLJS: c.cljs
...
1:49:52 PM cljs.1 |  <- Compile CLJS: a.cljsi

there are multiple threads compiling yes. I still won't comment any further without an actual reproducible example. guessing here is really pointless.

Ok, understandable. I don't suppose there are any options in shadow to make that compilation synchronous? I didn't see anything in the docs, just thought I'd check.

you can set :compiler-options {:parallel-build false} in your build config

Ok, thanks, I'll see where I can get with that, maybe I can get a simple repro. Very much appreciate you taking the time to provide some pointers.

@thheller, I put together a small https://github.com/zalky/shadow-repro. As best I can tell, it seems to me like a concurrency issue when it comes to macro compilation and transitive dependencies between recompiled namespaces. Let me know if I may have missed anything or could provide anything else that might be useful.

I have a question on polylith builds (so multiple deps.edn projects with :local/root dependencies. Could it be that shadow-cljs does not pick up the deps.cljs of multiple projects in this case? So I have to create ONE big deps.cljs file. I assume that shadow-cljs is looking only into JARS, and since the local deps are FILES, it will not find them inside a jar. I have not noticed a similar behavior when using JAR dependencies on clojars for exampel.

This issue does not happen, when the deps.cljs are in an empty namespace, so say in "src" of each project.

However, in this case when multiple projects get ombined into a JAR, then of course the classpaths of that jars will conflict.