Ability to disable extensions

[JosephTLyons]

Check for existing issues

• Completed

Describe the feature

Extensions should be allowed to be disabled via some setting, at both the global and local level, so workspaces can disable plugins they don't need running.

If applicable, add mockups / screenshots to help present your vision of the feature

No response

[kucho]

+1! I would also love the ability to disable some language servers per workspace.

[turbocrime]

this feature is available.

here's the zed documentation of this feature https://zed.dev/docs/configuring-languages#choosing-language-servers

and here's an example, from the documentation of biome's zed extension https://biomejs.dev/reference/zed/#project-based-configuration

i think disabling globally and enabling per-project and language is the correct way to do it, but you can of course do the inverse as you ask, and just disable it per-project.

it seems that language_servers is both a root config field and available per-language.

[notpeter]

While I appreciate the desire to be able to enable/disable extensions so that workspaces only have the extensions they need, I'm unclear of what the design of such an implementation would look like.

• An extension allow-list in project level settings would prevent using optional extensions (themes, slash command extensions, etc)
• An extensions deny-list at the project level would be inherently verbose and non-exhaustive

I'm opened to exploring ideas for how such a system might be designed.

[kkafar]

I just found myself in situation where I use different JavaScript language servers / formatters depending on the project I work on & the configuration I have there. I would love to have opportunity to mark e.g. biome as disabled and have it not conflicting with prettier in another repo.

In other words: in my use cases opportunity to disable a particular extension would be desired - "deny-list" approach would be sufficient. I agree that this approach is verbose, but it's not like disabling extensions is such common use case. I feel like it would be a tool to handle certain edge cases (such as mine) & verbosity is not that much of an issue.

[turbocrime]

i found myself in this exact situation. for biome specifically, there's a way to configure the extension to automatically enable/disable based on the presence of the biome.json config, which is exactly how the command-line biome works:

https://biomejs.dev/reference/zed/#enable-biome-only-when-biomejson-is-present

<~/.config/zed>/settings.json

{
  "lsp": {
    "biome": {
      "settings": {
        "require_config_file": true
      }
    }
  }
}

more generally, the language_servers zed config field can enable/disable any LSP globally or per workspace https://zed.dev/docs/configuring-languages#choosing-language-servers

[kkafar]

That is great! Thank you.

[Nico-Mayer]

I tried this and also disabled biome for each file type with '!biome' in the workspace settings.json, but biome still connects to every TypeScript and JSON buffer even though I have disabled it and set "require_config_file": true.

[eugenesvk]

• An extension allow-list in project level settings would prevent using optional extensions (themes, slash command extensions, etc)

you could have allow-list by extension type? This way you can only allow some language extensions while doing nothing to the themes

[mantou132]

Extensions can now register ts plugins. When the ts plugins registered by two extensions conflict, I need to disable one of the ts plugins. I think disabling the extension in the project configuration is a good solution.

e.g: gem extension conflicts with vue extension

@vue/typescript-plugin in vue invalidates some functions of gem's ts-gem-plugin

[mantou132]

I've tried overriding the ts-plugin configuration and that doesn't work now

[mantou132]

Now the only way to get the gem extension working properly is to uninstall the vue extension