I can see this being useful via clojure-lsp if it could figure out the most common alias used for a given ns and then flag all the other aliases as not matching that. I would not use this, however, because we have a convention of always using sut as the alias for the primary ns being tested in our test nses, so it would always flag those as inconsistent. We tend to use the alias linter almost solely for 3rd party nses.

sut ≟ stuff undergoing testing

well, we could build a configurable exclusion for sut etc of course

clojure-lsp already has the data it needs to implement this feature. clj-kondo could do it too but then you'd just get the feature when linting a directory, not via the editor (unless we keep more stuff in the on disk cache, which is kinda complicated)

cc @UKFSJSM38

I do think this is quite useful, but IMO would be nice to have built-in clj-kondo similar to unresolved-var linter which has context about other ns

If you have 100 uses of a ns and only one is inconsistent, the order you lint the code matters... If you see the inconsistent use first, the other 99 will be flagged; if you see it elsewhere, only that 1 use would be flagged:grin:

AFAIK clj-kondo does that for unresolved-var lint which reports when you have a unknown function from an alias

sure, I'm willing to think about it but then we get at the "complicated caching" bit, since clj-kondo needs to know about all aliases used in the project for a certain namespace. the process would be like this, when in an editor:

(ns foo (:require [clojure.string :as str]))

(ns bar (:require [clojure.string :as string]))

{clojure.string {str #{foo} string #{bar}})

Got it, how we update the cache for the unresolved-var case? indeed doing in clojure-lsp should be easier

unresolved-var and invalid-arity, etc etc are all just part of layout by namespace

.clj-kondo-cache/v1/foo/bar/baz.transit.edn

I see, I think I or @U04CAPVN1HS can take a look how hard would be to implement as a new custom linter in clojure-lsp

I think the only difficult thing about the on disk cache is: how to efficiently detect removals, e.g. when you change or remove an alias, how would you efficiently update the on disk cache

but perhaps this problem is actually similar with clojure-lsp, but just in memory

yep, we already do the same for unused-public-vars, so we have a ns dependency graph which helps both in performance and find that

nice