question about future approaches to macros. does the addition of hooks mean that the https://github.com/borkdude/clj-kondo/blob/master/doc/config.md#unrecognized-macros documented here: Clj-kondo only expands a selected set of macros from clojure.core and some popular community libraries will not be supported anymore in favor of us developing our own hooks? my question is if i want to contribute by updating or adding new built-in support for a macro, should i be exclusively developing hooks or will built-in support for libraries like compojure continue to be maintained?

@epransky Macros that are already supported will remain supported. Macros that are very common can eventually move from hooks to built-in supported.

thanks 🙂

E.g. if someone figures out a hook for core.match, it can be moved inside clj-kondo

Is there a limitation to why we can't write nodes as plain expressions instead of using the api syntax?

like an inverse of the sexpr function

@qythium Yes. I've explained it here: https://blog.michielborkent.nl/2020/06/21/clj-kondo-hooks/

ah, I didn't understand that point the first time round. Thanks!

Also this is more performant. Going from rewrite-clj -> sexpr -> hook -> sexpr -> rewrite-clj takes more operations than rewrite-clj -> hook -> rewrite-clj

But loss of information is the main reason I abandoned the idea

I wonder if hooks docs should link to your blog, it is very helpful. Either that or extracting a few key phrases from the blog to the hooks docs.

PR welcome!

Will do!

Hey! Does the new hooks API allow for allowing for different linting based off of clojure and clojurescript mode? I have a cljc macro for RPC that boils away the body on the cljs side (and instead does an RPC call) and behaves like a defn on the clj side. Since I'm conditionally requiring the clj libraries, lint-as clojure.core/defn doesn't work for me.

@rschmukler Currently there is nothing to go by in the hook, but I could add a :lang key that will contain either :clj or :cljs if that's helpful

@borkdude that'd be wonderful! It might also be worth including a :lang-via which could indicate that the file is cljc. I'm not immediately sure that this is useful at all, so feel free to consider it and ignore it if you can't think of a use case!

@rschmukler In clj-kondo itself I use a ctx map which has :base-lang :cljc and :lang :cljs for example

That's perfect

Also, have you considered somehow allowing libraries to communicate with the hooks library directly? It'd be cool if downloading a library via clojars automatically gave me linting, similar to how typescript allows types to be packaged up in NPM modules.... ie. Could library authors somehow get you clj-kondo hooks for free without requiring you modify the config...

Not sure if it's a road you want to go down, but maybe worth thinking about

I have thought about that: https://github.com/borkdude/clj-kondo/issues/559 For now I suggest library authors to post their configs here: https://github.com/borkdude/clj-kondo/tree/master/libraries Maybe eventually we can have some tool which can inspect the classpath and harvest these configs for you

Hmmmmm and now that I'm thinking about it - giving hooks access to the config could be useful then

ie. imagine if a library auto packages itself with hooks, maybe it has its own clj-kondo settings

I'll check out the issues, thanks for the replies! Super excited for the hooks API, I think it could really be something special if the community widely adopts it

Thank you

@rschmukler Could you maybe add an issue about those extra keys, in case I forget

Will do!