:discouraged-var: deem clojure.core as equivalent to cljs.core?

[vemv]

I tried the following :discouraged-var rule, in a cljs-oriented project:

clojure.core/for {:message "Laziness can cause rendering issues"}

It didn't work for clojure.core/for, while specifying it for cljs.core/for did.

I would say, for cljs users, clojure.core and cljs.core are largely equivalent.

In specific terms, all of these work in a .cljs file:

(for ,,,)
(clojure.core/for ,,,)
(cljs.core/for ,,,)

So, ideally I could specify clojure.core/for and get what I meant. Otherwise there's a risk of a false negative.

WDYT?

Thanks - V

[borkdude]

I admit that this is a potential source of confusion, but note that this works the same for all linters, not only for :discouraged-var.

[vemv]

Got it. I guess I wouldn't necessarily want to encourage an all-encompassing change, but maybe the end result would be in fact desirable?

[borkdude]

Yeah, maybe we could just allow non-qualified symbols, like for to not break people who rely on the already-in-place behavior.

[vemv]

Yeah, maybe we could just allow non-qualified symbols, like for to not break people who rely on the already-in-place behavior.

I thought about that, however, from the user perspective, for {:message "Laziness can cause rendering issues"} might look ambiguous - does it refer only to clj/s core for, or to any for that happened to be :refered into the given namespace?

---

I have a consideration to add: cljs.core and clojure.core can only considered equivalent on a cljs context. e.g., if kondo is linting a .clj file, a rule defined for cljs.core/for should be irrelevant.

So things would be asymmetric (just like there's an asymmetry when comparing the clj and cljs compilers).

In face of that consideration, does the following concern still apply...?

Yeah, maybe we could just allow non-qualified symbols, like for to not break people who rely on the already-in-place behavior.

As I imagine it, a useful existing pattern (worth not 'breaking') would not be possible. I'd be open to change my mind for a specific example.

[borkdude]

About ambiguous: this is just a matter of documenting, if the docs say it refers to all clojure dialects, it is not ambiguous anymore, but just an agreement of what it means.

Breakage: I don't know exactly where it was but I believe there was one such case in the config of clerk
https://github.com/nextjournal/clerk/blob/main/.clj-kondo/config.edn
I'm pretty confident that when I will make clojure.core/whatever to mean whatever for all clojure dialects, there will be bug reports afterwards. Having the ability to tweak core behavior per clojure dialect is pretty handy since not all clojure dialects work exactly the same, but often you will duplicate configuration. As you can see the clerk config could benefit from having one config for all clojure dialects as well.

[borkdude]

Another option could be to have one symbol to indicate all clojure dialects: core/+ which would mean clojure.core/+ and cljs.core/+. You can accomplish this in user space by introducing a namespace group:

https://github.com/clj-kondo/clj-kondo/blob/master/doc/config.md#namespace-groups

[borkdude]

A good example where you need a distinction between clojure.core/... and cljs.core/... is :type-mismatch:

For cljs.core you sometimes need different type signatures, e.g. for throw, that you can override as follows:

:type-mismatch {:namespaces {cljs.core {throw {:arities {1 {:args [:any]}}}}}}

[vemv]

(apologies for the radio silence - will get back to this as I clear my backlog)

[borkdude]

No worries, I won't have much time this week anyway as I'm heading out to Strange Loop tomorrow