Fork me on GitHub
#clj-kondo
<
2019-08-23
>
yuhan13:08:21

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

yuhan13:08:47

perhaps something like

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

borkdude14:08:39

@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

yuhan14:08:29

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

yuhan14:08:23

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

borkdude14:08:02

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

borkdude14:08:32

maybe macro authors can just document this in their READMEs

borkdude14:08:55

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

borkdude14:08:03

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

borkdude14:08:25

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

yuhan14:08:26

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?

borkdude14:08:00

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

yuhan14:08:08

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

borkdude14:08:48

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

borkdude14:08:21

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

borkdude14:08:00

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

borkdude14:08:59

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

borkdude14:08:41

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

borkdude14:08:39

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

yuhan14:08:42

sounds like a good idea 🙂

yuhan14:08:34

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...

yuhan14:08:01

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

lread21:08:46

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

sogaiu22:08:10

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