@ajarosinski Sorry, I didn't see your question

@ajarosinski I think this will work when you output EDN or text, but not all editors may supports this, so "it depends"

If I’ve written a kondo ‘hook’ function for a macro in a third-party library, what’s the best way to distribute it? Make a PR against that library? Or does it need to go in https://github.com/clj-kondo/config ?

@dpassen1 Cool. Which lib?

Gary Fredericks’ test.chuck

I think the preferred way is to PR it against the lib but if the maintainer of the lib isn't comfortable with this, you can PR it against clj-kondo/config or maintain it yourself somewhere

If you maintain it yourself, you can recommend to users of test.check to also include your lib (with only config) and then it will be automatically copied

Read https://github.com/clj-kondo/clj-kondo/blob/master/doc/config.md#exporting-and-importing-configuration for more

I think clj-kondo/config is nice since it's a central place where people might look for a config

Thanks. I’ll clean it up and try to get in contact with the author of the lib

We have a macro that imports a namespace (creates forwarding defs). Does clj-kondo have an api that enables a hook to access the cached symbols from a namespace? which would allow transforming the import into a sequence of defn/def forms.

@hugod currently not. but you could generate this macro using runtime info and then dump it into the config folder

what do you mean by “runtime info”?

in the REPL

or some function you run periodically

oh, completely outside clj-kondo

yes. e.g. when you eval the namespace you could trigger a side effects which writes the macro

that’s a possibility, I guess, though would require changing our codebase to something very specific for each current call site of the import macro. Seems like it would be simpler to just read the transit files generated by clj-kondo, and use it to rewrite the import calls.

@hugod The transit files are subject to change, not really a public API. The public API for this is https://github.com/clj-kondo/clj-kondo/blob/master/analysis/README.md

right - just looking to see how easy it would be to extend that api. Would that be something you would be open to accepting a patch for?

do you mean, the API of the hooks right?

or the analysis data?

sorry, misread. Yes extending the hooks api to include a function to get the cached data for a namespace.

I think that could be useful. But there is one problem here: the cache may not already been populated.

or it may not be recent. But that seems no different to the behave when linting with a require :all.

true

also the namespace may be coming from clj, cljs or cljc (depending on the caller namespace, this is a bit of trickiness that this API should then account for)

what about leveraging the analysis data, which has everything of your project, and use that to generate the macro?

there is now also a :custom-lint-fn which is called after analysis with the findings + analysis where you could do this

on the JVM

that might also not be ideal since you would have to run this function every time you change an imported namespace

there are some people who went completely away from these kinds of macros towards a code generation approach

clj-kondo has built-in support for this well known macro, I forgot the name

The import macro is used multiple times on different namespaces, so each instance would have to become unique, iiuc.

potemkin was the name

right, unfortunately we’re not using that

what’s the code generation approach?

oh - could we use :lint-as and point to the potemkin versions?

if @lee is around he could tell you what he did to replace potemkin with code generation. the gist of it is instead of letting the macro generate code at runtime, you generate the code and save that to a file

yes, you can use :lint-as iff the syntax is the same

but I assume your macro doesn't literally get to see the var symbols?

Right, it’s literal just passed the namespace name. potemkin doesn’t have an equivalent.

I’ll have a think about how generating a macro implementation could work in the build.

perhaps it could be part of the macro itself

since all those vars go through there anyway

could be - would require some logic to make it dev time only

e.g.

(defmacro import-all-vars [ns]
  (let [vars (ns-publics ns)]
         defs (map (fn [v] (list 'def v (symbol (str ns) (str v))) (keys vars)
         _ (spit ".clj-kondo/macros.clj" `(defmacro ~'import-all-vars .... (case ... ns (do ~@defs ....

you could also just disable the unresolved var linter for an imported namespace

if that doesn't work out, we can see if we can provide the hook API with some cache info

I think I've done a similar thing to make :refer :all work better

I’ll take a look at the implementation of refer :all.

https://github.com/clj-kondo/clj-kondo/blob/07e6d6ce824a8a58d8fbb82652177601b29b0f8d/src/clj_kondo/impl/analyzer/namespace.clj#L218

I could simplify that case to not take into account cljs, etc. since :refer :all is only supported in clojure (JVM)

it's the only spot in clj-kondo where I read from the cache during analysis

so to think about an API: (hooks-api/var-names ns-sym) and this would return all the names. if everything was just clojure, then this would be it.

but cljs/cljc makes it a little bit more difficult.

so perhaps it should take an options map where you can specify more options or so

I'll let you think about it a little bit, at least you know where to look now. And I'm going to sleep on it as well :)

Thanks for the detailed, useful response, as usual! Have a good evening!

is the semantics of your macro that ns1 is basically the same as ns2 ?

@borkdude I spotted the latest clj-kondo don't have a windows release artifact