This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (12)
- # babashka (36)
- # beginners (126)
- # calva (26)
- # cider (10)
- # clj-kondo (71)
- # cljdoc (3)
- # cljsrn (2)
- # clojure (232)
- # clojure-australia (1)
- # clojure-europe (11)
- # clojure-france (20)
- # clojure-nl (4)
- # clojure-norway (1)
- # clojure-serbia (4)
- # clojure-uk (6)
- # clojurescript (62)
- # conjure (5)
- # cursive (12)
- # data-science (1)
- # datomic (57)
- # deps-new (1)
- # duct (3)
- # emacs (5)
- # events (8)
- # fulcro (6)
- # graalvm (5)
- # helix (3)
- # jobs (6)
- # jobs-discuss (3)
- # kaocha (4)
- # lsp (128)
- # malli (12)
- # missionary (22)
- # off-topic (1)
- # pathom (7)
- # polylith (27)
- # quil (1)
- # re-frame (20)
- # react (9)
- # reitit (12)
- # releases (8)
- # remote-jobs (3)
- # sci (3)
- # shadow-cljs (9)
- # spacemacs (10)
- # tools-deps (7)
- # vim (7)
- # xtdb (14)
@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 ?
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
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
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?
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.
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
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
The import macro is used multiple times on different namespaces, so each instance would have to become unique, iiuc.
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
Right, it’s literal just passed the namespace name. potemkin doesn’t have an equivalent.
This is very sketchy pseudocode. I think the clj-kondo config macro would have to be extensible using a multimethod or so, so each time the macro is called with a different ns, this different ns registers another defmethod to which the macro can dispatch and appends that to the file.
(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 [email protected] ....
if that doesn't work out, we can see if we can provide the hook API with some cache info
I could simplify that case to not take into account cljs, etc. since
:refer :all is only supported in clojure (JVM)
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.
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 :)
@UKFSJSM38 ^ I'll probably have to do a new release tomorrow for Windows