Actually you don't need lens enabled, clojure-lsp will return a diagnostic saying that function is unused public var

I was more in running it on CI already have it in my emacs 🙂

carve seems exactly what i needed, thanks!

for CI you can check this as well: https://clojure-lsp.io/api/#ci

wow, it is brilliant! thanks a lot

There are various ways to deal with this. From easy + less precise to hard/more work + more precise errors: 1. Suppress unresolved symbols in compojure.api/context or compojure.api/GET etc, using the configuration. https://github.com/clj-kondo/clj-kondo/blob/master/doc/linters.md#unresolved-symbol

2. :lint-as can be used if there is a function/macro that behaves syntactically the same (but that doesn't seem to be applicable here)

3. use :macroexpand hook to write a macro to transform the code into simpler code that clj-kondo can understand. it does not have to transform into code that "works", just into expressions that clj-kondo will lint and make sense for linting. The macro does not have to correspond to the real macro.

4. use :analyze-call hook. Similar to 3. but this gives you more precise locations for errors.

So let's say if we shoot for 3, can you come up with a macro that receives the above expression and turns it into something that doesn't have special syntax?

you can write macros separately for context, GET, POST, etc

let's focus only on GET for now

I've tried 1 and 2 and it didn't work perfectly for me, because then things used within the POST block would not be recognized as used and kondo flags them as unused references. macro I tried, but couldn't figure it out (forgot exact reasons) thought I'm gonna need analyze-call for that, but that turned out to be even more tangled

I'll give a try to :macroexpand hook again

I think 1 should work without any false positives though

(ns foo
  {:clj-kondo/config '{:linters {:unresolved-symbol {:exclude [(compojure.api/GET)]}}}}
  (:require [compojure.api :refer [GET]]))

(GET "/plus" []
     :return {:result Long}
     :query-params [x :- Long, y :- Long]
     :summary "adds two numbers together"
     (ok {:result (+ x y)}))

This works without errors

I don't know the exact namespace for GET, this is just an example

Also when you type:

(let [foo 3]
  (GET "/plus" []
       :return {:result Long}
       :query-params [x :- Long, y :- Long]
       :summary "adds two numbers together"
       (ok {:result (+ x y foo)})))

with that config

are you using the :refer :all like in their README? this could cause problems as clj-kondo has to do guesswork where stuff is coming from

Right. okay. I'll keep playing with this. Sorry for being fuzzy on that. I'm space out a bit, because my last attempt was a couple of weeks ago. And cleaning up things with kondo in a huge project is not "a real work", but I'm doing it as a "side-project"

sure, no problem

Just come back with one isolated small piece of code where 1 doesn't work for you and I'm confident we can fix it

Alright! I guess I was overly excited and wanted to learn how to make custom hooks with :analyze-call, even though might be an overkill for this task 🙂

we can also do that. I think 3 is easier to get started with

@U0G75ARHC I think this could be a good start for a macro for GET :

(defmacro GET [path args & {:as opts}]
  [path args (update opts :query-params
                     (fn [params]
                       (list 'fn (vec (remove  #{':-} params)))))])

(macroexpand '(GET "/plus" []
                   :return {:result Long}
                   :query-params [x :- Long, y :- Long]
                   :summary "adds two numbers together"))

["/plus" [] {:return {:result Long}, :query-params (fn [x Long y Long]), :summary "adds two numbers together"}]

it's not perfect yet, but I hope you see the idea

so that last expression is something which clj-kondo can understand

you'll have to wrap the body of the GET into the function and then it will also understand the usages within the body

Thank you. I'll try this. Really appreciate your help. I think this gives me enough food for thought. I'm sure I'll have to come back again and ask some more questions.

Okay, now I remember why I wanted analyze-call.

So, I have something like this:

(context "/:id" []
  :query-params [{wait_for :- s/Bool}]
  :path-params [id :- s/Str]
  (PATCH "/" []
    ;; ... id an wait_for are used somewhere here

Yes, 1) this is a trade-off, you will ignore all false positives, but won't get additional errors. 2) yes, this is also a trade-off of :macroexpand. if you want precise locations you should make this an :analyze-callhook. The implementation is similar to your macro but is based on nodes rather than s-expressions.

so it's gradually more work but also getting better feedback

afk now, will respond tomorrow