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:

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