Vscode: Ability to enable extensions only on specific workspaces

[BobVul]

2882 recently added the ability to disable extensions either globally or on specific workspaces. With these new options, it is now possible to have extensions enabled on all except some selected workspaces.

However, it currently does not seem to be possible to enable extensions on specific workspaces while disabling them on all others, effectively the inverse of what is currently implemented.

I am currently running some extensions that incorrectly activate on workspaces they should not, and there is no way around it apart from toggling the enabled/disabled state every time I open a workspace¹. This is a rather tedious process. Getting the extension author to leave a marker file also pollutes the workspace, and some extension authors may not be willing to do so.

---

^{1 Disabling them on each workspace manually isn't a great solution, when I often use "Open with Code" on previously-unvisited directories. This particular offending extension ends up creating a hidden settings folder, leaving them scattered around unrelated directories.}

[wopian]

This also applies to when you want to change an extension to Disable (Always) while it's disabled in the current workspace. You first have to re-enable it in the workspace and then change it to Disable (Always).

Disabled in workspace:

Disabled globally:

[zrrtcs]

it would be a great pleasure if it is configurable from .vscode/settings.json
eg:

{
  "extensions.enabled": ["ms-vscode.csharp", ...enabled],
  "extensions.disabled": [/*whatever extensions wanted to be*/...disabled],
}

[danielo515]

This is very convenient.
I don't want to deactivate all the extensions that I don't use per project. It should be the other way around.

[josundt]

After starting to use the TSLint language plugin with the TypeScript language service in VSCode, I need to ensure that the whole team disables the TSLint extension.

We already use the file ".vscode/extensions.json" to promote recommend extensions for the workspace to the team. It make sense to also support disabling plugins through this file, right?

[OliverJAsh]

After starting to use the TSLint language plugin with the TypeScript language service in VSCode, I need to ensure that the whole team disables the TSLint extension.

We already use the file ".vscode/extensions.json" to promote recommend extensions for the workspace to the team. It make sense to also support disabling plugins through this file, right?

I have exactly the same requirement.

The disable issue you mentioned is tracked by https://github.com/Microsoft/vscode/issues/18386

[Ciantic]

I'd like to add my obvious notion from the duplicate I did:

It should store the extensions which are selectively enabled to workspace settings file like also @zrrtcs suggested, but VSCode could also then suggest for user to install the extensions if such workspace is opened with extension list.

Btw selectively disabling is a different beast, I think storing that to version control is less common. Storing enabled plugins however maybe even required for other people to open the workspace.

[pr-yemibedu]

Hello,
A possible best choice would be to make all extensions either (eager or lazy). That way when you have a project, you can add all the lazy extensions to load with it. and any eager extensions can be shutdown when out of scope.

• Marking something eager would allow it to load when its built in context is valid (file extension, user settings value, etc.) and you can shutdown it down for a specified workspaces settings.
• Marking an extension as lazy would provide for it to be in a hint to the user as helpful for this project, but not actually load unless the user makes that choice in their settings.

Everything could be marked eager by default to emulate current behavior and those who want a thinner profile can opt in to making more of their extensions lazy. The status bar could have an "EXT Hints" entry whenever a lazy extension would otherwise have been activated in the editor. Thank you. Good day.

[mherodev]

The biggest offender here is my collection of 5+ linters that are only individually useful alone on specific workspaces.

Preferably I could have my personal settings disable them by default, and them enable them on a workspace level, e.g.

User Settings

{
  "extensions.disabled": ["ms-vscode.jscs", "dbaeumer.vscode-eslint"]
}

Workspace Settings

{
  "extensions.enabled": ["dbaeumer.vscode-eslint"]
}

Then my linters are correctly enabled workspace to workspace.

[jrz]

Fully agree. For me it's forcecode and typescript/angular

[richarddavenport]

I love @mherodev's option. But, I also suggest enhancing the API so that we can build extensions to do this for us?

[jrz]

Can we prioritize this? VSCode is getting dog slow because of all the different types of projects

[sandy081]

Could not get to this in October milestone. Moving to November.

[xahon]

I dont understand. Is this feature already done?

[sandy081]

No.. Moved to next milestone.

[felixfbecker]

This would be very important for enabling formatters like Prettier only on the right workspace folders, relevant discussion: https://github.com/prettier/prettier-vscode/pull/252

[xahon]

This #37464 should be very similar to this issue

[sandy081]

This feature will be available in tomorrow's insiders. Please try out and give the feedback.

You can now enable an extension for a workspace using following action. This action is enabled on disabled extensions.

An extension can be

• disabled completely
• disabled for a workspace
• enabled completely
• enabled for a workspace

[jrz]

Great stuff will do tomorrow.

[buehler]

Most awesome! Will try it out. This feature will help in many ways.

[jrylan]

@sandy081 This is absolutely great! Is there anyway to control which extensions are enabled/disabled via your workspace settings folder (.vscode)?

[sandy081]

@jrylan Enabled/Disabled extensions are not stored in workspace settings. Instead it is stored in local storage cache. You can manage them from the extensions view.

[dbaeumer]

Marking as verified. I used this the last couple of day when coding PowerShell with the PS extension. Liked the support!