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

[TonyGravagno]

@redoper1 are you familiar with Profiles? And have you tried them? If you do not want Eslint or Prettier enabled, create a profile that does not have these, but does have plugins and settings that you do want your developers to use. Developers import the Profile. When a specific workspace type is loaded, they just select the appropriate profile. From then on, whenever those workspaces are loaded, the correct profile is used - they do not need to manually select the profile for each workspace. In summary, you get exactly what you describe - and it's already in the VSCode that you are running right now.

If anyone here is having a "really? I didn't know that's how it works" moment, please feel free to ask.
If that solution still does not address your needs, explain why so that decision makers can get a better understanding of why You need, and perhaps create a new ticket to track that specific use case.

(Downvotes on comments with no reasoning are not helpful. Please explain why a suggestion is not helpful if you downvote it.)
@codeflorist, @paustint, @Amebus

[paustint]

@TonyGravagno - did you read the use-cases above?

I want any person that uses my open source repo to make sure that one specific incompatible extension is not enabled for the workspace (or even a "we recommend disabling XYZ extension with this workspace")

Profiles have a high amount of overhead, must be shared, installed, and activated - there is a lot of friction in that process. and I change between 3 different computers and workspaces, I just want the setup to JustWork™️ when I clone the repo on a new computer and start working.

and I don't want to have to manage different profiles where I have to keep wondering why some new extension I installed on computer "A" did not sync to the other places I am signed in to the editor (because I now have to manage completely separate sets of all of my extensions, when truly I just want one extension to be disabled for one specific workspace. And I want that change saved to the repo so it is tied to the repo, just like I can have many other VSCode settings live in the repo.

....But with the amount of resistance to the suggested feature in this issue, I have pretty much accepted the current state of things. 😦

Edit I didn't mean to come of harsh 🙇 - I just think that Profiles serve a specific purpose (and a great one for the use-cases it was built for!), but does not satisfy the ask from this ticket. insert analogy here about wrong tool for job or choosing a tool that is complete overkill for the actual need

[Sandros94]

There are "confused" 😕 reactions to my notes above.

Oh man, I'm having PTSD flashback (comment link) all over again...

[codeflorist]

@TonyGravagno

(Downvotes on comments with no reasoning are not helpful. Please explain why a suggestion is not helpful if you downvote it.) @codeflorist, @paustint, @Amebus

My use-case is requiring vscode.typescript-language-features to be disabled in projects using vue.volar. Otherwise these projects do not behave correctly. Thus it is clear, that this should be enforced per workspace, for all developers working with that workspace. Thus disabling extensions per workspace would be the required feature.

Using your line of reasoning regarding profiles as a solution, you could ditch all workspace-settings completely, because "one could use profiles for all that". Of course that would be silly, since both have different usecases:

• Usecase for profiles: General vscode configs.
• Usecase for workspace settings: workspace-specific vscode configs enforced for all developers working with these projects.

and perhaps create a new ticket to track that specific use case.

The title of the ticket is already "Enable/disable extensions from config file", which is exactly the requested feature.

There are already duplicates, which have all been ignored and closed:
#40109 (9 upvotes)
#18386 (154 upvotes)
#39272 (98 upvotes)
(there may be others)

Adding the 600 upvotes of this ticket here (and no downvotes on all these tickets) should give a good overview, of the demand for this feature.

[redoper1]

@TonyGravagno I agree with what @codeflorist has written in the last comment. Even our use case is quite the same.

We need to have this feature because profiles are not made to solve this use case, and even though they can theoretically be used for this it can be quite difficult to keep them up-to-date with our project needs. The other problem is the need to switch them for every workspace by hand and some developers could forget about it and then there will be the problems again. The main problem would be with for example open-source projects as @paustint mentioned. Every contributor would need to activate a profile for every project. I know people who are contributing to for example 10 different projects and then it can be quite a hustle to keep everything under control.

[TonyGravagno]

I swear I started this response with
"You guys are right. I completely agree. Profiles are not ideal for public/FOSS repos."

But then I thought a bit more... Ok, this is my last post here (again 🤣) and I hope you find it compelling. Thanks for one more opportunity to be a PITA, purely in the hope that someone here might benefit.

---

Let's be clear about what is and what is not in a profile. Your comments are largely focused on workspace settings. Profiles don't need to be saved with workspace settings. They can be saved with just the Extensions, which is the scope of this ticket. Think of this like Composer, NuGet, or npm or any other package manager where you need to control the dependencies in the dev's build environment for your package, and nothing else.

As I write this I have three VSCode instances up, all with different project types and extensions. No workspace, user, or other settings have been compromised and there are no repo issues.

That configuration of Extensions comes from the following .code-profile, a JSON "config file".

<< (click the arrow) : How settings overrides work if you're not sure about how they work in profiles

So what about the settings? Well, if you don't want to mess with remote dev settings, then the problem is solved if you simply don't save anything but extensions in YourPackage.code-profile. Below I explain how the dev's settings will be set depending on whether you do include any settings. I'm almost certain that I have some details below wrong. The bottom line is that there is a system of settings overrides which you can choose to use or not. I know you know most of this, I'm filling in where profiles fit, just in case someone missed it.

• I believe if there is a .vscode\settings.json file, that file overrides everything.
• If a profile is used for a Folder project, and the profile doesn't include settings.json, it will use the user's own Default Profile settings.json. If that is missing, the user's AppData\Roaming\Code\User\settings.json is used.
• If a profile is used for a Workspace, and the profile doesn't include settings.json, the default settings come from the .code-workspace file, which in turn overrides \User\settings.json.
• If a profile for a Workspace does have settings, any .code-workspace settings will override the profile, and unspecified settings are taken from \User\settings.json. However, if you open "User Settings" in this configuration, you'll get the profile settings. That is, the profile essentially overrides user settings but ultimately defers down to user settings for unspecified defaults.

Whether you do or do not include any kind of settings in your repo now, with a Profile and Extensions-only it will still work exactly the same.

Once a package-specific profile is associated with a workspace, it will always re-open when that package is re-opened, without any dev intervention. To clear that, F1: Developer: Reset Workspace Profiles Associations.

Devs might appreciate that you show them a way to reconfigure on the fly for each project, with no manual effort after the first clone. They get TS here, .NET there, PHP, Java, C++, whatevah. Your other configs handle standards and their configs handle everything else.

If you modify your package profile, a dev does need to re-import it. You could version your profile : YourPackage_240214.code-profile. A few clicks is required to import new and delete old. It's not that bad considering the benefits.

[dkattan]

What if extensions could advertise known incompatibility with other extensions?

[paustint]

@dkattan

What if extensions could advertise known incompatibility with other extensions?

I do like this idea!
It won't solve my specific problem since there is one extension that takes over and changes settings on vscode load, so it is more of a clash of one extension with certain workspace settings as opposed to two incompatible extensions.

@TonyGravagno - I think there are two sides to the coin.

If someone (FOSS or PRIVATE) is working on multiple projects that are completely different programming languages and completely different setups, then profiles are a pretty good fit for that one person.

A random person on the internet wants to clone my repo and work on it locally.
I want to make sure that one specific extension is not in use (if they happen to have it installed) because it overwrites some of the workspace settings I have included in the repo.

I would hate for the unknown stranger on the internet to be forced to use a specific profile that I ship with the repository because then the internet stranger would have a completely different set of extensions and environment - they may not want to install a bunch of the extensions in the provided profile.

I will say it again: All I want is for a workspace setting (committed to my codebase in .vscode/settings.json) to have a list of extension that get auto-disabled (if installed) while working in this codebase.

I don't want to manage entire environments.
I don't want to manage multiple sets of user settings and extensions.
I don't want to force (or even suggest) internet strangers into using some profile, which would drastically change their editing experience.

But what I do want is: ☮️, ❤️ , and 😁. (with a specific extension disabled ✌️)

[codeflorist]

@TonyGravagno

The amount of text you need to detail your cumbersome, manual, hard to grasp profiles-workaround, that has many negative implications - as mentioned by several people multiple times, is in my opinion a good indicator, that it is a worse solution than a simple, clean, short, easy, intuitive, self-explaining, automated and effective solution like:

// .vscode/extensions.json
{
  "incompatible": [
    "whatever"
  ]
}

I can't really follow your continued persistence, that profiles are the better solution.

[codeflorist]

@dkattan

What if extensions could advertise known incompatibility with other extensions?

This is basically a good idea, but in my opinion doesn't solve the underlying problem, since it would presumably work in a global, and not in a workspace specific fashion. Using the example above, i would want to use Vue.vscode-typescript-vue-plugin for projects using vue, and having vscode.typescript-language-features disabled for just this workspace, while having it enabled for other typescript projects.

[codeflorist]

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

I don't really understand this reasoning. Installing and enabling extensions is also "user specific", yet workspaces can advertise extensions, which are recommended to be enabled, with recommended.

Why not let them also advertise extensions, which are recommended to be disabled with incompatible (or whatever you wanna call it)?

These are 2 sides of the same coin - both might be required for a workspace to work correctly, and both need to be "shared (in team)" for developers to work efficiently and without problems.

I would solve this exactly the same way as recommended is working.

If this:

// .vscode/extensions.json
{
  "recommended": [
    "Vue.vscode-typescript-vue-plugin"
  ]
}

...results in this:

Why can't this:

// .vscode/extensions.json
{
  "incompatible": [
    "vscode.typescript-language-features"
  ]
}

...result in this:

?

Now if you have both in your extensions.json it would just need 2 clicks for a user to have an optimal working workspace. It would be clear, logical, unobtrusive, consistent and easy to maintain, and leave the final decision in the hands of the developer.

To again illustrate the demand for such a feature:

• This issue has 600👍 (currently ranking at position no. 17 of issues with most 👍).
• The solution proposed by @ramya-rao-a has 178👍.
• This duplicate has 154👍
• This duplicate has 98👍
• This duplicate has 9👍

[frederikheld]

I really don't get why some people in this thread try to engineer this "incompatibility" feature like it's a whole new thing all the while everyone else just want's the same behavior that the "recommendations" feature already has. There's absolutely no reinventing the wheel needed here, we want the same thing we already have, but negated.

@codeflorist even took the time to mock screenshots to explain it. Can we please have it now?

[nabe1653]

I guess, at the time of issue creation, this is for user's convenience.

Even if some plugin enabled on local, there's no much problem. (If you use some 3rd party's auto uploading plugin, it's on you.)

But now MS has been created some uploding plugings officially (e.g. copilot). This will send data automaticaly if vscode enabled already. If user has some secret data in workspace, it may be sent.
Now I feel the problem has been changed as security matter. (of paied users !)

Why copilot plugin does not support ignoring list file in local yet and not about disabling plugin feature of workspace too.
They reffer to here at last but topics of both kind are stopping as same.

[frederikheld]

How is the requested feature related to co-pilot? This is just about giving a recommendation to the user about how to change their local project settings to have a better developer experience. They can accept it or they can deny it. Easy as that. It's not different from them making the changes themselves, just that we would improve DX by giving the recommendation so they don't neet to skim through the docs.

[TonyGravagno]

Everyone : I promise not to mention or refer to the P word anywhere in this post. 🤣
@codeflorist - Your suggestion shows how basic we all want this to be, but it needs refinement.

// .vscode/extensions.json
{
  "incompatible": [
    "whatever"
  ]
}

Needs refinement because

• That is not what the original request is, and only satisfies a specific subset of the use cases here.
• "incompatible" : What does that mean? Maybe don't use the noted extension? Mandatory don't use the extension?
• This doesn't address both Enable and Disable.
• This can only be used when a .code-workspace is defined, which is not the case with most GitHub FOSS projects.
• What happens with multi-root workspaces? Only one of these files can be processed per workspace.

Suggestions and new attempt at resolving this ticket

• If a single project disables an extension there isn't anything to guarantee that it will be re-enabled, unless another mechanism is put in place to only disable extensions for the current window instance. So the recommendation to the developer is, "if you want this to work automatically, you much create a workspace for it".
• (Ref dialog mockups by @codeflorist) A dialog offers the configuration and asks for approval to implement.
• On approval, installed extensions are enabled or disabled, only for the current workspace, using existing mechanisms for "Enable (Workspace)" and "Disable (Workspace)".
• If the user/developer doesn't have the project in a .code-workspace of their own, the dialog offers the information but cannot make changes.
• If there is more than one .vscode/extensions.json file in a multi-root project, only the first file found is processed.
• Whatever the syntax, support : suggest_disable, suggest_enable, must_disable, must_enable

In practical use, on first encountering a project with such a config file, the developer will install whatever extensions are required, create a workspace for the project, then reload the project and accept the must_disable directive for other extensions. After that, subsequent loads should not require any new action unless the local configuration changes.

Implementation

• Need a mechanism to read the file, maybe a task in tasks.json.
• Need a task-invoked mechanism open the dialog on reading the file.
• Need a function to compare installed/enabled/disabled extensions with the config file.
• Need dialog to show "delta" settings, with and without existence of .code-workspace.
• On developer approval of the settings, use the existing "Enable (Workspace)" and/or "Disable (Workspace)" features to toggle extensions. On developer rejection, take no further action.

Summary

This doesn't do anything new, doesn't modify existing files, doesn't require schema changes, doesn't require new design, doesn't have scope outside of initialization. This could probably be done with an extension.

With the exception of a one-time common effort by the developer, I don't believe this imposes special effort on anyone who produces or consumes FOSS, and I believe it addresses all use cases described so far in this thread.

Arguments against

It requires the developer to do something.

Yes, automatic installation or deactivations are a non-starter for most environments. This defines a configuration file that requires a one-time effort that everyone here is familiar with, and it's automated from then-forward.

The developer may need to manually install extensions.

Yes. The tooling can never install or unstall extensions for the user/developer, as this could lead to abuse or confusion. The ticket is about enabling and disabling, not installation or removal.

It allows developers to use forbidden extensions.

The user/developer should be allowed to continue however they wish with the project. The environment should never prohibit forward movement if the user doesn't accept a mandate. Each time the developer loads the project without environment compliance, they will get the same warnings. The developer could be forking, re-purposing, testing other extensions, or doing something else that the project leader is not aware of.

It allows developers to PR incompatible code.

Deal with this procedurally like any linting issue. Warn or terminate employees, stop processing PRs from non-compliant contributors.

[Cyclodex]

Hi all again.

I am following this thread a long time already, and I made once an extension which tries to solve some of the problems we mention in here.
When I read the latest post from @TonyGravagno I have the feeling that the extension I created is already pretty close to it.
I am very open to get contributors, PRs and help to improve it further!

The extension Unwanted Extensions, allows you to save "unwanted" Extensions, as recommendation. Basically the same, what VSCode already supports for recommendations, just the other way around. It will trigger a warning, if you have one of the unwanted extensions, but it doesn't enforce the user to disable it, just helping guide him.

The latest feature I have added allows to define SEMVER ranges for matching version numbers on packages, you don't want as I heard some people do need to define only some versions as deprecated and not the complete extension.
(The semver feature is only available in the pre-release which you can choose in VSCode - pre-release because I did not get a lot of feedback yet, and I personally don't really use it.

Feel free to check out my extension over here and help further improve it, until MS will set some new priority to fix this endless thread once. (It doesn't look like this will be part of the roadmap soon if I understand correctly)... :(

Extension
https://marketplace.visualstudio.com/items?itemName=Soulcode.vscode-unwanted-extensions
Github: (Help & contribution is very much welcome)
https://github.com/SoulcodeAgency/vscode-unwanted-extensions/tree/develop

[nabe1653]

This is just about giving a recommendation to the user about how to change their local project settings to have a better developer experience.

I don't deny your opinion and don't say unrecomended message feature is useless. I wish this too and it's easier request.
But it's just your opinion. See the tile: "Enable/disable extensions from config file".
Just there're some users that wanted to disable (not uninstall) before open workspace project too.

e.g. Around 2018 comments too, they want to disable extention to ignore some initialize process.
It will require disable the extentions before open for it, maybe.
This request is as the title and not against unrecomended-feature.

I understand that you are frustrated that simple things are not being implemented. But take it easy.

[frederikheld]

Well true. Then we should either split this issue up or just start with the easiest implementation (giving a recommendation) and see how people respond.

[l-inc]

As for me, a recommendation would be an unrelated feature request. For my use cases, I need to have a precise specification per workspace which extensions to keep on/off (preferably, "off" is specified in the user config file for most of the extensions, whereas the workspace configuration selectively enables applicable extensions). For a dozen or two of workspaces that I open and close like 20 times a day, I wouldn't like any pop-up dialogs to confirm that I really want what I configured. Overall, the recommendations are very much orthogonal to enables/disables:

• recommendation:

  • if not installed, pop-up with a request to install
  • if installed but disabled, pop-up with a request to enable

• enable/disable:

  • if not installed, do nothing (no pop-up dialogs)
  • if installed, silently apply enable/disable (no pop-up dialogs)

P.S. No, profiles do not fulfill our needs in the company. :-) We need versionable text-based configuration files. Specifically, the user's settings.json and the workspace-specific *.code-workspace.

[starball5]

@l-inc profiles can be exported to JSON or GH Gist, and you can store the exported thing in the workspace folder...

[l-inc]

@starball5, sorry, let me correct myself. No, profiles do not fulfill our needs in the company because we need versionable text-based configuration files [1]. And exported profiles do not fulfill our needs because then they have to be manually re-applied after every update.

[1] Specifically, the user's settings.json and the workspace-specific *.code-workspace.

[eta-orionis]

I have a feeling this thread is being pushed too much in the "disable extension X" or "mark extension Y as incompatible" direction. This is a blacklisting approach and it does not work because the list of things you don't want is much longer than the list of things you want.

What matters to many people following this thread is the following:

1. Extension list is declared/saved per workspace.
2. Every extension on that list should run, everything else should be disabled (unless explicitly overridden by user).
3. Extension list is saved in a workspace file, not in some deep VSCode system folders
4. Extension list takes effect automatically, just like other settings do upon opening the workspace

The problem/use case is the following (giving examples from my work so as to make it concrete):

We work with Vue (Vuetify and Quasar), React, Laravel (Livewire and Inertia), and Nuxt. Sometimes using Tailwind, sometimes not. Each of these requires different extension combinations, different code formatters, different testing extensions, etc. On top of that, every dev in the world experiments with other frameworks and programming languages, which require their own extensions too. The result is an absolute pile of extensions installed on the machine, but each workspace/project only uses about 25% of those extensions. The others either:

• conflict or race to be the first to "help", usually with abysmal results: Prettier vs. Pint, Vetur/Vue2 vs. Volar/Vue3, Vuetify intellisense vs. Quasar intellisense vs. Tailwind intellisense vs. VSCode's own intellisense, Pest vs. Phpunit, etc.
• bother with unnecessary prompts every time the workspace opens (i18n: "You have not configured i18n for this project. Want to do it now?")
• or make VScode slower.

Profiles do not solve the problem, because they need to be manually imported, installed, and switched whenever a different workspace is opened. Recommendations do not work because they only increase the pile of installed extensions. Manually "disable extension X in this workspace" does not work because it is unreasonable to manually enable/disable 75% of extensions every time a workspace is created. That is why this issue exists: To address this far too common use case.

[frederikheld]

@eta-orionis: this is a very good summary of the issue. Thanks!

[dkattan]

Funny enough, I got a message the other day in VS Code from the Volar extension telling me I no longer need to disable the Typescript extension so I think half of us can put down our pitchforks :D

vuejs/docs#2723

[starball5]

@dkattan yeah I'm subscribed to the extension deprecation discussion, so I saw microsoft/vscode-discussions#1 (comment), and thought of the many people here who had that use case.

[frederikheld]

Funny enough, I got a message the other day in VS Code from the Volar extension telling me I no longer need to disable the Typescript extension so I think half of us can put down our pitchforks :D

vuejs/docs#2723

This message confused the hell out of me some days ago. It is a great example how it should not be done. Because if I disable the extension as recommended, something else triggers another popup that recommends that the extension should to be enabled. So another race condition about who's right.

On top of that, the Vue docs on that matter are not up to date (that can't be blamed on VSCode though :-D).

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