Is it possible for library authors to define linter configs for consumers of the library? Sort of the inverse of the current method of using {:clj-kondo/config '{:lint-as ...}} metadata, which has to be done manually by users on a per-project/namespace basis

perhaps something like

(defmacro my-defn
  {:clj-kondo/lint-as `defn}
  ...)

@dharrigan thanks!

@qythium that's currently not possible but that could be useful indeed. macro authors could also give some more hints to clj-kondo where they introduce new vars or bindings

yeah, one concern would be whether it's too tightly coupled to a specific implementation - eg. Joker could use that information too but wouldn't look under a :clj-kondo/... namespace

I recall there was some discussion before about a :tooling/.. naming convention

one other concern would be that some people would find it cluttering their code if they don't use a linter

maybe macro authors can just document this in their READMEs

or if they have a .clj-kondo directory, maybe clj-kondo could pick up on that

library/src/clj-kondo/config.edn <- this config will be "exported"? but then that would only work if you linted your entire classpath

if you would only lint your git-staged files you would already not see that config, so it might be too fragile

ah, do you mean that anything in a .clj-kondo/ directory won't make it into the exported JAR, so there would be no way to get that information if someone uses the lib as a Maven dependency?

even if it would be in the jar, it would only be seen by clj-kondo if you lint your source + all your libs

I had the impression that was what it did anyway? otherwise how does it provide arity warnings for 3rd party libs

I guess clj-kondo could save config information while linting libs also to the cache, but I'm not sure if that works yet

you'll get the problem of the config being scattered over multiple places which can be hard to debug and understand

so for now it might be a good start if library authors started documenting their preferred clj-kondo config in their README

we can also make some command line option to generate a config file based on what is in your libraries, that might be a more transparent way

so if library authors exported some clj-kondo config, this command line option would gather those and add them to your config.edn

they could put it under libary/src/library/clj-kondo.export.edn or something

sounds like a good idea 🙂

I wonder if a good heuristic anyway would be to ignore unresolved-symbol warnings for the 2nd position in any form that starts with def...

that and any symbol that starts/ends with let would probably cover a good majority of these macros

Just used clj-kondo tools to find unused vars. It sparked much joy!

😄

careful, that joy-sparking could be contagious! oops, too late 😄