clj-kondo

kenny 2025-08-22T14:42:33.681299Z

Confirming - the expectation for the .clj-kondo/imports directory in my project is that it is committed to VCS?

borkdude 2025-08-22T14:43:22.820379Z

I commit those yes

kenny 2025-08-22T14:44:09.025569Z

Ok. Those are created/updated at a point in time with a command like this?

clj-kondo --lint "$(clojure -Spath)" --dependencies --copy-configs --skip-lint

borkdude 2025-08-22T14:45:00.197959Z

yes

πŸ‘ 1
kenny 2025-08-22T14:45:18.725899Z

FWIW: confusion is coming from the recent Cursive + clj-kondo release where I now have a bunch of these files, and I do not know how they were created

kenny 2025-08-22T14:45:31.134919Z

Got it - thank you πŸ™‚

borkdude 2025-08-22T14:45:33.865129Z

ok, I think Cursive might be doing this for you

borkdude 2025-08-22T14:45:37.988919Z

similar to clojure-lsp

kenny 2025-08-22T14:46:23.255609Z

Do you have any idea if the editors see this directory as managed by them? e.g., they’ll update it as my deps change over time. Or am I supposed to manually update it with the above command regularly?

borkdude 2025-08-22T14:47:48.918559Z

depends on the editor

borkdude 2025-08-22T14:48:02.863619Z

clojure-lsp does re-analyze stuff when deps.edn have changed I think (cc @ericdallo)

borkdude 2025-08-22T14:48:12.479809Z

or maybe when the lsp server starts

borkdude 2025-08-22T14:48:28.021659Z

I can't say for Cursive

kenny 2025-08-22T14:50:51.771139Z

Makes sense. Thanks for the quick response!

ericdallo 2025-08-22T14:52:49.905279Z

yes when starts. BTW at Nubank we stopped completly commiting those, especially because LSP always opy them from kondo/deps, so it's reproducable already with that deps you have

ericdallo 2025-08-22T14:53:15.972479Z

our git ignore looks like:

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

borkdude 2025-08-22T14:53:54.437639Z

that git config only works when you don't have any other hook files in your project but makes sense, whatever works

ericdallo 2025-08-22T14:54:02.601919Z

commit those generated lots of noise for devs, all the time a new lib was bumped and them it needed to update it along with project changes

ericdallo 2025-08-22T14:54:11.366149Z

yes, we have hooks in a central place

borkdude 2025-08-22T15:01:24.784929Z

in the future I'd like clj-kondo to have the concept of a classpath too so it can maybe just read those files directly from the classpath, although I don't know how much of a slowdown that will be

ericdallo 2025-08-22T15:01:56.147899Z

yeah that would be nice

Cam Saul 2025-08-22T22:42:33.578219Z

Sorry if this is a dumb question but am I doing something wrong, or should I open a bug on GH? I created a new project to make sure it's not something weird with my config. (Kondo version = 2025.07.28)

(ns example.x)

(defn ^:deprecated deprecated-fn-1 [x]
  (+ x 1))

(defn ^:deprecated deprecated-fn-2 [x]
  (+ x 1))

(defn ^:deprecated deprecated-fn-3 [x]
  (+ x 1))

(defn y [x]
  (-> x
      #_{:clj-kondo/ignore [:deprecated-var]}
      deprecated-fn-1
      #_{:clj-kondo/ignore [:deprecated-var]}
      deprecated-fn-2
      deprecated-fn-3))
When I run Kondo:
cam@Cam-PC:~/test-project$ clj -M:kondo
src/example/x.clj:14:9: info: Redundant ignore
src/example/x.clj:15:7: warning: #'example.x/deprecated-fn-1 is deprecated
src/example/x.clj:18:7: warning: #'example.x/deprecated-fn-3 is deprecated
linting took 61ms, errors: 0, warnings: 2
I would have expected deprecated-fn-3 to trigger a warning, but not deprecated-fn-1. Also, not sure why this would be considered a redundant ignore

Cam Saul 2025-08-22T22:43:48.606019Z

I ran into this while working on real code and I created this minimal example to double-check stuff before posting here

2025-08-23T01:51:00.200099Z

It is likely because clj kondo has a built to expand -> forms and the expansion is nested

borkdude 2025-08-23T18:09:39.800529Z

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

borkdude 2025-08-25T10:18:01.187079Z

@camsaul here's a solution PR: https://github.com/clj-kondo/clj-kondo/pull/2611

πŸŽ‰ 1