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

[cathaysia]

recently I add fuzz test for for my rust project. And I install a test explorer adaptor for rust: https://marketplace.visualstudio.com/items?itemName=swellaby.vscode-rust-test-adapter

This extension get the list of tests by run cargo command. such cargo -p xxx -- --list, however the fuzz test doesn't support this parameter, so these fuzz tests just start, this makes my fan spin.

I want to be able to tell my team in a file that I recommend disabling this extension.

[Cyclodex]

@github-yxb , @cathaysia my extension might help you for the time being:

Unwanted Extension

VS Code: Soulcode.vscode-unwanted-extensions
Marketplace link
Github repo link

[cathaysia]

@github-yxb , @cathaysia my extension might help you for the time being:

Unwanted Extension

VS Code: Soulcode.vscode-unwanted-extensions Marketplace link Github repo link

Thanks for your suggestion. But it may sound strange to suggest that the team install an extension to tell them that other extensions are not available.;)

[Cyclodex]

@cathaysia sure, but I am not aware of any other better solution or possibilities. If there is anything, please let me/us know ;)

Let's hope, VS Code team will improve the whole situation at some point.

[cathaysia]

If the vscode team doesn't provide a built-in solution, the best thing to do might be to just ignore it. Other people on the team may or may not run into the problem, but who cares? As long as it doesn't happen to me, it's fine.

[AnrDaemon]

The most important downside of profiles is that you have to separately manage extensions for them, which doubles your maintenance burden at the very least.
Really, all I actually need to do is to have a quick way of enabling certain extensions per workspace. They are installed disabled, just waiting to be turned on. i always see if any of them needs to be updated, I don't have to worry about copying settings back and forth, it's all the same space all the time.

[github-yxb]

If the vscode team doesn't provide a built-in solution, the best thing to do might be to just ignore it. Other people on the team may or may not run into the problem, but who cares? As long as it doesn't happen to me, it's fine.

😏 The latest update logs mention Copilot the most，they might be busy dealing with Cursor.

[JuniYadi]

Any update?

[doraemonxxx]

IT'S ALMOST 7 YEARS GUYS 😶‍🌫️

[feizhaojun]

IT'S ALMOST 7 YEARS GUYS 😶‍🌫️

Ask ドラえもん fixed this.

[susanforme]

Is there any progress?

[silikovaniy]

Any updates on this?

[sdykae]

any update :(

[dkattan]

any update :(

I'm pretty sure I saw this in the latest release notes. I think they did it.

https://code.visualstudio.com/updates/v1_96#_configure-allowed-extensions

[IronGeek]

any update :(

I'm pretty sure I saw this in the latest release notes. I think they did it.

https://code.visualstudio.com/updates/v1_96#_configure-allowed-extensions

AFAIK the Configure Allowed Extensions is only available for User settings, but NOT for Workspace settings, right?

That, and considering the literal text for this feature request is:

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.

No, I don't think they did it. Not even close...

[programming-with-ia]

+1

[knowbits]

Dec 15, 2017

Hoping someone in the core team would gain an interest in this issue .. and deliver a first minimal simple solution..
This feature seems to be wanted by quite a few devs.

The MVP:

1. A new section in an existing config file that specifies all MANDATORY EXTENSIONS to load for a given project.
   Install / enable these extensions when the project starts - as needed.
   (Please, no --profile option should be needed)

2. For the first MVP: Add an option to disable all other extensions.

Then we would have a simple per-project way of specifying which extensions to use for that specific type of project.
And we could easily switch between different types of projects without needing the tedious work of manually having to enable/disable extensions each time we open a project.

[jpickwell]

I'm not sure if anyone mentioned this already, but for what it's worth, DevContainers supports installing/enabling and disabling extensions in the devcontainer.json file.

{
    "customizations": {
        "vscode": {
            "extensions": [
                // disable builtin PHP features
                "-vscode.php-language-features",
                // install/enable Intelephense
                "bmewburn.vscode-intelephense-client"
            ]
        }
    }
}

It's not precisely what OP asked for, but it is something.

[knowbits]

DevContainers supports installing/enabling and disabling extensions

"Think of DevContainers as a way to package and distribute your development environment just like you would with your code."

Thanks @jpickwell, that might do it!

All I need is for each VS Code project to have its own set of extensions.

[mkvlrn]

@jpickwell It works very well, and it could be a solution for most people, but you'll have a proglem if you have to work on a repo that already has a devcontainer setup that is there for a team.

Then you'd have to further customize your own local container with your extensions and settings, which isn't that much of a big deal, until the devcontainer gets updated and you have to repeat the process.

Or is there a way to use two devcontainers at once? Either way this would be a lot more work expected from the user than just using profiles.

[AnrDaemon]

@jpickwell That's again profiles. You have to update each separately.

[knowbits]

From @mkvlrn :

Or is there a way to use two devcontainers at once?

For developers working in a team who wants to use their own set of extensions instead of the "default" that has been checked into git, maybe introduce separate devcontainers settings file(s) that contains all the user-specific overrides?

The user-specific override settings doesn't get checked into git - by adding them to .gitignore.

[jpickwell]

I wasn't trying to imply that devcontainers was a complete solution to what was being asked for here. It's a partial solution if you're working with them already, and even then, yes, it has its caveats. They work for me and my team but won't work for everyone or every situation—just another tool in the toolbox.

[l-inc]

@knowbits, @mkvlrn, while devcontainers aren't a suitable solution for our team, we solve the problem of personal customizations on top of the team defaults by rebasing: one fetches the master branch with the defaults and rebases the personal customizations on top of it. I think, this is the best possible solution in a general case. Especially, because one gets a good view of possible inconsistencies with the defaults thanks to the inherently textual nature of the configuration. That works almost equally well with "data/extensions/extensions.json". The only difference is that one has to run a prettifier/formatter over it after updating the extensions (and before making a commit out of the update). But that is easily automated.

[knowbits]

@l-inc

I'm not very experienced in using git rebase..

The idea is to keep your "custom settings files" (that overides the "team settings files") in a separate branch?

And then rebase that "custom settings branch" onto the latest origin/main branch after fetching/pulling from github?

And then make sure to not commit or push any of the "custom settings files" back into the repo.

Yes?