Exclude paths from linting?

[ghost]

I’m working on a project that contains 342 generated .clj files with 56032 LoC. This takes clj-kondo a while to lint; roughly 5–6 seconds. Whereas if I delete the subtree containing all that generated code, linting the rest of the code takes 35–40 milliseconds. I’ve got the path added to [:output :exclude-files] in config.edn but that only disables clj-kondo from outputting any problems it finds in the generated code. I’d prefer to speed up linting by having clj-kondo not lint the generated code at all.

Is there any way to do this?

If not, might this be worth possibly adding as a feature?

[borkdude]

@aviflat I think an option for this would be convenient, similar to {:output {:exclude-files ...}} but then a top level :exclude-files [...] option that you can also pass from the command line, probably.

[ghost]

Yes, that’d be perfect!

[borkdude]

A short-term workaround would be to limit the directories passed in --lint to only the files you want to lint.

[ghost]

Good point, I’ll do this in my CI job, thanks!

[lvh]

I wonder if we could cache this to make it fast; the generated code also doesn't change very often in a steady state, and during development, the clj-kondo output can still be just as useful for identifying problems as it would be for other code. If not more, since it's a pile of macro code where the bigger gap between programmer and final code produced might result in more subtle bugs :)

[ghost]

That makes sense, but I do seem to have this cache locally and it seems to be populated, but linting is still taking 5–7 seconds. Although, hmmm, it looks like maybe some of the generated code analyses are missing from the cache. Maybe that’s the problem… I guess I need to look into this…

[borkdude]

The cache doesn't determine which code to skip: all code that you pass to --lint gets linted.
But the cache does play a role in providing extra information to the files you are linting.

[ghost]

Right, but isn’t it faster to lint a file that’s been linted before and already has an entry in the cache?

[borkdude]

It's complicated. There is a check to skip linting dependencies that are in jar files, since those are more or less guaranteed to never change. If you use the --dependencies flag, it will skip an already linted jar file. But for normal source files, you would also have to check a few more things: all the files that this file depends on, the clj-kondo configuration and everything referenced from that (since when that changes, all bets are off). In in-editor situations (what clj-kondo is optimized for) it's actually more work to check all of this which will make the typical use case slower, not faster, when you're editing your sources.

[ghost]

Ah, fascinating, thanks!

Now that you mention it, I guess it doesn’t really matter all that much if it takes 6000 ms vs 40 ms when linting the entire codebase, because most of the time we do that only in CD jobs, which are more or less asynchronous. I do occasionally lint entire codebases manually from my shell myself, but not often enough that this matters all that much.

So, this (the ability to exclude certain paths from linting) still seems like a logical feature to me but it’s certainly not at all urgent.

Thanks!