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

[KristoferHansson]

My use case is efficiently toggling LSP used for a specific language, in this case C++ where I want to easily toggle between clangd and vscode-cpptools. I want to be able to create a task that disables one and enables the other + also in the same task change the current c_cpp_properties config used, one set up for vscode-cpptools usage and one for clangd.

[yvbeek]

I'm running into a similar issue as mentioned earlier. In our React-Native project we're using ESLint for code formatting and don't want to use Prettier. If the Prettier extension is installed, it will start formatting files. The extensions.json file would be an excellent central configuration to turn off certain extensions for a project.

Workarounds like using a shared profile or additional extensions to manage extensions are not a proper solutions. If the developer has to take manual action, it is not a matter of if things will go wrong, but just when things will go wrong.

[kazak1377]

I can provide another example of when disabling extensions per-project will be really benefitial:

We working on monorepo with: nestjs, vue, where some vue projects using tailwind and others vuetify. Like main site is in vue with tailwind and admin interface using vue and vuetify. I dont need tailwind autocomplete when working on admin interface and i dont need nestjs support when working on frontend. So opportunity to disable some extensions when i working on files in specific subdirectories and be able to share that across the whole team is really something that could help.

[luohuidong]

When developing a Vue project, I encountered the issue shown in the screenshot. Vue plugins are incompatible with Deno plugins, Lit plugins, and Svelte plugins. In scenarios where multiple people are collaborating on this Vue project, it would be very convenient to disable the Deno, Lit, and Svelte plugins via a configuration file.

[l-inc]

For the record, the new feature of Local workspace extensions may appear useful as a workaround for some here. In particular, it can be misused as follows:

1. Create/assume a directory tree similar to the following:

vscode/
    workspaces/
        project-x.code-workspace
    my-projects/
        project-x/
    local-extensions/
        some-extension-1/
            .vscode/
                extensions/
                    some-extension-1/
                        <unpacked extension 1>
        some-extension-2/
            .vscode/
                extensions/
                    some-extension-2/
                        <unpacked extension 2>

2. To configure your projects, use the workspace files ".code-workspace" (say, "project-x.code-workspace" as in the tree above) with the following content:

{
    "folders": [
        {
            "path": "../my-projects/project-x"
        },
        {
            "path": "../local-extensions/some-extension-1"
        },
        {
            "path": "../local-extensions/some-extension-2"
        }
    ],
    "settings": {
        "files.exclude": {
            "**/some-extension-1": true,
            "**/some-extension-2": true
        }
    }
}

3. Open "project-x.code-workspace" and install the recommended extensions "some-extension-1" and "some-extension-2" by clicking "Install Workspace Extension".

This is likely not how the developers meant the feature of "Local Workspace Extensions" to be used, but this roughly meets the requirement to enable the extensions using a configuration file.

Unfortunately, the developers solved one problem (workspace-specific extensions) by introducing another one (security issue due to the extensions being supplied from unverified repositories), which they in turn solved by making such extensions a kind of recommendations (instead of just running them), which in turn brings us back to the original problem: the setup will require manual interaction instead of just working out of the box. The effort of this interaction can be kept low, but putting these extensions under recommendations creates interference with other expectations. In particular, we prefer to use "extensions.ignoreRecommendations": true and even "extensions.showRecommendationsOnlyOnDemand": true . The former suppresses the notification, and the latter hides the desired local workspace extensions from the "Extensions" sidebar.

[AnrDaemon]

Such ability would resolve my question of setting up rapidly created projects.

Setting up a single workspace and then simply cloning it will be sufficient to start working on a new lesson without much fiddling.

[Gambitier]

I tried to implement this as a extension, here's the repo. But faced another issue #201672 specifically for this part.

[IronGeek]

I really appreciate all the effort that tries to tackle this issue through extension, I've tried going the same route before too and come to a conclusion:

... this whole extension disabling/enabling feature should be handled in vscode core, not delegated to yet another extensions. Having an extension to disable/ enable another extensions is too meta...

An extension should not have the capability to enable/ disable another extensions. So I kinda agree that exposing API such as #201672 should not be supported. Imagine if such API is actually supported:

What if we ended up with an extension that forcefully enable/ disable some extensions and we want to (forcefully) enable/ disable that extension (or some extensions it enable/ disable)? should we make/ install yet another extension to enable/ disable said extension? ...

[gusbemacbe]

@rivy

Here's a script that converts a '*.code-profile' file into a normal JS object (modified from @zachhardesty7's script) ...

// `node vsc-profile-to-JSON.js CODE_PROFILE`
// * convert VSCode CODE_PROFILE file to JSON

const fs = require('fs');

const file = fs.openSync(process.argv[2], 'r');

const profileText = fs.readFileSync(file, 'utf8').split('\n');
const profileTextAsJSON = JSON.parse(profileText);
const profileProps = Object.keys(profileTextAsJSON);

const profile = {};

// de-JSON-stringify profile properties
profileProps.forEach((prop) => {
	profile[prop] = JSON.parse(profileTextAsJSON[prop]);
	// * fixup double-wrapped 'settings' entry
	if (prop === 'settings') profile[prop].settings = JSON.parse(profile[prop].settings);
});

console.log(JSON.stringify(profile, null, 2));

When I converted the VSCode profile file to JSON, I received the following error:

SyntaxError: Unexpected token 'D', "Default" is not valid JSON
    at JSON.parse (<anonymous>)

I verified the code and saw that it failed with "name":"Default" and the comments.

[github-yxb]

I have many different versions of Python projects, and due to the plugins in the Python ecosystem no longer being maintained for certain versions, this feature is very much needed. Has this suggestion from seven years ago not been implemented yet?

[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?