Clojurians Log v2
clj-kondo 2026-05-26
Is there a way to tell clj-kondo to ignore specific warnings inside all comment forms?
Specifically, I'd like to ignore warning: Unresolved namespace [...]. Are you missing a require?.
yes, :config-in-comment
Ah, perfect, thanks!
I'm probably doing something wrong.
I have two namespaces in three files - let's call them components.clj, components.cljs, and icons.cljs.
In components.clj I have a defcomponent macro that works similar to defn.
In components.cljs and icons.cljs I use that macro as defn, but all the specified arguments are unused - they serve only documentation purposes.
I added a hook for defcomponent:
(defn defcomponent [{:keys [node]}]
(let [[_defcomponent cljs-name args comp] (:children node)
new-node (api/list-node
[(api/token-node 'defn)
cljs-name
args
comp])]
{:node new-node}))(defcomponent x [arg] ...) was used, so I added
:config-in-call {components/defcomponent {:linters {:unused-binding {:level :off}}}}(defcomponent ...) in components.cljs.
icons.cljs still produces the warnings.It's probably easier to emit the arguments as used in the defn expansion in the hook
e.g. return a vector
Oh, of course.
Or not... That would mean quite a bit of work for arg vectors like
[a b {:keys [x y]} & stuff]you can also attach metadata to the body
{:clj-kondo/ignore [:unused-binding]}I'm not sure why icons.cljs still produces warnings. what's different about it than components.cljs
I'm an idiot, that's why.
I had a bazillion defcomponents in there, but one rogue defn with lots of unused bindings. I just glanced over the linter's results and thought the whole icons.cljs is to blame since I don't remember having any defns in there.
ah ok :)
Oh, a new finding - yet another difference between CLJ and CLJS, when calling sets with two arguments.
And clj-kondo doesn't seem to be aware - it complains with error: Set can only be called with 1 arg but was called with: 2 in CLJS.
Dunno if you want to tackle this or not.
https://ask.clojure.org/index.php/15104/consider-allowing-passing-two-arguments-sets-used-functions
That would be an easy fix
PR welcome or issue
That's a start: https://github.com/clj-kondo/clj-kondo/pull/2848
BTW dev.md probably has a mistake - it mentions running clojure -X:test:test-regression locally but it produces so many errors I had to stop it and run clj -M:test.
"so many errors" also manifests on CI ;) https://app.circleci.com/jobs/github/clj-kondo/clj-kondo/37007 these are two different sets of tests btw. but it's fine, I'll take a look
Ah, huh.
interesting, I think something must have changed in the versions that are pulled, error locations seem to have shifted
Yeah, I couldn't make sense of the expected/actual mismatches. Hence my initial thought about the command being woefully outdated.
This also make it correct for vectors?
I found the root issue of the regression tests btw, it makes a test in CLJS now valid and the rest of the errors shift. Just wanted to double check on the vector issue
Ah crap, you're right about vectors.
Updated the PR.
thanks! merged
Awesome!
Does anyone know of a tool that uses clj-kondo's analysis to find unused defmethods? Basically like https://github.com/borkdude/carve but for defmethods
defined "unused". a defmulti without defmethod or a defmethod with a value that is never statically visibly used?
The latter
how many defmethods are statically used? I think most of ours are dispatched ultimately based on values derived from a database of some sort
how can you statically decide that a defmethod won't be used?
sorry my message was lagged due to network issues
Sorry stepped away. Finding unused would be (set/difference defined-dispatches used-dispatches) . defined-dispatches for a given defmulti name could a be reusable fn but it's trivial to write as a one-liner so probably don't need kondo for this. The defmulti's I'm seeing are statically used in a couple different ways. But since this varies per defmulti, I can see why there's no general purpose tool for this
we have
• :defmethod: true when the usage is a defmethod
• :dispatch-val-str: the dispatch val of a defmethod, represented as a string
not sure if that's useful