I am not very familiar with cljkondo. If there is a way to store lint rules in another library and pass them to cljkondo via config, I would very much love to build/use such a lint rule.

Is such a rule even possible with current capabilities of clj-kondo?

It is possible to build rules for certain function calls

See https://github.com/clj-kondo/clj-kondo/blob/master/doc/hooks.md

This is mostly used to macroexpand custom macros

But you can use it for purposes of linting bodies of function calls too

From an initial skim of the document, it sounds like I have to register my custom code for every function I wish it to be executed against. In my scenario scan was one function where the issue was demonstrated. I would ideally like to lint/check every (as many as needed) function.

@U0A5B1LJU In your case, I recommend to make a fork of clj-kondo to experiment and see how useful your linting rule becomes.

And then you could raise an issue and explain in more detail why you would want to contribute that back

In the case of your linting rule, I expect this would be "too much" for most people, it is very common to not use all arguments in all branches

I noticed this section https://github.com/clj-kondo/clj-kondo/tree/master/analysis#analysis-data-and-tools ... is that a viable option? or forking is more viable?

in the analysis data you can access all locals

where they are introduced, their scope and where their usages occur

but you cannot see if they are in the left or right side of an if for example (I think)

> I expect this would be "too much" for most people, it is very common to not use all arguments in all branches True. Even I am not sure how useful it will be. It is an experiment for me.

I think what you can do with the analysis: You know the scope of each local You know the locations of each usage of the local You know the scope of each var usage (function call)

Then you can decide if there are function calls within the scope of a local that have no local usages

but this will also catch:

(let [x 1]
  (prn x)
  (prn :hello) ;; no usage)

so you kind of have to know if you are a direct child of a conditional

and then you would have sufficient data to calculate this

we could try to add that to the analysis data, if that turns out to be useful

clj-kondo actually already has a callstack like thing

which we could just include in the analysis

but for now, do it in a fork

Would supporting the kind of linter we are theorizing , be a valid reason to augment the analysis data 🙏

for experimentation

it's a chicken and egg problem: you don't know if it's worth adding until you know that what you added it for is useful enough

so a fork is best

Thanks a lot. This is helpful. It will take me a while to understand the code enough to build this. It will be interesting for me to do though 🙂 Will ping in the channel when I need help. Thanks again.

@chris441 can you provide some more specific things that you're not satisfied with?

Sorry, I am right now checking into master a cleanup. One sec.

(base) chrisn@chrisn-lt3:~/dev/tech.all/tech.ml.dataset$ gpush To http://github.com:techascent/tech.ml.dataset b6f9f4e..e3fca12 master -> master (base) chrisn@chrisn-lt3:~/dev/tech.all/tech.ml.dataset$ scripts/clj-kondo src/tech/v3/dataset/io/column_parsers.clj:132:20: warning: unused binding rowcount src/tech/v3/libs/arrow/datatype.clj:15:13: warning: Unused import TimeStampMilliTZVector linting took 969ms, errors: 0, warnings: 2

lol, -- not asking you to look into hundreds of warnings!

😅

I'm now getting: > linting took 1106ms, errors: 0, warnings: 232

on branch master

btw, this config is not correct:

:config-path ["cnuernber/dtype-next"]

it should be: :config-paths

Done. Now I get a few more warnings but not many.

Also I recommend checking in the config for cneurber/dtype-next into the .clj-kondo dir

so everyone who clones the repo can use the config straight away

makes sense.

btw- I am super happy with where this ended up. I get a bit more robustness, linting, and discoverability across every clojure editor as a result of the whole process. Thanks for the help so far - will definitely shout it out.

cool :) I lost track of what the remaining issue is

definterface produces spurious rowcount warning.

That would be one. The second is being able to skip linting for a particular file via config.

Have you tried

{:output {:exclude-files ["regex/for/file.clj"]}}

About the definterface one: I think that's a bug in clj-kondo, please file an issue

you can temporarily put a #_:clj-kondo/ignore before the form to ignore the warning