Vscode: Feature Request: Enable/disable extensions from config file

[michaeljota]

• 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]

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?

[sandy081]

@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.

[JacksonKearl]

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.

[michaeljota]

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 think this could be useful, as in large team projects, this would allow to have a different but consisten configuration across all the projects inside an organization.

[jankalfus]

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/create unnecessary cognitive load.

[michaeljota]

@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.

[jankalfus]

@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 6 months, just got back to it a few days ago :)

[michaeljota]

@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.

[ramya-rao-a]

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

[sandy081]

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.

[michaeljota]

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

[sandy081]

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

[sandy081]

From @FancyBanana

Currently it seems that information about which extension is enabled/disabled is stored globally.
I propose that workspace enabled/disabled state should be stored in .vscode folder. This way the configuration will survive moving/copying project folder to another location.

[sandy081]

@FancyBanana I think your request is for synchronising workspaces?

[FancyBanana]

@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

[sandy081]

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

[JordyScript]

@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 would make the recommended extensions feature more complete, because it also provides a convenient way to accept these recommendations.

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.

[carlocardella]

@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

[FancyBanana]

@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.

[JordyScript]

@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.

[SaniHaque]

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

[FancyBanana]

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

[WORMSS]

I am having issues where my environment is not acting 'exactly' the same way as my co-workers is.

I would love to have a "disable ALL my extensions and settings" and "install all the extensions and settings my coworker" has (or in this case, the .vscode/settings.json).

even if it's temporary. Because something in my setup just isn't right and I don't know what it is, because I had VSCode a long time before we started this project and obviously has a bunch of extensions and settings that are in conflict but not sure what or where.

[sandy081]

@WORMSS you can disable all installed extensions temporarily. There is a command to do that. Also you can point to different users data directory and extensions directory if you want to run temporarily without existing extensions/settings/state. For that you can use --user-data-directory and --extensions-dir arguments in the command line.

[WORMSS]

I doubt I could do --extensions-dir="\\vpn\external-machine\ignore-their-os-just-give-me-there-vscode-folder\"
But I will give the secondary user directory thing a go, as I have somehow destroyed vs code to the point that everything that was cool about it (the quick fix, the renaming variables, the auto import) have all stopped working and I can't get them to work again.

[sandy081]

yeah, you can only locations on disk as extensions dir

[LuisUrrutia]

Any news on this issue?

[ackvf]

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. Disabling/Enabling all extensions isn't an option as it also enables all extensions that were previously disabled and are still meant to be.

[lonix1]

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:

json "recommendations": [ "ms-vscode.vscode-typescript-tslint-plugin", "dbaeumer.vscode-eslint", "msjsdiag.debugger-for-chrome" ], "enableForSession": [ "foo", "bar", "baz" ]

[muuvmuuv]

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.

[Luckz]

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.

[lonix1]

@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.

[chan-dev]

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

[lonix1]

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

[ghost]

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.

[Pandawan]

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.

[lonix1]

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.

[ghost]

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?

[michaeljota]

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.

[iwnow]

maybe we can create an extension that does it?

[Pandawan]

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.

[kanlukasz]

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_

[TonyGravagno]

:+1: I work with many languages and frameworks. Different workspaces have commonalities and differences. As noted earlier, we can use a work-around with --user-data-directory, but why should we need such things?

The answer to these questions about where to find the Enabled/Disabled flags is in the code. I was just looking through the VSCode source and it's very tough to trace exactly how and where the flags are stored. I'm tired now after looking around for a long time. But the answer is in there. And when we nail it down, some code can be written to dynamically reconfigure the environment based on workspace requirements.

@sandy081 - If we can't move this enhancement up in the backlog, I'm really hoping you can briefly guide us through the interfaces and abstractions in the code, and identify the specific location and data type (extensions) that need to be queried. I'm certainly not qualified enough with TR to do a PR yet, but depending on the details, I or someone else here might be able to work out something else - after all, we're all developers here. Thanks.

[ivnnv]

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).

[lonix1]

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... 😉

[Sti2nd]

An attempt at a summary of the different needs and wants:

Needs and wants for disable/enable extensions from config

Use a (shareable) config file to ...

1. disable extensions in a workspace
2. enable extensions in a workspace
3. suggest extensions to install in a workspace
4. install extensions automatically
5. uninstall extensions automatically
6. enforce same developer environment

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? If it is needed it is probably to be used together with installing a bunch of extensions, like undoing all the recent installations.
• - Already possible with the Profile Switcher extension
• - Uninstalling without asking for approval is bad

Number 6 - Use a shareable config file to enforce same developer environment

Some requests the features disabling/enabling or installing/uninstalling extensions because their goal is to enforce the same developer environment for everyone. Seen as an editorconfig that includes the extensions. Suggested by https://github.com/microsoft/vscode/issues/40239#issuecomment-537682963 and https://github.com/alefragnani/vscode-project-manager/issues/281#issue-452977135

Conclusion

Since this issue is about disabling and enabling extensions from config and since that also seems to be the most wanted feature I will not make conclusions about installing and uninstalling from config. As I see it, it all boils down to one inconsistency and one feature request:

The inconsistency -> put disabled extensions in settings.json

Which extensions are enabled and disabled are settings, and like the rest of the user's 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 disabled extensions = enforcing same environment

People want to be able to share which extensions should be on or off across projects with similar technologies and with their team.

I propose to follow a version of https://github.com/microsoft/vscode/issues/40239#issuecomment-397470014. One adds an "unwantedExtensions" list to the extensions.json. Users will be prompted to:

1. disable the extensions in unwantedExtensions and
2. to enable the extensions that are recommended in extensions.json but currently disabled.

This prompt appears once when opening the workspace. Whether you want to strictly follow the recommendations, just some or none are stored in the workspace settings.json. The next time opening the workspace, VS Code will follow the workspace settings.json and read whether it should use extensions.json to disable extensions, enable extensions or none.

The feature request can probably be continued to be discussed in #18386 and continue to discuss the inconsistency that does not have to do with sharing in this thread? Sorry for the long read @sandy081

Problems

Enabling and disabling extensions sometimes requires reloading, so the user could be prompted for reload the first time. This hopefully won't be a problem the next times, VS Code ideally should check settings.json and extensions.json on load and not load the disable extensions, but this is perhaps the reason why disabled/enabled are saved in localstorage? 😨

[Pandawan]

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)

[muuvmuuv]

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}

[Sti2nd]

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. With this proposal, 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 alternative I see is like 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 for the most part.

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 (necessarily shared, although it is possible). Having them separate underlines that there is a difference. After my proposals extensions.json will continue to hold recommendations meant to be shared, while settings.json will continue to hold your personal settings (for those who want their own). 😊

[Sti2nd]

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 [...]

@muuvmuuv 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.

[muuvmuuv]

@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}

[Sti2nd]

@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 guess there are several settings in your case, just points out a different way to work. I do understand that when I wrote "individual settings.json" in my original comment it is confusing, since workspace settings.json can both be individual and shared, so I rewrote that 😊

Maybe https://github.com/microsoft/vscode/issues/15909 is a feature you are looking for?

[tpaksu]

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?

[austonpramodh]

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

[Sti2nd]

@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

[tpaksu]

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.

[Pandawan]

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).

[tpaksu]

@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.

[Luckz]

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.

[tpaksu]

@Luckz sorry I've missed that detail. It's a bit better than different portable folders. I guess there might be a way to make it being read from the workspace file and load extensions and user data from that folder. Will look.

[basickarl]

Any update on this? Would be awesome for teams to have the exact same vscode setup on every machine.

[tpaksu]

@basickarl you can do this with sync extension.

[TheryFouchter]

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

[fourpastmidnight]

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.

[ghost]

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, even tasks and launch configs. (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.

[fourpastmidnight]

@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.)

[ghost]

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.

[fourpastmidnight]

@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.

[ghost]

@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).

[fourpastmidnight]

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.

[ghost]

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.

[diegosomar]

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?

[fourpastmidnight]

@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:

1. VS Code startup is quick and minimize Extension Host crashes
2. Extensions globally enabled by the user are always enabled (e.g. Themes, productivity extenions such as pomodoro timer, etc.)
3. 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.

[diegosomar]

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.

[JohnGalt1717]

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.

[ldsands]

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.

[KaungZawHtet]

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

[guushamann]

I would be very happy with this option!

[chrisroat]

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.

[junaideqbal]

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

[alsaibie]

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.

[c0nd3v]

Good idea

[jpz]

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.

[webdog]

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

[KaungZawHtet]

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

[alexkreidler]

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

1. 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
2. In this file, add have an enable list
3. 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)
4. If a folder name matches, add the extensions that in the object to a set of activated extensions for that folder
5. Repeat 4 for all valid matches (this would effectuate the cascading logic mentioned above, accumulating extensions)
6. 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.