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.