Calva adds .lsp and .clj-kondo folders to every VSCode project

[evaogbe]

Steps to reproduce

1. Create a folder with files that aren't related to Clojure, e.g. .rs files
2. Open the folder in VSCode

Expected outcome

No Clojure files get generated

Actual outcome

.clj-kondo/.cache/v1/lock and .lsp/.cache/db.transit.json get generated

Versions

• MacOS Sonoma
• VSCode 1.92.2 (Universal)
• Calva v2.0.467

I've had this issue for months, so it's been a problem with older versions as well

Additional notes

This happens whenever I open a project and also whenever I refresh extensions due to updates. It happens even if I don't interact with the Calva Inspector. I have never installed Joyride.

Calva settings:

"calva.fmt.configPath": "CLOJURE-LSP",
"calva.evalOnSave": true,
"calva.testOnSave": true,
"calva.useLegacyReplWindowPath": false,

[KingMob]

This is quite annoying. It's also happening in Windsurf with the latest Calva. I have a Wordpress plugin project, which is nothing but PHP and Javascript, and Calva keeps adding these files to the repo.

[PEZ]

Calva shouldn't activate in a project without Clojure files. Something is activating Calva for you. I think Joyride has been known to cause this, or possibly some other Calva or Clojure related extension. Are you using any such extension besides Calva, @KingMob?

[KingMob]

Thanks for looking into this @PEZ

---

I don't have Joyride. Plus, I see that's in the "Project Roots Search Exclude" list.

VS Code has Calva Spritz as well as Calva, but I'm not using VS Code these days.

Maybe indent-rainbow? Tho that seems unlikely. mise has a version of Java activated in that directory (inherited from the parent dir), but not Clojure.

I see the "Enable Clojure Lsp On Start" setting is "always-use-first-workspace-root"; could it be triggered if I had other Windsurf windows open with Clojure projects in them at the same time?

I double-checked, and there are no *.clj* or *.edn files anywhere.

---

In the "Problems" tab, I see:

config.edn   .lsp
    file does not exist   clj-kondo(file) [Ln 1, Col 1]

but I don't know if that existed before I deleted the .clj-kondo/ and .lsp/ dirs.

[PEZ]

Calva Spritz should not have this effect. Or, I am pretty sure it doesn't. With Calva I am less sure. I know that I can open non-Clojure projects without those files appearing, but that doesn't mean Calva is not to blame.

The Enable Clojure Lsp On Start settings shouldn't have to do with it either. It could have effect on where the files are created, in a multirepo scenario, but the activation trigger is statically configured. That said, clojure-lsp multiproject support in Calva is pretty complicated stuff, so there may be bugs hiding there.

If there is another extension causing this it may work to run Extension Bisect. Though, I think that could be a bit tedious. 😄

The culprit is that Calva activates in the first place. Because when it activates, it will start clojure-lsp and clojure-lsp will create those files. I am looking at the Calva extension manifest now and the activation is configured like so:

  "activationEvents": [
    "workspaceContains:**/project.clj",
    "workspaceContains:**/shadow-cljs.edn",
    "workspaceContains:**/deps.edn",
    "onDebugResolve:type"
  ],

And that onDebugResolve:type I guess could be triggered somehow by any extension. Or some configuration you have... I don't even know why it is there. @bpringe do you know?

[evaogbe]

I also have indent-rainbow installed. Maybe it's related

[KingMob]

I could try extension bisect, but the problem doesn't appear reliably, so it may not work.

[KingMob]

Interesting update: Windsurf (and presumably VS Code) allows us to disable an extension for a particular workspace, so I disabled Calva just for the WP plugin, until this is fixed.

Not long after, I started getting paredit error popups in the Windsurf LLM sidebar (see attached screenshot), which obviously, has no Clojure code, and probably shouldn't use paredit even if it did.

Could this be what's triggering Calva?

[bpringe]

And that onDebugResolve:type I guess could be triggered somehow by any extension. Or some configuration you have... I don't even know why it is there. @bpringe do you know?

@PEZ I don't remember / know why that's there. We could experiment with removing it and making sure the debugger still works.

Relevant links:

• https://code.visualstudio.com/api/references/activation-events#onDebugResolve
• https://code.visualstudio.com/api/extension-guides/debugger-extension#using-a-debugconfigurationprovider