Fork me on GitHub
#clj-kondo
<
2020-10-31
>
dominicm15:10:13

I'm considering automatically running clj-kondo --parallel --lint in the background on JVM startup. Any reason not to?

borkdude15:10:09

battery life?

dominicm15:10:38

@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?

borkdude15:10:13

clj-kondo always caches when there's a .clj-kondo dir, unless --cache is false

dominicm15:10:20

@borkdude so the files in jars won't be re-linted?

borkdude15:10:13

oh you mean like if you call --parallel --lint next time, it will skip the jars? no it doesn't have logic for that

borkdude15:10:21

there's an issue for this. let me look it up

dominicm15:10:47

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 :)

borkdude15:10:05

there's a bb script in there ;)

borkdude15:10:09

It's possible to build this logic inside clj-kondo, but then we've got a cache for the cache, which may introduce ... issues?

dominicm15:10:31

heh, that appears to be from a project I worked on :p.

borkdude15:10:50

you worked with daniel compton?

dominicm15:10:15

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"

dominicm15:10:34

So a cache would be a literal cache for that lint history

borkdude15:10:03

yes, cache is maybe the wrong word, but I also didn't want to call it a database

dominicm15:10:13

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.

borkdude15:10:17

I think using the cpcache for this might be a nice idea btw, post it in the issue :)

dominicm15:10:03

Am I safe-ish to create files in .clj-kondo/cache? If so, I'll use the cpcache as my approach.

borkdude15:10:39

yeah, you can put anything in the .cache dir, clj-kondo won't punish you

borkdude15:10:31

you could even have a global cache I guess of linted jars

borkdude15:10:47

like ~/.clj-kondo/.cache/foo.jar/....

borkdude15:10:04

and when clj-kondo lints the jar it will just copy it from there or something

dominicm15:10:24

I might encourage a symlink if possible. Learning from the npm->yarn transition!

borkdude15:10:49

yeah, or clj-kondo will just do lookups to a global cache as a fallback

borkdude15:10:15

I can already feel the github issues coming ;)

borkdude15:10:43

but it could be nice. lint your .m2 dir once, profit many times

dominicm15:10:56

fwiw, I think clj is going to pursue a similar idea for AOT.

dominicm15:10:20

or maybe for prod, not sure. Alex hinted at it.

dominicm15:10:38

Immutable deps make this a lot easier

borkdude15:10:05

the cache is also keyed on .clj-kondo version btw, so updates to clj-kondo would invalidate it

dominicm15:10:13

Makes sense.

dominicm15:10:43

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.

borkdude15:10:03

other tricks can be posted in the issue I guess?

dominicm16:10:22

I meant unrelated to caching :) Others similar to auto-caching on JVM startup

dominicm16:10:23

❯ 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
That's... impressively slow :p

dominicm16:10:00

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.

dominicm16:10:16

Might be worth doing a content cache I guess, not sure if you do already

borkdude16:10:45

you mean, like hashing the source?

borkdude16:10:07

clj-kondo doesn't use any of this, it just re-lints every time you feed it something

borkdude16:10:41

@dominicm btw, the JVM may be a tad faster due to JIT

borkdude16:10:55

so you could also include clj-kondo as a JVM dep

dominicm17:10:01

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.

dominicm17:10:05

Will ponder.