Fork me on GitHub
#clj-kondo
<
2023-07-12
>
mkvlr07:07:17

morning, the following triggers a warning: Unused private var nextjournal.clerk.eval/nippy-tweaks

(defonce ^:private nippy-tweaks (do ,,,))
I’m using the defonce to run setup code that I’d like to only run once so I don’t think it should trigger a warning. Can file an issue if you agree. Or is there another recommended pattern?

borkdude07:07:52

This is a pretty rare case. For rare cases you can use an ignore hint.

😑 2
genmeblog07:07:41

I've just hit the same problem 🙂 (adding one custom, global listener to the awt event dispatcher)

borkdude08:07:21

Like I said:

#_{:clj-kondo/ignore [:unused-private-var]}
(defonce ^:private dude 42)
There are cases in which you do want the warning. If you only use defonce for side effects (which is only a subset of what you can use defonce for), just use this.

mkvlr08:07:41

so you like kondo to warn when in doubt?

mkvlr08:07:00

for me it’s the opposite

borkdude08:07:20

in this case clj-kondo cannot read your mind why you are using defonce, it can be argued both ways

mkvlr08:07:34

but for these cases you’d like to err on the side of warnings?

genmeblog08:07:55

No worries! Just wanted to share that case can be more common than you think.

borkdude08:07:28

Why are you even creating a var when all you want is some piece of code to be executed once. I think it's just evidence of an edge case of an edge case. Automatically deciding no not warn here is too opinionated. This is exactly why we have ignore hints.

mkvlr08:07:16

I guess we want different things from kondo

mkvlr08:07:56

if you want kondo to warn when in doubt I’ll know not to bring up things like this in the future

borkdude08:07:19

This is not in general the case, I'm only talking about this specific case

borkdude08:07:35

I don't find the evidence to change the current behavior compelling enough, I can see cases where it would work against you

borkdude08:07:50

Might change in the future though

mkvlr08:07:40

hmm, work against you = some dead code at worst?

mkvlr08:07:13

how would you write setup code that should only be executed once?

mkvlr08:07:45

need some state to store that it ran already

borkdude08:07:53

> hmm, work against you = some dead code at worst? exactly, clj-kondo first and foremost is a tool to keep your code clean and minimal, hence the name :) I've used defonce myself in this way but it's not the only way people use defonce. I think not warning would go against the name of the tool ;)

borkdude08:07:31

so just use the ignore hint is the current advice. we could introduce some convention for unused vars that start with an underscore, but this is pretty rare, in the sense that, it has never come up before. I'd be open to that option though

mkvlr08:07:53

makes sense now that you spell it out like this

mkvlr08:07:36

I’m less interested in clean & tidy code but want things to not explode

borkdude08:07:11

I think it's easier to make a mess than to keep things tidy, clj-kondo errs on the side of the latter

👍 2
🧹 2
borkdude08:07:48

also I didn't have my coffee yet and I was a bit grumpy, sorry for that

mkvlr08:07:01

didn’t get that feeling here, all good! Enjoy your !

borkdude08:07:21

(defonce ^:private _foo ...)
is something we could do though.

👍 3
1
mkvlr08:07:34

yeah, guess it would go well together with the handling of fn unused args

👍 2
borkdude08:07:52

ok, I'll add that

💯 2
mkvlr09:07:18

excellent, thank you!

🤝 2
simonkatz16:07:28

After upgrading clojure-lsp and using the new-ish feature that allows clj-kondo metadata to be added to macros (eg {:clj-kondo/lint-as 'clojure.test/deftest}), I’m now seeing .lock files in my .clj-kondo directories. What are these .lock files? Should I commit them into version control? There are also inline-configs directories. Should I commit them into version control? (Sorry if I’ve missed documentation that covers this.)

simonkatz16:07:40

OK; thank you!