Fork me on GitHub
#cljs-dev
<
2019-02-28
>
Yehonathan Sharvit07:02:46

“philosophically cool” sounds to me as an oxymoron @chancerussell :thinking_face:

mhuebert10:02:43

I think there is a bug with compiler cache invalidation, for namespaces that use macros. if I… 1. compile my project, eg. clj -m cljs.main --optimizations advanced -c app.core 2. make a change to a macro that app.core depends on, say app.macros 3. re-run the same compile, app.core does not pick up the changes in app.macros - instead I have to delete the out dir or make a changes to app.core in order for it to correctly re-compile.

thheller11:02:48

pretty sure that CLJS doesn't check macros at all when deciding if a file needs to be recompiled (or dependency changes in general)

borkdude12:02:13

that’s probably a benefit of using boot where clj and cljs run in one process, so you can redefine macros in the JVM?

thheller12:02:32

I'm pretty sure he is talking about 2 fresh JVM instances

borkdude12:02:36

oh right, using clj. what happens when you do (require [the-ns-with-macros] :reload) from the REPL though? could be a workaround

thheller12:02:34

no. :cache-analysis doesn't check any of that. the problem isn't that the macros are not updated, the problem is that compilation is skipped completely

dnolen15:02:30

@thheller not true about dependency changes

dnolen15:02:06

we could look at macros, but we don't do that at the moment - since it's just less common

dnolen15:02:07

patch welcome

thheller15:02:57

I only can find one reference where *recompiled* is actually bound and that is in cljs.closure/build. are you sure thats actually bound when using cljs.main?

dnolen15:02:06

we go through cljs.build.api

dnolen15:02:19

which goes through cljs.closure/build

dnolen15:02:27

@mhuebert we could add :require-macros to the set of things we look at - probably a slightly finicky change but not that challenging I think - feel free to file an minor issue

5
dnolen16:02:36

@bhauman ^ might want to watch this one? I think you have some custom stuff for this case?

dnolen16:02:06

also maybe shadow-cljs too?

thheller16:02:44

shadow-cljs does its own cache handling so it already handles this

bhauman16:02:03

not really thanks for the heads up though 🙂

anmonteiro21:02:51

Didn’t exactly follow the backlog, but I did something like that in CLJS-1490 at some point: https://github.com/clojure/clojurescript/commit/2267a8e5e9607aff8c940fa372dbdb35816350ba