Honor clj-kondo :unused-namespace config, if present

[vemv]

Context: #359 (comment)

Proposes to read .clj-kondo config in search of :unused-namespace config which is essentially the same as our :libspec-whitelist config option.

This way, refactor-nrepl can discover existing config, keeping things smart/DRY, and also reducing friction for teams using diverse tooling.

Feedback welcome - not necessarily to merge as-is!

[bbatsov]

I'm fine with the proposal. Just make sure it's documented in the docs as well, so people won't be surprised.

[bbatsov]

Let's avoid the problematic "whitelist" terminology. I guess the namespace can be simply named "libspec".

[vemv]

The nice thing about the name is that it maps 1:1 to the existing piece of config.

FWIW I also favor avoiding these terminologies where I can, but often keeping things maintainable/non-broken takes precedence.

[bbatsov]

I know how the config value is named, but I don't see any reason to name a namespace after a configuration option. Especially after in the long run it's highly likely that the current name will be deprecated in favor of some alias with a different name.

[magnars]

If some alternative to whitelist is useful, let me suggest allowlist.

…

On Sun, Feb 6, 2022 at 5:56 PM Bozhidar Batsov ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In src/refactor_nrepl/ns/libspec_whitelist.clj <#361 (comment)> : > @@ -0,0 +1,49 @@ +(ns refactor-nrepl.ns.libspec-whitelist I know how the config value is named, but I don't see any reason to name a namespace after a configuration option. Especially after in the long run it's highly likely that the current name will be deprecated in favor of some alias with a different name. — Reply to this email directly, view it on GitHub <#361 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACA4OJ6ZNX44EEED5RYCG3UZ2R2XANCNFSM5NCZEMYQ> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[bbatsov]

Yeah, that's the most common alternative. Generally I prefer the more specific "allowed-libspecs" or "ignored-libspecs". There's also the part that the name doesn't really imply it's related to clean-ns, so a name like clean-ns-allowed-libspecs would be even better IMO.

[vemv]

, but I don't see any reason to name a namespace after a configuration option.

It would mean a less ample vocabulary one has to learn and fewer mappings to keep in one's head.

Anyway I've renamed the internals to *allowlist. The piece of config itself can be renamed later.

[bbatsov]

Btw, I still don't get why we need a separate ns for this, as there's already a libspecs ns where it seems to me that this would fit. I've never been too fond of overly granular namespaces, unless there are needed to avoid some circular deps.

[vemv]

Yeah that's one of those things that we'll never quite agree on :)

For me an objective decider is that tools.namespace (refresh) works better with fine-grained namespaces, otherwise altering one file can cascade into reloading many more namespaces, which is slower.

[bbatsov]

I get your point, but I've always aimed to optimize code for people not for tools. :-) Anyways, not a big deal.