clj-kondo 2025-09-15

We have a strange problem where clj-kondo keeps warning us that medley.core/greatest-by and medley.core/least-by don't exist. Details in ๐Ÿงต

โœ… 1

Here's an example:

clj-kondo --lint src/matnyttig/import/tilsynsloop.clj
src/matnyttig/import/tilsynsloop.clj:4:14: warning: namespace cljc.java-time.local-date-time is required but never used
src/matnyttig/import/tilsynsloop.clj:10:34: error: Unresolved var: greatest-by
src/matnyttig/import/tilsynsloop.clj:10:46: error: Unresolved var: least-by
linting took 49ms, errors: 2, warnings: 1
See namespace form in screenshot

The red line is lsp complaining about the same thing via kondo

are you using :refer-all maybe?

No, just refer, see screenshot

clj-kondo --lint src/matnyttig/import/tilsynsloop.clj
src/matnyttig/import/tilsynsloop.clj:125:25: error: Unresolved var: medley.core/least-by
src/matnyttig/import/tilsynsloop.clj:664:36: error: Unresolved var: medley.core/greatest-by
linting took 87ms, errors: 2, warnings: 0
It complains even without the refer

ah ok. can you see if there is a cache file in

.clj-kondo/.cache/v1/cljc/medley.core.transit.json or so?

and then send it here?

Will do. I cleaned out .clj-kondo to verify that this problem persisted btw - it did.

do you perhaps have another version of medley on the classpath accidentally? medley changed organizations which is a likely cause of having the same library on the classpath twice.

dev.weavejester/medley 

it used to be medley/medley I think

so print your deps tree and see if there's another medley in there

Yes, I also suspected multiple medley's on the classpath ๐Ÿ˜„

But there was only one

clojure -X:deps tree | grep medley
dev.weavejester/medley 1.9.0

is this the same classpath that clojure-lsp uses? it might combine multiple from shadow-cljs etc too

Hmm, good question

I verified the problem without lsp though - using clj-kondo on the CLI. Not sure what deps it is using?

I'm pretty sure this is the issue. I'll bet you a beer on it next time we meet on a conference ;)

I don't mind receiving a beer ๐Ÿ˜„

๐Ÿ˜‚ 1

it doesn't use any deps unless you tell it to lint a classpath. if you just wipe the .clj-kondo/.cache then it won't complain about this

so try to find out which classpath clojure-lsp uses

Yes, verified that the warning goes away without the .cache dir

Any hints on how to find out what classpath lsp uses? ๐Ÿ˜…

I'm trying to figure out that myself :)

does it have a command line option for this?

I don't really know anything about it, @magnars just made sure it works in my Emacs ๐Ÿ˜„

ah lsp-clojure-server-info-raw in emacs

this will print the classpath in some buffer

in *Messages*

hah, look at that

A wild Medley 1.4.0 appears

FWIW, I said the same thing to @magnars earlier: "There has to be two medleys on the classpath"

This reminds of how nrepl-refactor uses https://github.com/benedekfazekas/mranderson to isolate dependencies via name munging.

What this output isn't telling me is where it's coming from

do you have a bb.edn with medley in it? or perhaps shadow-cljs? maybe in an alias in deps.edn?

transitively

or project.clj

clojure-lsp just combines anything it can find ;)

Yeah, I just realized I ran -X:deps without any of the aliases. I just don't know how to do it ๐Ÿ™ˆ

do you use any aliases with shadow-cljs or clojure-lsp itself?

:aliases '[:foo :bar]' as arguments I think

shadow-cljs, yes

want to bet another beer? ;)

๐Ÿ˜‚ 2

Well, well, well, if it isn't the consequences of my own actions lolcry

The culprit was ๐Ÿฅ Compojure

also a weavejester production!

Which also has @weavejester's name on it ๐Ÿ˜„

Haha, exactly!

I'll make a PR

Thanks for helping us track this down, it's been a minor annoyance for some time ๐Ÿ˜…

nice! no problem

Apologies for the issue @christian767. I've just released Compojure 1.7.2 that should fix it.

๐Ÿ™ 2

that reminds me, maybe clj-kondo should just warn about this by looking at your deps.edn or project.clj and warn that a library got an org change? not sure if that would really would have detected this issue though

Awesome, thanks @weavejester ! Wasn't a big problem, I'm just glad this long running low key mystery has a conclusion ๐Ÿ˜„