This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # architecture (1)
- # asami (25)
- # babashka (1)
- # beginners (1)
- # calva (23)
- # clj-kondo (54)
- # cljfx (23)
- # cljsrn (9)
- # clojure (72)
- # clojure-europe (2)
- # clojure-spec (16)
- # clojure-uk (4)
- # clojurescript (10)
- # code-reviews (1)
- # cursive (2)
- # datomic (1)
- # events (2)
- # exercism (2)
- # fulcro (6)
- # graalvm (1)
- # malli (1)
- # membrane (1)
- # off-topic (31)
- # pathom (3)
- # reagent (6)
- # reitit (2)
- # releases (1)
- # shadow-cljs (1)
- # vim (6)
- # vrac (25)
- # xtdb (4)
I'm considering automatically running
clj-kondo --parallel --lint in the background on JVM startup. Any reason not to?
@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?
oh you mean like if you call
--parallel --lint next time, it will skip the jars? no it doesn't have logic for that
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 :)
It's possible to build this logic inside clj-kondo, but then we've got a cache for the cache, which may introduce ... issues?
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"
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.
the cache is also keyed on .clj-kondo version btw, so updates to clj-kondo would invalidate it
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.
That's... impressively slow :p
❯ 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.
clj-kondo doesn't use any of this, it just re-lints every time you feed it something
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.