Feature Request: Enable/disable extensions from config file

VSCode Version: 1.18.1
OS Version: Windows 10 FU

Explain:
There are certain extensions that play well together, and it would be useful to be able to set a config file to enable and disable certain extensions in that workspace. This would be a config file, like the extensions recommendations, but with a series of parameters that would allow to enable and disable certain extensions.
This would be like a config file for the "[Dis]Allow (Workspace)" setting.

@ramya-rao-a Extensions recommendation file is meant to be shared (in team). Disabling and enabling extensions is user specific. Merging these two is not a good idea I guess.

This could be merged with #48743, in that we can prompt a user to enable and disabled extensions which have been marked as recommended, and prompt the user to disable any enabled extensions marked as unwanted. This could be saved per workspace.
The control would still be at the hands of the user to accept/reject/permanently ignore those prompts. It could end up with a similar feel to the existing prompt to install recommended extensions, where the team suggests the user do something, but the user is at liberty to ignore those suggestions.

I would personally prefer to have a whitelist, not a blacklist, of extensions for a particular workspace. The reason is I might add extensions to Code later and I don't want to go to every workspace and explicitly disable that extension. On top of that, if some extension is disabled and I don't have it installed, no action is required :)
I would really like to see this feature implemented. My VS Code has tons of extensions, but some projects use only a small slice of those, so I don't see a reason why they should be enabled and slow everything down.

@jankalfus I read somewhere that VSCode only loads the extensions that it needs, so having then installed and enable should not slow down your editor if you are not using it, but maybe this can be clarify by the team.

@michaeljota I would also expect it to work like that, but I remember the C# extension complaining on every VS Code start that it needs to download some files for code completion or something. It didn't matter which project I opened (plain JavaScript). This might have been fixed though, I haven't been using Code for about a half a year, just got back to it a few days ago :)

@jankalfus Well, yeah, I remember that. But I think that's only the first time it updates or something like that. Like I said, maybe the team can explain a little bit about how/when the extensions are actually being used.

I read somewhere that VSCode only loads the extensions that it needs, so having then installed and enable should not slow down your editor if you are not using it, but maybe this can be clarify by the team.

Each extension declares when it should be activated by VS Code. See Activation Events

We already support this feature in Extensions view.
You can go to Installed Extensions view in Extensions viewlet and use Disable (Workspace) action under gear icon to configure extensions to be enabled for the given workspace.

I know you can disable an extension in a Workspace, what I'm asking is a file to do this automatically.

@michaeljota Just want to understand what is the use case to have this in a file?

@FancyBanana I think your request is for synchronising workspaces?

@sandy081 No, my idea is pretty much creating another .json config file inside .vscode folder that overrides enabled/disabled state of extensions.
Also a good point form @burtek:

Please keep in mind, that if implemented, the state should be kept in a separate file that could be explicitly ignored within VCS, so that it won't be shared between developers working on the same project. Especially, it should not be put in extensions.json, as this file may contain extensions recommendations that are usually included to VCS and shared between developers

@FancyBanana creating a file under .vscode folder will have side affects like @brutek mentioned.

@sandy081
I have seen the same feature requested many times. It seems to be something people (including myself) care about. The answer that is often given is that we should just manually enable/disable extensions on a per workspace basis, but this quickly gets tedious for developers working on many projects.
I understand that there are limitations to what additions we can make to the vscode architecture (even though I don't know the nature and extent of these limitations), therefore I would like to propose a solution that works with the existing implementation of workspace specific enabling/disabling of apps.
Why don't we implement a new command that you can run from the command pallete called:
"Extensions: Enable only recommended extensions for workspace"
This command should:

disable all extensions for this workspace only,
enable only the extensions listed in the ".vscode/extensions.json" file of the current workspace
then reload vscode.

The workspace specific settings would still be stored in local storage where it is currently stored. Just the manipulation of those settings would be automated by a command that takes the already existing extensions.json file as input, thereby adding a secondary purpose/utility to it without introducing side effects, because the command has to be explicitly invoked by the user.
This command should not automatically install recommended extensions found in ".vscode/extensions.json", though, which is not always desirable, but for those that also wish to install extensions that are not yet installed, that could become a separate command too called:
"Extensions: Install all recommended extensions"
This command should:

install only the extensions listed in the ".vscode/extensions.json",
then reload vscode.

Implementing these commands would allow for a workflow where developers have template extensions.json files that they can copy into their respective workspaces, then run at most two commands (which they could even make into an initialization build task) and then be completely set up to work on their desired project.
We could even create commands like:
"Extensions: Configure recommended extensions based on template"
and
"Extensions: Create/edit recommended extensions template"
Which would allow developers to create and browse through a list of recommended extensions  templates for the extensions.json file. These templates would also be saved in local storage.
It could look something like this dropdown list where templates are user created:
Configure recommended extensions based on selected template
php        - extensions.json
python     - extensions.json
javascript - extensions.json
web-dev    - extensions.json
C++        - extensions.json
Sorry if perhaps this comment is a bit lengthy. Bolding is added to highlight, not to shout.

@FancyBanana I think your request is for synchronising workspaces?

I'd love this feature implemented and for me it would definitely be to sync workspaces: I use multiple machines for my work, I can already sync installed extensions and a number of config settings using dedicated extensions (e.g. shan.code-settings-sync) but if I want to disable some extensions in specific workspaces then I have to manually replicate the configuration across all machines

@JordyScript Your solution sounds like a good compromise, but there's couple of inconveniences i can see:

I personally have ~10 extensions active all the time and i only manage at most 5 per workspace
Themes are counted as extentions

Those amount to the fact that extentions.json will have a lot of boilerplate code.

@FancyBanana You raise good points. I agree that the extensions.json file should not be littered with user specific preferences unrelated to the project, like themes or general utilities, rather than project specific preferences, since the original aim of this file was to share between team members. You don't wanna end up with a list of recommendations, most of which other users will want to ignore.
What we need then, in addition to those aforementioned commands, is a global whitelist of extensions that the user can specify to always remain active, which would then override/ignore the behaviour of the aforementioned commands.
Built-in Extensios are already unaffected by the existing command to disable all Extensions, so it should be possible to create a separate category for the user-installed Extensions/Themes that one wishes to remain active at all times. Of course a user could add to and take away from this category at any time.
So with this modification, we would end up with two whitelists:

global whitelist
workspace whitelist

And the interplay between these two would hopefully provide the granularity of control to cover everyone's needs.

please add this feature it'll help a lot of people including me.

This issue is already a year old and still not resolved... I wish someone would look into it.

Any news on this issue?

I need a way that allows me to quickly disable/enable batches of extensions when there is a problem with extension interference and I need to debug various settings and/or find which extensions are responsible for the wrong observable behaviour.

There is another use case: auto-enable extensions per session. Since my other issue was closed:
We develop apps in node, asp.net, and python. We have extensions for each platform, so my vscode has almost 50 extensions, and some conflict with each other. Switching between projects is challenging, as I need to disable/enable various extensions.
It would be nice to have something similar to .vscode/extensions.json, but it enables specific extensions for that workspace. Let's call it .vscode/session.json for example.
So by default all the extensions would be installed, but not enabled. When I'd open a workspace with a .vscode/session.json, the extensions in that file would be automatically enabled, for that session only.
Maybe we could reuse .vscode/extensions.json like this:
"recommendations": [
  "ms-vscode.vscode-typescript-tslint-plugin",
  "dbaeumer.vscode-eslint",
  "msjsdiag.debugger-for-chrome"
],
"enableForSession": [
  "foo",
  "bar",
  "baz"
]

In my case I would love to have a file or section in extension.json that is shared through git because it would help others in our team as well.
Let's say someone new starts to work with your project in your company and installs all the recommendations but also has similar plugins already installed in his Code installation (linter or formatters that work without configurations). Now this person would have problems, will format things different, need to reconfigure his default formatter or ... – just for just one project.
Whitelisting or Blacklisting (both would be nice) would solve this and would add extra power and startup speed.
Somehow this would also force some people to use VS Code when they prefer other editors (yep this humans exist). Maybe we could think about something like EditorConfig but just PluginsConfig? Just an idea. Many plugins/projects/authors implement EditorConfig and will reuse it, what if we could have this for plugins as well. I know this is out of scope of a native implementation but just a thought that could work across editors/ide's.

We develop apps in node, asp.net, and python. We have extensions for each platform, so my vscode has almost 50 extensions, and some conflict with each other. Switching between projects is challenging, as I need to disable/enable various extensions.

If you can cleanly separate it into three sets of extensions, you could use shortcuts that launch VS Code with different data and extension directories.

@Luckz Yep that's what we do - but it's a workaround. The idea is to encode the environment into the json file, so it goes into source control.

@lonix1 may i know how do you do different config for every vscode shortcut?

@chan-dev It's been a while since I tinkered with that, if I recall correctly the trick was to 1) disable or remove all extensions from the command line, 2) install the ones you want again, 3) start vscode. Very slow and aggravating, but it works and can be scripted.

Is it really not possible to create a config file containing a list of enabled plugins and then simply type in the Command Palette, for example, "load Svelte profile" and automatically have all my Svelte plugins enabled and all of my Vue plugins disabled?
If not, such a feature seems like a no-brainer. In a given day, one can easily start/jump-between multiple projects, each using totally unrelated plugins. To have to manually enable/disable each plugin for a workspace by—pardon me—"clicking a mouse" 🤮 is blasphemous and archaic.

There is an extension called profile switcher that allows for this but it completely uninstalls/installs the extensions rather than simply turning them on/off.
It would definitely be nice to have an official way of doing so which disables/enables extensions like you mentioned.

The reason is that the CLI allows to "disable all extensions", but not to "disable single extension". So the only way is to uninstall all of them, and reinstall the ones you want.
A simple intermediate fix would be to simply add "disable individual extension" to the CLI, then my approach would be quicker, and less taxing on the MS extension server.

Somewhere in this codebase there must be functionality to disable a single extension—we know this because it is possible to manually do so:

... which is the current suggested solution for configuring extensions on a per workspace basis.
The problem of course, is that there is currently no way to save such a configuration across multiple workspaces. If such a feature were implemented, it should be a personal (per instance of VS Code) configuration—I don't think it's an issue of trying to sync extensions across a team, like an .editorconfig or something. But if config files for this did exist there's also no reason why they couldn't be shared if so desired.
Why not allow for the ability to create a new set of config files each containing a specific 'whitelist' of enabled extensions and call it something along the lines of: "SomeName Extension Profile". One can then, for example, open the Command Palette and "Load Python Extension Profile".
The whitelist of extensions in the "Python Extension Profile" can be compared to the list of all extensions the user currently has installed. If a whitelisted extension is not enabled and exists, enable it. If a non-whitelisted extension is currently enabled, disable it. This could import the existing logic which allows for the manual extension enabling/disabling (as pictured above), and just automate it.
This feature should have the final say in the state of all extensions, overriding and updating any other saved state.
Are there any techincal problems with this proposal? Is such a feature considered low priority?

https://github.com/svg/svgo/issues/1137#issuecomment-518351171

I think it is considered low priority as extensions authors must enable their extensions only when a certain kind of file gets open. So, in theory, working with multiple extensions that you are not using, should not impact on the performance of VSCode as it only will load the extensions that you are actually using. Of course, this all in theory, and we all have our suspects it's not actually the case.

maybe we can create an extension that does it?

Well there already is. The issue is that VSCode doesn’t expose the correct methods or properties to enable/disable extensions. So extensions like profile switcher are required to uninstall and install extensions completely instead as mentioned previously.

Maybe we can go a step further and make that dependent on the language too.
I expect it can be complicated, but it's just an idea

Why?

For example, I'm using a plugin like Highlight Matching Tag. I want to use it for XML files, but I do not want to use it in HTML files at the same time

The next example is that I use the Prettier plugin. I would like it to function only in JS files.

These are two examples that immediately came to my mind, but I think there are more cases where it could be useful

My original ticket ➡ https://github.com/microsoft/vscode/issues/78349

Can't believe this feature is not implemented via any config file like extensions.json.
A clear example of a common issue is when using flow, theres even a popular stackoverflow thread about vscode complaining about types being used on .js files instead .ts files.
Then you need to deactivate built-in module "TypeScript and JavaScript Language Features" so module "Flow Language Support" can take control.
This is something developers of the extension are aware of so please make this happen so we all dont have to deal with manually deactivating the built-in extension every time we create a workspace (and so we could share the configuration on projects).

Actually the best reason for them to prioritize this feature, is that the workaround I gave above (which apparently is widely used), hammers their extensions servers.
So it's in their interest to work on this... 😉

An attempt at a summary of the different needs and wants:
Use a (shareable) config file to ...

disable extensions in a workspace
enable extensions in a workspace
suggest extensions to install in a workspace
install extensions automatically
uninstall extensions automatically

What is already possible
Number 3 is the only one possible. Number 3 is possible by using the Workspace recommended extensions feature that utilises an extensions.json file in the .vscode folder. The file is meant to be shared. VS Code prompts users to install the workspace recommended extensions the first time opening the workspace. One can even ignore workspace suggestions which will add the ignored extensions to the extensions.json under "unwantedRecommendations".
Number 1 is not possible with a config file but can be achieved locally. Docs: disabling extension
Number 2 is not possible with a config file but can similarly to 1 be achieved by manually enabling the extension through GUI. This only works for enabling previously disabled extensions.
Justification discussion
Why disabling can be necessary
Generally it is being said https://github.com/microsoft/vscode/issues/55985#issuecomment-411502392 that one do not need to disable extensions. Extensions should (generally) only be activated when they are needed, and they achieve this by listening to activation events. Extensions could, however, choose to start when VS Code starts, so the only way to be sure is to disable them.
Another issue is that even though the extensions aren't active, the views they register will show. In the image below I opened a React project with no java or pom-files. We see that the views Maven Project and Spring-Boot Dashboard still shows in the Explorer, and an extra Test Java icon shows in the side bar. Disabling the extensions removes the views.

Number 1 - Use a (shareable) config file to disable extensions in a workspace

+ Most settings in VS Code is saved in a settings.json that users can access. Storing the disabled extensions in settings.json seems consistent.
+ Storing disabled extensions in the settings.json would allow for transferring (copy-paste) the information about which extensions are disabled to another project. Good for quickly using (in this case disabling) the same extensions on projects with the same technology. Storing disabled extensions in the extensions.json would allow for sharing disabled extensions with team members.
+ When one have many extensions for different languages turning one extension off at a time is annoying.

Number 2 - Use a (shareable) config file to enable extensions in a workspace

+ At least two users wanted to make extensions disabled by default, which makes this feature valid https://github.com/microsoft/vscode/issues/40239#issuecomment-403378144 and https://github.com/microsoft/vscode/issues/18386#issue-199999376 When the number of extensions become high it could be easier to enable the extensions one want rather than disabling the ones one do not want.
- Since extensions are enabled in a workspace by default one can discuss whether there actually is a need for explicitly enabling extensions in a config file.

Number 4 - Use a (shareable) config file to install extensions automatically

+ Useful for installing extensions on a new set-up
+ Install and uninstall extensions each time one switches workspace to use less CPU and memory https://github.com/microsoft/vscode/issues/55985#issue-348603388
One user wants to force his team to use a specific linter... https://github.com/microsoft/vscode/issues/347#issuecomment-380270294.
- Already possible to create extension pack
- Already possible with the Profile Switcher extension
- Installing without asking for approval is bad https://github.com/microsoft/vscode/issues/55985#issuecomment-411502392

Number 5 - Use a (shareable) config file to uninstall extensions automatically

+ Install and uninstall extensions each time one switches workspace to use less CPU and memory  https://github.com/microsoft/vscode/issues/55985#issue-348603388
- In itself this feature doesn't make much sense?
- Already possible with the Profile Switcher extension
- Uninstalling without asking for approval is bad

Conclusion
As I see it, there are one inconsistency and one feature request:
The inconsistency -> disabled in settings.json
Which extensions are enabled and disabled are settings, and like the rest of global and workspace specific settings these should be stored for the user to see in the global settings.json or workspace settings.json, dependent on what the user want.
Since extensions are enabled by default I propose to only add disabled extensions to settings.json.
The feature request - sharing
People want to be able to share which extensions that should be on or off across projects with similar technologies and with their team.
I propose to follow https://github.com/microsoft/vscode/issues/40239#issuecomment-397470014. One adds an "unwantedExtensions" list to the extensions.json and users will be prompted to disable these extensions. One could also prompt the user once to enable the extensions that are recommended in extensions.json but disabled.

Great summary! I agree for the most part with this.
The main issue I see with only adding in a “unwantedExtensions” is whenever you add a new extension, say for Java, you have to add it to every single workspace that shouldn’t use it, in this case any project that isn’t in Java.
Perhaps a toggle between default enable and default disable for all apps would be good. From that, you could have the “unwantedExtensions” and the “wantedExtensions” which makes sure that some extensions are enabled.
Lastly, I feel like the “recommendedExtensions” should be either moved back to settings.json, or these proposed changes should all be moved to extensions.json. Having them separate like this seems disorganized.
(Sorry for bad formatting, I’m on mobile)

Hm. In my opinion... I have a totally different thought about this. Maybe not everyone will agree but; what about having extension installed as normal and if there is a extensions.json with (not with recommend) an extensions prop that says „this project and this extension are a perfect fit“ so VS Code will parse (before doing anything else) and disable all except this extensions an recommend the not installed once so everyone with this project have the SAME Vs Code + Plugins as anyone else. This could be opt-in. So any user can have A VS Code option that says „automatically use workspace/project extensions“ or „use this workspace extensions from this project from certified/verified authors or created by yourself“. This would allow everyone working with your project or every project from yourself, to work on the exact same env that fits the requirements. I think that is something similar to .editorconfig but with extensions. Saying it again „opt-in“. I would love this. So I would have the perfect env in every of my own projects (parsing configs and ext. Before loading the view) and would be ask to have it on other projects (after loading the view).
Sent with GitHawk

The main issue I see with only adding in a “unwantedExtensions” is whenever you add a new extension, say for Java, you have to add it to every single workspace that shouldn’t use it, in this case any project that isn’t in Java.

@PandawanFr Mostly true, if you have different projects you need to add the extension to each project's "unwantedExtensions". At least you can commit the extensions.json to git or copy-paste it around like a profile. The other alternativ is indeed your next paragraph:

Perhaps a toggle between default enable and default disable for all apps would be good. From that, you could have the “unwantedExtensions” and the “wantedExtensions” which makes sure that some extensions are enabled.

But that is yet another feature request. Current behaviour is to turn installed extensions "on" which makes sense.

Lastly, I feel like the “recommendedExtensions” should be either moved back to settings.json, or these proposed changes should all be moved to extensions.json. Having them separate like this seems disorganized.

"recommendedExtensions" in extensions.json are meant to be shared through source control, settings.json are not. Having them separate underlines that there are a separation. Extensions.json will continue to hold recommendations meant to be shared, while settings.json will continue to hold your personal settings.

So any user can have A VS Code option that says „automatically use workspace/project extensions“ or „use this workspace extensions from this project from certified/verified authors or created by yourself“. [...] This would allow everyone working with your project or every project from yourself, to work on the exact same env [...]

Good input! I think this need wasn't clearly included in my summary so I added it as Number 6 and updated "The feature request" section.

@Sti2nd settings.json should be source controlled too unless it is the workpsace setting because it just makes sense. Imagine a python project with venv where you need to tell the python extension to use autopep and python inside the venv. If you would not source control it. Everyone in your project would need to manually adapt your settings.json.
Sent with GitHawk

@muuvmuuv You could source control it if you want everyone on your team to have the exact same settings. If there is only one setting you need to enforce across the team, I would say it is overkill to sacrifice everyone's customisation freedom.

I would also add my desire about this feature, I'm coding Laravel and want to learn Django, or .NET Core, but I don't want to have Laravel Extension Pack enabled on those, instead I would use Python Extension Pack in Django projects, I would like to group these extensions and choose the environment by using global settings, or auto detection or workspace settings file etc..
So, question, can we control extension loading/unloading with some extension? I guess any extension written to do this would need to have a priority to load before any others to prevent loading of further extensions. So it's more likely to be handled by core. Am I right?

I would also add my desire about this feature, I'm coding Laravel and want to learn Django, or .NET Core, but I don't want to have Laravel Extension Pack enabled on those, instead I would use Python Extension Pack in Django projects, I would like to group these extensions and choose the environment by using global settings, or auto detection or workspace settings file etc..
So, question, can we control extension loading/unloading with some extension? I guess any extension written to do this would need to have a priority to load before any others to prevent loading of further extensions. So it's more likely to be handled by core. Am I right?

+1

@tpaksu You are right in that extensions do not have access to disable extensions today. The profile switcher extension installs and uninstalls extensions as a work around https://marketplace.visualstudio.com/items?itemName=aaronpowell.vscode-profile-switcher

How about grouping the extensions in a directory and choosing the directory path when loading specific workspaces as the extension directory? When installing an extension in the related workspace active, it can move the extension to that directory automatically, and there might be a global extension directory for loading the common extensions for all groups.

Good idea. But I think the implementation isn’t much of an issue. It’s how you set it up that’s main problem.
On one hand, you could keep all global extensions enabled by default and read the workspaces’ unwantedExtensions setting to disable those that you don’t need.
On the other hand, you could have a list of the extensions that should be enabled and disable all by default (which might not be good if users install extensions for themselves).

@PandawanFr the implementation is an issue because I'm thinking about a way without modifying the core and make it work in everywhere (even in the older versions of VSCode. Last night another option came to my mind, it's not related with any core or extension but it'll consume some space on the hard drive. The method came to mind is to use the portable mode for each development environment with their own data folders with their own extensions :) Probably the easiest solution right now.

The method came to mind is to use the portable mode for each development environment with their own data folders with their own extensions :) Probably the easiest solution right now.

There's commandline options for user data and extensions, https://code.visualstudio.com/docs/editor/command-line#_advanced-cli-options , as mentioned above in https://github.com/microsoft/vscode/issues/40239#issuecomment-525193644 etc.

I use some kind of workaround to be able to use the extensions I want.
According to the vscode-cli your can specify the folders for extensions and user-data:
Options                  Description

--extensions-dir <dir>   Set the root path for extensions.
--user-data-dir <dir>    Specifies the directory that user data is kept in. Can be used to open multiple distinct instances of Code.

Basically, I create a specific folder for my specific tasks (one of front, one for back, ..) and set basic extensions to my default vscode.
To launch my custom config:
code --extensions-dir "$HOME/.vscode/profiles/my-super-profile/extensions" --user-data-dir "$HOME/.vscode/profiles/my-super-profile/data"

The problem are that:

It's not really a project config file but a global preference file
I had to install manually the extensions. I believe there is a hackish way to do this
It use more size than necessary (multiple vscode data / duplicate extensions)
It doesn't solve in a clean way the team-sharing problem

I hate to add yet another voice to this already long issue, but I also feel strongly about this. I work on many different types of projects and I have a TON of extensions installed. Startup of VS Code is extremely slow and the UI is often locked up waiting on tasks to complete (or more likely, it's just heavily CPU bound and unable to respond to user input), and usually, 20% - 30% of the time, the extension host dies while all the extensions are being loaded. Also, VS Code consumes GBs of RAM. In reality, for each project, I only need a few extensions enabled at any one time.
The ideal situation for me is that I could install all of the extensions I wish to have installed which are intended to be used across various different workloads. I could disable globally (for my user profile) all project-specific extensions (e.g. C#, F#, docker, azure, linters, beautifiers, etc.) while leaving others enabled (i.e. color themes, SettingsSync, pomodoro timer, etc.). Now I acknowledge that we can already do this today--basically, disable all extensions, then re-enable the ones you always want to be enabled.
But the next part: only enabling extensions required for a certain workspace—this is not possible to do, automatically, today without some kludge (like the aforementioned profile switcher extension or specifying the extensions and user directory as command-line switches to VS Code (i.e. a shortcut per project/environment type), which in my view is hardly desirable for several obvious reasons).
I submit that this information may need to live in two different places

One is a shared location meant to be distributed amongst members of the team (i.e. checked in to source code control): this file would contain the names of extensions, that if installed, will be enabled when the folder is opened (so, if this file is present, VS Code would need to process this file when opening the folder). If the extension is not installed, nothing happens. I imagine extensions which are not installed would also be specified in the extensions.json file and would recommend the installation of such an extension. (Perhaps the existing extensions.json file is already the correct location for this information?) The obvious place for this is in the .vscode folder.
The other location would hold a user-specific workspace extensions settings file. Perhaps, in addition to the recommended workspace enabled extensions, there are other extensions you personally like to use to aid your productivity for a given workspace/workload. They're not expressly forbidden by your organization/team nor do they conflict in any way with other project extensions (e.g. linters, beautifiers)—I mean, I suppose it's possible they could, but then your use of these extensions is between you and your team 😉. This file would also be read upon folder open and enable those extensions, too. The trick is—where does this proposed file live?

Thinking about the proposed user-specific workspace extensions settings file: on the one hand, it could be stored to the same location where your personal VS Code settings are stored in your user profile (i.e. another file in your User settings folder for VS Code--not in the settigs.json file). But then you have the issue of mapping settings to workspaces. (Do workspaces have a name/id? And what about when Visual Studio Code forgets about your workspace? I can't tell you how many times I've lost my "context" due to VS Code not properly recording which files were open in a session when VS Code goes down hard.)
But then it occurred to me: I've heard it suggested that the .vscode folder shouldn't be checked into source code control. But then, there are clearly files in there that are meant to be shared. Perhaps this folder is too big of a "catch-all" folder for "settings". Perhaps we need a folder such as .vscode-user that holds personal workspace settings not meant to be committed to source code control. While that could help with user-level workspace configuration settings, the downside is "yet another folder to ignore" in our .gitignore files. But, not only are extensions something that might be user-specific, but Tasks, Launch configurations, and other general VS Code settings as well. This suggestion alone might neatly resolve a lot of the issues with requests of this nature.

user-specific workspace extensions settings file

@fourpastmidnight You can use a .code-workspace file for that. That's how I personally configure my workspaces, with one single Project.code-workspace file (where Project will be the name of the workspace) which holds all workspace specific editor settings, theme settings, extension settings, extension recommendations etc. (VSCode will also launch the workspace when you open the file). I exclude this file from source control since it's specific to my preferences.

The trick is—where does this proposed file live?

Technically it can live anywhere, as you can specify the directories of your project files inside this file (relative or absolute paths). I keep it in the root workspace folder though.
As for this issue, an extension whitelist setting would be the ideal solution (to save workspace-enabled extensions in the workspace settings, and globally enabled extensions in the user settings). Currently I just use the recommendations setting to keep track of workspace specific extensions and enable/disable what I need manually when I set up the project.

@raz-avr  Ah, I have never used the "multi-root workspace" feature, so I didn't even know about the existence of this file.
However, is this file intended to be shared amongst team members? It looks like the answer to this question is "it depends". If this file is shared, then it would not serve as a good place for user-specific extension preferences for a workspace. (I'm thinking of something akin to the Visual Studio .vs folder that holds things like the solution .suo file for holding user-specific solution settings, such as IISExpress host/port settings, for example.)

is this file intended to be shared amongst team members? It looks like the answer to this question is "it depends".

@fourpastmidnight Yes, it depends. It's a configuration file that stores settings, so it depends on whether you want to share the specific settings that are in it. The extension recommendations setting for example feels like it's intended to be shared in that regard. In any case I think that generally it makes more sense for users to have individual workspace settings, rather than shared.

@raz-avr I agree it makes sense for users to have individual workspace settings, including what extensions he/she would like to have enabled for a given workspace (which may be a subset of or in addition to extensions already globally enabled for that user). I don't see the .code-workspace file fulfilling this purpose particularly well—unless a user-specific version of the file lives in the proposed .vscode-user folder I mentioned above, in which case, it becomes user-specific workspace settings.

@fourpastmidnight  For me, it achieves its purpose perfectly. I see the .vscode folder as an alternative to the .code-workspace file, in case multiple similarly user-specific and workspace-specific files are needed. If there are settings/files within these that are intended to be shared, they should simply be put somewhere else (and thus added to source control). But, I suppose what is intended to be shared or not is ultimately subjective (and out of scope for this particular issue).

I think sharing is a big part of the problem, however.
Ensuring that user-specific settings (especially as it pertains to extensions to be automatically enabled upon a folder being opened by VS Code—what the main topic of this issue is about) have a well-defined place to live and is explicitly known that it should not be checked into source code control.
As already mentioned, I started this off with thinking about the initial problem at hand: automatically enabling installed extensions upon folder open (both extensions specified by workspace-specific configuration settings (in .vscode) shared amongst a team as well as user-specific settings)—but I came to realize that there are other settings such as tasks, and debug launchers which could also have "shared/team" configurations (again, currently stored in .vscode) as well as personal configurations for any given workspace (which don't have an explicitly defined place to exist).
Sure, you can hijack the .code-workspace file—and that all works until your team has a git repository containing multiple folders and checks in a .code-workspace file to make it easier for the team to work on the repo.

Perhaps there could be a third layer of settings named Shared, in addition to User and Workspace. It would override any User and Workspace settings similarly to how Workspace overrides User, and support both a single-file multi-root structure (i.e. .code-workspace) and a folder structure (i.e. .vscode). The file names would have to be different of course, (e.g. .code-workspace.shared and .vscode-shared). That way the default .code-workspace/.vscode would become explicitly defined to not be checked into source control.
It would be yet another file/folder to have in your project directory, yes, but it would give users freedom to have both user-specific workspace settings and shared workspace settings. Those who only need one of the two would only keep the one file/folder they need.

This is a great feature. I have a use case here. When I'm working in a PHP project, I always have to manually disable all extensions for Ruby, Angular, Node (etc). When I'm working in a Ruby on Rails project, I have to disable manually all extensions for PHP, Angular, Node (etc). When I'm working in a Node/Angular project, I have to disable manually extensions for PHP, Ruby......
Why I'm doing this? Because I want my environment fluid and every byte saved is very important to my RAM.
If we have an extensions blacklist file in project (like workspace file), always the project (or workspace) are opened, the specifics extensions are disabled automatically.
That makes sense?

@diegosomar I get where you're coming from, but I think it should be the other way around, and is what I was proposing: most extensions are disabled by default, and then one or more workspace files (a shared team file and/or a user-specific file) can "whitelist" extensions that should be enabled for that workspace.
Using an "opt-in" model will ensure that:

VS Code startup is quick and minimize Extension Host crashes
Extensions globally enabled by the user are always enabled (e.g. Themes, productivity extenions such as pomodoro timer, etc.)
The workspace then defines the other workspace-specific extensions that should be enabled (upon folder open), ensuring that only extensions required for the workspace are enabled, also saving precious RAM/CPU resources.

The only "Gotcha" here is that some extensions require a reload when they're enabled. So these could be problematic for this "opt-in" model of extension auto-enabling/disablling.

I agree with you @fourpastmidnight! The fewer extensions are active at startup, the faster it opens and the less resources it allocates. Whitelist or blacklist solves the problem. Now, the VS Code team can decide which one is the better implementation.

What I'm hoping for out of this is that I can disable in a specific window, all of my angular extensions that tack on right click menus etc. while working in our C# REST api, and in the angular project disable the extensions for C# to get rid of the distractions.
Especially useful for Test Runners. I don't need the protractor test running enabled taking up space and confusing things when I'm doing C# work.

Note: crossposted here
Could we not also base this upon the language as well. For example, if you open a folder and there are .csproj and fs files then all the c#/.net extensions load and then also the f# extensions as well?
A lot of the options that have been discussed in similar issues I think would be a lot easier to deal with if they took into account the languages in the folder that is being worked on.
Some example options that I have thought of could look something like one or more options below:
{
    // language settings option
    "[python]": {
        "editor.defaultFormatter": "ms-python.python",
        "editor.rulers": [
            88
        ],
        "extensions.activation": [
            "magicstack.magicpython"
            "ms-python.python"
            "njpwerner.autodocstring"
            "frhtylcn.pythonsnippets"
        ]
    },
    // global whitelist option
    "extension.global.activation": [
        "akamud.vscode-theme-onelight",
        "salbert.copy-text"
    ],
    // global blacklist option
    "extension.global.deactivation": [
        "akamud.vscode-theme-onelight",
        "salbert.copy-text"
    ],
    // per extension whitelist option
    "extension.global.activation": {
        "akamud.vscode-theme-onelight": [
            "python",
            "markdown"
        ],
    }
}

I also like the idea of using user defined extension groups that can be used instead of the more verbose way that I show above as mentioned in this post.
Others have suggest similar solutions or discussed this in comments [here],(https://github.com/microsoft/vscode/issues/40239#issuecomment-521186857), here, here, here, here and many more.

Any update on this issue? We are struggling in managing same-characteristic projects everyday

I would be very happy with this option!

I also would find this useful.  I have a multi-root project where different folders use different languages.   The python extensions really want an interpreter and wants to find tests, even though a folder has no python code.  Whether this is done via settings.json, another json, or another mechanism is no matter.
I'd like to see the ability to turn off extensions in some manner on a per-folder basis.

I also find this useful. This feature would be a great addition.

With VSCode being a versatile tool for many independent work environments. This would be a very useful feature, a setting flag in the .code-workspace such as "enable-extensions-only": ["extension 1", "extension 2"  etc] would be a good start to opt-in the workspace-specific extensions settings.

Good idea

I have a use case here.  I have some C++ projects, sometimes I use the clang compiler on Windows, and sometimes I use the Microsoft compiler on Windows.  Each environment has different plug-in set up, but both at C++.
So differentiation by language isn't sufficient.  I want to set up one project to load the clang C++ extensions, and I want to set up another project to load the Microsoft C++ extensions.  It simply makes sense this activation/deactivation of extensions is project specific and should exist locally to my projects which have these requirements.

This would be really nice, adding the choir here.
I would like to organize my projects folder by an overarching type (Let's say I'm writing a whole bunch of serverless apps, as an example)
(Lines prefixed with $ indicate a project name, those that do not have the prefix represent the extension that I would like at that level, and would flow down to dependents)
$PROJECT_ROOT
├── vim
├── Markdown All in One
├── AWS Toolkit
├── Remote SSH
├── $Super-Awesome-Python-Lambda-Function
│   ├── Python Extension
│   └── Pylance
├── $Incredible-MQ-Service-Deployed-With-Node
│   ├── node-snippets
│   ├── Node Debug
└── $NoSQL-Using-golang
    ├── Go Extension
    ├── vscode-dynamodb

While not impossible today, I have to install all of these packages at the top level, and then disable in each project with the GUI. What I would prefer to do is the inverse: A minimal set of self-defined-as-required extensions across all of my projects, and then capability to incrementally add-on or disable when appropriate for my project (Maybe I decide I don't want to use vim in one project because it conflicts with another extension, but I'd still like to keep it globally.)
Interestingly, this functionality is already somewhat available with Visual Studio/GitHub Codespaces through the use of .devcontainers here: https://github.com/microsoft/vscode-dev-containers/tree/master/containers/codespaces-linux

Supported codespace configuration keys

You can use configuration keys supported by Codespaces in devcontainer.json.
General settings

name
settings
**extensions**
forwardPorts
devPort
postCreateCommand

extensions being available in the Codespace container to configure at these lines of code

Now I m using  Profile Switcher for different projects with different natures. But sadly, the extension is still in early stage and buggy.

Reading through this thread, it's clear this is a much-needed feature, and I've longed for something like this for a while. It seems like there are a few considerations:

@sandy081 mentioned earlier that "recommended extensions" should be shared among a team, but that tracking each individual extension (e.g. serializing the Extensions pane into the .vscode folder) would cause issues because most users have different extension needs  at any given time
as @webdog mentioned above, the ability to cascade extensions in nested projects. Of course, if one were to open the entire project in VSCode, it follows logically that it would need to load all the extensions of both the root and every sub-folder, such that extensions could properly emit activate events for different file types. However, it makes sense that cascading might be important for defining a base set of extensions like he mentioned, and then adding several on only when opening one of the sub-folders as the project in VSCode.

Proposal
Here's a strawman proposal that tries to achieve the following goals:

serialize the default state of all extensions at the user level
provide a config for folders (projects) to enable or disable extensions
support either keeping that config at the project level (using .vscode/<some-config-file>.json) OR solely at the user level to avoid the side-effects effects on multiple users of tracking it in Git.

In the user level config

Have a user-level configuration file such as extensions.json Serialize the state of all installed extensions in an extensions key, a map from the extension ID to true or false, indicating whether the extension is enabled or disabled
In this file, add have an enable list
The list would contain test objects that have a test value for a pattern matching system like Regex or globs to match new project opened folder names (likely would want absolute path to allow using parent folder names as information)
If a folder name matches, add the extensions that in the object to a set of activated extensions for that folder
Repeat 4 for all valid matches (this would effectuate the cascading logic mentioned above, accumulating extensions)
Since there's also a "Disable for this workspace" option, add a disable map that disables extensions. This should have a higher priority that 5 (e.g. remove a value if in 5). We can bikeshed over whether the disable option should support regexes,

Example
Based on the data/extensions from the comment above. Uses extension names from the example. In real life, this would likely use extension IDs.
{
    "extensions": {
        "vim": false,
        "pylance": true,
        "Python Extension": false,
        "Node Debug": true
    },
    "enable": [
        {
            "test": "PROJECT_ROOT/.*",
            "extensions": [
                "vim",
                "Markdown All in One",
                "AWS Toolkit"
            ]
        },
        {
            "test": "PROJECT_ROOT/Super-Awesome-Python-Lambda-Function",
            "extensions": [
                "Python Extension",
                "Pylance"
            ]
        }
    ],
    "disable": [
        {
            "test": "Incredible-MQ-Service-Deployed-With-Node",
            "extensions": [
                "Node Debug"
            ]
        }
    ]
}

In this example PROJECT_ROOT has no special meaning, as it is not a regex operator. It's simply an example folder path.
In the project config
We could simply have two lists of extension IDs:  enable and disable in the project-level config in .vscode. Theoretically, since enable could decrease performance, it should be accompianied by a warning, unless a user-level config for trustedEnableExtensions: ["project-name"] or trustAllProjectsEnableExtensions or similar is set.
With user-level extensions in a separate config file, and every project containing its own enable and disable keys, that would be enough to serialize the 4 current options (Enable/Disable (for this workspace)). We should also show an error if a user tries to put the same extension in both enable and disable
For teams that don't want to track individual extension enables/disables in the .vscode folder, they could add a flag like noExtensionTrack that shows an error if users add an enable or disable keys to the appropriate config file in .vscode.
This would then result in the 4 options being serialized as user-level enables or disables in the top extensions map in the user config, or as something like
"enable": [
  {
            "test": "Super-Awesome-Python-Lambda-Function",
            "extensions": [
                "Python Extension",
                "Pylance"
            ]
  }
]

Of course, it would be an important decision what the specificity of the regex should be, because we likely wouldn't want to enable/disable extensions from the 4 options for all projects with the same name. However VSCode currently does it (e.g. absolute path) is probably how it should be done.
The next step would be supporting both methods: tracking project-level extension state in both the user and project config. The project config would override user config where they conflict. Other than that, if user config also specifies enabling an extension in a project it should be enabled. There definitely should be more consideration to these interactions here.
Bikeshed questions

How do the enable and disable extension sets interact? Does disable always cancel out enable?
Should disable or enable only be "individual project" and not cascading (e.g. regex). Using regex and supporting "cascading"- just having multiple regexes match and add the set of extensions is more than the original poster described. This is a powerful feature, but regexes are very general and this could introduce complexity.
Should enable be cascading but disable not? Or the other way around? Would these promote new ways of working? E.g. where for most for most users every day, all extensions you use are installed but disabled, and then upon opening a project that matches some test, a set of extensions are enabled.

Hopefully this is an interesting starting point for some discussions. I'm very glad that the community is working towards serializing all the extension state in an viewable, editable format, and not just having it be opaque to VSCode and used by Settings Sync behind the scenes. I'll also link to #109430 as it is slightly related.

Hi everyone, I made a simple Bash script to achieve this. I'll try to work with the source code soon. I would love to get some feedback on this.
Here is the profiles.json for which I've set the path as $HOME/.config/code-oss-profiles/profiles.json
{
    "_common": {
        "enabled_extensions": [
            "vscodevim.vim",
            "extr0py.vscode-relative-line-numbers",
            "PKief.material-icon-theme",
            "CoenraadS.bracket-pair-colorizer"
        ]
    },
    "web_dev": {
        "enabled_extensions": [
            "abusaidm.html-snippets",
            "ecmel.vscode-html-css",
            "Gruntfuggly.todo-tree",
            "Zignd.html-css-class-completion"
        ]
    },
    "godot": {
        "enabled_extensions": [
            "geequlim.godot-tools"
        ]
    },
    "octave": {
        "enabled_extensions": [
            "toasty-technologies.octave"
        ]
    },
    "text": {
        "enabled_extensions": []
    },
    "java": {
        "enabled_extensions": [
            "redhat.java"
        ]
    },
    "cpp": {
        "enabled_extensions": [
            "ms-vscode.cpptools"
        ]
    },
    "python": {
        "enabled_extensions": [
            "ms-python.python"
        ]
    }
}

In the script, the extensions in _common.enabled_extensions are always set to enabled when code-oss starts. Other extensions depend on the profile you provide with the -p flag.
And here is the bash script (named code-oss-profiles)
#! /bin/bash

PROFILE_PATH="$HOME/.config/code-oss-profiles/profiles.json"

while getopts :p: option
do
case "${option}"
in
p) PROFILE=${OPTARG};;
esac
done

installed_extensions=( $(code-oss --list-extensions) )
enabled_extensions=( $(jq -r ".$PROFILE.enabled_extensions[]" $PROFILE_PATH 2>/dev/null) )
common_extensions=( $(jq -r "._common.enabled_extensions[]" $PROFILE_PATH 2>/dev/null) )

enabled_extensions+=( "${common_extensions[@]}" )

disabled_extensions=( $(echo ${installed_extensions[@]} ${enabled_extensions[@]} | tr ' ' '\n' | sort | uniq -u) )
# declare -p disabled_extensions
disable_argument=""

for extension in "${disabled_extensions[@]}"; do
    disable_argument+=" --disable-extension $extension "
done

code $disable_argument $@

On running with:
$ code-oss-profiles -p python
Warning: 'p' is not in the list of known options, but still passed to Electron/Chromium.

The warning is expected but the flag is not in use so there aren't any side effects as of now.
Here is the screenshot of enabled extensions after running the above command.

Thanks for this job !
I've also created a bash script that can manage profiles switching for VS code
It uses folders to define profiles and symlinks to activate extensions. As it, there is no duplicated extension.
The script can be found at https://gitlab.com/linuxdev_gameamea/osscripts/-/blob/master/Linux/switchVsCode
It's a part of a repo that contains a library of linux scripts that I've created for my daily work.
I have tried to document the code as much as possible to make it as understandable as possible.
To use it:

clone the whole repo (the script has some light dependencies on other scripts)
read the comment the beginning of the script
create the needed structure for the folders
change some values to variables to suit your installation
launch the command to see basic usage: switchVsCode -h

Feedbacks and PR are welcome !

Extensions are bloat up overtime. It would be really nice to have an option to create custom extension profiles.
The use case would be that users will be able to create profiles (I would give language or frameworks name) and enable/disable profiles as they wish according to their current workspace.
The extension profiles basically will be just a group actions to enable/disable extensions. The current feature Disable (Workspace) needs a lot of single manual actions and needs to do it all over again if I open another workspace even with the exact same software stacks.

I also want this feature.

Provide extensions more control over the sequence and grouping of their settings in the settings editor, e.g., support to group commonly used settings

This line from vscode roadmap suggests this is going to be implemented. If I am getting it right.

Thanks for you work towards this feature, looking forward to see it implemented 🤓
Please also keep in mind that this feature ideally should work for VS Code workspaces as well, one workspace having several projects with different configurations and enabled/disabled extensions in it. In the case of a workspace it is not practicable to restart VS Code each time the project changes if the projects enable/disable different extensions.
Usually you will have several tabs from the different projects open and the enabled/disabled extenions would need to be loaded dynamically for which file the user is currently looking at.
Is initializing / uninitializing extensions within a workspace even a thing without restarting VS Code?
Our use-case for example is backend development in PHP and frontend development in JavaScript / Vue. I
We have both the project with the backend code and the frontend code in one workspace to quickly switch between the two.
Sometimes the formatting extensions fight over dominance over the source code. Usually the "Prettier" formatting extension for the backend does not cause problems with the "eslint" formatting configuration for the frontend, but it would be cool to have their respective relevant extensions deactivated (or at least ignored) in the other project depending on which tab is currently in view.
Switching between tabs we would have to activate and deactivate the respective extentions from their .vscode configuration, which could take a performance hit when switching tabs (unless the extensions don't get fully deactivated, more "muted" or "ignored" for a certain project).
Having two separate VS Code windows open to make this feature happen is no show-stopper but if this feature cannot handle workspaces with different configurations for each project correctly there needs at least some type of warning that it only works with separate VS Code windows open.

Provide extensions more control over the sequence and grouping of their settings in the settings editor, e.g., support to group commonly used settings
This line from vscode roadmap suggests this is going to be implemented. If I am getting it right.

No this reads more like extenions will have an option to group and sort their settings (I'm assuming instead of simply alphabetical), judging from the wording.

For some of us, the problem is much simpler: VSCode takes a while to load up, and then complains about PASCAL not loading correctly, and then that no Python tests were found, and then takes a while to scan the entire source directory for ruby gems, and then tells us that we need to upgrade dart because the dart extension just updated, and then the file loads, but we can't type anything into it because yet another extension is loading and then the extension host crashes and VSCode is brought down to a very basic form without extensions and then we restart the host and then it takes forever and maybe it succeeds.....
All so we can change a line in a C# script for Unity.

For some of us, the problem is much simpler: VSCode takes a while to load up, and then complains about PASCAL not loading correctly, and then that no Python tests were found, and then takes a while to scan the entire source directory for ruby gems, and then tells us that we need to upgrade dart because the dart extension just updated, and then the file loads, but we can't type anything into it because yet another extension is loading and then the extension host crashes and VSCode is brought down to a very basic form without extensions and then we restart the host and then it takes forever and maybe it succeeds.....
All so we can change a line in a C# script for Unity.

Since I focused on VSCode for the past few years, my keymaps and snippets in Sublime are pretty much outdated and out of sync up to the point that I don't even care about them any more and every time I open Sublime for some quick text hacking, I cry, because I can't control it any more. Though, it's still much better than Notepad.
I wish I could use VSCode for any text file by default in my system instead of Notepad or Sublime - with a minimalistic UI and very limited set of extensions to make it blazingly fast.
So, that being said, most of the time, I already know what file type or project I will be working with, so I would even imagine setting up multiple VSCode shortcuts with various preferences:

Since I focused on VSCode for the past few years, my keymaps and snippets in Sublime are pretty much outdated and out of sync up to the point that I don't even care about them any more and every time I open Sublime for some quick text hacking, I cry, because I can't control it any more. Though, it's still much better than Notepad.
I wish I could use VSCode for any text file by default in my system instead of Notepad or Sublime - with a minimalistic UI and very limited set of extensions to make it blazingly fast.
So, that being said, most of the time, I already know what file type or project I will be working with, so I would even imagine setting up multiple VSCode shortcuts with various preferences:

I like the idea of having a minimal version of VS Code but IMO it should be a separate installation that has no extensions enabled by default to enable it based on you use-case. For example, I open a lot of Markdown files in Sublime, so I would enable extensions like Markdown all in one and Prettier for formatting. Opening a folder would always open the Standard VS Code and the minimal would have two more commands "Open file VS Code IDE" and "Open folder in VS Code IDE".

I like the idea of having a minimal version of VS Code but IMO it should be a separate installation that has no extensions enabled by default to enable it based on you use-case. For example, I open a lot of Markdown files in Sublime, so I would enable extensions like Markdown all in one and Prettier for formatting. Opening a folder would always open the Standard VS Code and the minimal would have two more commands "Open file VS Code IDE" and "Open folder in VS Code IDE".

According to the CLI documentation you can start VSCode without any extensions using --disable-extensions for a pure text editor. Of course this will have no extensions activated.
Alternatively, using the --extensions-dir option one can set up different extension directories for varying profiles as suggested above using separate shortcuts for each job.
This sounds good for an individual setting up their own dev environment. But this is not ideal and a little clunky to maintain for a team of developers and an awkward workaround.
Working towards a team-oriented approach is very much appreciated.

According to the CLI documentation you can start VSCode without any extensions using --disable-extensions for a pure text editor. Of course this will have no extensions activated.
Alternatively, using the --extensions-dir option one can set up different extension directories for varying profiles as suggested above using separate shortcuts for each job.
This sounds good for an individual setting up their own dev environment. But this is not ideal and a little clunky to maintain for a team of developers and an awkward workaround.
Working towards a team-oriented approach is very much appreciated.

this feature will be really helpful.

this feature will be really helpful.

Why does this need to take more than 3 years to get implemented? Clearly there are use cases enough. The architecture, the mechanics and logic are already there, all we need now is for the existing function to be exposed as a command that can be called from the plugin API. Then some goodhearted Samaritan can implement the gist. No idea why this does not get more support. There was even an issue asking for just that, but it also got closed ... https://github.com/Microsoft/vscode/issues/15466

Why does this need to take more than 3 years to get implemented? Clearly there are use cases enough. The architecture, the mechanics and logic are already there, all we need now is for the existing function to be exposed as a command that can be called from the plugin API. Then some goodhearted Samaritan can implement the gist. No idea why this does not get more support. There was even an issue asking for just that, but it also got closed ... https://github.com/Microsoft/vscode/issues/15466

I already can disable extensions for a workspace. Can't this somehow be moved into the .vscode folder?

I already can disable extensions for a workspace. Can't this somehow be moved into the .vscode folder?

Actually this feature is already available. You simply need to create an Extension Pack in your <profile>/.vscode/extensions/ folder, add extensions to its package.json file and whenever you need it simply go to this extension on your extensions list and hit Enable in workscape. This will enable all the extensions available in this pack. Here's all you need to make it work: https://code.visualstudio.com/blogs/2017/03/07/extension-pack-roundup

Actually this feature is already available. You simply need to create an Extension Pack in your <profile>/.vscode/extensions/ folder, add extensions to its package.json file and whenever you need it simply go to this extension on your extensions list and hit Enable in workscape. This will enable all the extensions available in this pack. Here's all you need to make it work: https://code.visualstudio.com/blogs/2017/03/07/extension-pack-roundup

@SharakPL That's not the feature described here and it doesn't solve the same problem.
I (and many others) want to be able to configure enabled extensions within a configuration file that can be committed to a project's repo - so when I open that project (ie. workspace) on a different machine, or anyone else on my team does that, the correct extensions are enabled automatically.
I do not want to manually enable/disable extensions for each of the projects I work on. I want to clone a project, open its workspace file, and have everything correctly set up.
That's the value of this feature request, and none of the alternative proposals provide that value.

@SharakPL That's not the feature described here and it doesn't solve the same problem.
I (and many others) want to be able to configure enabled extensions within a configuration file that can be committed to a project's repo - so when I open that project (ie. workspace) on a different machine, or anyone else on my team does that, the correct extensions are enabled automatically.
I do not want to manually enable/disable extensions for each of the projects I work on. I want to clone a project, open its workspace file, and have everything correctly set up.
That's the value of this feature request, and none of the alternative proposals provide that value.

I might as well add my use case as well...
I'm a polyglot. I have many customizations for many different languages. I anticipated that when I selected Disable (Workspace) that something in .vscode, perhaps settings.json, that I'd be able to create a new workspace and just copy the disabled extensions list. I found instead that this setting seems to be stored in state.vscdb. The format of this value seems like it could be used right now if it could be overridden by a key in settings.json. Alas I found this thread instead.
Maintaining a global accept/reject list, which defines the default enabled/disabled extensions, with a per workspace accept/reject list to override would be ideal. This way you could manage a set of global extensions and they could also be manageable for group projects. It might even be advantageous to provide a way to replicate group workspace settings and still keep .vscode in the .gitignore.
I appreciate the comments some have made about trying to create group workspace settings, but for me, I don't want to sift through ~90 extensions to decide if I need it for Deno, PowerShell, Clojure, C#, etc. As a platform to support all of these different languages, there needs to be a better way of scoping extensions in a more organized fashion... some workspaces might need combinations, so it isn't just as simple as choosing a language set of defaults. Making these settings more portable than a SQLite 3 database would be a solid start.

I might as well add my use case as well...
I'm a polyglot. I have many customizations for many different languages. I anticipated that when I selected Disable (Workspace) that something in .vscode, perhaps settings.json, that I'd be able to create a new workspace and just copy the disabled extensions list. I found instead that this setting seems to be stored in state.vscdb. The format of this value seems like it could be used right now if it could be overridden by a key in settings.json. Alas I found this thread instead.
Maintaining a global accept/reject list, which defines the default enabled/disabled extensions, with a per workspace accept/reject list to override would be ideal. This way you could manage a set of global extensions and they could also be manageable for group projects. It might even be advantageous to provide a way to replicate group workspace settings and still keep .vscode in the .gitignore.
I appreciate the comments some have made about trying to create group workspace settings, but for me, I don't want to sift through ~90 extensions to decide if I need it for Deno, PowerShell, Clojure, C#, etc. As a platform to support all of these different languages, there needs to be a better way of scoping extensions in a more organized fashion... some workspaces might need combinations, so it isn't just as simple as choosing a language set of defaults. Making these settings more portable than a SQLite 3 database would be a solid start.

Sorry if I am not responding to all contributions here, but may I be so frisk and drop a simple view? IMO we should focus on usable workflows based on Everything As Code.
Please bear with me and follow this pseudo logic and respond on that:
IF a Workspace settings.json is found, and since it is the ONLY mechanism available in the repo to tell vscode anything
ASSUME it is there to control ALL extensions for that project
SO ALL (global) extensions will be disabled unless specifically enabled in that file
That way we can be sure of how vscode behaves in that project.

@Morriz Well a workspace can also include several different projects.
Assume you have a workspace with one project having a web-backend and another project with the corresponding frontend.
Both projects will surely benefit from having different extensions activated, deactivated and/or recommended.
This is a typical use-case for our team.
Extensions fighting over formatting is usually battled with the Formatting toggle extension, formatting settings and lastly .eslintrc.js,  .prettierrc and  .stylintrc. Useful for team-wide formatting settings anyway, of course, but it's still a pain sometimes to share and update that knowledge with the team instead of providing a per-project default set of extensions as well.
It will also be annoying to deactivate all extensions not mentioned in the configuration file. Many extensions are only productivity extensions which are personal preference (let's say Bookmarks, status bar time or any of the status bar extensions).
I think allowing people to have a personality should not be discouraged. Would even motivate me to leave.

I see your point. I think the system would need tags or categories to discern there can only be one active at a time, and when .vscode/setttings.json activates one, any other globals ones offering the same should be deactivated.

I do not want to manually enable/disable extensions for each of the projects I work on. I want to clone a project, open its workspace file, and have everything correctly set up.

You can commit extension pack. I bet you can even make a script that would install it automatically or you can simply describe what needs to be done in the readme. This way you have only 1 extension to enable/disable in workspace. That's the way Microsoft suggests for sharing extension configuration in a project.

It will also be annoying to deactivate all extensions not mentioned in the configuration file. Many extensions are only productivity extensions which are personal preference (let's say Bookmarks, status bar time or any of the status bar extensions).

@Peter-Krebs thinking about this, I think it would be great to at least have the ability to disable a plugin (so that we can disable undesired plugins, such as other formatters than the one chosen in the repo). We could assume the usual suspects and just turn them off. This would not cover all of them of course, but at least we have some control.
Don't vscode plugins have a mechanism to avoid clashing on the same territory? It would be great if conflicts were detected by the low level plugin framework (again, probably based on tags & categories), so that the user gets a question popped up.

That's the way Microsoft suggests for sharing extension configuration in a project.

Are you sure? What is .vscode/settings.json for then?

That's perfectly clear in extension pack description:
- Want to bundle your Python extensions, so you can easily disable and enable when you are working on a Python project? Use an Extension Pack.

I also should add my specific use case.
I'm a database engineer, working with many databases which all have their own specific dialects of SQL (and their own extensions which deal with these dialects).   All of these extensions provide support for .sql files (and typically some other file extensions that often clash).
So I want to be able to flag a workspace (essentially all the build scripts for a database) to use the extension appropriate for SQL Server, Db2 for z/OS, Db2 for LUW, Oracle or whatever database.  It is so annoying to have to enable / disable extensions every time I switch workspaces to work with a new database (which I do multiple times per day).

@Peter-Krebs thinking about this, I think it would be great to at least have the ability to disable a plugin (so that we can disable undesired plugins, such as other formatters than the one chosen in the repo). We could assume the usual suspects and just turn them off. This would not cover all of them of course, but at least we have some control.

Yeah, this of course needs to be carefully done, though.
If this means only the popular plugins are covered and configuration conflicts arise again with lesser-known extensions, this is only brushing the problem under the rug.
It's probably not that wild of an expectation for a team to configure their VS Code projects with a proper list of extensions to activate and deactivate, recommended configuration etc..
It's just not a core part of VS Code currently and a team-based approach to managing everything is increasingly clear to be a hard rule in any industry. VS Code needs to grow into those shoes.

Don't vscode plugins have a mechanism to avoid clashing on the same territory? It would be great if conflicts were detected by the low level plugin framework (again, probably based on tags & categories), so that the user gets a question popped up.

I believe which extensions are active at any time is depending on what is currently opened in the editor.
My understanding is that this even changes while tabbing through the different files when you have multiple files opened.
It is very unlikely a PHP extension flips out while you have a python script open, for example.
Some things extensions do are not that clear-cut, however.
I have a workspace with a Laravel-based PHP backend and a Vue (Quasar) frontend project in it.
Formatting your code with, for example, prettier has a slightly different result than formatting using eslint.
I cannot deactivate prettier entirely because the PHP code for our backend is formatted using that.
eslint is used for code in the frontend. Several configuration files later that is less of a problem (.eslintrc.js, .prettierrc and .stylintrc). Otherwise whoever formatted the code latest wins.
I understand creating separate workspaces for those two projects is a sensible workaround, but this only avoids the problem VS Code is not solving.
Having a consistent code formatting across the team is not that uncommon of a goal.

@scotdb Well there is a solution to deactivate extensions for a workspace. In the extensions click the ⚙ icon and then select Disable (Workspace):

Apparently you can not activate/deactivate an extension based on the project within the current workspace you're currently looking at. But at the broad workspace level you can deactivate extensions. At least as an individual developer.
A team-based approach for that with each project in mind, not just the workspace as a whole, would be more ideal but at least there is that.

@scotdb Well there is a solution to deactivate extensions for a workspace. In the extensions click the  icon and then select Disable (Workspace):

Apparently you can not activate/deactivate an extension based on the project within the current workspace you're currently looking at. But at the broad workspace level you can deactivate extensions. At least as an individual developer.
A team-based approach for that with each project in mind, not just the workspace as a whole, would be more ideal but at least there is that.

Yes, I'm aware of the ability to disable a workspace in that way.
But it doesn't really meet the use case, which is to set things up so that whoever checks the workspace out of source control has the extensions to use (and not use) defined at the workspace level.
That doesn't work when the details are stored in the extension configs rather than within the workspaces themselves.

@Peter-Krebs thinking about this, I think it would be great to at least have the ability to disable a plugin (so that we can disable undesired plugins, such as other formatters than the one chosen in the repo). We could assume the usual suspects and just turn them off. This would not cover all of them of course, but at least we have some control.

Yeah, this of course needs to be carefully done, though.
If this means only the popular plugins are covered and configuration conflicts arise again with lesser-known extensions, this is only brushing the problem under the rug.
It's probably not that wild of an expectation for a team to configure their VS Code projects with a proper list of extensions to activate and deactivate, recommended configuration etc..
It's just not a core part of VS Code currently and a team-based approach to managing everything is increasingly clear to be a hard rule in any industry. VS Code needs to grow into those shoes.

Don't vscode plugins have a mechanism to avoid clashing on the same territory? It would be great if conflicts were detected by the low level plugin framework (again, probably based on tags & categories), so that the user gets a question popped up.

I believe which extensions are active at any time is depending on what is currently opened in the editor.
My understanding is that this even changes while tabbing through the different files when you have multiple files opened.
It is very unlikely a PHP extension flips out while you have a python script open, for example.
Some things extensions do are not that clear-cut, however.
I have a workspace with a Laravel-based PHP backend and a Vue (Quasar) frontend project in it.
Formatting your code with, for example, prettier has a slightly different result than formatting using eslint.
I cannot deactivate prettier entirely because the PHP code for our backend is formatted using that.
eslint is used for code in the frontend. Several configuration files later that is less of a problem (.eslintrc.js, .prettierrc and .stylintrc). Otherwise whoever formatted the code latest wins.
I understand creating separate workspaces for those two projects is a sensible workaround, but this only avoids the problem VS Code is not solving.
Having a consistent code formatting across the team is not that uncommon of a goal.

That's the problem with Prettier, not with VSCode. Also a reason I stopped using Prettier because it ignored completely my eslint, stylelint or phpcs configuration and forced its own rules, often messing my code completely. A tool for everything can't do a good job at all.

Thanks for the suggestion! I think this is offtopic now regarding the formatting.
Regardless, an integrated team-based approach to managing extensions (enabled, disabled, recommended) would be greatly appreaciated.
Extension packs are a good start, but they currently do not support disabling other extensions (compatibility reasons or otherwise) or adding recommended extensions via the pack.
Having many different projects over the years you would need lots of extension packs, leaving you with managing those over time.
As suggested by @ramya-rao-a using the extensions.json could work better for this, as this is more of a project-by-project thing.

A tool for everything can't do a good job at all.

So you're saying VS Code doesn't do a good job? 😰

A tool for everything can't do a good job at all.

So you're saying VS Code doesn't do a good job? 😰

VSCode is just a wrapper for extensions and it does its job perfectly. Stylelint or eslint also work great as extensions because they focus on specific feature. Stylelint may even format inline style="..." in html, but never mess with html itself. Prettier tries to do everything at once and it's not very good at it in my opinion. I believe english version of that saying is "jack of all trades is a master of none"

I'd like this to be extended by a version-setting per extension.
I currently have the problem that a debugger-extension I use only works for certain versions of the tool to debug.
Thus the extension gets updates when the target is updated. As I need to fix things for 2 versions of the target I need two versions of the extension.
At the moment I need to reinstall the extension quite often in one of my workspaces and reload it...

Hi,
it would be very nice to be able to enable or disable extensions from the settings.json config file.
More importantly, in a multi-root workspace, it would be nice to enable or disable extensions on per-root basis.
This would be very useful in complex setups as mines (I have many folders, with projects hosted on different services -- Gitlab, Github, etc. -- written with different programming languages, but all these pieces together create a single huge project, in a multi-root workspace).
Regards.

How would you know which extension to disable? What if a collaborator using your config file has some other extensions you don't know about that cause problems with your set? I can't see a way to implement disabling properly. The only way would be to start with something like extensions.disableAll: true and then enable what you need, but it's basically a prison cage for developer 😅
For everything else Remote - Containers extension looks like best approach (Docker required). It allows customizing VSCode settings and extensions per workspace the way you want - with a config file. You could even disable extensions if they had a dedicated property for this eg. prettier.enable: false

Hi ,
IMHO assuming that the configs are committed and shared in the team is not a fine assumption at all! Very often many developers prefer to use slightly different setups, with different extensions, etc. For example, many extensions provide clipboards, many extensions provide C++ completion, etc.. There is no reason to force all the team to use the same setup: what is important is to force code standards, not development environment standards.
Moreover very often, in shared contexts, disabling some extensions is fine for all the team: my actual needs are in this case.
Think for example to an extension dealing with something (XML? YAML? C++? TS? what you prefer?) which is not used in a repo. It is fine to disable it for all the team.
Finally, an editor or IDE should be generic and allow users to do what users prefer, not what IDE developers think it is right.
Regards.

@michaeljota Just want to understand what is the use case to have this in a file?

Having it in a settings file instead of having it in a database makes it portable.

Think working from home on a Windows machine, working in a flex office on a public PC, going to the basement working on my Linux machine, laptop, ... the possibilities are endless. I use Visual Studio Code in all those environments. Right now there is no way I can sync my workspace disabled/enabled extensions. I can sync the installed extensions.
Working on different workspace environments, think

Latex
Markdown
Sphynx
Programming C# / Pyton / Whatever

If I enable all my extensions at once my context menu is overflowed by items, performance gets a massive hit.
I know plugin developers could make there plugins only load in certain circumstances. But experience tells me most developers ignore them ...
Just look at what my context menu looks like, really makes it quite useless ...

The solution was already given in the first few comments, lets not make this issue about everything, but keep it simple. If everybody is so afraid of breaking VSC by implementing, at the very least make an API call available that can enable or disable an extension. Leave implementation to the community.

We can re-use the existing extensions.json file for this.
Currently the json file looks like this:
{
	// See https://go.microsoft.com/fwlink/?LinkId=827846
	// for the documentation about the extensions.json format
	"recommendations": [
		"eg2.tslint",
		"dbaeumer.vscode-eslint",
		"msjsdiag.debugger-for-chrome"
	]
}

We could have new entries in this json file like
{
	"disabled": [
		"eg2.tslint",
		"dbaeumer.vscode-eslint",
		"msjsdiag.debugger-for-chrome"
	]
}

All installed extensions would be enabled by default. If there is an entry like the above, then they would be disabled.
When user clicks on the Enable (Workspace) or Disable (Workspace) this file gets edited.
Currently we store the list of disabled extensions for each workspace in local storage.
All we need is to move the list to this file.
@sandy081 Thoughts?

How would you know which extension to disable? What if a collaborator using your config file has some other extensions you don't know about that cause problems with your set? I can't see a way to implement disabling properly. The only way would be to start with something like extensions.disableAll: true and then enable what you need, but it's basically a prison cage for developer
For everything else Remote - Containers extension looks like best approach (Docker required). It allows customizing VSCode settings and extensions per workspace the way you want - with a config file. You could even disable extensions if they had a dedicated property for this eg. prettier.enable: false

I generally feel that it wouldn't be a prison cage for developers if some extensions were forced by the project.
For example, theming and other non-project related extensions are meant to be user-specific, because not all users prefer the same theme (and some users might need accessibility-related extensions etc.). These should not be managed by a specific project/workspace.
On the other hand, linters and static analysis tools are very project-specific and it is my opinion that they should definitely be disabled by default at the IDE level, and only enabled per-workspace, because the workspace knows which linter it wants to use (and the whole team working on a single project should be forced to use the same linter for the sake of consistency, as consistency is basically the primary purpose of linters).
In fact I already do this with some extensions that provide a configuration flag to enable/disable them - for example I have stylelint.enable: false in my global VS Code settings, and then I have stylelint.enable: true in the settings section of some of my projects' *.code-workspace files. Unfortunately, some extensions don't provide such a setting, and there are some that used to, but now warn of this setting being deprecated, and pointing me to enable/disable them via the extensions viewlet - e.g. eslint.enable shows such a warning, which is in my opinion a step backwards from having a consistent development experience within a team.
It doesn't make sense for ESLint to be a per-user configuration setting - my team's CI environment performs linting via ESLint, and the whole team needs to use this extension to avoid wasting time responding to CI errors - it's not a matter of individual preference. If you think this puts developers into a prison cage, by that same logic we shouldn't have any linters or forced style at all - but it seems to me that the general consensus is that we do actually want to force a consistent style (hence the variety of tools aimed at this purpose).
This would be achieved by simply providing a configuration-based API (just like the stylelint.enable configuration setting) by VS Code itself, where you could just refer to an extension by its ID and force it to be enabled for a workspace.

In fact I already do this with some extensions that provide a configuration flag to enable/disable them - for example I have stylelint.enable: false in my global VS Code settings, and then I have stylelint.enable: true in the settings section of some of my projects' *.code-workspace files. Unfortunately, some extensions don't provide such a setting, and there are some that used to, but now warn of this setting being deprecated, and pointing me to enable/disable them via the extensions viewlet - e.g. eslint.enable shows such a warning, which is in my opinion a step backwards from having a consistent development experience within a team.

Same here. I second that. This latest development is going the wrong direction, as it should be made easier to toggle extensions from code repos. What happened to everything as code paradigm?

We can re-use the existing extensions.json file for this.
Currently the json file looks like this:
We could have new entries in this json file like
{
	"disabled": [
		"eg2.tslint",
		"dbaeumer.vscode-eslint",
		"msjsdiag.debugger-for-chrome"
	]
}

All installed extensions would be enabled by default. If there is an entry like the above, then they would be disabled.
@sandy081 Thoughts?

Thanks but I got this error: "Property disabled is not allowed."

@tabebqena  are you kidding? this feature is still open for discussion, it is not been implemented yet.

Any update from the team on this one?
IMHO, a configuration file to enable/disable extension is kind of mandatory for software like VSCode, given how much people rely on extensions and how much an extension can influence the performances of it...
I'm using VSCode for C++, Python, Haxe, Nim, Javascript..., so I do rely on many extensions that I rarely need all the time on all projects. At one point I even thought about compiling VSCode from source for "every" language I use, but the maintenance was way too much.

Also, when a .code-workspace file is renamed, these settings are lost as they do not reside within the project itself.

@gjsjohnmurray good tip

Though from a quick look, it also seems that the settings during a "Save Workspace As..." are not transferred, just copied. So if you create a new workspace with the same name after the operation, it gets the same settings.

We can easily disable an extension for "this workspace only" option, but if we have a multiple extensions, team collaboration, different workstation.. we can't go to extensions list and click on every one. We should have also a way to do this using .json file.

key is to drive it with code, not ask individuals to manually configure extensions...who (dis)agrees with this? (disagreements could use some extra explanation imo)
emojis please!

Hi,
I believe that there are two different aspects (or maybe I have not understand).
On one hand, there are all the automatic/"auto-magical" smart thing that could be implemented, which is fine.
On the other hand, there should be the option to always allow users to override the "default smart behavior".
This second option is what we truly need right now. Improvements in default behaviors are welcome, but they are not critical, as long as users can always override them (which lead us back to the critical part making it even more critical IMHO :-) ).
As exemplified in a previous comment, my setups are quite complex and no strategy can guess exactly what I truly need. Therefore I need a way to fine-tweak the extensions configurations.
Regards.

@Morriz Yes, but how? you mean using settings.json ?

@FStefanni I agree, the second option is what we need right now 👍

@Morriz Yes, but how? you mean using settings.json ?

yes, as that is what exists now and should stay alive imo...until something better "as code" is delivered

I wrote a plugin that allows you to quickly apply the necessary extensions to the project on pre-prepared profiles.
The essence is very simple, you create a profile, select extensions and apply the profile.
Even after restarting VSCode, extensions remain assigned to projects.

The extension is already available on the marketplace
Who is interested here is the repository
PS: This is my first extension 🚀, if someone likes it, thank me with a star in the repository or rate me on the marketplace 😊

@evald24 The past few days, I have just happened to also be working on an extension to solve (or workaround) this issue :smile:
It sounds like your extension automatically enabled/disables extensions within workspaces.  I would be interested in understanding a but more about the details of this solution.
My extension (baincd.extension-profiles) takes a different approach, working within the limitations of the VS Code API.
In a nutshell, you configure lists of extensions as profiles, disable those extensions globally, then when you activate a profile those extensions are automatically displayed in the extension sidebar where you can quickly enable them.  Other features include checks at startup that the appropriate extensions are enabled, and the ability to define extensions that should be disabled for a profile.
There are more details on the extension page.  I encourage everyone to take a look, and am interested in hearing all feedback.
Thanks!

I want to say it is trouble to use an extension to manage other extensions. Here has the self conflict for such extension: how to deal with self?
I tried one extension which makes my user settings mess, so I give up.
So before the vscode provide native feature, the only way is manually disable extensions for each workspace.
My strategy is disable all extensions firstly, then enable common extensions for any tech stack. at last, enable special extensions per workspace for different tech stack project.
I know this is a workaround, but the workspaces are quite stable for long times. So basically I only need to do that manual seeting once time for a new workspace.
BTW, I installed about 120 extensions in my local for different tech. stack, I also really hope vscode can provide such per workspace configuration to define enabled extensions in the .vscode fold.

I want to say it is trouble to use an extension to manage other extensions. Here has the self conflict for such extension: how to deal with self?
I tried one extension which makes my user settings mess, so I give up.
So before the vscode provide native feature, the only way is manually disable extensions for each workspace.
My strategy is to disable all extensions firstly, then enable common extensions for any tech stack. at last, enable special extensions per workspace for different tech stack project.
I know this is a workaround, but the workspaces are quite stable for long times. So basically I only need to do that manual seeting once time for a new workspace.
BTW, I installed about 120 extensions in my local for different tech. stack, I also really hope vscode can provide such per workspace configuration to define enabled extensions in the .vscode fold.

My plugin works the same way. The path ~/Library/Application Support/Code/User/workspaceStorage/ contains folders with workspaces, which contain state.vscdb files. The extensionsIdentifiers/disabled field stores information about the disabled extensions in this workspace, and the extensionsIdentifiers/enabled contains the enabled extensions for the workspace. My plugin adds selected extensions to enabled, not selected ones to disabled. By disabling the extension as standard for the workspace, the data changes only there, so this is a small automation. You do not have to choose the necessary extensions every time, but only create a profile and apply it wherever you need to in a couple of clicks.

@evald24 The past few days, I have just happened to also be working on an extension to solve (or workaround) this issue 😄
It sounds like your extension automatically enabled/disables extensions within workspaces. I would be interested in understanding a but more about the details of this solution.
My extension (baincd.extension-profiles) takes a different approach, working within the limitations of the VS Code API.
In a nutshell, you configure lists of extensions as profiles, disable those extensions globally, then when you activate a profile those extensions are automatically displayed in the extension sidebar where you can quickly enable them. Other features include checks at startup that the appropriate extensions are enabled, and the ability to define extensions that should be disabled for a profile.
There are more details on the extension page. I encourage everyone to take a look, and am interested in hearing all feedback.
Thanks!

Try my solution, if it suits you, you can use it. If anything is missing, please submit your ideas or check my implementation in the  repository or can help with some questions 😊

@leolcao,

I want to say it is trouble to use an extension to manage other extensions. Here has the self conflict for such extension: how to deal with self?

I agree.  And it is a unique challenge to document how an extension that manages other extensions works in a non-confusing way :laughing:

My strategy is to disable all extensions firstly, then enable common extensions for any tech stack. at last, enable special extensions per workspace for different tech stack project.
I know this is a workaround, but the workspaces are quite stable for long times. So basically I only need to do that manual seeting once time for a new workspace.

I have a similar strategy, with the exception that I keep some extensions enabled globally so the number of extensions that have to be enabled per-workspace is smaller.  My baincd.extension-profiles extension just helps make this strategy a bit easier, by showing only the extensions I want to enable for a workspace directly in the extension sidebar, and checking after startup if there are extensions that should be enabled/disabled in the workspace.

It is not uncommon for me to be creating new workspaces for one reason or another, so I wanted to be able to quickly and easily enable the list of extensions I want for different types of projects.
@evald24,

My plugin works the same way. The path ~/Library/Application Support/Code/User/workspaceStorage/ contains folders with workspaces, which contain state.vscdb files. The extensionsIdentifiers/disabled field stores information about the disabled extensions in this workspace, and the extensionsIdentifiers/enabled contains the enabled extensions for the workspace. My plugin adds selected extensions to enabled, not selected ones to disabled. By disabling the extension as standard for the workspace, the data changes only there, so this is a small automation. You do not have to choose the necessary extensions every time, but only create a profile and apply it wherever you need to in a couple of clicks.

So you are basically editing the VS Code user data directly to enable/disable extensions in workspaces?  I have to admit, that is a pretty clever solution.  Although I do have my reservations about that solution (potentially breaking something within the VS Code data, or VS Code making a change to it's internals breaking the extension), I do have to applaud you for your ingenuity!

Hi,
all your extensions and efforts are great, and can help us in many ways.
Nevertheless, I still feel the need of the fix of this issue, since the objectives are similar (managing extensions), but
the ways of doing so are different and lead to different results.
Regards.

Actually I just wonder why these extension enable/disable settings were not in settings.json when the first time it was introduced.  It would have saved lots of efforts :-)

Only progress about this issue is more comments 🤣 🤣 🤣

I only see regression in this setup, as we now are asked to choose which formatter to use when a global config (User) one conflicts with a repo config (Workspace). Wtf would vscode not choose the Workspace settings over the global settings?!

So I want to comment on a something I read above that was authored in 2018
Someone commented that somewhere across the vast abstract desert that we call the internet, that the read, V.S. Code extensions don't run unless you need them. Of course, they never stated where that article "that they read" came from.
VS Code extensions rely on the developer to write when they are, and when they are not activated. Most of the VS Code extension APIs help with this, but the API is far from perfect, and from what I have seen, most extension developers don't even think about making sure that their extension doesn't use resources when the user who has installed it is working in an environment that doesn't make use of the extension that they wrote. In other words, when users download several extensions, and they don't disable the extensions that they don't need in an environment that doesn't make use of some of the extensions that they installed, those developers are putting their trust into the developers of the extensions, that those developers designed, and wrote their extensions with integrity. And whereas you might have a high level of trust for 3rd Party Software, I personly do not, This is exactly why I find it crucial that some sort of black, and or white list, is offered to us for enabling & disabling extensions.
Personally, I think a totally separate configuration file would be best, and have it be able to white & black list extensions.
    //  ".../.vscode/extensions.json"
    {
        "extensions": {
            "enabled": ["foo.bar", "bar.foo"],
            "disabled": ["rab.oof", "oof.rab"]
        }
    }

I just read @sandy081 's comment about it already being available, and I actually came here shortly after asking for this on stack overflow, where I give a reason as to when individually disabling them is a nuisance.
How can V.S. Code extensions be configured, so that they are either enabled, or disabled. depending on the workspace that is open?
Also, wouldn't this be an easy thing to implement. I mean if you can do it individually via the V.S. Code GUI, shouldn't it be easy to implement a configuration file. I guess what I am wondering is; "When you disable an extension for a workspace, where is that information stored? Shouldn't we already be able to access where ever that information is, in which a decent 3rd party extension can be made if the V.S. Code team has a reason for not implementing the feature???"

I'm sorry but it's unbelievable that since 2017 this hasn't been implemented properly yet.
Here's the problem. VSCode it's getting slow for so many people, and why that? Because of extensions. I guess a lot of people work with at minimum 2 languages(back and front). Imagine with 3, 4 and so on.
And what we want?
A simple and quickly way to activate the extensions that we want to that folder that we opened. Could be made with a feature like " select extensions profile" or even improving with the existent "workspace" with example quoted above (also in related issues), allowing us the freedom to choose and get better perfomance programming.
This wouldn't change anything with team shared config, the recommended key could continue. If a team don't want that they just don't set anything.
It's a simple logic to enable or disable extensions that I've config on startup (VSCode) on that folder.

A simple and quickly way to activate the extensions that we want to that folder that we opened. Could be made with a feature like " select extensions profile" or even improving with the existent "workspace" with example quoted above (also in related issues), allowing us the freedom to choose and get better perfomance programming.

I code in Java and Vue js at work and Angular, Nestjs, Vue and Java at home. Being able to have a 'Java' extension profile that I can choose when I start a new project would be great

I'm also interested in this feature!

I note that .devcontainer/devcontainer.json has an "extensions" section,
when specifying a Docker dev container.  This is a good example of
something that works to define the extensions which the project requires.
Native use that is not Docker-specific however lacks this feature.
I guess the issue is the overlap between extensions which are "chrome" and
extensions which are language and project-specific.  When better thought
and design is put into distinguishing the real categories of extensions, it
will later emerge what are extensions that are project specific, and which
are user customisation.
On Tue, Aug 31, 2021 at 10:44 PM Matthias König @.***>
wrote:

I'm also interested in this feature!
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/microsoft/vscode/issues/40239#issuecomment-909202107,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAHEDRGAW7TXL5YQSFYENCLT7TFCFANCNFSM4EILTE2Q
.

Hello everyone,
I do want to make it clear that at this moment in VS-CODE there is no native concept of projects.
What is meant in this threat by project I think is the concept of workspaces that is currently in VSC.
It is only making this issue extra complicated if we keep confusing everybody with the concept "project" which does not exist in VSC natively right now.
Workspaces do exists, that is where the focus needs to be. A workspace can contain many folders, from anywhere on the filesystem. So the worspace-settings file would be the best candidate to put the extension specific on/off switches into.
PS: this is no personal attack, I appreciate everyone's opinion and effort. If this view sounds a bit harsh: I apologize in advance.

I also add myself to the request , also I want the possibility to activate or deactivate a certain group of extension (that you can configure at will) , through these modes:
-For a certain workspace

for a certain file extension (like .js ; .kt ; .java ; .py; etc...)
through a command.
-By key shortcut

imagine having 20+ extensions (total) and maybe for a project in .kt you need 3 and you have to deactivate the other 17+ and for another project in .py you need 4 and then you have to deactivate the ones you have activated for the project in .kt and activate only the ones for the project .py, after a while you go crazy.... (it becomes very long to deactivate/activate every single extension for every single project, much better if there is something automatic )
it is surprising (in a sad way) how for 4 years you refused to implement this very requested and very useful feature. what were you thinking?
Translated with www.DeepL.com/Translator (free version)

I'm bringing here pieces of a comment I added on my Project Manager extension, because I think it could be my 2c 😃
We may have a bunch of extensions installed, but only a few being active when you open a certain project. It's up to the extension to choose the conditions to activate (https://code.visualstudio.com/api/references/activation-events), and VS Code uses that.
Of course, some extensions chooses to be active for any project you open (like Project Manager does), but others only activates if you open a certain file type (.java, .cs), or a project that contains a certain file (.eslintrc.json), etc. Extensions should care about the activationEvents and only activates when necessary. If we see some extension that is active but shouldn't, maybe you could ask the author to revisit its activationEvents. Sometimes is intentional, sometimes an issue.
I'm not saying I don't want this feature, because actually, I do 😃, but it's not just VS Code itself that needs attention.
I used a few IDEs/Editors, and don't remember a single one that does that. Every IDE/Editor seems to activate all plugins/extensions for every session, with no customization at all. In fact, I wonder how much memory you need available to open 5 to 10 instances of IDEs like VS, Eclipse, Delphi, JetBrains. Maybe you can do that with Sublime, Notepad++, Atom, but these Editors suffers the same limitation.
Based on what I have seen about this feature, I guess it should be available only when VS Code also support installing/enabling/disabling extension without reloading the current window. Probably an architecture revisit (extension related) will be necessary.
Why not allow the user to override the activationEvents, just like it does with extensionKind? Doing so, the user could restrict (or expand) when an extension should be activated.
Just another 2c 😬

Still seems like a step away from everything as code mentality.
A projects .vscode/settings.json should be able to tell vscode which plugins to deactivate. Having multiple plugins like linters/formatters conflicting with one another is a problem most of us want to solve here.

It's impossible for settings.json to know which extensions to deactivate because each user can have a completely different set. Everyone would have to setup this individually anyway so what's the point? I feel like some of you expect magic here 😅
You have extension packs which are pretty easy to setup and then enable/disable whole set of extensions with one click. What's wrong with this approach?
You have devcontainer.json where you can directly specify an array of extensions to be enabled automatically in each workspace. What else do you want?

Confusing
The OP is talking about the locally enabling and disabling certain extension per workspace settings. Please stop confusing everybody in this threat ...
Magic?
There is no magic that needs to be implemented, only a way to enable/disable extensions on a file based input.
Currently
we need to manually enable/disable(per workspace) by right-clicking each of the extensions one by one.

We need to do it every time we change work environment, or create new workspaces.
To sum it up
A file based way of enabling, disabling extensions based on what workspace we are currently working. Implemented exactly the same way it is implemented now. No magic, No hocus pocus.
Manually enable / disable ALREADY SUPPORTED
from: https://code.visualstudio.com/docs/editor/workspaces

Thanks
Thanks for taking the time to read. :tada:

To make it clear, devcontainer.json is for containers, where you can decide exactly which exts to install or not.
What we are talking about is to disable/enable exts per workspace, locally.
I do agree that it is better not to disable sth in settings.json, iff you are submitting it to the repo. But the thing is, you should have .vscode/ ignored, whether by a gloal ignore file, or by .git/info/exclude, or by a star in .vscode/.gitignore. The settings.json file should be local so that everyone in the team can do it in their own way, and so that they can use some other editors than vscode.
It is like, you don't want .DS_Store submitted because many people don't use macos, so you don't want .vscode submitted because many people don't use vscode, or at least don't in your way.
And, since .vscode is local, it is no harm to allow it to disable some exts in trusted workspace.

To make it clear, devcontainer.json is for containers, where you can decide exactly which exts to install or not. What we are talking about is to disable/enable exts per workspace, locally.

not really clarifying much in this context

I do agree that it is better not to disable sth in settings.json, iff you are submitting it to the repo.

That is exactly opposite of what is needed and discussed here: we want to disable stuff going into the repo, so devs all adhere to using the same tooling.

It is like, you don't want .DS_Store submitted because many people don't use macos, so you don't want .vscode submitted because many people don't use vscode, or at least don't in your way.

Again, I think it is the opposite: we know extensions exist that might interfere with the ones we want to enable, so we can list the usual suspects and disable those, knowing devs that have a preference for them will not be allowed to use them.

we know extensions exist that might interfere with the ones we want to enable, so we can list the usual suspects and disable those

However it can be unrealistic to have an exhaustive list of  unwanted extensions. It is easier to have a white list but a blacklist is impossible. What if I am write my own extensions and one of those happens to be interfering? That is what I think @SharakPL is talking about.
And if you submit .vscode/, you are preventing others to have their own local preferences, since all changes to it will be tracked by git.
Again, what if I have a very uncommon extension to disable, which is a totally waste of bits for everyone else ?
And there are people who don't vscode. I you want something for the whole team to agree on, it might be sth like a editorconfig, but certainly not .vscode.

And it will be totally safe to let settings.json or .vscode/ to take full control of everything in trusted workspaces,  if we keep it local and personal. Or it would be just too complicated, even if you use a white list.
Like, What if I use some vim mode extensions that not everyone use?  But what if this very extension is somehow interfering? You don't want your blacklist filled with extensions you never heard of either.
So the only way: don't commit it and keep it personal, your team only need to agree on what they commit, not how they work it out.

So this is just a matter of taste: for me it is "Devs are free to do it on their own, as long as they pass the lints and tests", and for you "everyone in my team need to have the same experience".
Maybe every single person on Earth loves vscode, but I still think it is too much to "strongly advise" it. I am just trying to keep it "platform independent" and "clean", you know.
Or it is like, .vscode is not a part of the code, so it is not a part of the repo, like .DS_Store. I am also for "don't put .DS_Store to .gitignore, put it to core.excludesFile or info/exclude", btw.
Anyway we are agree that .vscode/ or settings.json should be able to enable/disable extensions. I just want to say, "feel free to mess up .vscode/ since we can always choose to exclude it from the repo".

So this is just a matter of taste: for me it is "Devs are free to do it on their own, as long as they pass the lints and tests", and for you "everyone in my team need to have the same experience".

Again: they are free to use whatever as long as everything is delivered as code, including automation tooling touching our code

Maybe every single person on Earth loves vscode, but I still think it is too much to "strongly advise" it. I am just trying to keep it "platform independent" and "clean", you know.

Some devs in our shop came with other editors but were like “I always wanted to try it out so now is a good time”. Maybe that answer was made easier after I asked them to otherwise bring the config of their tooling that has idempotent results.

I just want to say, "feel free to mess up .vscode/ since we can always choose to exclude it from the repo".

Opposite position for us, we want to include config for tooling of choice to cover all devs and be able to have consistent code style which makes for easier reviewing.
I actually wonder who in this thread is dealing with style and linting rules from a lead perspective, because I see quite some comments from ppl that seem to be allowed to deliver whatever. Don’t you have the same needs as I describe? Enforcement of code formatting and linting helps any team that wants to be consistent.

@yw662
Not really a matter of taste in the current documented implementation of VS Code settings.
VS Code provides two different scopes for settings:
- User Settings - Settings that apply globally to any instance of VS Code you open.
- Workspace Settings - Settings stored inside your workspace and only apply when the workspace is opened.

What it seems you want is likely: a new, not yet existing VS Code setting scope: Individual settings for workspaces. Sounds neat, particularly when working on a large project where its configured for Windows, and you are trying to run it from a cloud/Linux instance and vice versa and don't want to constantly be manually editing the checked in settings file. Or even tab sizes, as you mention. I would like to see this feature. I was gonna suggest opening new feature request, but looks this is already captured in #40233 (and handful of others).
This thread though, it seems to be about adding/exposing ability to configure an extension state, which would likely apply in any/all VS Code setting scopes (existing and new).

Based on VS Code documentation (https://code.visualstudio.com/docs/getstarted/settings)

VS Code provides two different scopes for settings:

User Settings - Settings that apply globally to any instance of VS Code you open.
Workspace Settings - Settings stored inside your workspace and only apply when the workspace is opened.

Workspace settings override user settings. Workspace settings are specific to a project and can be shared across developers on a project.

Based on that, you just have to use/add the .vscode folder to your repo, IF you intend to share the configs.
The original request is exactly this. A file based approach to enable/disable extensions, just like the Recommendations works. And in fact you already can do that, but unfortunately VS Code just stores this info on its internals, not on a file.
IMHO, I think this is too granular. I don't want to enable/disable extensions for each repo I use. I would like to have a kind of project approach instead, but that's another issue 😁
Just my 2c about the linting/formatting subject. Unless VS Code is the only tool your team uses, it makes no sense to use VS Code settings to ignore/remove/force things. It would be independent, so you could do the same quality checks on CI environments. Using Git repos, maybe git hooks can help. But of course, you could have an extension to manage that as well.
Personally, I think the User Profiles, which is on the way, may solve most of the scenarios, if they handle Extensions too. At least, I hope that 😬

on another note, if anybody here would like to see VSCode implement a per-project env file solution that gets read before plugins load (so the plugins have access to them without having to start VSCode from a preloaded shell), then please upvote its here:
https://github.com/microsoft/vscode/issues/135775#issue-1035164719

Just want to understand what is the use case to have this in a file?

I have a workspace I work on across multiple devices and operating systems. Because I often work this way, vscode is setup to sync my settings. Of course, this also syncs the extensions. Now (as I understand it anyway) without a file in the workspace to say otherwise, I have to disable the same plugins over and over again every time I start working on a different computer.

As said previously, a file might not be ideal. Sometimes a workspace is shared among different users, who will have different extensions they want.

Is there a good way to resolve 1. without having 2.?

Just want to understand what is the use case to have this in a file?

I have a workspace I work on across multiple devices and operating systems. Because I often work this way, vscode is setup to sync my settings. Of course, this also syncs the extensions. Now (as I understand it anyway) without a file in the workspace to say otherwise, I have to disable the same plugins over and over again every time I start working on a different computer.
As said previously, a file might not be ideal. Sometimes a workspace is shared among different users, who will have different extensions they want.

Is there a good way to resolve 1. without having 2.?

Nr 2 does not necessarily go against nr 1. Workspace settings are usually not in the way of User settings, and the shared ones addressed in the file are mostly there to force extensions to work a certain way. (I see no reason to want to go against enforcing linting and formatting.)

I developed an extension to solve this problem, For more information, please see the Disable Extensions.
If it can help you, please give a star to the github repository.

@muzaisimao congratulations! your extension for disabling extensions are third extension for such purposes there :) And there is still no progress for this request from vscode team unfortunately.

@muzaisimao And there is still no progress for this request from vscode team unfortunately.

@sandy081 removed it from the backlog last Friday and it was added to the November Iteration as a stretch goal (Take a look at the "Extensions" section at #136630). Hopefully we will see some more progress in the near future

The thread is so long that I am not even sure my comment is relevant. Anyway.
For me the use case is simple, we have a mono-repo that is becoming fairly large, for this, we are using VSCode workspaces with multiple folders, but we noticed that it didn't solve our performance problems, in fact, I am not sure if vs-code loads the extensions per project or it just loads them per workspace if it is the latest then the extensions are loaded for projects they are not needed into, the problem becomes serious when certain extensions try to work on the entire folder tree, If I need to include the root as a workspace folder the problem is even worse. for this, I want to be able to divide my project into multiple projects and disable extensions per project. I know that it could become challenging for vs-code maintainers, but most of the developers work on multiple projects anyway, having the possibility to isolate every project's configuration becomes crucial.
So maybe vs-code-workspaces is not the solution for this problem, at least in the current implementation. if I had to suggest a solution I would propose an entirely different approach. instead of loading every sub-project in one instance of vs-code why not load multiple instances of vs-code in one workspace, an example of this would be how most of the multi-messaging applications deal with different channels/apps like in Slack:

The result would be something like that:

Or even better IMO, the projects list on the top:

This way every project in the workspace has its own configuration and extensions can now be loaded as per project only.
we also simplify the file tree and now path handling becomes simpler as we are showing them relative to the currently selected project.
For the configuration, things become interesting as I can now have a configuration per project:

{
  "folders": [
    {
      "path": "root",
      "extensions": {
        "recommendations": ["bazelbuild.vscode-bazel"],
      }
    },
    {
      "path": "vscode",
      "extensions": {
        "recommendations": ["eg2.tslint", "dbaeumer.vscode-eslint", "esbenp.prettier-vscode"]
      }
    },
    {
      "path": "vscode-docs",
      "extensions": {
         "recommendations": ["esbenp.prettier-vscode"],
      }
    }
  ],
  "extensions": {
     // merged with project specific recommendations!
     "recommendations": ["redhat.vscode-yaml", "ms-azuretools.vscode-docker"],
     "only-recommended": true, // by default, enable only recommended extensions, developers can override.
  }
}

Voilà, I hope this adds another perspective and helps tackle this problem that so many developers are dealing with nowadays.

Have fun deactivating/activating more than 30 extensions (I have more than 40 for example) every time you change programming language.

Exactly, thus why I proposed created named extension sets that would be enabled/disabled as a group and can be applied to workspaces or languages.

This would be useful for other uses like for this proposal https://github.com/microsoft/vscode/issues/137091

@g13013's suggestion is great. Ideally, I could easily load up a workspace that's personal to me and can be selected per project. If I'm making a flutter app, I want to be able to press one button and have my config for flutter apps load up.  I can custom-define these configs or optimally download prebuilt configurations from the marketplace. That way my status bar and sidebar won't be cluttered with Python, Docker, and Kubernetes when I'm developing an Android app, but I won't have to manually turn those back on for their respective development environments either.