for the record, it does, else I would have stopped maintaining it

https://github.com/clj-commons/meta/issues/71#issuecomment-1424338506 is aligns with my sense of Kibit compared to the others so I guess I'm not imagining things.

To me, Eastwood and clj-kondo are direct competitors but Kibit is something else and it's valuable and I think more people would use it if its parsing was brought up to date which is what @UEENNMX0T is offering, I believe.

I use Eastwood on HoneySQL but that's purely historical -- I inherited that in 1.x and just never got around to replacing it with clj-kondo 🙂

I rely on Eastwood to report on deprecated APIs in java libs. Very handy for that.

And reflection warnings on a very fine-grained manner. And more linters :)

The thing is that what kibit does could be implemented using kondo's tech, which has is very suitable given its speed and is particularly well-understood and interoperable (think clojure-lsp) There's no need to implement every kibit bit as an officially accepted clj-kondo linter, I believe. It has extension APIs. So there would be no need to clearly delimitate what a "linter" is - it's all very blurry. Much more practical to implement/choose whatever you deem necessary.

True, if Kibit could essentially be rebuilt on top of clj-kondo, I think that would be a great way forward -- since LSP/clj-kondo are so widely used now.

I've thought about doing that, to be honest. My issue is that writing clj-kondo hooks/lints is really cumbersome, you have to do all of the destructuring and checking yourself at each step: is the number of args N? is the second arg Y? is the third arg a map with x y and z? etc

Kibit's usage of core.logic to handle pattern matching on sexprs is really powerful and doesn't currently exist in the clj-kondo universe, in part due to the way clj-kondo (and rewrite-clj underneath) build their data

Ah, good point. And core.logic isn't compatible with sci at the moment, I guess?

I have an in-progress/abandoned pattern matching library (https://github.com/NoahTheDuke/spat) built specifically for clj-kondo's data shape, maybe this is a good reason to finish fleshing it out.

Perhaps it would all start with making a comprehensive table of kibit-exclusive features (linters, if you will) As mentioned I'd be super happy for those to be implemented in clj-kondo, but if that task indeed feels too low-level, I'd be willing to facilitate its implementation in Eastwood. February would be great month to do so for me, and also I know @UEENNMX0T likes to hang out in the Eastwood issue tracker from time to time :) For the hopefully!