…. or are these just ghosts from older versions of clj-kondo?

these are configurations imported automatically while scanning the classpath

you can disable this in .lsp/config.edn :copy-kondo-configs? true

you are probably seeing these configs because of babashka support in lsp

if you are using those configs, you can check them into source control, else you can ignore / delete them

I think it’s good to have them, just not in the version control as they get created automatically and don’t need versioning.

if the config.edn is the only relevant file, this should be ok:

.clj-kondo/*
!.clj-kondo/config.edn

… but maybe if the configurations were imported under one folder, it would be easy to exclude, maybe even under .cache?

> I think it’s good to have them, just not in the version control as they get created automatically and don’t need versioning. This isn't true. They are only copied from the dependencies because lsp does this. If you want to have the same linting in CI, it's good to version those things into version control.

The recommended way is to include them into version control, so everyone who uses clj-kondo with this repo gets exactly the same linting, whether you use lsp or not

good to know, thanks!

[lassemaatta@archlinux] 10:58 $ echo '(def parse-long 1)' | clj-kondo --lang clj --lint -
<stdin>:1:1: warning: parse-long already refers to #'clojure.core/parse-long
linting took 7ms, errors: 0, warnings: 1

clj-kondo v2022.03.09

I'm creating the local cache with the typical --dependencies --parallel --copy-configs

the clojure.core.transit.json within the cache does not (obviously) mention the new parse- functions

if you lint dependencies using clj-kondo --lint $(clojure -Spath) this should reset to the clojure version you are using locally

you can add :refer-clojure :exclude [parse-long] in your namespace to prevent the warning, makes it future-proof anyway

hmm.. if I do something like clj-kondo --lint $(clojure -Spath) --lint some-path-in-project I still get warnings about parse-long, parse-double. Even if I clear the cache. Of course, it's a good idea to deal with those functions, as you said, but I'm curious why do we get these warnings.

and to be clear, clojure -Spath returns src:/home/lassemaatta/.m2/repository/org/clojure/clojure/1.10.3/clojure-.10.3.jar:/home/lassemaatta/.m2/repository/org/clojure/core.specs.alpha/0.2.56/core.specs.alpha-.2.56.jar:/home/lassemaatta/.m2/repository/org/clojure/spec.alpha/0.2.194/spec.alpha-0.2.194.jar

do you have a .clj-kondo directory? this is a requirement for the cache to be saved

sure

can you try:

mkdir -p .clj-kondo
clj-kondo --lint $(clojure -Spath) --dependencies

exactly that

done

and still the warning about parse-long?

yes

on the command line?

yes 🙂

repro welcome

and as I mentioned previously, I looked into the cache and at the clojure.core.transit.json file and found no references to the parse- -functions within

ok, so the transit file is updated to the newest

to your own version of clojure

no problem, I'll see if I can build a repro 🙂

oh and thanks for you help debugging this, much appreciated 👍

https://github.com/clj-kondo/clj-kondo/issues/1619 with a link to a simple repro project

Ah I see yeah. This is probably a won't fix as there is a list of clojure vars built-in independent of version and it's already bumped to 1.11. Just future-proof your repo using :exclude

Thanks for repro-ing.

ah, ok 👍

i've already read all the relevant kondo source and i don't have a hypo for why this may be; it all looks correct!

https://github.com/clj-kondo/clj-kondo/blob/master/src/clj_kondo/impl/config.clj#L197-L208 https://github.com/clj-kondo/clj-kondo/blob/master/src/clj_kondo/impl/linters.clj#L443

Possibly you have :skip-comments true?

i definitely have!

That acts as if the comment doesn't exist. There is now something far better:

{:config-in-comment {...}}

Just use that instead and disable any linters you don't want to activate in comments

:redefined-var is already deactivated automatically

{:config-in-comment {:linters {:unresolved-namespace {:level :off}}}}

yes this is so much better!

for example yes

hm. with that in, i'm still getting the warnings. surely the presence of a comment form is irrelevant here? i wish to control the linting of the top-level ns form

oh right sorry :)

what's your config?

hehe :)\

{:linters {:unused-namespace {:exclude ["^dev.*$"]}}
 :skip-comments true}

other than this, we have a bunch of lint-as and a bunch of hooks

well, clojure.data.csv doesn't match this regex?

ohhh man

so the exclude is about the requires themselves, not the ns in which the unused require is?

exactly :)

hi i'm robert and i am a professional haha

hehe, no problem

ok so there's no way to do what i thought it did, right

i'd basically have to add a rule to each ns in dev/* separately

aha so in dev* you want to disable a linter, I see

yessir

cos its full of scripts we use via remote repl, with all the meat in comment forms

so we specifically don't care about unused requires in just this source folder

if you move those requires to comment forms then it would be possible...

it would not be very hard to support this though

(comment
  (require '[clojure.data.csv])
)

ok, thanks man, i appreciate your time on this, very helpful

issue is welcome.

i'll add one for the idea of being able to prevent a rule running within (rather than about) a pattern of namespaces

it's really just the generalisation of :namespaces here

yeah, thanks. clj-kondo already generalized :config-in-comment as :config-in-call {clojure.core/comment ...}

but we need :config-in-namespace too

happy with the language? https://github.com/clj-kondo/clj-kondo/issues/1618

Yep!

Note that for CI purposes you could lint your sources in multiple steps with different configs

yeah. what we're trying to do right now is get one config in use in hooks and in CI, and with zero known issues. then we'll try to work to keep issues to zero. so, it's important that our editors, our pre-commits, and our CI all agree on what an error / warning is

the other thing is we want our entire classpath to remain compilable so that e.g. lsp or clj-refactor doesn't break when using find-usages or similar

thanks @U04V15CAJ! have a great weekend man!

That seems like a bug. I will create an issue. Workaround:

(defn path
  [url]
  (keyword #_:clj-kondo/ignore (re-find (re-matcher #"(?<=\{\{services\.).*?(?=\}\})" url))))

I guess clj-kondo assumed the return value would be something like:

user=> (re-find (re-matcher #"foo" "foo"))
"foo"
user=> (re-find (re-matcher #"(foo)" "foo"))
["foo" "foo"]

Thanks! Yeap, makes sense.

This is a reagent component right?

correct

If reagent had some marker functions then we would be able to write a hook for it

but right now you cannot see statically that a function is a reagent component

yea. thats what i was worried about. errr.

if you write a custom macro that just passes the body to defn, e.g.

(defmacro component [& body]
  `(defn ~@body))

(component [x y]
  (fn [x y] ...))

But I guess reagent also has with-let for this right?