Fork me on GitHub
#lsp
<
2022-08-16
>
dharrigan04:08:11

Does clojure-lsp walk up directories until it finds a parent deps.edn?

dharrigan09:08:03

Here's a little tip for those working with monorepos, and using vim + coc. Ensure you set your coc.preferences.rootPatterns correctly, otherwise the wrong project-root will be sent to clojure-lsp when determining the classpath.

dharrigan09:08:08

Something like this may be helpful:

dharrigan09:08:13

"coc.preferences.rootPatterns": [
    "deps.edn",
    "project.clj",
    ".git",
    ".projections.json"
  ],

ericdallo12:08:30

we stopped doing that manually and finding deps.edn, and just delegate to the classpath resolver tool, like lein classpath or clj -Spath which usually bring the expected correct classpath, but yeah, you need to setup the project root properly

dharrigan13:08:02

after some reviewing of the code etc, it all made sense.

dharrigan13:08:28

Thing is, is that coc hands to clojure-lsp the project root which it believes is correct

dharrigan13:08:01

so if you're in a monorepo, it'll walk up until it finds a .git directory then the whole thing gets confused, as the source paths are then all set incorrectly

ericdallo13:08:15

yeah, we have the same issue on emacs, people importing the root wrongly, this is something client should ask and handle correctly, there is nothing to be done on server side I believe :/

Sigve07:08:10

I am again having problems with jumpReferences giving me hits in the target directory on the newest version of clojure-lsp in clojurescript. This despite setting both :source-paths and :source-paths-ignore-regex to try to avoid this. I went back some versions, trying both 2022.05.03-12.35.40 and 2022.06.22-14.09.50 , but they had the same problem. Version 2022.03.31-14.21.14 is working as expected (pjuh)

ericdallo12:08:05

@U04V15CAJ reported the same https://clojurians.slack.com/archives/CPABC1H61/p1660120980660409, I still need to investigate that. @U01E4ELDYM9 Do you have any sample project where I can try?

ericdallo12:08:12

I can try repro on babashka-cli too

borkdude12:08:57

@UKFSJSM38 first run clojure -T:build uber to create a target dir. Then restart the project and the navigation should go to the wrong place

šŸ‘ 1
ericdallo13:08:48

@U04V15CAJ done, I tested some go-to-defs and it seems to be working, do you have a example of a var you are trying to go to which goes to target?

borkdude13:08:48

do you have a target dir?

borkdude13:08:10

Here's a repro:

borkdude13:08:21

hmm, it's probably an issue with my emacs PATH vs my shell PATH

ericdallo13:08:00

yeah, I have the target after ran that command and going to parse-args works for me :thinking_face:

ericdallo13:08:53

Could you check lsp-clojure-server-info ? it should print to messages buffer a edn, there you should find source-paths

ericdallo13:08:11

This is mine:

:source-paths
  ["/home/greg/dev/babashka-cli/src"
   "/home/greg/dev/babashka-cli/dev-resources"
   "/home/greg/dev/babashka-cli/test"
   "/home/greg/dev/babashka-cli/.build"]
note: clojure-lsp excluded the target source-path properly

Sigve13:08:46

Here is a repro for cljs (in my case using CoC and nvim): 1. clone https://github.com/sigvesn/cljs-dummy 2. start repl with clj -M:dev -m figwheel.main , creating the target dir in the process 3. call jumpReferences on any of the defined functions in src/web/core.cljs

ericdallo14:08:09

It works too for me @U01E4ELDYM9 I suspect you have the same issue borkdude is having, maybe clojure-lsp is not finding the source-paths properly, could you check what is the return of the clojure/serverInfo command? I'm not sure how to call it from vim though, on emacs we have a function to help with that M-x lsp-clojure-server-info

Sigve06:08:50

It seems that source-paths in final-settings is set correctly to

'source-paths': ['/home/sigvesn/clojure/web/src'
                                     '/home/sigvesn/clojure/web/tests'
                                     'src'
                                     'tests']
here is the full result of serverInfo (found using echo CocRequest('clojure-lsp', 'clojure/serverInfo/raw')` )

Sigve07:08:55

Any other info i can provide to help? Should i open an issue?

ericdallo12:08:29

I gave it a try and I can't reproduce, your settings looks correct too, clojure-lsp didn't include any target folder in source-paths, so it seems something different, not sure if the client (vim) may affect that. Maybe ask if other people using vim are having the same issue with that repro?

šŸ‘ 1
teodorlu12:08:06

Hi! I'm writing a library, and clojure-lsp gives me "unused public var" warnings for my public API namespace. I'm curious about how other people who are writing libraries and are using clojure-lsp are doing here. Do you simply disable "unused public var" warnings for the whole namespace?

lispyclouds12:08:18

for me i'd generally have some tests which run the fns so that takes care of the warnings for me šŸ˜„

teodorlu12:08:12

ahh, good point. I could consider writing some tests. That's .. yeah, I should actually do that. šŸ˜„

šŸ˜¬ 1
ericdallo12:08:08

there are some ways to solve that: ā€¢ add #_{:clj-kondo/ignore [:clojure-lsp/unused-public-var]} to a specific function ā€¢ Add a custom config to exclude specific ns patterns. At Nubank we use this and works pretty well for most projects, for example: .clj-kondo/config.edn

{:linters {:clojure-lsp/unused-public-var {:exclude-regex [".+\\.server/run-dev"]}}
 :config-in-ns {user {:linters {:clojure-lsp/unused-public-var {:level :off}}}}} 

šŸ’Æ 1
ericdallo12:08:35

I suggest using the :config-in-ns kondo setting which allows you have a good tuning for specific ns

teodorlu13:08:41

That's great - thank you!