Add setting that allows keeping unused unaliased requires

[OknoLombarda]

#292
#359

Add setting that allows keeping unused unaliased requires, disabled by default

• The commits are consistent with our contribution guidelines
• You've added tests (if possible) to cover your change(s)
• All tests are passing (run lein do clean, test)
• Code inlining with mranderson works and tests pass with inlined code (run ./build.sh install -- takes a long time)
• You've updated the changelog (if adding/changing user-visible functionality)
• You've updated the readme (if adding/changing user-visible functionality)

Thanks!

[OknoLombarda]

I'll add tests and update readme if you have no comments regarding the code

[expez]

The example in clj-kondo linters file is (ns foo (:require [foo.specs])).

In other words, this will allow both foo.specs and [foo.specs] to remain, but isn't the wrapping what's used to signal that it's side-effecting in the clj-kondo convention?

[OknoLombarda]

It doesn't seem like clj-kondo cares about brackets

[vemv]

The resolution of #359 (comment) is quite more recent than the one of the other issue.

I'd like refactor-nrepl to contribute to a more explicit, standarized tooling landscape.

The lack of an alias does't mean much in official Clojure terms. The extra semantic is a clj-kondo invention, that precedes its more explicit :unused-namespace config.

So I'd prefer that people write explicit .clj-kondo config. It's something that refactor-nrepl currently reads. It also is something that other tools (e.g. Eastwood) could also eventually read.

It's a much better approach than reading magic comments (#_,,,) or making up semantics. For users and tool makers alike.

[vemv]

Also, non trivially, one approach is naturally more prone to false positives than the other.

If I add an entry to my .clj-kondo file, then my intent is certain.

Contrariwise, adding [some-lib] without an alias is an everyday action, it can happen for any reason, from any person. So we can easily get a false positive.

For that reason alone, e.g. making our tools correct I think the right approach is clear now. It's not just aesthetics or 'standards'.

Will be moving this PR to draft (with the intent of closing it if there isn't much opposition)

[OknoLombarda]

Yeah, I just though that'd be convenient, but you're right, picking convenience in some situations over correctness is not worth it 【⸟ ͟ʖ⸟】

[magnars]

Any reason this could not be extended to actually using the clj-kondo file? Or is that already supported?

[OknoLombarda]

It is already supported #361

[magnars]

Excellent 👍👍

[vemv]

Thank you both for the understanding! 🍻