Fork me on GitHub

I managed to get clojure-lsp to hang again. This time I accidentally introduced a circular dependency between deps.edn files. Maybe clojure-lsp shouldn’t get stuck in that situation and just warn about the circular dependency?


I will add a tries in a loop and log that


I added something similar yesterday


But not for the source-paths discovery


What was the exactly cyclic dependency you added? A local root that points to the same parent or something?


I just managed to repro


Just pushed a fix/improvement

👍 2
Lukas Domagala14:12:03

the thread-*-all action doesn’t do anything for me in vscode with calva. is there some trick to get it working? i’m on 2021.12.01-12.28.16 and tried it with:

(:a (:b {}))


it's a calva issue

Lukas Domagala14:12:04

ah ok, thanks. i’m guessing theres a ticket already for that?


actually it will fix it as soon a new clojure-lsp version is released


there was, let me find it


in the end we reverted because of other issues and found a way to "fix" it on clojure-lsp side

Lukas Domagala14:12:52

it’s fine, just wanted to let them know, but if you are fixing it anyway i’m happy:)


I'll release clojure-lsp tomorrow probably

Lukas Domagala14:12:26

ah its all of them again, didn’t try any others yet today apparently

Lukas Domagala14:12:41

great work, thank you!

👍 1
Drew Verlee18:12:14

Why are the lsp breadcrumb file names underlined in red? (see picture)


It's be a use there is a error diagnostic on that segment level


I personally disable that



Drew Verlee19:12:13

I think i understand. Ill probably just disable tthe file path info, i rarely need that context when i'm in the file


Yeah, I implemented the lsp-mode breadcrumb but I need to confess that I don't use it anymore :p

😄 2
Drew Verlee19:12:49

How would i lint a clojure macro as clojure defn. the current project structure /.clj-kondo/config.edn -> {:lint-as my-macro/foo defn} this is the currently the lsp project level (how do i check which workspace i'm using to make sure i'ts not "some-dir" which has a nother clj-kondo config. /some-dir/.clj-kondo/config -> other lint-as rules /some-dir/foo.cljs -> where marco is underlined as red.


Your lint-as is wrong


lint-as value needs to be a map

Drew Verlee19:12:42

yes. I didn't copy it correctly to the comment. It's :lint-as {my-macro/foo defn}


ATM clojure-lsp support only clj-kondo config at project root level

Drew Verlee19:12:31

will it support nested clj-kondo configs?


With clojure-lsp ATM no

Drew Verlee19:12:29

interesting. thanks. I wonder why we have this strucute then, maybe something else is using those lint-as rules.


Not sure how hard would be to implement that since we do lint the whole project at start and would need to check if there is kondo config in each linted subdir


Clj-kondo only, supports nested config


Clojure-lsp doesn't

Drew Verlee19:12:44

now i just have some-dir as the lsp project and some-dir/.clj-kondo/config with my macro correctly specified, but its still underlined as red. Is there a way to ask lsp what rules it's using to resolve symbols/text to see if my clj-kondo config file is in that list? Output of logs

[Trace - 01:37:28 PM] Sending request 'textDocument/codeAction - (22)'.
Params: {
  "textDocument": {
    "uri": "file:///home/drewverlee/archmedx/kyber/server/src/pathom/resolvers/curriculum/learners.cljs"
  "range": {
    "start": {
      "line": 10,
      "character": 13
    "end": {
      "line": 10,
      "character": 13
  "context": {
    "diagnostics": [
        "tags": [],
        "message": "Unresolved symbol: readiness",
        "source": "clj-kondo",
        "code": "unresolved-symbol",
        "severity": 1,
        "range": {
          "end": {
            "character": 25,
            "line": 10
          "start": {
            "character": 16,
            "line": 10


No, you change kondo config and just make any changes to the file that will be linted with the new config


Also, make sure the project was imported with the current project root on lsp-mode


Via lsp-workspace-folders-remove/add

Drew Verlee20:12:04

Is LSP concerned about anything in the workspace structure like a deps.edn file or .clj-kondo/config.edn ? i'm guessing it does look at the kondo file, but i wouldn't assume it cares about the deps/lein project config file.


It scans the deps.edn/project.clj for source-paths discovery only, nothing related with lint/kondo

Drew Verlee20:12:11

whats the outcome if your workspace root doesn't have a deps.edn or project.clj?

Drew Verlee20:12:47

it can't help with autocomplete on those deps?


source-paths won't be found and some features won't work


why your project doesn't have a deps or project?


is it possible to share you project or create a minimal repro?

Drew Verlee20:12:50

Because the project is split across a browser client and a server. They put the .clj-kondo at the root that shared both and the deps in the root/client/deps.edn root/server/deps.edn And then had clj-kondo at multiple levels root/server/.clj-kondo/config root/.clj-kondo/config So for the moment, what i have done is to copied the shared clj-kondo into the 2 projects. Both of which will be separate LSP workspace: root/client/deps.edn + clj-kondo root/server/deps.edn +clj-kondo


yes, that sounds like a valid workaround


Please open an issue about the nested kondo support so we can discuss better how to implement and make lsp support that

Drew Verlee20:12:32

That sounds like a good idea. It might be that our project should make a change to. I'm currently too overloaded to think on it further 🙂

👍 1

@U0DJ4T5U1 what is the reason you have one root clj-kondo and multiple projects?


you can use :config-paths to share configuration in multiple projects


I think that should cover this use case

Drew Verlee21:12:59

thanks, ill take a look. :config-paths is an option of clj-kondo right @U04V15CAJ? that wouldn't cover lsp handling a root directory that didn't have a clojure deps file or lein project.clj file. the clj-kondo file was likely intended to be shared between the browser client and the server code. I think CI tooling is using it for both of them.


yes. my suggestion is to have always a .clj-kondo directory in each project and use :config-paths to refer to a shared config from each project


this will also work better for VSCode users on your project


:config-paths ["../../shared-kondo-config"]
the first .. is for going up into the project too, and the second .. is for going to the parent directory of the project


so .clj-kondo/../../shared-config

Drew Verlee21:12:32

That makes sense, thanks for the pointers!