Clojurians Log v2
clj-kondo 2025-10-09
I'm working with multiple projects which unfortunately have too many linter faults to tackle in one go. clj-kondo wasn't enforced before.
Is there a simple script/thing that will create a config that will silence the existing faults, but not allow new ones?
(Ideally not touching the source files themselves, I do not want to insert #_{:clj-kondo/ignore all over the place)
One possible, agnostic approach 🤔 : Don't rely on the clj-kondo exit code. Just observe its output. Remove from it the known file-line-fault combinations. If anything remains, fail
I'm in a similar situation. What we're doing at the moment is using a separate clj-kondo config for CI, which disables several linters. Then we could ideally tackle each linter separately later and fix issues in the existing code and enable the linter. I'd too love to hear if there are some better alternatives.
@vemv This is a common question. Several ideas here, with the same kind of question: https://clojurians.slack.com/archives/CHY97NXE2/p1759255577513259
Maybe it's not what you're looking for, but still: create a file called "linting-paths.txt" with paths to lint, e.g.:
src/foo/com/this_namespace
src/aaa/test.clj
and so onday after day, grow this file, and sooner or later separate files will collapse into parent dirs, and so on
One pragmatic solution could be to only fix warnings in files that developers touch, so only the ones part of a git commit
Thanks, everyone. I think I like what I suggested myself - it's exhaustive, and CI-enforceable. It's also 'subtractive' - you create one big list just once, then all you have to do is to remove items from it, which gives you a clear sense of what's remaining
@vemv I've had luck with that approach in the past. A quick tip: it's a good idea to tweak the clj-kondo output format to remove the line number. Makes the output to compare against "known bad" occurrences less fragile as code moves around due to additive changes higher up in the file.
note that you can also use EDN output and use some scripting to make this a bit easier
We've just tackled it in my workplace for projects that didn't have the linter working.
What we used is a lint-diff task in ci which is mandatory and made the lint task (lint all project) optional (it runs, but doesn't fail pipeline)
lint-diff only lints the changed files (careful not to lint deleted files):
- git diff --diff-filter=d --name-only -- "*.clj" "*.cljs" | xargs -r clj-kondo --lint We will enforce lint on all projects after devs become more used to the linter 🙂
What we do at work is to track a file containing lint output and have the build fail if new items appear (i.e., the line count increases), rather than check the exit code of the linter. If the line count stays the same or decreases, we just commit the updated file. We do a similar thing with reflection warnings.
The latest core.async alpha has a new macro called defparkingop that generates the defs for the single bang parking ops. Running kondo using the alpha signals linter warnings for those parking op vars because kondo doesn't know anything about the new macro like it does for the https://github.com/clj-kondo/clj-kondo/commit/a21d51ea0933df31a121438dfc67aa4a981852a0#diff-f591b825c81f488c7fa9426a07ba9dd30f948cc52e445be929d5fd8299bc7ddeR1582-R1583. Is it possible to add support to kondo for this new macro? If so, do you prefer a patch, ticket, both?
Is this someting user facing? clj-kondo issue would be welcome
Technically they are user-facing, even moreso in this alpha and future versions.
👍
https://github.com/clj-kondo/clj-kondo/issues/2633