Client configs with cljs 1.10 break

[yannvanhalewyn]

It looks like cljs 1.10 breaks the ability to have multiple figwheel builds, even across projects. It seems that cljs 1.10 caches compiled dependencies, and after building figwheel the first time the config for that specific build sticks. This read-config macro: https://github.com/bhauman/lein-figwheel/blob/master/support/src/figwheel/connect.cljs#L9 effectively only runs the first time any figwheel resources are compiled.

Reproduction:

• lein new figwheel my-project
• :dependencies [org.clojure/clojurescript "1.10.145"]
• Add a second build, without on-jsload hook for example, for testing purpouses.

Run both builds, and checkout both resources/public/js/compiled/{out1|out2}/figwheel/connect.js and confirm the var config = statement is always the same (even when previously built in another project). They now either both have the on-jsload hook, or neither.

Consequences

No need to elaborate, but issues with js-load hooks not being configured, repl's not connecting because the build id doesn't match, ...

I'm not entirely sure if I should post this here or at cljs, what do you think @bhauman?

[yannvanhalewyn]

Not all too familiar with the figwheel codebase or the closure compiler, but a solution might be to pass in the config to connect.start in the generated output.js:

document.write("<script>figwheel.connect.start(config);</script>");

if that's achievable.

[bhauman]

Does :aot-cache false fix it?

You'll probably have to do :validate-config false as well.

[bhauman]

cc/ @swannodette

[bhauman]

cc/ @darwin this will probably be a problem for dirac configuration as well?

[yannvanhalewyn]

Not sure where the :aot-cache option goes, could you specify?

[bhauman]

it would go in the :compiler options for the build. and :validate-config false would be under the top level figwheel config.

[yannvanhalewyn]

That's what I thought but was missing :validate-config. I'll try it.

[bhauman]

Don't forget to delete all the assets even the cache.

[yannvanhalewyn]

I didn't :)

Confirmed, clearing ~/.cljs/.aot_cache, lein clean and running with those options works.

[yannvanhalewyn]

It consistently fails without them on a clean project, so I guess a more durable solution is needed. I'll gladly help out but I'm struggling a bit to find where changes can be made in the codebase to submit a PR.

[bhauman]

AOT cache was introduced to help with command line start up times. I'm thinking the smart solution for now is to default to :aot-cache false for figwheel.

[bhauman]

It will also, no doubt, help prevent folks from experiencing other weird behavior when the cache delivers stale code.

[yannvanhalewyn]

That definitely would work. That or moving configuration to figwheel.preload.

[bhauman]

How would that fix it?

[bhauman]

The preload would get cached just as well correct?

[yannvanhalewyn]

Thought it might run at compile time, I don't see the bigger picture here though. :aot-cache false as default seems like the easier and better idea indeed.

[bhauman]

So actually :aot-cache false should work even if you don't clear the cache though, is that correct?

[yannvanhalewyn]

I guess, it seems like it shouldn't go look for any cache files also.

[yannvanhalewyn]

I'll try it real quick

[bhauman]

Thanks!

[bhauman]

I'll have a snapshot deployed in a jiffy

[yannvanhalewyn]

Allright, confirmed also that :aot-cache false works when there already is a cache!

I'll have a snapshot deployed in a jiffy

Awesome 😄

[bhauman]

Great!

[bhauman]

Looks like :aot-cache false will be the default in the compiler.

[bhauman]

So I'm not going to deploy a snapshot that sets :aot-cache false. I am going to deploy a snapshot that accepts all the new config options.

[yannvanhalewyn]

I saw the commit, all will be good then. Thanks so much for the quick responses and actions @bhauman!