It’s such an invaluable tool in lowering the barrier to entry for many people interested in Clojure, IMO. So much amazing work.. thanks to the whole team!

I think this might depend a bit on which provider is in action. Please report as an issue and include if you have different results with the REPL connected or not.

You are right. The problem is with babashka. This is a screenshot from shadow-cljs:

https://github.com/BetterThanTomorrow/calva/issues/1987

Then I think it might be an issue to file on babashka. But we can start with Calva.

Seems similar in scope to a comment borkdude made yesterday, regarding a different editor. I think we simply cannot expect all features to work properly with Babashka at the present time. https://clojurians.slack.com/archives/CLX41ASCS/p1670155904152339

Doesn't mean we cannot aim to improve that. 😉

I think this should be pretty easy to fix in the babashka nrepl server. I will have a look at the #C03DPCLCV9N one and maybe I will have to take this back.

Me too and there was a recent thread with extensive contribution from @U4LCNMMGS on the subject

Are you using Leiningen or the Clojure CLI (`deps.edn`)?

In my case - Leiningen (and packaging via mvn clojure-maven-plugin)

...which copies source files to target/classes when building JARs... which is what causes this I think?

(although it seems that LSP should ignore that folder?)

Not only when building jars, I think, but also when preparing to run tests - which also does the AOT compilation. It seems to me that the presence of clj files in target/classes is not a fault.

Right, it's reasonable to have source in that folder -- LSP should ignore it.

But I think LSP uses the classpath by default and so you'd need to configure it to use something different or ignore that folder...

(with the Clojure CLI, even if you "build" into target/classes, it typically is not on your classpath)

interesting... so with Clojure CLI you don't use AOT-produced class files?

Yes, but target/classes isn't on your classpath (so LSP doesn't see it).

(or are you talking about having to AOT-compile for :gen-class etc which your tests need?)

It could be the REPL that takes you to these files. Unless we have reason to know it is a clojure-lsp thing?

As I pointed out in https://clojurians.slack.com/archives/CBE668G4R/p1670003785898009?thread_ts=1670003785.898009&cid=CBE668G4R yesterday, the default lsp config includes this setting ...

:source-paths-ignore-regex ["resources.*" "target.*"]

And shouldn't cljs be compiled into js in target/classes, in order to be served as "resources"? All in all - I'm surprised people can get very far without target/classes on the classpath

With the CLI, you are usually a lot more surgical about what exactly gets compiled and what exactly gets copied into target/classes...

Has Lein had a recent update? Maybe they changed their use of dynamic classloaders in a way that circumvents how LSP is checking the classpath to determine if some path should be ignored.

@U90R0EPHA the lein I'm using has not changed in years.

There are two things to never, ever, ever update. Emacs and Leiningen.

(while I'm always on the very latest release of the CLI 🙂

@U04V70XH6 it's a great service to civilization, that someone keeps up with Clojure Deps. Its direct-to-git dependencies are "obviously" the long-term Right Thing To Do. Hopefully someone will ring a bell over my grave when Deps is finally finished and stable and has a command line as simple as Lein's.

I'm using deps.edn (with shadow-cljs, so shadow-cljs.edn

@U0HG4EHMH I have questions about your comments. I started a https://clojurians.slack.com/archives/C6QH853H8/p1670200591801199 to ask you in #tools-deps, to avoiding derailing this thread.

If someone who has this problem can provide a good repro in an issue on the clojure-lsp repo that could help @UKFSJSM38 find the problem.

And if it hasn’t yet been verified that it’s not the repl taking the user to those file, that should probably be verified. Although, that could be tricky. I think even if clojure-lsp isn’t analyzing those files initially, if the repl takes the user to them at some point, once the file is opened, I think clojure-lsp may analyze it, which might cause it to take you there after you disconnect the repl to check if it was clojure-lsp.

So to verify you’d probably want to remove your .lsp/.cache directory, reload your project window, then see if go to def takes you there. Then if not, connect the repl and and see if you get taken there afterward.

I will try to get back to this tomorrow. I spent too much time on it and had to get back to my actual work. But I can guarantee it's not the repl because mine doesn't work. 🙂

Oh, that helps!

@U90R0EPHA summarized well the issue https://clojurians.slack.com/archives/CBE668G4R/p1670196033216489?thread_ts=1670195106.343089&cid=CBE668G4R, my strong guess is that clojure-lsp is linting the target folder when it's changed after lsp initialized for whatever reason (like cljs recompiling clojure code), then clojure-lsp lints those files and consider as analysis which is bad, I think doing a smart check on the watchedFiles on server side would be probably the ideal fix A repro would be perfect.

Even without a repro, it does makes sense for clojure-lsp ignore watched files that are inside the ignored source-paths so I made a commit on clojure-lsp right now fixing that. If that was indeed the issue, it should be fixed so I suggest trying again with nightly build or wait for next release which I'm about to do today.

Could anyone having the issue confirm if https://clojurians.slack.com/archives/C06MAR553/p1670610435631639 fixed it indeed?