Clojurians Log v2
clj-kondo 2025-04-10
I'm looking into creating a company-wide set of linter rules, (for example "this artifact name is outdated" or "don't use this library"), are there any helpers for this kind of stuff or am I setting up myself for writing a bunch of custom hooks? I looked at (now abandoned) clj-holmes and its syntax rules, and it's more or less what I was looking for but it would be nice to use just one linter, especially that it's bundled with clojure-lsp
ok, looks like custom hooks are the way to go for now - it was easier to put them together than I expected 🙏
That's a common issue we are facing at Nubank, we are thinking about adding support in clojure-lsp for project aware custom linters since the only way to support that today is via clj-kondo hooks but they are aware of the current ns only c/c @andreribeirocamargo
that would be very neat indeed
"don't use this library" is supported (more or less) already via discouraged-var and discouraged-namespace although you have to be explicit about the namespaces
Can discouraged-* linter configs be packaged in a library?
interesting, what about general syntax rules like traversing project.clj dependency list and linting that?
there isn't a special hook for defproject, but I guess we could treat defproject in clj-kondo as leiningen.core/defproject or whatever the right namespace is and then you could make a custom hook for that
yeah, at nubank we want to create defproject linters as well, not only that, deps.edn as well, so using the hook API for that seems a little bit weird
that was one of the things that made me look into clj-watson - I can create patterns like [some.dep $string $&] and alert that some.dep is used, but given state of things clj-watson seems to be a dead end, and clearly kondo should be capable of offering something like this - which I'm more than happy to help with with very limited time
with grasp you can do similar pattern searches, only using clojure.spec: https://github.com/borkdude/grasp you could also do a runtime check in your program whether you're using certain dependencies or a bb script that analyzes deps.edn or project.clj clj-kondo already has several deps.edn checks, we could look into making those more configurable some thought here too: https://github.com/clj-kondo/clj-kondo/issues/1392 and this closed-by-expiration one although we could re-open it: https://github.com/clj-kondo/clj-kondo/issues/1690 note that you're limited to static analysis in clj-kondo
this is helpful, and yeah - I was thinking of using BB, but it felt like I'll be reinventing half of kondo at some point
plus, I mentioned dependencies but that's of course just part of the problem - that `*warn-on-reflection* use case is very much something that I'm also after
I have a good approach for managing reflection warnings on the JVM without any overhead. I'll look into open sourcing it.
It's always going to be tough via kondo.
> without any overhead do you mean, without loading the program?
No I mean without reloading everything with tools.analyzer. Enforcing per-namespace reflection warnings during normal JVM loading.
this is a test I implemented for reflection in httpkit: https://github.com/http-kit/http-kit/blob/fd6b9939fc774f71385a476f56e5cdb046d3d67c/test-graal/bb.edn#L39
and the dev folder contains a user.clj which enables reflection checks here: https://github.com/http-kit/http-kit/blob/fd6b9939fc774f71385a476f56e5cdb046d3d67c/test-graal/dev/user.clj