FWIW I have a custom linter for this sort of thing, but where I can I try to get people to use clj-kondo first :)

This has come up before. You can find the reasoning in the original issue on GitHub

My understanding is that it boils down to point 4? https://github.com/clj-kondo/clj-kondo/blob/a550a8279e1bf2134921d5a31b98aa68c60f5a00/doc/dev.md#design-principles

I'm trying to find the original issue but this is extremely hard...

It was in a discussion with Dave Yarwood I remember

I took the link from https://github.com/clj-kondo/clj-kondo/issues/561

ok yes, this is the main consideration: https://github.com/clj-kondo/clj-kondo/issues/561#issuecomment-547539721

there is a little tool here to populate your config: https://github.com/oxalorg/clj-konmari/

> ok yes, this is the main consideration: If that is the main consideration (and not a higher-level design consideration), I disagree. If you have a linter failure for two aliases, you can, instead of adding config at all, solve the conflict by changing one of the aliases. i.e. the 'endgame' is to have consistent aliases, not to have a config. There's a very objective, desirable advantage to this approach: you get consistency enforced for all aliases - not for a cherry-picked subset. i.e. 100% coverage. Had you considered the matter in this way?

I'm afk for a bit, will reply later

Right, so, yes with :inconsistent-alias you can specify the namespaces you care about, namespaces not mentioned there aren't considered. This can be considered a feature or a shortcoming. Some people might consider the linter to be too strict if you would consider namespaces not mentioned there, although this could be configured perhaps. To implement the strict mode, clj-kondo would have to keep data in the cache of every namespace + alias encountered, which is not impossible but also not trivial.

Thanks for the reponse. Maybe I dont agree with "too strict", it's very annoying to have projects with inconsistent aliases. I'd go as far as saying that it's detrimental for the ability to properly code-review things over github, etc. > To implement the strict mode, clj-kondo would have to keep data in the cache of every namespace + alias encountered, which is not impossible but also not trivial. Maybe this is the sort of thing that clojure-lsp is already good at?

There could be a mode in which you lint multiple namespaces at once in which clj-kondo reports this, so not the editor mode let's say, but a CI mode, then it would be much easier to implement.

It's also not so hard to do this yourself in a :custom-lint-fn over the analysis data

(...Again, I have a linter that addresses this https://github.com/nedap/formatting-stack/blob/main/src/formatting_stack/linters/ns_aliases.clj but I'm mostly interested in something that can reach as many people as possible without convincing them of extra tooling etc)

One other thing to consider is: what should the error message look like: Inconsistent alias found for foo: yes, alright, but what to do now? Scan the project for occurrences of foo: or configure clj-kondo's consistent-alias linter? Well, then we're back at where we are now. All trade-offs considered, I think having a small tool like konmari printing a config for you and regularly updating it, isn't too bad

I think the expectation of this linter would be clearer if it were named :preferred-alias , that's really what it is

Example message: The alias foo is inconsistently used in the project. An extended description in the .md could be as verbose as desired. Probably for non-novice Clojure programmers the preferred course of action would be self-evident anyway > I think having a small tool like konmari printing a config for you and regularly updating it, isn't too bad It seems very ugly to have a huge list regularly being spit from a foreign tool. It's just more moving pieces e.g. now I have extra stuff in CI? More security weak spots also > I think the expectation of this linter would be clearer if it were named :preferred-alias I agree with that, but this seems a pretty big opportunity for clj-kondo for making codebases fundamentally better. Which benefits everyone in the community, workplaces etc

Alright, issue welcome.

If you can, leave in the "thumbs up" message so we can poll how much the community wants this, so it can be prioritized accordingly.

I'm also open to PRs

How to I reference node?

(extend-protocol IExpression
  clj_kondo.impl.rewrite_clj.node.token.TokenNode ...

(ns hooks.defs
  (:require [clj-kondo.hooks-api
             :refer [token-node list-node vector-node reg-finding!
                     token-node? list-node? vector-node? sexpr]]
            [clj-kondo.impl.rewrite-clj.node :as node]
            [clojure.string :as str]))

This isn't exposed

I think you're better off using the :tag of the node and use multimethods

Sorry, one more question: what am I doing wrong? I tried to get tags on parent node children: (println head :class (class head) :tag (:tag head)) And I see nils on symbol (TokenNode) tags:

<token: !a> :class clj_kondo.impl.rewrite_clj.node.token.TokenNode :tag nil
<token: !b> :class clj_kondo.impl.rewrite_clj.node.token.TokenNode :tag nil
<list: (invoke> + 2)> :class clj_kondo.impl.rewrite_clj.node.seq.SeqNode :tag :list

one way to go with multimethod is to have dispatch function as (-> % class str), but seems not elegant

Hmm, not sure why the tag is missing. Can you post a issue + repro?

https://github.com/clj-kondo/clj-kondo/issues/1768