hmm right. the timestamp of the shadow-cljs jar itself does matter. this is to ensure that cache invalidates when switching shadow-cljs versions. could be hash based too I guess
I ended up just printing the timestamps and I see this
first shadow-cljs run (builds the cache)
[1782570507000 1782570507000 1782570505000]
second shadow-cljs run (tries to consume the cache)
[1782570507000 1782570507000 1782570506000]
The 3rd row corresponds to cljs/analyzer.cljcAlright, with this commit https://github.com/frankitox/shadow-cljs/commit/b0add3d422436a529dab6a129a6a61c45742b17a the cache hits
I couldn't figure out why the timestamp changes