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.

[levacic]

@SharakPL That's not the feature described here and it doesn't solve the same problem.

I (and many others) want to be able to configure enabled extensions within a configuration file that can be committed to a project's repo - so when I open that project (ie. workspace) on a different machine, or anyone else on my team does that, the correct extensions are enabled automatically.

I do not want to manually enable/disable extensions for each of the projects I work on. I want to clone a project, open its workspace file, and have everything correctly set up.

That's the value of this feature request, and none of the alternative proposals provide that value.

[rbeesley]

I might as well add my use case as well...

I'm a polyglot. I have many customizations for many different languages. I anticipated that when I selected Disable (Workspace) that something in .vscode, perhaps settings.json, that I'd be able to create a new workspace and just copy the disabled extensions list. I found instead that this setting seems to be stored in state.vscdb. The format of this value seems like it could be used right now if it could be overridden by a key in settings.json. Alas I found this thread instead.

Maintaining a global accept/reject list, which defines the default enabled/disabled extensions, with a per workspace accept/reject list to override would be ideal. This way you could manage a set of global extensions and they could also be manageable for group projects. It might even be advantageous to provide a way to replicate group workspace settings and still keep .vscode in the .gitignore.

I appreciate the comments some have made about trying to create group workspace settings, but for me, I don't want to sift through ~90 extensions to decide if I need it for Deno, PowerShell, Clojure, C#, etc. As a platform to support all of these different languages, there needs to be a better way of scoping extensions in a more organized fashion... some workspaces might need combinations, so it isn't just as simple as choosing a language set of defaults. Making these settings more portable than a SQLite 3 database would be a solid start.

@alexkreidler's strawman seems the best fit for what I'm hoping for.

[Morriz]

Sorry if I am not responding to all contributions here, but may I be so frisk and drop a simple view? IMO we should focus on usable workflows based on Everything As Code.

Please bear with me and follow this pseudo logic and respond on that:

IF a Workspace settings.json is found, and since it is the ONLY mechanism available in the repo to tell vscode anything ASSUME it is there to control ALL extensions for that project SO ALL (global) extensions will be disabled unless specifically enabled in that file

That way we can be sure of how vscode behaves in that project.

[Peter-Krebs]

@Morriz Well a workspace can also include several different projects.

Assume you have a workspace with one project having a web-backend and another project with the corresponding frontend.
Both projects will surely benefit from having different extensions activated, deactivated and/or recommended.

This is a typical use-case for our team.
Extensions fighting over formatting is usually battled with the Formatting toggle extension, formatting settings and lastly .eslintrc.js, .prettierrc and .stylintrc. Useful for team-wide formatting settings anyway, of course, but it's still a pain sometimes to share and update that knowledge with the team instead of providing a per-project default set of extensions as well.

It will also be annoying to deactivate all extensions not mentioned in the configuration file. Many extensions are only productivity extensions which are personal preference (let's say Bookmarks, status bar time or any of the status bar extensions).
I think allowing people to have a personality should not be discouraged. Would even motivate me to leave.

[Morriz]

I see your point. I think the system would need tags or categories to discern there can only be one active at a time, and when .vscode/setttings.json activates one, any other globals ones offering the same should be deactivated.

[SharakPL]

I do not want to manually enable/disable extensions for each of the projects I work on. I want to clone a project, open its workspace file, and have everything correctly set up.

You can commit extension pack. I bet you can even make a script that would install it automatically or you can simply describe what needs to be done in the readme. This way you have only 1 extension to enable/disable in workspace. That's the way Microsoft suggests for sharing extension configuration in a project.

[Morriz]

That's the way Microsoft suggests for sharing extension configuration in a project.

Are you sure? What is .vscode/settings.json for then?

[Morriz]

It will also be annoying to deactivate all extensions not mentioned in the configuration file. Many extensions are only productivity extensions which are personal preference (let's say Bookmarks, status bar time or any of the status bar extensions).

@Peter-Krebs thinking about this, I think it would be great to at least have the ability to disable a plugin (so that we can disable undesired plugins, such as other formatters than the one chosen in the repo). We could assume the usual suspects and just turn them off. This would not cover all of them of course, but at least we have some control.

Don't vscode plugins have a mechanism to avoid clashing on the same territory? It would be great if conflicts were detected by the low level plugin framework (again, probably based on tags & categories), so that the user gets a question popped up.

[SharakPL]

That's the way Microsoft suggests for sharing extension configuration in a project.

Are you sure? What is .vscode/settings.json for then?

That's perfectly clear in extension pack description:

Want to bundle your Python extensions, so you can easily disable and enable when you are working on a Python project? Use an Extension Pack.

.vscode/settings.json is to override default settings that you want different for specific projects.

[scotdb]

I also should add my specific use case.

I'm a database engineer, working with many databases which all have their own specific dialects of SQL (and their own extensions which deal with these dialects). All of these extensions provide support for .sql files (and typically some other file extensions that often clash).

So I want to be able to flag a workspace (essentially all the build scripts for a database) to use the extension appropriate for SQL Server, Db2 for z/OS, Db2 for LUW, Oracle or whatever database. It is so annoying to have to enable / disable extensions every time I switch workspaces to work with a new database (which I do multiple times per day).

[Peter-Krebs]

@Peter-Krebs thinking about this, I think it would be great to at least have the ability to disable a plugin (so that we can disable undesired plugins, such as other formatters than the one chosen in the repo). We could assume the usual suspects and just turn them off. This would not cover all of them of course, but at least we have some control.

Yeah, this of course needs to be carefully done, though.
If this means only the popular plugins are covered and configuration conflicts arise again with lesser-known extensions, this is only brushing the problem under the rug.
It's probably not that wild of an expectation for a team to configure their VS Code projects with a proper list of extensions to activate and deactivate, recommended configuration etc..

It's just not a core part of VS Code currently and a team-based approach to managing everything is increasingly clear to be a hard rule in any industry. VS Code needs to grow into those shoes.

Don't vscode plugins have a mechanism to avoid clashing on the same territory? It would be great if conflicts were detected by the low level plugin framework (again, probably based on tags & categories), so that the user gets a question popped up.

I believe which extensions are active at any time is depending on what is currently opened in the editor.
My understanding is that this even changes while tabbing through the different files when you have multiple files opened.

It is very unlikely a PHP extension flips out while you have a python script open, for example.

Some things extensions do are not that clear-cut, however.
I have a workspace with a Laravel-based PHP backend and a Vue (Quasar) frontend project in it.
Formatting your code with, for example, prettier has a slightly different result than formatting using eslint.
I cannot deactivate prettier entirely because the PHP code for our backend is formatted using that.
eslint is used for code in the frontend. Several configuration files later that is less of a problem (.eslintrc.js, .prettierrc and .stylintrc). Otherwise whoever formatted the code latest wins.

I understand creating separate workspaces for those two projects is a sensible workaround, but this only avoids the problem VS Code is not solving.
Having a consistent code formatting across the team is not that uncommon of a goal.

[Peter-Krebs]

@scotdb Well there is a solution to deactivate extensions for a workspace. In the extensions click the ⚙ icon and then select Disable (Workspace):

Apparently you can not activate/deactivate an extension based on the project within the current workspace you're currently looking at. But at the broad workspace level you can deactivate extensions. At least as an individual developer.

A team-based approach for that with each project in mind, not just the workspace as a whole, would be more ideal but at least there is that.

[scotdb]

@scotdb Well there is a solution to deactivate extensions for a workspace. In the extensions click the icon and then select Disable (Workspace):

Apparently you can not activate/deactivate an extension based on the project within the current workspace you're currently looking at. But at the broad workspace level you can deactivate extensions. At least as an individual developer.

A team-based approach for that with each project in mind, not just the workspace as a whole, would be more ideal but at least there is that.

Yes, I'm aware of the ability to disable a workspace in that way.

But it doesn't really meet the use case, which is to set things up so that whoever checks the workspace out of source control has the extensions to use (and not use) defined at the workspace level.

That doesn't work when the details are stored in the extension configs rather than within the workspaces themselves.

[SharakPL]

Some things extensions do are not that clear-cut, however.
I have a workspace with a Laravel-based PHP backend and a Vue (Quasar) frontend project in it.
Formatting your code with, for example, prettier has a slightly different result than formatting using eslint.
I cannot deactivate prettier entirely because the PHP code for our backend is formatted using that.
eslint is used for code in the frontend. Several configuration files later that is less of a problem (.eslintrc.js, .prettierrc and .stylintrc). Otherwise whoever formatted the code latest wins.

I understand creating separate workspaces for those two projects is a sensible workaround, but this only avoids the problem VS Code is not solving.
Having a consistent code formatting across the team is not that uncommon of a goal.

That's the problem with Prettier, not with VSCode. Also a reason I stopped using Prettier because it ignored completely my eslint, stylelint or phpcs configuration and forced its own rules, often messing my code completely. A tool for everything can't do a good job at all.

You should use Intelephense for formating PHP.

[Peter-Krebs]

Thanks for the suggestion! I think this is offtopic now regarding the formatting.
Regardless, an integrated team-based approach to managing extensions (enabled, disabled, recommended) would be greatly appreaciated.

Extension packs are a good start, but they currently do not support disabling other extensions (compatibility reasons or otherwise) or adding recommended extensions via the pack.
Having many different projects over the years you would need lots of extension packs, leaving you with managing those over time.

As suggested by @ramya-rao-a using the extensions.json could work better for this, as this is more of a project-by-project thing.

A tool for everything can't do a good job at all.

So you're saying VS Code doesn't do a good job? 😰

[SharakPL]

A tool for everything can't do a good job at all.

So you're saying VS Code doesn't do a good job? 😰

VSCode is just a wrapper for extensions and it does its job perfectly. Stylelint or eslint also work great as extensions because they focus on specific feature. Stylelint may even format inline style="..." in html, but never mess with html itself. Prettier tries to do everything at once and it's not very good at it in my opinion. I believe english version of that saying is "jack of all trades is a master of none"

[Daeruun]

I'd like this to be extended by a version-setting per extension.

I currently have the problem that a debugger-extension I use only works for certain versions of the tool to debug. Thus the extension gets updates when the target is updated. As I need to fix things for 2 versions of the target I need two versions of the extension. At the moment I need to reinstall the extension quite often in one of my workspaces and reload it...

[FStefanni]

Hi,

it would be very nice to be able to enable or disable extensions from the settings.json config file. More importantly, in a multi-root workspace, it would be nice to enable or disable extensions on per-root basis.

This would be very useful in complex setups as mines (I have many folders, with projects hosted on different services -- Gitlab, Github, etc. -- written with different programming languages, but all these pieces together create a single huge project, in a multi-root workspace).

Regards.

[SharakPL]

How would you know which extension to disable? What if a collaborator using your config file has some other extensions you don't know about that cause problems with your set? I can't see a way to implement disabling properly. The only way would be to start with something like extensions.disableAll: true and then enable what you need, but it's basically a prison cage for developer 😅

For everything else Remote - Containers extension looks like best approach (Docker required). It allows customizing VSCode settings and extensions per workspace the way you want - with a config file. You could even disable extensions if they had a dedicated property for this eg. prettier.enable: false

[FStefanni]

Hi ,

IMHO assuming that the configs are committed and shared in the team is not a fine assumption at all! Very often many developers prefer to use slightly different setups, with different extensions, etc. For example, many extensions provide clipboards, many extensions provide C++ completion, etc.. There is no reason to force all the team to use the same setup: what is important is to force code standards, not development environment standards.

Moreover very often, in shared contexts, disabling some extensions is fine for all the team: my actual needs are in this case. Think for example to an extension dealing with something (XML? YAML? C++? TS? what you prefer?) which is not used in a repo. It is fine to disable it for all the team.

Finally, an editor or IDE should be generic and allow users to do what users prefer, not what IDE developers think it is right.

Regards.

[generic-user]

@michaeljota Just want to understand what is the use case to have this in a file?

Having it in a settings file instead of having it in a database makes it portable.

• Think working from home on a Windows machine, working in a flex office on a public PC, going to the basement working on my Linux machine, laptop, ... the possibilities are endless. I use Visual Studio Code in all those environments. Right now there is no way I can sync my workspace disabled/enabled extensions. I can sync the installed extensions.
• Working on different workspace environments, think
  • Latex
  • Markdown
  • Sphynx
  • Programming C# / Pyton / Whatever

If I enable all my extensions at once my context menu is overflowed by items, performance gets a massive hit. I know plugin developers could make there plugins only load in certain circumstances. But experience tells me most developers ignore them ...

Just look at what my context menu looks like, really makes it quite useless ...

The solution was already given in the first few comments, lets not make this issue about everything, but keep it simple. If everybody is so afraid of breaking VSC by implementing, at the very least make an API call available that can enable or disable an extension. Leave implementation to the community.

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?

Although I think it would be better sooted in the .code-workspace we already use. That file is already used to enable and disable language servers (ea: snooty).

[levacic]

How would you know which extension to disable? What if a collaborator using your config file has some other extensions you don't know about that cause problems with your set? I can't see a way to implement disabling properly. The only way would be to start with something like extensions.disableAll: true and then enable what you need, but it's basically a prison cage for developer

For everything else Remote - Containers extension looks like best approach (Docker required). It allows customizing VSCode settings and extensions per workspace the way you want - with a config file. You could even disable extensions if they had a dedicated property for this eg. prettier.enable: false

I generally feel that it wouldn't be a prison cage for developers if some extensions were forced by the project.

For example, theming and other non-project related extensions are meant to be user-specific, because not all users prefer the same theme (and some users might need accessibility-related extensions etc.). These should not be managed by a specific project/workspace.

On the other hand, linters and static analysis tools are very project-specific and it is my opinion that they should definitely be disabled by default at the IDE level, and only enabled per-workspace, because the workspace knows which linter it wants to use (and the whole team working on a single project should be forced to use the same linter for the sake of consistency, as consistency is basically the primary purpose of linters).

In fact I already do this with some extensions that provide a configuration flag to enable/disable them - for example I have stylelint.enable: false in my global VS Code settings, and then I have stylelint.enable: true in the settings section of some of my projects' *.code-workspace files. Unfortunately, some extensions don't provide such a setting, and there are some that used to, but now warn of this setting being deprecated, and pointing me to enable/disable them via the extensions viewlet - e.g. eslint.enable shows such a warning, which is in my opinion a step backwards from having a consistent development experience within a team.

It doesn't make sense for ESLint to be a per-user configuration setting - my team's CI environment performs linting via ESLint, and the whole team needs to use this extension to avoid wasting time responding to CI errors - it's not a matter of individual preference. If you think this puts developers into a prison cage, by that same logic we shouldn't have any linters or forced style at all - but it seems to me that the general consensus is that we do actually want to force a consistent style (hence the variety of tools aimed at this purpose).

This would be achieved by simply providing a configuration-based API (just like the stylelint.enable configuration setting) by VS Code itself, where you could just refer to an extension by its ID and force it to be enabled for a workspace.

[Morriz]

In fact I already do this with some extensions that provide a configuration flag to enable/disable them - for example I have stylelint.enable: false in my global VS Code settings, and then I have stylelint.enable: true in the settings section of some of my projects' *.code-workspace files. Unfortunately, some extensions don't provide such a setting, and there are some that used to, but now warn of this setting being deprecated, and pointing me to enable/disable them via the extensions viewlet - e.g. eslint.enable shows such a warning, which is in my opinion a step backwards from having a consistent development experience within a team.

Same here. I second that. This latest development is going the wrong direction, as it should be made easier to toggle extensions from code repos. What happened to everything as code paradigm?

[leolcao]

@tabebqena are you kidding? this feature is still open for discussion, it is not been implemented yet.

[melMass]

Any update from the team on this one? IMHO, a configuration file to enable/disable extension is kind of mandatory for software like VSCode, given how much people rely on extensions and how much an extension can influence the performances of it...

I'm using VSCode for C++, Python, Haxe, Nim, Javascript..., so I do rely on many extensions that I rarely need all the time on all projects. At one point I even thought about compiling VSCode from source for "every" language I use, but the maintenance was way too much.

[acicovic]

Also, when a .code-workspace file is renamed, these settings are lost as they do not reside within the project itself.

[gjsjohnmurray]

Also, when a .code-workspace file is renamed, these settings are lost as they do not reside within the project itself.

In my experience, Save Workspace As... transfers these settings.

[acicovic]

@gjsjohnmurray good tip

[acicovic]

Though from a quick look, it also seems that the settings during a "Save Workspace As..." are not transferred, just copied. So if you create a new workspace with the same name after the operation, it gets the same settings.

[hassandraga]

We can easily disable an extension for "this workspace only" option, but if we have a multiple extensions, team collaboration, different workstation.. we can't go to extensions list and click on every one. We should have also a way to do this using .json file.

[Morriz]

key is to drive it with code, not ask individuals to manually configure extensions...who (dis)agrees with this? (disagreements could use some extra explanation imo)

emojis please!

[FStefanni]

Hi,

I believe that there are two different aspects (or maybe I have not understand).

On one hand, there are all the automatic/"auto-magical" smart thing that could be implemented, which is fine. On the other hand, there should be the option to always allow users to override the "default smart behavior".

This second option is what we truly need right now. Improvements in default behaviors are welcome, but they are not critical, as long as users can always override them (which lead us back to the critical part making it even more critical IMHO :-) ).

As exemplified in a previous comment, my setups are quite complex and no strategy can guess exactly what I truly need. Therefore I need a way to fine-tweak the extensions configurations.

Regards.

[hassandraga]

@Morriz Yes, but how? you mean using settings.json ?

[hassandraga]

@FStefanni I agree, the second option is what we need right now 👍

[Morriz]

@Morriz Yes, but how? you mean using settings.json ?

yes, as that is what exists now and should stay alive imo...until something better "as code" is delivered

[evald24]

I wrote a plugin that allows you to quickly apply the necessary extensions to the project on pre-prepared profiles.

The essence is very simple, you create a profile, select extensions and apply the profile.

Even after restarting VSCode, extensions remain assigned to projects.

The extension is already available on the marketplace

Who is interested here is the repository There are some ideas there and I want to understand whether the extension will be interesting and whether it needs to be developed

PS: This is my first extension 🚀, if someone likes it, thank me with a star in the repository or rate me on the marketplace 😊

[baincd]

@evald24 The past few days, I have just happened to also be working on an extension to solve (or workaround) this issue :smile:

It sounds like your extension automatically enabled/disables extensions within workspaces. I would be interested in understanding a but more about the details of this solution.

My extension (baincd.extension-profiles) takes a different approach, working within the limitations of the VS Code API.

In a nutshell, you configure lists of extensions as profiles, disable those extensions globally, then when you activate a profile those extensions are automatically displayed in the extension sidebar where you can quickly enable them. Other features include checks at startup that the appropriate extensions are enabled, and the ability to define extensions that should be disabled for a profile.

There are more details on the extension page. I encourage everyone to take a look, and am interested in hearing all feedback.

Thanks!

[leolcao]

I want to say it is trouble to use an extension to manage other extensions. Here has the self conflict for such extension: how to deal with self?

I tried one extension which makes my user settings mess, so I give up.

So before the vscode provide native feature, the only way is manually disable extensions for each workspace.

My strategy is to disable all extensions firstly, then enable common extensions for any tech stack. at last, enable special extensions per workspace for different tech stack project.

I know this is a workaround, but the workspaces are quite stable for long times. So basically I only need to do that manual seeting once time for a new workspace.

BTW, I installed about 120 extensions in my local for different tech. stack, I also really hope vscode can provide such per workspace configuration to define enabled extensions in the .vscode fold.

[evald24]

I want to say it is trouble to use an extension to manage other extensions. Here has the self conflict for such extension: how to deal with self?

I tried one extension which makes my user settings mess, so I give up.

So before the vscode provide native feature, the only way is manually disable extensions for each workspace.

My strategy is to disable all extensions firstly, then enable common extensions for any tech stack. at last, enable special extensions per workspace for different tech stack project.

I know this is a workaround, but the workspaces are quite stable for long times. So basically I only need to do that manual seeting once time for a new workspace.

BTW, I installed about 120 extensions in my local for different tech. stack, I also really hope vscode can provide such per workspace configuration to define enabled extensions in the .vscode fold.

My plugin works the same way. The path ~/Library/Application Support/Code/User/workspaceStorage/ contains folders with workspaces, which contain state.vscdb files. The extensionsIdentifiers/disabled field stores information about the disabled extensions in this workspace, and theextensionsIdentifiers/enabled contains the enabled extensions for the workspace. My plugin adds selected extensions to enabled, not selected ones todisabled. By disabling the extension as standard for the workspace, the data changes only there, so this is a small automation. You do not have to choose the necessary extensions every time, but only create a profile and apply it wherever you need to in a couple of clicks.

Example code from the repository:

const platform_slash = process.platform === "win32" ? "\\" : "/";

// ...

export async function setWorkspaceStorageValue(uuid: string,  key: "enabled" | "disabled", extensions: ExtensionValue[]) {
  const db = await open({
    filename: `${getUserWorkspaceStoragePath()}${platform_slash}${uuid}${platform_slash}state.vscdb`,
    driver: sqlite3.Database,
  });

  return await db.run("INSERT OR REPLACE INTO ItemTable (key, value) VALUES (?, ?)", `extensionsIdentifiers/${key}`, JSON.stringify(extensions));
}

[evald24]

@evald24 The past few days, I have just happened to also be working on an extension to solve (or workaround) this issue 😄

It sounds like your extension automatically enabled/disables extensions within workspaces. I would be interested in understanding a but more about the details of this solution.

My extension (baincd.extension-profiles) takes a different approach, working within the limitations of the VS Code API.

In a nutshell, you configure lists of extensions as profiles, disable those extensions globally, then when you activate a profile those extensions are automatically displayed in the extension sidebar where you can quickly enable them. Other features include checks at startup that the appropriate extensions are enabled, and the ability to define extensions that should be disabled for a profile.

There are more details on the extension page. I encourage everyone to take a look, and am interested in hearing all feedback.

Thanks!

Try my solution, if it suits you, you can use it. If anything is missing, please submit your ideas or check my implementation in the repository, or I can help you with some questions 😊

[baincd]

@leolcao,

I want to say it is trouble to use an extension to manage other extensions. Here has the self conflict for such extension: how to deal with self?

I agree. And it is a unique challenge to document how an extension that manages other extensions works in a non-confusing way :laughing:

My strategy is to disable all extensions firstly, then enable common extensions for any tech stack. at last, enable special extensions per workspace for different tech stack project.

I know this is a workaround, but the workspaces are quite stable for long times. So basically I only need to do that manual seeting once time for a new workspace.

I have a similar strategy, with the exception that I keep some extensions enabled globally so the number of extensions that have to be enabled per-workspace is smaller. My baincd.extension-profiles extension just helps make this strategy a bit easier, by showing only the extensions I want to enable for a workspace directly in the extension sidebar, and checking after startup if there are extensions that should be enabled/disabled in the workspace.

It is not uncommon for me to be creating new workspaces for one reason or another, so I wanted to be able to quickly and easily enable the list of extensions I want for different types of projects.

@evald24,

My plugin works the same way. The path ~/Library/Application Support/Code/User/workspaceStorage/ contains folders with workspaces, which contain state.vscdb files. The extensionsIdentifiers/disabled field stores information about the disabled extensions in this workspace, and theextensionsIdentifiers/enabled contains the enabled extensions for the workspace. My plugin adds selected extensions to enabled, not selected ones todisabled. By disabling the extension as standard for the workspace, the data changes only there, so this is a small automation. You do not have to choose the necessary extensions every time, but only create a profile and apply it wherever you need to in a couple of clicks.

So you are basically editing the VS Code user data directly to enable/disable extensions in workspaces? I have to admit, that is a pretty clever solution. Although I do have my reservations about that solution (potentially breaking something within the VS Code data, or VS Code making a change to it's internals breaking the extension), I do have to applaud you for your ingenuity!

[FStefanni]

Hi,

all your extensions and efforts are great, and can help us in many ways. Nevertheless, I still feel the need of the fix of this issue, since the objectives are similar (managing extensions), but the ways of doing so are different and lead to different results.

Regards.

[yw662]

Actually I just wonder why these extension enable/disable settings were not in settings.json when the first time it was introduced. It would have saved lots of efforts :-)

[KaungZawHtet]

Only progress about this issue is more comments 🤣 🤣 🤣

[Morriz]

I only see regression in this setup, as we now are asked to choose which formatter to use when a global config (User) conflicts with a repo config (Workspace). Wtf would vscode not choose the Workspace settings over the User settings?!

[JAYD3V]

So I want to comment on a something I read above that was authored in 2018

Someone commented that somewhere across the vast abstract desert that we call the internet, that the read, V.S. Code extensions don't run unless you need them. Of course, they never stated where that article "that they read" came from.

VS Code extensions rely on the developer to write when they are, and when they are not activated. Most of the VS Code extension APIs help with this, but the API is far from perfect, and from what I have seen, most extension developers don't even think about making sure that their extension doesn't use resources when the user who has installed it is working in an environment that doesn't make use of the extension that they wrote. In other words, when users download several extensions, and they don't disable the extensions that they don't need in an environment that doesn't make use of some of the extensions that they installed, those developers are putting their trust into the developers of the extensions, that those developers designed, and wrote their extensions with integrity. And whereas you might have a high level of trust for 3rd Party Software, I personly do not, This is exactly why I find it crucial that some sort of black, and or white list, is offered to us for enabling & disabling extensions.

Personally, I think a totally separate configuration file would be best, and have it be able to white & black list extensions.

    //  ".../.vscode/workspace.json"
    {
        "extensions": {
            "enabled": ["foo.bar", "bar.foo"],
            "disabled": ["rab.oof", "oof.rab"]
        }
    }

Personally, I think that the exensions.json file would have been better for this. I don't feel that extension-recommendations was an appropriate use for that name, because it is misleading, and I have seen people think that it is (what's being asked for in this feed) a white, &/or black list for extensions, which obviously it is not.

[JAYD3V]

I just read @sandy081 's comment about it already being available, and I actually came here shortly after asking for this on stack overflow, where I give a reason as to when individually disabling them is a nuisance.

How can V.S. Code extensions be configured, so that they are either enabled, or disabled. depending on the workspace that is open?

Also, wouldn't this be an easy thing to implement. I mean if you can do it individually via the V.S. Code GUI, shouldn't it be easy to implement a configuration file. I guess what I am wondering is; "When you disable an extension for a workspace, where is that information stored? Shouldn't we already be able to access where ever that information is, in which a decent 3rd party extension can be made if the V.S. Code team has a reason for not implementing the feature???"

[hericlesbitencourt]

I'm sorry but it's unbelievable that since 2017 this hasn't been implemented properly yet. Here's the problem. VSCode it's getting slow for so many people, and why that? Because of extensions. I guess a lot of people work with at minimum 2 languages(back and front). Imagine with 3, 4 and so on.

And what we want? A simple and quickly way to activate the extensions that we want to that folder that we opened. Could be made with a feature like " select extensions profile" or even improving with the existent "workspace" with example quoted above (also in related issues), allowing us the freedom to choose and get better perfomance programming.

This wouldn't change anything with team shared config, the recommended key could continue. If a team don't want that they just don't set anything.

It's a simple logic to enable or disable extensions that I've config on startup (VSCode) on that folder.

[SSmale]

A simple and quickly way to activate the extensions that we want to that folder that we opened. Could be made with a feature like " select extensions profile" or even improving with the existent "workspace" with example quoted above (also in related issues), allowing us the freedom to choose and get better perfomance programming.

I code in Java and Vue js at work and Angular, Nestjs, Vue and Java at home. Being able to have a 'Java' extension profile that I can choose when I start a new project would be great

[timthedev07]

I have extensions for Python, Svelte, React, React Native, Markdown, Babel, C/C++ GraphQL, and Typescript installed, but I mainly code in Typescript + GraphQL and the projects are relatively large and complex that it's getting slower significantly. (mostly the language server and extensions)

It's nice to have such a capable and flexible IDE that empowers my productivity, but it's a disaster for me when I have to manually disable every single extension I'm not using in the UI after I discovered all these other stuff I don't need for a particular project running in the background and at the same time not being able to sync these configurations across all my devices that use VScode and sync with my co-workers, as a consequence, I or the other people have to do this manually to gain some speed and performance.

Hope the VSCode team can consider adding this functionality for the sake of the people with a bunch of thick extensions. Dude, it's 2021!