is this just an idea or something you're experiencing as a problem? In my experience when writing a .cljc file you usually get sufficient warnings if you're trying to do a JVM thing in an un-reader-conditionalized part of the code

Thanks for the shift in perspective! It’s more of an idea I think. We have a huge CLJS-based app, and would like to test and run parts of it on nodejs. Converting everything to CLJC is probably not happening, but would be the sensible thing to do if we wanted it cross platform

What I have is:

(ns hooks.spec-generate
  (:require [clj-kondo.hooks-api :as api]))

(defn generate-> [{:keys [node]}]
  (let [[_ & body] (rest (:children node))
        new-node (api/list-node
                  (list*
                   (api/token-node '->)
                   nil
                   (if body
                     body
                     (api/list-node
                      (api/keyword-node :default)))))]
    {:node new-node}))

But when the call site has, eg:

(generate-> :first-arg (assoc :foo :bar))

so I feel like I'm Doing It Wrong:tm: but can't work out why

config.edn (extract):

{:hooks
 {:analyze-call {finops.spec/generate-> hooks.spec-generate/generate->}}}

This might be easier with a macroexpand hook

This looks wrong:

(api/token-node '->)
                   nil

You should probably write:

(api/token-node 'clojure.core/->)
(api/token-node nil)

and (api/list-node ..) should be called with a list-like thing, not with a single node

if you call clj-kondo on the command line with --debug it will tell you that latter error

probably also the other error for nil not being a node

Yeah, all that fixed it. I think I understand the hooks API a little better now, thanks!

as one who writes a lot of hooks lol, I wonder what's gained by having to manually write api/token-node and api/list-node etc. is there something special about those that a postwalk couldn't do?

or if you don't want to enable it for everyone, maybe there could be a helper function to do it that hook authors can use themselves

This is what the :macroexpand hook does?

oh really?

yes

is that the only difference? for some reason, I thought :macroexpand did other stuff too

the differences are described in the docs, but in short, macroexpand is less powerful

since you don't have precise control over locations: numbers, etc cannot carry metadata

but for def-whatever like macros it's often enough

can you call reg-finding! in them? does it work the same otherwise?

yes, you can

hell yeah, okay

the docs made it seem like it was more magical and couldn't do all the same stuff as :analyze-call

maybe you read magic into it?

it's not magic, but it's less accurate because of loss of data while translating to s-expressions and back

also there is currently a problem with namespaced keywords like ::foo/bar - those aren't properly converted back and forth

not many people have noticed that though

right. i think the lack of examples and the short docs made me think it was fundamentally different from :analyze-call. the analyze-call docs are long and have lots of examples, and the macroexpand docs don't say "this is analyze-call but with coercion".

maybe i'll write up an example that calls api/reg-finding! to demonstrate that it all works the same as :analyze-call except for the returned type

that would be nice :)

macroexpand didn't exist at first when those docs got written

i did some looking through the hooks code and it turns out you have api/coerce in there already, so that's exactly what i was looking for lol. from

(let [defn-block (api/list-node (list* (api/token-node 'defn-)
                                           job-name
                                           (api/vector-node [fn-arg])
                                           body))
          node (api/list-node [(api/token-node 'do) defn-block job-name])]
      {:node node})))

(let [node (api/coerce `(do (defn- ~job-name [~fn-arg] ~@body)
                                ~job-name))]
      {:node node})))

once again, you've outdone yourself and have made my development life easier. thank you!

thanks!

I think clojure-lsp is in a better place to do this than clj-kondo since clojure-lsp runs as a server and scans your entire project. It is possible to use the existing data as shown here: https://github.com/clj-kondo/clj-kondo/blob/12342316a4eecf1c543f1f1dbfd283b6cc68dc68/analysis/README.md?plain=1#L454

A macro that should have been linted as clojure.core/fn was linted as clj-kondo.lint-as/def-catch-all incorrectly

With 2023.09.07 it runs, but in 2023.10.20 it fails to parse and throws an NPE

I'm carving out a small repro

This bug was already reported and fixed on master.

Ok great

Thank you

https://github.com/clj-kondo/clj-kondo/commit/e49369b0886b104832eb9f67711042987dc166df

We're fixing our lint-as config