No, it should work if the project root is the mono repo root

Which is what currently works best for clojure-lsp

A single clojure-lsp process that understand the whole mono-repo

how would i determine why that isn't happening?

First thing is check if LSP is starting at the mono-repo root

What editor do you use? If emacs, lsp-clojure-server-info will tell that

i use emacs but i don't personally use clojure-lsp, since it was locking up emacs for me in our monorepo last year when i tried it

most of our devs use vscode i think

The server log should tell that https://clojure-lsp.io/troubleshooting/#server-log

i'll see if i can get someone who can repro to try it

is the idea that if the "project root" is somewhere else, it doesn't work?

I tried using the monorepo root as the project root but I couldn't get any of the language features to work

I'll try again next week and come back to this. It may be that I just have to wait a long time for all the code in the monorepo to get indexed. Unsure.

The server logs will tell if something is wrong, also not aware of any non working mono-repo, so LMK if need more help with that

The first time should take some time, few mins depending on the size, next times should be way faster

I'll try that again then, I may have been too impatient.

Thanks for helping us debug

Also, a .clj-kondo config pointing to a parent folder always work if for some reason you don't want to use the mono repo as root

Using :config-paths setting

Yeah that's what I've configured which seems to work okay. The only annoying thing is if you goto definition on something in an upstream project in the monorepo it goes to the file inside the jar

Instead of going directly to the file in the repo

So ideally if the lsp process is running at the monorepo root that wouldn't be an issue anymore.

Yes, that's what I expect. You can check clojure-lsp project itself which is a mono-repo as well

A structure similar to polylith works best, a root deps.edn pointing all known sub deps.edn

we use lein-monolith (we built it). i wonder if clojure-lsp needs to understand how that works

There was a issue to fully support lein-monolith, let me find it

I wonder if clojure-lsp is not able to grab the right set of classpaths at the monorepo root for the lein monolith case

https://dawranliou.com/blog/advise-eglot-to-support-clojure-monorepo-setup/

Yeah, that is the issue with lein-monolith

i was looking for stuff about eglot and found this article, which talks about setting up clojure-lsp to work with lein-monolith 😅

For deps.edn, you can get the whole classpath just pointing to subfolders, but there is no lein monolith command for that

> Here's the updated solution! Since https://github.com/clojure-lsp/clojure-lsp/issues/752, clojure-lsp uses the classpath to discover the source code to analyze. The trick is to merge all the classpaths from the monorepo's sub-projects. Conveniently, lein-monolith provides a way to https://github.com/amperity/lein-monolith#merged-source-profile. Therefore we can invoke the command lein monolith with-all classpath instead. Your clojure-lsp configuration file that goes to <monorepo-root>/.lsp/config.edn should look like this: >

{:project-specs [{:project-path "project.clj"
>                   :classpath-cmd ["lein" "monolith" "with-all" "classpath"]}]}

Yeah lein monolith with-all classpath seems legit

Interesting...

The only downside is that users of clojure-lsp will have to configure the project path correctly that's sent to the client from their editor but that doesn't seem too hard.

Oh I recall, yeah, that was the guy that asked to add that support haha

So it should work, good finding, I will add that to my guide for mono repos at clojure-lsp documentation

@ULYNWKCNA that's pretty common for LSP users, open the right root, unfortunately there's not much we can do besides tell to open at the right root

If all works, you could in the future use clojure-lsp as your linter tool as well ;) As the classpath will be correct, it will give to you findings from kondo, format from cljfmt, clean-ns support

Yeah makes total sense. Thanks for talking through this with us!

All in a single tool, it's how we are using at Nubank for 99% of the projects

You're welcome! LMK if need any help

after trying this out, the lein monolith with-all classpath command can take minutes to run and it seems to be run every time i try and start the lsp server

at least, I've tried running clojure-lsp dump and it seemed to generate the cache, but i'm not sure

The classpath command is run everytime to check the classpath didn't change, usually a command to retrieve the classpath is fast like lein classpath

What if we try using a refresh fingerprint so you only have to do it for projects that changed

We already do that for project code, we only analyze files changed, still we need to do if deps changed

Yeah but you'll run lein monolith with-all classpathfor each file that changed

Instead of only running with the actual projects that had affected changes.

No, if the deps file checksum didn't change, we don't run the classpath command again, https://github.com/clojure-lsp/clojure-lsp/blob/master/lib/src/clojure_lsp/startup.clj#L217

also, the command is run always in the project root

There is no such concept of subprojects for clojure-lsp

Only source paths and classpath

Oh interesting

Okay that's helpful

we could look into optimizing lein monolith's ability to calculate the classpath in such a way

Does it take that long? Usually clojure, shadow-cljs, lein, bb take few seconds

yeah it takes minutes in our monorepo

maybe 10s of minutes

idk why yet

That's weird.. I don't know too much about lein monolith but AFAICS it should be a lein classpath that only considers the subprojects, probably something could be improved

No, should not block

is there a general preference between eglot and lsp-mode now?

I use lsp-mode as I am a lsp-mode maintainer as well, so generally will be more maintained for Clojure probably. eglot support improved recently, but still some features are missing like code lens and call hierarchy

Both should work

I currently use flycheck-mode for clj-kondo. should i disable that?

If you use eglot it automatically integrates with flymake for errors, so you don't need separate clj-kondo setup, I think I was a flycheck-eglot package that bridges the two

Both modes work well. Eglot is a bit less ui heavy by default and aims at integrating with emacs defaults, lsp-mode supports more lsp features. I used both and frankly they are quite equivalent. I would say maybe what you use in your config for other modes might drive you to use one or the other

If you use eglot flymake-diagnostic-at-point is quite nice btw