Clojurians Log v2
clj-kondo
I'm considering automatically running clj-kondo --parallel --lint in the background on JVM startup. Any reason not to?
battery life?
@borkdude seems like a non-issue, given that it's only on the rare reboot of the JVM. Does clj-kondo cache at all for that operation?
clj-kondo always caches when there's a .clj-kondo dir, unless --cache is false
@borkdude so the files in jars won't be re-linted?
oh you mean like if you call --parallel --lint next time, it will skip the jars? no it doesn't have logic for that
there's an issue for this. let me look it up
Ah. I'll start with naïve approach, and assume clj-kondo will either fix it later, or I can just cache against the .cpcache :)
there's a bb script in there ;)
It's possible to build this logic inside clj-kondo, but then we've got a cache for the cache, which may introduce ... issues?
heh, that appears to be from a project I worked on :p.
you worked with daniel compton?
I thought you worked at JUXT before your current job
Hmm, that depends I guess? :) I wouldn't describe this as a cache, the existing thing is more of a "lint history" or "lint record"
Daniel worked with JUXT :)
So a cache would be a literal cache for that lint history
And then he got laid off due to the pandemic or was that another thing?
yes, cache is maybe the wrong word, but I also didn't want to call it a database
I should clarify. Daniel's company employed JUXT to help out.
ah right
Hypothetically, clj-kondo could be taught how to resolve namespaces by itself and then it could check the "database" OR just resolve it as a fallback. Hypothetically ofc, there's a bunch of thinking that would need to go into that.
I think using the cpcache for this might be a nice idea btw, post it in the issue :)
Am I safe-ish to create files in .clj-kondo/cache? If so, I'll use the cpcache as my approach.
yeah, you can put anything in the .cache dir, clj-kondo won't punish you
you could even have a global cache I guess of linted jars
like ~/.clj-kondo/.cache/foo.jar/....
and when clj-kondo lints the jar it will just copy it from there or something
I might encourage a symlink if possible. Learning from the npm->yarn transition!
yeah, or clj-kondo will just do lookups to a global cache as a fallback
meh
I can already feel the github issues coming ;)
but it could be nice. lint your .m2 dir once, profit many times
fwiw, I think clj is going to pursue a similar idea for AOT.
https://clojure.org/guides/dev_startup_time automating this process
or maybe for prod, not sure. Alex hinted at it.
Immutable deps make this a lot easier
yeah
the cache is also keyed on .clj-kondo version btw, so updates to clj-kondo would invalidate it
Makes sense.
Btw, if any other tricks like this come to mind that a project could experiment with, let me know. I'm working on a place for hacks like this to be tested in a way that wouldn't require long-term commitments on your part.
other tricks can be posted in the issue I guess?
I meant unrelated to caching :) Others similar to auto-caching on JVM startup
ah right.
❯ time clj-kondo --parallel --lint /home/overfl0w/.m2/repository/refactor-nrepl/refactor-nrepl/2.5.0/refactor-nrepl-2.5.0.jar
<snip>
clj-kondo --parallel --lint 4.77s user 0.35s system 99% cpu 5.163 total
❯ time clj-kondo --parallel --lint /home/overfl0w/.m2/repository/cider/cider-nrepl/0.25.3/cider-nrepl-0.25.3.jar
clj-kondo --parallel --lint 7.82s user 0.38s system 99% cpu 8.272 total
I suspect that's mostly my machine being old, but also the size of these two jars is probably disproportionate. They contain embedded tools reader copies, etc.
Might be worth doing a content cache I guess, not sure if you do already
you mean, like hashing the source?
clj-kondo doesn't use any of this, it just re-lints every time you feed it something
@dominicm btw, the JVM may be a tad faster due to JIT
so you could also include clj-kondo as a JVM dep
Hmm, don't think that's useful necessarily here. As if the user doesn't have clj-kondo installed, then the cache isn't much use to them.
Will ponder.
ok