@borkdude https://github.com/clj-kondo/clj-kondo/issues/1164 is this something that would be useful?
@adam678 Is it an option to put this code in a :clj
reader conditional?
If not, please make a small repro which clarifies the problem
Replied in the issue
me also 🙂
I'll let the issue be open to gather feedback from the community first.
If this doesn't end up in clj-kondo eventually you can write a custom hook to handle cond and condp yourself
how would I go about writing custom hook, we’ve being bitten in our rear end few times over last days because of condp lacking default case
I will write a small one
https://github.com/clj-kondo/clj-kondo/issues/1164#issuecomment-776679048
1🔥thank you Michiel
np. you might have to do some more work to take into account :>>
, e.g. filter it out, but if you're not using that this should already be sufficient
I tried to make my case here but feel free to close it if you find it to be too narrow of a use case: https://github.com/clj-kondo/clj-kondo/issues/1165 Thanks!
Why don't you suppress unresolved symbol linting for this macro?
{:linters
{:unresolved-symbol
{:exclude [(your-ns/eval-as-clojure)]}}}
I have another feature in the works to only lint .cljc as one language, e.g. only consider the :clj branches and unbranched code as only clj and ignore the rest.
Would that also fit your use case?
This would disable cljs linting for .cljc
The thing is, forms passed to such a macro are Clojure forms which should be linted as usual. In that example, Clj-kondo will end up complaining about format
because it thinks it is going to be called from CLJS as well.
It is essentially about forcing to lint as Clojure in a context where a reader conditional cannot be used.
Unfortunately, forcing linting to Clojure in a whole CLJC file would be a heavy price to pay since you would become blind regarding the CLJS side.
so the macro is always executed by clojure on the JVM side right?
so expanding the macro into #?(:clj the-forms)
in a hook would be the correct interpretation?
this is currently not possible I think but could be an appropriate solution
Exactly so
I guess you didn't have many people requesting that. Outside of tooling, I admit I am not sure how useful that would be in "day to day" code
yes, but adding the possibility of creating reader conditionals to hook code might be generally useful
1👍although still a bit niche maybe
Unfortunately I can't help you much since I am not very aware of the inner workings. I've started writing hooks and taking a deeper look only recently
I'll leave the issue open and will think about it for a while
1🤘Idea for linting: warn about useless ->
in the code like (-> 'x)
.
Sometimes during refactoring I remove all forms in threading macro and miss remaining macro itself.
Maybe also (-> x y)
feel free to post an issue
“Maybe also (-> x y)” NO!
Why? That is like (y x)
with extra chars.
I'm not talking about when y
is a form, that should be fine, but for a symbol or keyword.
Sometime I would like to emphasize that x
is more important in the context than y
. Like (f a (-> b xform))
. This allows me to place accents.
https://clojurians.slack.com/archives/CHY97NXE2/p1612971030126000?thread_ts=1612969334.125300&cid=CHY97NXE2
Interesting, never thought about using it that way. Thanks.