How can you manage (force- not recommend) what extensions are enabled/disabled in a VS Code workspace with a configuration file?

Question

You can manage settings for each workspace in the .vscode/settings in the root of the workspace folder, it doesn't seem possible to do this with enabling/disabling extensions (unless the extension itself has a setting to enable/disable itself). For example so that extensions can be disabled gloablly and then enable in the workspaces you need them without having to go through the GUI. Obviously you might not have these extensions installed which might be why you can't do it, but that usually means it's someone else working on it which is what extension recommendations in the extensions folder is for, but that's not what I need.

Answer 1

The best you can do for configuring what extensions are enabled per-workspace via configuration file is extensions.json, which only gives recommendations for what extensions to have installed and enabled / disabled. There is no file that you can use to force what gets enabled or disabled per workspace. I wager that this is by design to allow each user to make their own choices (I think forcing something upon the user could make for bad user experiences).

Related questions:

• Is there a way to toggle VS Code extensions per project?
• Where does VSCode store the enabled/disabled state for extensions?

I think what you are looking for is covered by Feature Request: Enable/disable extensions from config file #40239. I suggest that you give that issue ticket a thumbs up reaction to show support for it, and subscribe to it to get notified about discussion and updates. Please avoid making noisy comments like "+1" / "bump", and if you want to participate in the discussion, please read through what has already been discussed to avoid repeating what has already been said.

Answer 2

As with many things, the solution to a challenge might not come in exactly the form that you've envisioned. One solution to this challenge is not to set the list of extensions in the workspace, but in a Profile. Ref

This is a hotly debated topic Ref where the current VSCode provides solutions for many similar challenges, but it's not a one mechanism truly fits all use cases. And really, how many tools actually fit all use cases?

Specifically, a Profile has environment-specific settings that you may or may not wish to mandate for specific workspaces. You have the choice. Here is an example of what a Profile contains:

A Profile can be saved with a workspace, and you can make it a team policy to always load the profile that comes with the workspace from the repo.

When you load a Workspace, it will load with the Profile you last used with it. So you don't need to manually load the Profile with every Workspace. That is - when you open the project, your extensions are modified for that specific Workspace. Ref

The Profile can also be selected from the CLI. There is a CLI --profile option to set which Profile to use for the current session. Ref If you load VSCode with an alias this can be done automatically for you.

Summary: This addresses the presented challenge:

so that extensions can be disabled gloablly and then enable in the workspaces you need them without having to go through the GUI.

Specifically, you setup your environment as you wish, save the current environment as a Profile, and the next time you open the workspace you have the same settings.
In the bigger picture you'll want several Profiles, one default for "General" projects, maybe one for React, one for Vue one for PHP, one for C++, etc..

Suggestion: Try to use Profiles and see if they work for some or all of your use cases. Use them where they fit, and not where they do not.

Request: Please don't debate the nuances of the implementation of Profiles in VSCode (nuanced team use cases, ugly JSON, using .code-profile and not .code-workspace...). This is an Answer to a Question, and the OP may decide it is their accepted answer - or it may not suit their use cases. Elegance is a different topic which is discussed in the referenced GitHub ticket. If you want to debate elegance, please do it there.