I thought it did that automatically...?

I thought it was going to, a few months ago. I might just be exporting wrong.

I've added the "resources" folder to my deps.edn :path vector, per the docs. Here's my project https://github.com/johnmn3/dispacio

nevermind, I just had to restart vscode

I guess the last issue I have is that my defmethod lint-as thing is not taking effect on subsequent instances of the defined methods:

Is the only to handle that with hooks?

:lint-as should work I think... That's how I do it in Expectations.

Here's my config.edn: https://github.com/johnmn3/dispacio/blob/master/resources/clj-kondo.exports/net.clojars.john/dispacio/config.edn I'm a little scared to bite off implementing a hook. I tried making one that wrapped the body in a do and added a (declare the-thing-name) at the top of the do form, but I couldn't get it to work

Hmm, here's what I have in Expectations: https://github.com/clojure-expectations/clojure-test/blob/develop/.clj-kondo/com.github.seancorfield/expectations/config.edn -- completely different path to what you have.

Hmm, according to the docs, your path is correct. No idea, sorry.

Oh, wait, I have it there as well https://github.com/clojure-expectations/clojure-test/blob/develop/resources/clj-kondo.exports/com.github.seancorfield/expectations/config.edn

hmm, maybe you can't have a :lint-as and a :linters config for the same symbol

hmm, not sure. Thanks for checking @U04V70XH6

I think using a hook is a better option here than linting as + repressing unresolved symbols

I'll try locally when I'm at the keyboard

@U050PJ2EU Made a pull request which fixes the above issues. You can execute clj-kondo --lint .clj-kondo/test.clj to see that it works, with the newest clj-kondo.

https://github.com/johnmn3/dispacio/pull/2

@U04V15CAJ There might be an issue with the paths

dispacio/dispacio?

going to try to remove one level of dispacio

No, this is correct

You just have to use the newest clj-kondo, released yesterday

aaah

In the newest clj-kondo, the .clj_kondo extension is supported

for hook code

to not confuse it with application code

and I used that

Okay. So that'll flow in from clojure-lsp at some point?

Perhaps @UKFSJSM38 can tell you how to use the master version of clojure-lsp

Yes. You can try with the clj-kondo vscode extension now if you want btw and disable linting in clojure-lsp

temporarily

I just pushed to master the bump of clj-kondo on clojure-lsp, if you want you can use a nightly build on #clojure-lsp-builds

awesome!

Am giving the clojure-lsp nightly a whirl on macOS doom emacs.

@UKFSJSM38 I guess I should be viewing the new .clj_kondo files in clojure-mode?

Probably missing changing that on clojure-mode, right @U04V15CAJ?

We should open a PR there and on other projects to consider that as a clojure file like clojure-lsp itself 😂

When I do switch to clojure-mode for a .clj_kondo file, I do get an odd finding for that file:

This could entirely me just being emacs-naive and not doing some more setup/config?

IIRC that can't parse comes from kondo, probably we need to consider .clj_kondo files as clj ones as well there

But the .clj-kondo hook files are being picked up and used for linting. And the enhanced macroexpand hook behaviour seems to be pinpointing errors at their location.

Do you repro that if you use latest kondo and lint manually that file via CLI?

Good question… Here’s the hook source:

(ns etaoin.impl.util)

(defmacro defmethods
  "Declares multimethods in batch. For each dispatch value from
  dispatch-vals, creates a new method."
  [multifn dispatch-vals & fn-tail]
  `(doseq [dispatch-val# ~dispatch-vals]
     (defmethod ~multifn dispatch-val# ~@fn-tail)))

;; essence only for linting
(defmacro with-tmp-file [prefix suffix bind & body]
  `(let [~bind "somepath"]
     ~@body))

❯ clj-kondo --version
clj-kondo v2022.05.29
❯ clj-kondo --lint .clj-kondo/hooks/etaoin/impl/util.clj_kondo 
.clj-kondo/hooks/etaoin/impl/util.clj_kondo:11:26: warning: unused binding prefix
.clj-kondo/hooks/etaoin/impl/util.clj_kondo:11:33: warning: unused binding suffix
linting took 12ms, errors: 0, warnings: 2

So, the answer is: no.

Perhaps clojure-lsp is passing a wrong --lang clj_kondo or so

Hum, probably, I will take a look soon

Yup, I think borkdude is onto something there:

❯ clj-kondo --lint .clj-kondo/hooks/etaoin/impl/util.clj_kondo --lang clj_kondo
.clj-kondo/hooks/etaoin/impl/util.clj_kondo:0:0: error: Can't parse .clj-kondo/hooks/etaoin/impl/util.clj_kondo, No matching clause: :clj_kondo
linting took 6ms, errors: 1, warnings: 0

Maybe lsp is passing in --lang :unknown ?

Not pass any --lang ... probably, unless you know what you're doing ;)

lang defaults to clj if you don't pass anything and the extension is unknown

And my example above shows that I will leave in lint warnings without clj-kondo/lsp help. I am totally dependent.

I'll change to not pass lang

@U04V15CAJ does it make sense to lint hooks code? I guess so, but would like a borkpinion.

Maybe call hooks more so than macroexpand hooks?

I think it makes sense to lint it while developing those

@UKFSJSM38 It depends how you are calling clj-kondo. If you pass just stdin text without a filename, then clj-kondo cannot guess the language, so you can give a hint --lang cljs or so

But if you just pass the filename with the extension, then clj-kondo will derive the language from that

Just pushed the fix on clojure-lsp

Awesome!!!

Just gave it a go @UKFSJSM38, my .clj-kondo files are no longer producing lint warnings!