You answered your own question ;)

Is clj-kondo parsing that markdown file?

When clj-kondo looks for inline defs it must use some kind of definition, I am thinking.

But I couldn’t find it on a quick scan of the repo, so I am lazy and ask here. 😃

The default level of that linter is :warning the docs say

The default config is in clj_kondo/impl/config.clj

but this should not matter, the docs should reflect the truth

It’s still not what I want. 😃 I suck at expressing myself. I’d like to know how clj-kondo goes about determining that something is an inline def. So if I would write a similar linter myself, I could look at the one you’ve done as inspiration.

This is intertwined in the analysis if I remember correctly. If you encounter def when you already entered another def or defn then you know it's "inline"

Makes sense. Thanks!

Why are you building your own linter, if I may ask for the context? Just curious

I am not. 😃 I just used that as a vehicle to clarify my question. I am suggesting at work that we make the default level for this linter to be :error, and there was worry that we wouldn’t be able to use defs in some contexts that we do today. Now we know that we can just ban them. 😃

you can use #_:clj-kondo/ignore for the rare cases

Ah, good that you reminded me. Then I can use that on the only case there is in our current code base, before I understand if I can remove it.

usually you want intern I think instead of def for "inline" usage

or for debugging, I still do it a lot, but then remove it afterwards

intern? 👀

(interns *ns* 'the-var some-value)

if you want to dynamically define vars

What’s the difference from def?

def is static

you can not have a variable symbol

also, def creates the var no matter if you're in a condition or not

for example: (when false (def x 1)) still creates the var x but it remains uninitialized

Oh, interesting! Thanks. Lot’s of TILs for me here. 😃

The worry I mentioned above was actually exemplified with a def in a when. Did you guess that? 😃

I did not :)

if I understand correctly, clj-kondo analysis data includes clj-kondo hard-coded cherry picked metadata of interest only

for me, this is probably fine, I am interested in :no-doc which is included.

but probably an accident that it is included for ns only (not vars).

(asking in support of https://github.com/borkdude/api-diff/issues/4)

There is probably a very good reason that clj-kondo analysis data does not simply include all metadata on var/ns, yeah?

Hello

There has been work on an issue to ask for more var metadata, but it stalled.

Would a function work like {:analysis {:var-meta (fn [m] ...)}} work? Syou can just select the extra metadata you want and this will end up in {:var-definitions [{:name ... :meta ...}]?

@UE21H2HHD I made a comment here: https://github.com/clj-kondo/clj-kondo/issues/1280 A PR for this is welcome or I'll do it myself since the question has come up a couple of times lately.

Yeah, thanks, I think that would work fine.

Oh didn’t answer if I am up for this PR. Sure? Maybe? Why not? Yeah, I can give it a go. Unless you’ve already borkduded it!

not borkduding on this one so go ahead :)

So the var is only deprecated in :clj?

Yep

What about:

(def
  #?(:clj ^{:deprecated "reason"} my-deprecated-var
     :cljs my-deprecated-var)
  :bla)

it's a bit more readable too, I personally think

but clj-kondo should probably support the other way too, so feel free to make an issue about it

It seems to work with this syntax… However I was facing this from another library I had required in my project, so Ideally would be great to have this fixed without needing to change it in the source. I will open an issue anyway, but thanks for the workaround for now 🙂

ah that's too bad, yeah, I hope it can get fixed soon