This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (1)
- # aws (17)
- # babashka (2)
- # beginners (14)
- # calva (1)
- # cider (16)
- # clara (1)
- # clj-kondo (68)
- # cljdoc (2)
- # clojure (51)
- # clojure-dev (1)
- # clojure-italy (2)
- # clojure-spec (1)
- # clojure-uk (19)
- # clojurescript (34)
- # cursive (4)
- # fulcro (1)
- # heroku (3)
- # leiningen (36)
- # lumo (28)
- # music (2)
- # off-topic (16)
- # reagent (22)
- # specter (7)
- # sql (7)
How do you think - is it reasonable to check that any particular namespace has consistent aliases throughout the project?
E.g. one file uses
(:require [a.b.c :as c]), another one uses
[a.b.c :as x], the third one uses something else.
I didn't write it, but the data is there now. I got a bit hung up trying to figure out a happy integration story.
@p-himik what I'm referring to is this feature: https://github.com/borkdude/clj-kondo/tree/master/analysis
I've had discussions internally, and some people are really into "context" of reusing namespace aliases. I don't think this can be in kondo because there's no consensus.
It can be there as an "optional" linter that's turned off by default, just like the "missing docstring" one
but it can already be done as a separate script on top of the analysis export, so it doesn't have very high priority
Ok, thanks. I'm using a strange library that sort of encourages/needs
:refer :all and I don't want to turn it off wholesale. But I'm starting to think that turning it of is the best option atm.
I'd be curious why/when it would be encouraged. it doesn't work at all in CLJS for example
@p-himik No, specter encourages but doesn't require that so I use it with a alias usually.
Yep, that's why after starting using clj-kondo, I had no remorse replacing
:require :as. 🙂
@U04V15CAJ it's http://github.com/viasat/salt and it works this way because it will be transpiled to tla+ and it wants to keep the semantic close to that language.
That would be too different from the way tla+ works I suppose. Being near the output is an objective.
But you are right, I can refer specific symbols and it worked. I think I tried to use alias before and that doesn't work.
in general, i avoid using
:refer :all, but i do prefer it in rare cases where a library provides a DSL
when libraries like salt and alda-clj give you a DSL, using
:refer :all lets you pretend that all the public vars in a namespace are sort of a part of the clojure language. like you're not writing clojure anymore, you're writing clojure + alda-clj, or whatever
thanks @U0AHJUHJN, so maybe for these rare cases a rule in clj-kondo would be good then
unless the linter already complains about a lot of other stuff as well, that it doesn't know about
i think it would be useful to have the ability to whitelist namespaces to make them OK to
i don't think
:refer [about twenty-five different vars] would help in cases like alda-clj
when i use alda-clj, i'm putting myself in a mindset where i have a whole language available to me, and it's cumbersome to either have to namespace all the vars, or worry about which ones i've explicitly referred in
if you can provide me with some typical alda-clj code, I'd be happy to take a look in an issue for it
here's an example: https://github.com/daveyarwood/alda-clj/blob/master/examples/clapping-music
to give you an idea of the standard library: https://cljdoc.org/d/io.djy/alda-clj/0.2.2/api/alda.core
note: the unresolved symbols for the referred-all namespace go away once clj-kondo has linted the lib namespace and there is a .clj-kondo directory in the project
@U0AHJUHJN if you feel like it, you're welcome to make PR. if you don't feel like it, that's ok too 🙂
This is the relevant documentation: https://github.com/borkdude/clj-kondo/blob/master/doc/config.md#exclude-unresolved-symbols-from-being-reported
Yeah, I saw that. I was just wondering if it could be undocumented 😉 Do you think that would be a useful addition?
Well, the same library http://github.com/viasat/salt has a thing where when you create a variable
x it creates another
x' that is the next step for
x. I want to whitelist
#".*'$" in this case.
If it's just to support this library I would say it's not a strong enough case yet. But you can blacklist certain files in your project so linting is turned off there