clj-kondo 2023-07-01 | Slack Archive

dharrigan18:07:17

Is there a configuration knob that will tell clj-kondo to not lint a file (or set of files based upon regex?), I mean totally skip linting a file (rationale - I have in a project several edn files that are megabytes in size, and it takes a long long time for clj-kondo to lint them all (and they aren't worth linting as it's generated content)

borkdude18:07:26

I could have sworn we had an issue for this but no, this currently isn't possible. A workaround is to just enumerate the paths you do want to analyze/lint: src:test:whatever

borkdude18:07:37

but we should really just support excluding files

dharrigan18:07:46

That would be appreciated, as clj-kondo (embedded with clojure-lsp) is scanning all these edn files and taking minutes for the editor to become responsive.

borkdude18:07:11

perhaps lsp does support such an exclusion pattern already?

dharrigan18:07:23

checking

dharrigan18:07:16

Can't see anything obvious that would disable invoking clj-kondo (as the edn file are on the classpath)

borkdude19:07:29

ok, made this issue and will implement it as part of the next version, hopefully somewhere next week https://github.com/clj-kondo/clj-kondo/issues/2128

dharrigan19:07:50

w00t

dharrigan19:07:51

thank you

dharrigan19:07:15

I'm asking on clojure-lsp to see if I've missed anything about disabling the invocation of clj-kondo for a set of files

dharrigan19:07:54

(for reference, the totality of the edn files is about 81 megabytes, that I don't need to lint)

👍 2

jacob.maine23:07:36

The analysis reports that the :ns of the following keyword is __current-ns__. I think it should be foo. I have a fix, but wanted to check here first… is there a reason it needs to be __current-ns__?

(ns foo)
#::{:bar 2}

didibus01:07:23

My guess is that yes, this seems like someone went out of their way to introduce this. I think it's to indicate that :: is used, so the namespace is dynamic.

jacob.maine03:07:28

I have several reasons I don’t think it was intentional… First, to clarify, by “dynamic” I think you mean “auto-resolved to the current namespace”. Is that correct? • There are many other situations that auto resolve to the current namespace, and all of them provide the true :ns. In the following, the only keyword that says :ns is __current-ns__ is the marked one. All the rest resolve to definer.

(ns definer)
  ::defined
  #::{:defined 1} ;; <-- this is the only one that resolves to __current-ns__
  (defn f [{:keys [::defined]}] defined)
  (defn f [{::keys [defined]}]  defined)

• Similarly, when using an alias, the correct namespace is always resolved. In the following, the analysis reports that the :ns of every keyword is definer (n.b. not aliased). ◦ Unfortunately, not all of these have :alias, only the first and third. I assume that’s because those are the only ones that have a /. But that reflects how they’re written, not what they mean, which is usually what the analysis is supposed to give us.

(ns aliaser (:require [definer :as aliased]))
  ::aliased/defined
  #::aliased {:defined 1}
  (defn f [{:keys [::aliased/defined]}] defined)
  (defn f [{::aliased/keys [defined]}]  defined)

• There are other attributes on analysis elements that describe how the keyword is written and what it means, including :auto-resolved, :namespace-from-prefix, :keys-destructuring, and :alias. • The analysis emphasizes what an element means, and de-emphasizes how it was written. Using __current-ns__ achieves the opposite goal. ◦ :__current-ns__ is assigned in the parser, but doesn’t seem to be intended to escape into the analysis. ◦ The analyzer has enough information to know that the ns should be definer, so it’s surprising that it discards it. OTOH, there’s an argument to support your point… If :ns were changed from __current-ns__ to definer, the analysis of the following two elements would be the same. Because of their equivalence, I don’t think it’d be possible to work backwards from the analysis to re-generate what was written. I’m not sure that’s a goal of the analysis, but it’s something to keep in mind.

(ns definer)
  #::{:defined 1}
  (ns aliaser (:require [definer :as aliased]))
  #::aliased{:defined 1}

I guess what I really wish is if it were always possible to tell both how a keyword was written and what it means. There’s a lot to keep track of. • If in a namespaced map, the keyword itself needs information from the map to distinguish between: #::{:foo 1} or #::aliased{:foo 1} or #:literal{:foo 1}. • If in destructuring keys, the keyword needs information from the destructuring to distinguish between :keys [foo], ::keys [foo], ::aliased/keys [foo] and :literal/keys [foo]. ◦ In destructuring, it would also be nice to know if the user wrote :keys [foo] or :keys [:foo], which have the same meaning. • On the keyword itself, you need to distinguish between :foo, ::foo, ::aliased/foo, :literal/foo, and :_/foo. The last has special meaning if and only if in a namespaced map or in destructuring.

🙌 2

jacob.maine04:07:05

I have a tendency to be long-winded. 🙂 A more succinct way to say all of that is: I’d like to know the resolved namespace of (ns foo) #::{:bar 1}. Is changing the analysis to replace __current-ns__ with foo the best way to do that?

borkdude06:07:29

I don't know why it's __current-ns__ , perhaps just a bug, feel free to post an issue + proposal PR

2023-07-01

Channels