It's complaining about this because clj-kondo doesn't see a require of the namespace clojure.core.async before the expansion of this macro. You can fix this by providing another bit of config:

{:config-in-call {app.test-utils/with-fx-ch {:linters {:unresolved-namespace {:exclude [clojure.core.async]}}}}

Is it unable to see the require in the config macro or the prod macro? the prod macro ns has the require, though the macro itself is using fully qualified fns.

It would have been easier if your macro followed a syntax of an existing macro, so you can use :lint-as. Can you give an example of how this macro is called in practise? It might be similar to cljs.test/async

If you have a namespace like this:

(ns foo (:require [app.test-utils]))
(app.test-utils/with-fx-ch ...)

(ns foo (:require [app.test-utils]))
(let [.. (clojure.core.async/chan 100)])

and in that namespace, clojure.core.async hasn't been required yet, so clj-kondo complains about it.

another way to suppress this from the macro expansion side is:

(vary-meta ... assoc :clj-kondo/ignore [:unresolved-namespace])

but this will suppress all such problems within the macro usage

Sample usage

(testing "some side effecty code"
  (test-utils/with-fx-ch [effects]
    (testing "scenario X"
      (execute-the-subject)
      (email-sent? effects))))

I'd just add the config

it seems you could also use {:lint-as {your.ns/your-macro clojure.core/fn} perhaps

Seems to work fine:

(ns app.test-utils
  {:clj-kondo/config '{:lint-as {app.test-utils/with-fx-ch clojure.core/fn}}}
  (:require [clojure.test :refer [testing]]))

(defmacro with-fx-ch
  [[nom] & body]
  `(let [~nom (clojure.core.async/chan 100)]
     (with-redefs [app.effects-dispatcher/dispatch
                   (fn [[k# v#]] (clojure.core.async/put! ~nom {k# v#}))]
       ~@body)))

(testing "some side effecty code"
  (with-fx-ch [effects]
    (testing "scenario X"
      (prn effects))))

Yeah. I tested it locally and it works!

I wouldn't have seen that equivalence with fn . Thank you!

Can you give the complete form?

does it have problems with the first or the second?

problems with the first form I mean. When I have more args in front.

(defn-handler {:permissions :read-application} retrieve-foo
 [{{:keys [application-id]} :path-params :as req}
  {:foo :foo}])

yeah, that's not syntax that defn has so it won't work. why not use var metadata instead of a custom macro?

or you can support the map after the name in your custom macro, then it would work since that's where normally the metadata goes

(defn foo {:hello :there} [])

I guess we were to macro happy in the code base I am working rn

its a good lesson, if you make a defn macro, add extra args to where the body usually goes I guess. In the spot that :pre etc goes I suppose

the other option, other than writing a hook is to use {:lint-as {your.ns/your-macro clj-kondo.lint-as/def-catch-all}

👀

it should yes

do you have a reason to believe it doesn't?

Not at the moment, just reading up on the feature itself and saw that the examples use .clj as the file extension for the expansion files

That's probably just from before

PR welcome to change it

are macroexpansion definitions distributed the same way with libs as other config/hooks?

yes

> PR welcome to change it Will do once I confirm it works

cc @UKFSJSM38

@UCY0GT0QM The clojure-lsp/* linters are implemented by #lsp - it might help asking questions over there

oh I suppose those :exclude-when-defined-by etc. options are a clojure-lsp custom thing. I'll poke around in its implementation.

@UCY0GT0QM https://clojure-lsp.io/settings/#clojure-lspunused-public-varare the docs detailing all possible settings for that linter, but I'm wondering if we should exclude vars defined with ^:export meta, WDYT?

I think that makes sense. ^:export is indicating that it's used out of scope, so even aside from the macro I wouldn't want an unused-public-var warning on (defn ^:export some-fn-called-from-js [] ...)

the issue with defined-by for macros is that relies on user defining :defined-by in clj-kondo hooks like https://github.com/nubank/state-flow/blob/master/resources/clj-kondo.exports/nubank/state-flow/nubank/state_flow.clj#L35 :/

ah, I see. so that sounds like my resolution is to use hooks instead of :macroexpand and set that rule accordingly.

Yeah, makes sense, feel free to create a issue where we can discuss the implementation at clojure-lsp

yes, as a workaround that may work

well, that's separate from the ^:export thing. actually now that I think about it, that already works. there's a separate ^:exported function here with no warning about that. if I un-`^:export` it, I get an unused warning.

at nubank we have custom vars with a specific meta as well, so maybe we should allow user define metas to exclude, but if exports is a cljs/clj thing/standard, clojure-lsp should support OOTB

shadow-cljs recently added a non-standard ^{:export-as "jsFunctionName"} option too, that should probably have the same semantics as ^:export (`^:export` is CLJS standard, not just shadow-cljs)

oh, indeed we already have support for export did one year ago

https://github.com/clojure-lsp/clojure-lsp/pull/753

yeah, probably should have more work to support export-as

let me try setting :export true on the dummy defns in my :macroexpand

(defn foo []
  {:export true} ...)

althought from the linked PR I don't see how metadata is picked up

okay, metadata after the args doesn't work (not sure why) but ~(vary-meta sym assoc :export true) on the defns in the :macroexpand does work.

I think the only resulting action here should be documenting that the :exclude-when-defined-by only works if the :defined-by is set in the hook for that macro. I imagine plenty of libraries with defn-ish macros have that built in, but if you're building something of your own then it's weird that the option doesn't work.

agreed, TBH I didn't pay attention that :exclude-when-defined-by could be used by macros, worth mentioning that

I can file an issue with clojure-lsp's docs if you like.

Sure!

I lied there's also the :export-as thing. https://github.com/clojure-lsp/clojure-lsp/issues/1511 https://github.com/clojure-lsp/clojure-lsp/issues/1512

thanks, I mentioned in the last one how it should be fixed, LMK if you wanna work on that

I haven't actually tripped over it yet, but probably will later this week or next week. I'll fix it when I do, or when I've got some idle time.