@chris441 I already did some of those configs on upstreams project so I can help you if you want

IMO providing the hook on the upstream package is the best way to make downstream just work with minimal config

That is great to know - I appreciate the offer and I will be taking you up on that :-)

:) Some libs I added clj-kondo hooks and custom config that worked for downstreams: https://github.com/nubank/state-flow/blob/master/resources/clj-kondo.exports/nubank/state-flow/config.edn https://github.com/marick/Midje/tree/master/test-resources/clj-kondo.exports/marick/midje

I'll try to explain: my repo root is wsmain LSP creates .lsp there (as expected for Calva usage). My REPL is started in wsmain/clojure. The classpath script for LSP cd's into clojure to run clojure -Spath ... because that's where deps.edn is.

However, I end up with TWO .clj-kondo folders. One in wsmain and one in wsmain/clojure.

Both of them get the exported configs from dependencies. Both of them get a .cache folder -- but the contents seem to be different.

I don't know why the clojure/.clj-kondo folder is created.

I thought the setup with Calva was such that it only ran clj-kondo via LSP and so I expected that wsmain/.clj-kondo would be the only folder created.

I'd suggest not having your root not on the same folder of your deps.edn but I think you have your reasons, you probably need to setup more than just project-specs if you are doing that

like :source-paths

anyway, it doesn't make sense create a clojure/.clj-kondo indeed since clojure-lsp creates that from the passed project-root-uri that calvas sends on the initialize request

Not sure what :source-paths you are referring to?

.lsp/config.edn is

{:project-specs [{:project-path "clojure/deps.edn"
                  :classpath-cmd ["./.lsp/classpath.sh"]}]}

https://clojure-lsp.io/settings/#source-paths-discovery

since the source-paths discovery will not work because there is no deps.edn on the project-root, you should specify manually it with the :source-paths lsp settings

This is a monorepo with dozens and dozens of subprojects that are :local/root deps.

The classpath will contain all those directories tho'

yeah, the classpath thing should work, but other clojure-lsp features like rename namespaces and some others that rely on correctly configured source-paths won't

I don't care about refactorings.

Only linting.

alright, so it should work, not sure why is creating the clojure/.clj-kondo dir, are you sure there are no extra plugins anything?

This is clojure-lsp code that creates the kondo dir, it only checks the project-root-uri sent by the client (calva): https://github.com/clojure-lsp/clojure-lsp/blob/master/src/clojure_lsp/crawler.clj#L176-L185

Just Calva and Clover and I'm pretty sure the latter doesn't do anything with clj-kondo?

yeah I think so

well, clojure-lsp logs when it's creating the kondo dir, maybe you can search there

search for "creating for necessary clj-kondo analysis..."

I think there is a calva command to get clojure-lsp logs

Calva Diagnostics: Open Clojure-lsp Log File

Looks like I'd need to do a clean restart without those folders to see what it is doing? That's going to be too disruptive right now but I'll try to set aside some time for that tomorrow.

yes

Not sure I follow fully, but I'll try to see what Calva gives to clojure-lsp in this scenario.

I can’t see that Calva configures any project root for clojure-lsp. Should we?

@U0ETXRFEW It has to do with the concept of workspace / working directory. I think Calva and LSP have just one concept of what the project root is.

So if you work inside a sub-directory in your workspace the project root is still the root directory.

Calva has a concept of project root that is used for various things. This is currently determined from the current file and then upwards looking for a project file. I have on my todo to revisit this to better support monorepos, polylith, etc. I don’t see that we send this info to clojure-lsp, though. And from what I take from this thread, it would risk mess things up if we did? Maybe VS Code is giving clojure-lsp some project root automagically…

ok, then we should ask @ericdallo.

This is how the clj-kondo LSP plugin does it: for every file that you edit, regardless of what is your working directory, it looks up from the path of that file for the config directory, https://github.com/clj-kondo/clj-kondo.lsp/blob/b1097c318c0d51b3c7e45192005c0f7d8765cd68/server/src/clj_kondo/lsp_server/impl/server.clj#L130

This approach should work for Sean's situation

The project-root-uri is a mandatory string that clients should send, if calva is not sending manually then vscode is, probably it uses the current folder root opened or something. It's possible to get that in LSP logs like I mentioned above

@ericdallo the clj-kondo.lsp plugin doesn't care about it though. it just uses the file path to scan upwards for a config

EDIT: I meant clj-kondo.lsp, not clojure.lsp.

I think it makes sense that clojure-lsp does what clj-kondo.lsp does for this. Calva should probably share what it thinks is the project root anyway, but it seems to be a bit unrelated?

CC: @U9A1RLFNV

We could improve that on clojure-lsp I think, but that would work for single file edits only, not full project lint on startup as we pass project sources to kondo

But it'd solve most issues I think

Actually, this is the first one I see

I wonder what the reason is that Sean doesn't just open the sub-project directory. He mentioned issues with git that way

yeah, I agree clojure-lsp could have better mono-repo support, I improved that for polylith and other mono-repos, but threre are lot of cases

I know that feeling!

Just FYI, you can see what root path is being sent from VS Code / Calva in the Clojure Language Client output channel, if the setting clojure.trace.server is set to verbose . The info is in the initialization message.

That's what showed up with verbose tracing and a fresh setup (no .clj-kondo folder)

for context: your .clj-kondo folder is in wsmain/clojure/.clj-kondo, correct?

No, it's in wsmain/.clj-kondo

I've removed the wsmain/clojure/.clj-kondo folder.

LSP creates it in the root of the tree.

ok

I'll keep an eye out for wsmain/clojure/.clj-kondo appearing -- that was what broke things before, but as long as that doesn't get created I think this setup will work just fine.

LSP might create it if you open VSCode at wsmain/clojure

not sure though.

Will report back if I see that reappear. For a while, it was randomly reappearing, while I was using VS Code, but I don't know what triggered it.