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.

[nvmker]

As a person who responsible for DevOps and Cloud such of things I have more than hundred workspaces or repositories in use with different set of languages such as Python, Go, C++, Faust, Swift, SQL, Markdown, Restructured Text, JSON and YAML with different schemas, XML sometimes, Terraform and CloudFormation and some others for my work and my personal projects.

So I know your pain guys and completely agree that extensions should be enabled/disabled via workspace config and not only manually.

[LaurentOngaro]

As none of the extension that manages profiles in VS code repo was stratifying me, I've created a Bash script (for Linux of course) that can switch between various "profiles" of VS code.

It uses a symlink to replace the "extensions" folder and point at different folders , each one containing symlinks to the extensions that are enabled for that profile. No extension is duplicated, and switching is instantaneous and very easy. For instance switchVsCode -p C++ ->switch to my C++ profile (if exists, if not, it will be asked for creation) switchVsCode -p Base ->switch to my Base profile, with all extensions in "real folders "

Creating a new profile is very simple : just switch to a non exiting one, and the "Base" profile will be "cloned" using symlinks

As, when an extension is removed in a profile, VS code just deletes its folder, in my case, in fact, it just deletes the symlink

This solution works rather well for me.

The only conterpart is that when an extension is updated, I have to recreated the symlink for that extension in each "profile". It's not very time consuming and could probably be scripted too (I'll probably include that functionality in my script later)

You can find this script, switchVsCode, on my gitlab repo for my all my bash scripts.

The code is clear, well commented, and could be easily understood and adapted.

Comments, Contributions and PR are welcome.

The same principle could be applied for Windows users by using a powershell script and junctions instead of symlinks

[aptMattKoe]

I'm also interested in this feature!

[jpz]

I note that .devcontainer/devcontainer.json has an "extensions" section, when specifying a Docker dev container. This is a good example of something that works to define the extensions which the project requires.

Native of VSCode that is not containerised however lacks this feature.

I guess the problem is the overlap between extensions which are "chrome"-like in nature, and those extensions which are language and project-specific.

If we work to distinguish the those categories of extensions and any other categories for that matter, it should emerge what types of extensions are project specific, and which are just, for instance, user customisation - which should not be governed by project configuration and settings.

That distinction does not appear to be super clear at present...

[generic-user]

Hello everyone, I do want to make it clear that at this moment in VS-CODE there is no native concept of projects.

What is meant in this threat by project I think is the concept of workspaces that is currently in VSC.

It is only making this issue extra complicated if we keep confusing everybody with the concept "project" which does not exist in VSC natively right now.

Workspaces do exists, that is where the focus needs to be. A workspace can contain many folders, from anywhere on the filesystem. So the worspace-settings file would be the best candidate to put the extension specific on/off switches into.

PS: this is no personal attack, I appreciate everyone's opinion and effort. If this view sounds a bit harsh: I apologize in advance.

[GHOSTS15]

I also add myself to the request , also I want the possibility to activate or deactivate a certain group of extension (that you can configure at will) , through these modes:

• For a certain workspace
• For a certain file extension (like .js ; .kt ; .java ; .py; etc...)
• Through a command.
• Via a key shortcut

imagine having 20+ extensions (total) and maybe for a project in .kt you need 3 and you have to deactivate the other 17+ and for another project in .py you need 4 and then you have to deactivate the ones you have activated for the project in .kt and activate only the ones for the project .py, after a while you go crazy.... (it becomes very long to deactivate/activate every single extension for every single project, much better if there is something automatic )

it is surprising (in a sad way) how for 4 years you refused to implement this very requested and very useful feature. what were you thinking? @egamma

[alefragnani]

I'm bringing here pieces of a comment I added on my Project Manager extension, because I think it could be my 2c 😃

We may have a bunch of extensions installed, but only a few being active when you open a certain project. It's up to the extension to choose the conditions to activate (https://code.visualstudio.com/api/references/activation-events), and VS Code uses that.

Of course, some extensions chooses to be active for any project you open (like Project Manager does), but others only activates if you open a certain file type (.java, .cs), or a project that contains a certain file (.eslintrc.json), etc. Extensions should care about the activationEvents and only activates when necessary. If we see some extension that is active but shouldn't, maybe you could ask the author to revisit its activationEvents. Sometimes is intentional, sometimes an issue.

I'm not saying I don't want this feature, because actually, I do 😃, but it's not just VS Code itself that needs attention.

I used a few IDEs/Editors, and don't remember a single one that does that. Every IDE/Editor seems to activate all plugins/extensions for every session, with no customization at all. In fact, I wonder how much memory you need available to open 5 to 10 instances of IDEs like VS, Eclipse, Delphi, JetBrains. Maybe you can do that with Sublime, Notepad++, Atom, but these Editors suffers the same limitation.

Based on what I have seen about this feature, I guess it should be available only when VS Code also support installing/enabling/disabling extension without reloading the current window. Probably an architecture revisit (extension related) will be necessary.

Why not allow the user to override the activationEvents, just like it does with extensionKind? Doing so, the user could restrict (or expand) when an extension should be activated.

Just another 2c 😬

[Morriz]

Still seems like a step away from everything as code mentality.

A projects .vscode/settings.json should be able to tell vscode which plugins to deactivate. Having multiple plugins like linters/formatters conflicting with one another is a problem most of us want to solve here.

[SharakPL]

It's impossible for settings.json to know which extensions to deactivate because each user can have a completely different set. Everyone would have to setup this individually anyway so what's the point? I feel like some of you expect magic here 😅 You have extension packs which are pretty easy to setup and then enable/disable whole set of extensions with one click. What's wrong with this approach? You have devcontainer.json where you can directly specify an array of extensions to be enabled automatically in each workspace. What else do you want?

[generic-user]

Confusing

The OP is talking about locally enabling and disabling certain extensions per workspace (can contain multiple folders!).

Please stop confusing everybody in this threat ...

Personal override vs Team Based override

VS Code provides two different scopes for settings:

quote from: https://code.visualstudio.com/docs/getstarted/settings User Settings - Settings that apply globally to any instance of VS Code you open. Workspace Settings - Settings stored inside your workspace and only apply when the workspace is opened. Workspace settings override user settings. Workspace settings are specific to a project and can be shared across developers on a project.

So the [filename].workspace-code file is not the place to set the local overrides.

The user settings file could be the place to store these personal override preferences to Enable/Disable extensions for certain workspaces, in the same way it is stored right now in the internal database (so again, no magic needed for implementing; logic already exist).

This gives user's the bonus of easily sharing, and copying and pasting the personal preferences.

Magic?

There is no magic that needs to be implemented, only a way to enable/disable extensions on a file based input. The only problem that needs solving is where to save it. Not how.

Currently

Currently, we need to manually enable/disable(per workspace) by right-clicking each of the extensions one by one.

We need to do it every time we change work environment, or create new workspaces.

To sum it up

A file based way of enabling, disabling extensions based on what workspace we are currently in. Implemented in exactly the same way it is implemented now. No magic, No hocus pocus.

Remote

I do not see what devcontainor.json has to do with the original request.

ALREADY SUPPORTED: Manually enable / disable

from: https://code.visualstudio.com/docs/editor/workspaces

Thanks

Thanks for taking the time to read. :tada:

[yw662]

To make it clear, devcontainer.json is for containers, where you can decide exactly which exts to install or not. What we are talking about is to disable/enable exts per workspace, locally.

I do agree that it is better not to disable sth in settings.json, iff you are submitting it to the repo. But the thing is, you should have .vscode/ ignored, whether by a gloal ignore file, or by .git/info/exclude, or by a star in .vscode/.gitignore. The settings.json file should be local so that everyone in the team can do it in their own way, and so that they can use some other editors than vscode.

It is like, you don't want .DS_Store submitted because many people don't use macos, so you don't want .vscode submitted because many people don't use vscode, or at least don't in your way.

And, since .vscode is local, it is no harm to allow it to disable some exts in trusted workspace.

[Morriz]

To make it clear, devcontainer.json is for containers, where you can decide exactly which exts to install or not. What we are talking about is to disable/enable exts per workspace, locally.

not really clarifying much in this context

I do agree that it is better not to disable sth in settings.json, iff you are submitting it to the repo.

That is exactly opposite of what is needed and discussed here: we want to disable stuff going into the repo, so devs all adhere to using the same tooling.

It is like, you don't want .DS_Store submitted because many people don't use macos, so you don't want .vscode submitted because many people don't use vscode, or at least don't in your way.

Again, I think it is the opposite: we know extensions exist that might interfere with the ones we want to enable, so we can list the usual suspects and disable those, knowing devs that have a preference for them will not be allowed to use them.

Declarative coding: describe intended behaviour and know it will be executed exactly like that

[yw662]

we know extensions exist that might interfere with the ones we want to enable, so we can list the usual suspects and disable those

However it can be unrealistic to have an exhaustive list of unwanted extensions. It is easier to have a white list but a blacklist is impossible. What if I am writing my own extensions and one of those happens to be interfering? That is what I think @SharakPL is talking about.

And if you submit .vscode/, you are preventing others to have their own local preferences, since all changes to it will be tracked by git. Again, what if I have a very uncommon extension to disable, which is a totally waste of bits for everyone else ? And there are people who don't vscode. I you want something for the whole team to agree on, it might be sth like editorconfig, but certainly not .vscode.

[yw662]

And it will be totally safe to let settings.json or .vscode/ to take full control of everything in trusted workspaces, if we keep it local and personal. Or it would be just too complicated, even if you use a white list. Like, What if I use some vim mode extensions that not everyone use? You don't want your white list filled with all of these. But what if this very extension is somehow interfering? You don't want your blacklist filled with extensions you never heard of either. So the only way: don't commit it and keep it personal, your team only need to agree on what they commit, not how they work it out.

[GHOSTS15]

Confusing

The OP is talking about locally enabling and disabling certain extensions per workspace (can contain multiple folders!).

Please stop confusing everybody in this threat ...

Personal override vs Team Based override

VS Code provides two different scopes for settings:

quote from: https://code.visualstudio.com/docs/getstarted/settings User Settings - Settings that apply globally to any instance of VS Code you open. Workspace Settings - Settings stored inside your workspace and only apply when the workspace is opened. Workspace settings override user settings. Workspace settings are specific to a project and can be shared across developers on a project.

So the [filename].workspace-code file is not the place to set the local overrides.

The user settings file could be the place to store these personal override preferences to Enable/Disable extensions for certain workspaces, in the same way it is stored right now in the internal database (so again, no magic needed for implementing; logic already exist).

This gives user's the bonus of easily sharing, and copying and pasting the personal preferences.

Magic?

There is no magic that needs to be implemented, only a way to enable/disable extensions on a file based input. The only problem that needs solving is where to save it. Not how.

Currently

Currently, we need to manually enable/disable(per workspace) by right-clicking each of the extensions one by one.

We need to do it every time we change work environment, or create new workspaces.

To sum it up

A file based way of enabling, disabling extensions based on what workspace we are currently in. Implemented in exactly the same way it is implemented now. No magic, No hocus pocus.

Remote

I do not see what devcontainor.json has to do with the original request.

ALREADY SUPPORTED: Manually enable / disable

from: https://code.visualstudio.com/docs/editor/workspaces

Thanks

Thanks for taking the time to read. 🎉

Have fun deactivating/activating more than 30 extensions (I have more than 40 for example) every time you change programming language.

[SharakPL]

@GHOSTS15 how about just 2 clicks per workspace? @generic-user seriously, how hard is this?

[generic-user]

@GHOSTS15 how about just 2 clicks per workspace? @generic-user seriously, how hard is this?

/image removed to safe screen estate/

Sorry, I cannot tell if you are serious or just trolling. 🙄

Clearly, I am missing a key ingredient to actually understand what's going on in the image? Care to explain in detail instead?

[nvmker]

Looks like @SharakPL using an extension pack he made, but anyway those comments are irrelevant to this feature request, just some additional noise in this topic. I'm a bit curious, why those people sometimes finding such issues and leave such comments, or this is just a trolling as @generic-user mentioned?

[Morriz]

However it can be unrealistic to have an exhaustive list of unwanted extensions. It is easier to have a white list but a blacklist is impossible. What if I am writing my own extensions and one of those happens to be interfering? That is what I think @SharakPL is talking about.

We just want to blacklist the “usual suspects” and do reviews to detect our devs are overriding tooling such as linting or formatting. If we can force these from Workspace settings then great. If we detect other ones interfering we will add it to the blacklist. Best we can do for now imo. Until we get a project master switch that will disable everything except a whitelist. (Please give us that present Santa!)

And if you submit .vscode/, you are preventing others to have their own local preferences, since all changes to it will be tracked by git.

Only preventing the blacklist (which won’t contain any extension that does not format or lint code). It is up to the devs to have global extensions turned on that don’t interfere.

Again, what if I have a very uncommon extension to disable, which is a totally waste of bits for everyone else ?

Answered above: code review would detect unwanted extensions operating.

And there are people who don't vscode. I you want something for the whole team to agree on, it might be sth like editorconfig, but certainly not .vscode.

We strongly advise our devs to use vscode (they all do actually, I wonder why, is it really the norm now?), but are allowed to use whatever if they translate the same linting/formatting settings to a consumable config file for their tool of choice, and demonstrated to achieve the exact same results.

[yw662]

So this is just a matter of taste: for me it is "Devs are free to do it on their own, as long as they pass the lints and tests", and for you "everyone in my team need to have the same experience".

Maybe every single person on Earth loves vscode, but I still think it is too much to "strongly advise" it. I am just trying to keep it "platform independent" and "clean", you know. Or it is like, .vscode is not a part of the code, so it is not a part of the repo, like .DS_Store. I am also for "don't put .DS_Store to .gitignore, put it to core.excludesFile or info/exclude", btw.

Anyway we both agree that .vscode/ or settings.json should be able to enable/disable extensions. I just want to say, "feel free to mess up .vscode/ since we can always choose to exclude it from the repo".

[Morriz]

So this is just a matter of taste: for me it is "Devs are free to do it on their own, as long as they pass the lints and tests", and for you "everyone in my team need to have the same experience".

Again: they are free to use whatever as long as everything is delivered as code, including automation tooling touching our code

Maybe every single person on Earth loves vscode, but I still think it is too much to "strongly advise" it. I am just trying to keep it "platform independent" and "clean", you know.

Some devs in our shop came with other editors but were like “I always wanted to try it out so now is a good time”. Maybe that answer was made easier after I asked them to otherwise bring the config of their tooling that has idempotent results.

I just want to say, "feel free to mess up .vscode/ since we can always choose to exclude it from the repo".

Opposite position for us, we want to include config for tooling of choice to cover all devs and be able to have consistent code style which makes for easier reviewing.

I actually wonder who in this thread is dealing with style and linting rules from a lead perspective, because I see quite some comments from ppl that seem to be allowed to deliver whatever. Don’t you have the same needs as I describe? Enforcement of code formatting and linting helps any team that wants to be consistent.

[yw662]

Enforcement of code formatting and linting helps any team that wants to be consistent

Of course it is important, but I would rather do it by some general methods, like git hooks, and ci tools like github actions. And editorconfig if it works.

You know people don't even need to agree on how many spaces a tab should be, if you have a good pre-commit hook.

[iyerusad]

@yw662

Not really a matter of taste in the current documented implementation of VS Code settings.

VS Code provides two different scopes for settings:
- User Settings - Settings that apply globally to any instance of VS Code you open.
- Workspace Settings - Settings stored inside your workspace and only apply when the workspace is opened.

What it seems you want is likely: a new, not yet existing VS Code setting scope: Individual settings for workspaces. Sounds neat, particularly when working on a large project where its configured for Windows, and you are trying to run it from a cloud/Linux instance and vice versa and don't want to constantly be manually editing the checked in settings file. Or even tab sizes, as you mention. I would like to see this feature. I was gonna suggest opening new feature request, but looks like this is already captured in #40233 (and handful of others).

This thread though, it seems to be about adding/exposing ability to configure an extension state, which would likely be available in any/all VS Code setting scopes (existing and new).

[yw662]

a new, not yet existing VS Code setting scope: Individual settings for workspaces

You know what, this can be easily implemented by not commiting .vscode/. I have this line in my core.exlcudesFile of ~/.gitconfig.

[alefragnani]

Based on VS Code documentation (https://code.visualstudio.com/docs/getstarted/settings)

VS Code provides two different scopes for settings:

User Settings - Settings that apply globally to any instance of VS Code you open. Workspace Settings - Settings stored inside your workspace and only apply when the workspace is opened.

Workspace settings override user settings. Workspace settings are specific to a project and can be shared across developers on a project.

Based on that, you just have to use/add the .vscode folder to your repo, IF you intend to share the configs.

The original request is exactly this. A file based approach to enable/disable extensions, just like the Recommendations works. And in fact you already can do that, but unfortunately VS Code just stores this info on its internals, not on a file.

IMHO, I think this is too granular. I don't want to enable/disable extensions for each repo I use. I would like to have a kind of project approach instead, but that's another issue 😁

Just my 2c about the linting/formatting subject. Unless VS Code is the only tool your team uses, it makes no sense to use VS Code settings to ignore/remove/force things. It would be independent, so you could do the same quality checks on CI environments. Using Git repos, maybe git hooks can help. But of course, you could have an extension to manage that as well.

Personally, I think the User Profiles, which is on the way, may solve most of the scenarios, if they handle Extensions too. At least, I hope that 😬

[iyerusad]

a new, not yet existing VS Code setting scope: Individual settings for workspaces

You know what, this can be easily implemented by not commiting .vscode/. I have this line in my core.exlcudesFile of ~/.gitconfig.

Its said that every 5 years, the number of developers double. I think that's a quote from Github CEO but don't have it handy.

Committing (sane) defaults in a project repo for what is essentially a flood of new developers being onboarded helps more people get going faster in a somewhat herded approach. Adding user specific workspace settings scope would enable more experienced/opinioned/experimenting developers to tweak away. The first is possible today, the second is advocated for in #40233.

Regardless, the ship has already sailed - VS Code implemented workspace specific settings via committed .vscode file(s). If you'd like that to not be the case, by all means file a request for the feature removal. Perhaps others will agree or not.

[Morriz]

on another note, if anybody here would like to see VSCode implement a per-project env file solution that gets read before plugins load (so the plugins have access to them without having to start VSCode from a preloaded shell), then please upvote it here:

https://github.com/microsoft/vscode/issues/135775#issue-1035164719

[dylan-k]

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

1. I have a workspace I work on across multiple devices and operating systems. Let's say for example that for this project there are some extensions I'd like to disable, even though I rely on them for other projects. Since vscode is setup to sync my settings, it also syncs the extensions. Now (as I understand it anyway) without a file in the workspace to say otherwise, I have to disable the same plugins over and over again every time I start working on a different computer.

2. As said previously, a file might not be ideal. Sometimes a workspace is shared among different users, who will have different extensions they want.

Is there a good way to resolve 1. without having 2.?

[Morriz]

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

1. I have a workspace I work on across multiple devices and operating systems. Because I often work this way, vscode is setup to sync my settings. Of course, this also syncs the extensions. Now (as I understand it anyway) without a file in the workspace to say otherwise, I have to disable the same plugins over and over again every time I start working on a different computer.
2. As said previously, a file might not be ideal. Sometimes a workspace is shared among different users, who will have different extensions they want.

Is there a good way to resolve 1. without having 2.?

Nr 2 does not necessarily go against nr 1. Workspace settings are usually not in the way of User settings, and the shared ones addressed in the file are mostly there to force extensions to work a certain way. (I see no reason to want to go against enforcing linting and formatting.)

[muzaisimao]

I developed an extension to solve this problem, For more information, please see the Disable Extensions. If it can help you, please give a star to the github repository.

[nvmker]

@muzaisimao congratulations! your extension for disabling extensions are third extension for such purposes there :) And there is still no progress for this request from vscode team unfortunately.

[Sven-Niehus]

@muzaisimao And there is still no progress for this request from vscode team unfortunately.

@sandy081 removed it from the backlog last Friday and it was added to the November Iteration as a stretch goal (Take a look at the "Extensions" section at #136630). Hopefully we will see some more progress in the near future

[SharakPL]

VSCode already works like that. I mean it loads per-workspace setup or defaults for new workspace. So it should be as simple as making it load from the file first and then look for workspace settings. Question is: where VSCode stores workspace settings and what files does it look for?

[sharpninja]

Have fun deactivating/activating more than 30 extensions (I have more than 40 for example) every time you change programming language.

Exactly, thus why I proposed creating named extension sets that would be enabled/disabled as a group and can be applied to workspaces or languages.

[g13013]

This would be useful for other uses like for this proposal https://github.com/microsoft/vscode/issues/137091

[natejgardner]

@g13013's suggestion is great. Ideally, I could easily load up a workspace that's personal to me and can be selected per project. If I'm making a flutter app, I want to be able to press one button and have my config for flutter apps load up. If later I'm developing an Angular app, I want my extensions for that framework to load up. I can custom-define these configs or optimally download prebuilt configurations from the marketplace. That way my status bar and sidebar won't be cluttered with Python, Docker, and Kubernetes when I'm developing an Android app, but I won't have to manually turn those back on for their respective development environments either.

[baincd]

Some of the recent comments on this thread got me thinking of an idea to be able to enable multiple extensions within workspaces easily:

• In the extensions folder, create a new folder (with any name, ex: my-custom-ext-pack)
• In this new folder, create the following package.json:
  • Edit the name, displayName, description, and publisher to anything you'd like
  • Replace the entries for extensionPack with the extension IDs you want to be part of this custom extension pack

    {
    "name": "tbd-ext-name",
    "displayName": "TBD Display Name",
    "description": "TBD Description",
    "version": "0.0.1",
    "publisher": "mycustomextensionpacks",
    "preview": true,
    "engines": {
    "vscode": "^1.32.0"
    },
    "extensionPack": [
    "foo.awesome-extension",
    "bar.another-cool-extension"
    ]
    }

• Go to the extension sidebar, refresh to see the custom extension pack, and disable it globally
• Enable the custom extension pack in the workspaces you want that group of extensions enabled

Testing this it seems to work well and I think is pretty simple.

One thing to note though is that if you add an extension to the extensionPack array, in workspaces where the extension pack was already enabled you will either need to toggle the extension pack (disable in workspace, then enable in workspace), or enable the newly added extension.

[SharakPL]

@baincd that's exactly what I'm doing here. As you can see people here don't seem to like this method 😉

[sharpninja]

It needs a GUI.  Having to lookup and manage lists of dozens of extension id's is beyond tedious.

[Morriz]

Really? A GUI? The solution needed involves code imo. Everything as code. Repeatability for projects is the biggest use case I would think. Those just working on one or two projects don’t feel the pain we have now. And it only gets worse trying to fix things with “better” GUIs. That is sooo Microsoft.

On 12 Dec 2021, at 02:05, The Sharp Ninja @.***> wrote:

 It needs a GUI. Having to lookup and manage lists of dozens of extension id's is beyond tedious. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[SharakPL]

@Morriz nobody forces you to use Microsoft software 😉

Like I said, VSCode is already working like that. State of every extension enabled/disabled in a workspace is saved there and every time I get back to that workspace I get the same state of all extensions even if in the meantime I create another workspace with different extensions setup. So just figure out where VSCode stores this information (hopefully a file somewhere) and make it look for that file in your workspace instead.

Personally I'm fine with using extension pack for that as it gives me more control (maybe I just want to check the project files and don't want to pollute my workspace with unwanted extensions). Only problem is settings sync doesn't sync actual extensions, so I would have to make it available online on the Marketplace first. It will be filled with all kinds of extension packs if everyone would start doing that. Would be best to have a private section for extensions.

[rbeesley]

@SharakPL the only problem I see right now is that workspace information is kept in a SQLite database as I recall. It isn't easily accessible and therefore not really cloneable. But there isn't a single solution that works for everyone... hence why this is still being discussed, 4 years and 192 comments later. I would be decently happy with personal extension packs if there was an easy way to pair them up with different languages... which gets more complicated when I have projects with more than one language...

[SharakPL]

I would rather make packs per project type, not by language. But that's just because there's less project types in my work than languages used. Besides nowadays VSCode's performance is much higher than 4 years ago. Certain extensions are activated only when specific file is opened so there's really no reason to disable them in the first place. Just let them be and they'll simply be activated when needed.

[yw662]

the only problem I see right now is that workspace information is kept in a SQLite database as I recall. It isn't easily accessible and therefore not really cloneable.

if so the first thing can be done is to move that database file into ./.vscode instead of ~/.vscode or somewhere. After that we can commit or ignore or copy or do whatsoever to that database file, as long as it is under the project dir, not the home dir. We may not even need it in plain text. A database file under projectDir/.vscode is just fine for most people.

[natejgardner]

Really? A GUI? The solution needed involves code imo. Everything as code. Repeatability for projects is the biggest use case I would think. Those just working on one or two projects don’t feel the pain we have now. And it only gets worse trying to fix things with “better” GUIs. That is sooo Microsoft.

Yes, a GUI for definition with a code-editable file backing it. Just like the way every other aspect of config already works. Best of both worlds :)

[KaungZawHtet]

Jetbrains' fleet is doing what VS Code doesn't. (Polyglot experience) . It enable n disable extensions intelligently by analysing the project. We r discussing the management about diff proj with diff natures (Polyglot exp) . Am I right ?

For more info, here is the link

[sharpninja]

It needs a GUI.  Having to lookup and manage lists of dozens of extension id's is beyond tedious.

I've begun working on an Extension Sets Manager Extension, nut it's slow going because of CSP constantly getting in the way is there a better way to build a GUI in VSCode than using a WebView?

[alefragnani]

@KaungZawHtet VS Code already does that, from the day 1. The point is, some extensions don't apply any rule to activate, so it will always be active when you open a new VS Code instance.

More details here: https://code.visualstudio.com/api/references/activation-events

[rbeesley]

@alefragnani, it can be a little more complicated than that though.

I have several other extensions which I use with a particular language, don't use with other languages, and are intentionally language agnostic because they are designed to be general purpose. Activation events are completely meaningless in this sort of situation because as the consumer of an extension I am trying to manage when and how it is used and the intent of the extension designer doesn't even matter...

Here's one that's even more of a challenge. I want to have some extensions applied when I'm working with Unity and different extensions applied when I'm working with some C# dotnet project. In both cases VS Code will see C# and those extensions which follow activation-events will want to load.

At the other extreme, I have some workspaces which have several different languages in the same project, so it wouldn't be enough to declare some top-level language selector for a workspace.

I love using VS Code because it can handle practically anything I throw at it, but I want to be able to manage that experience more closely to match the work I'm doing on a particular project, without needing to manually deselect extensions for each workspace I create.

@KaungZawHtet, VS Code is hyper-polyglot which is precisely why it appeals to me. Fleet is interesting and I hope JetBrains is successful in driving some business their way, I've used IntelliJ in the past and think they make a good IDE, I've not used Rider but hear good things about it for dotnet, however there are lots of things I do with VS Code where Fleet doesn't even have support on the roadmap.

[alefragnani]

Of course it is way more complicated than a polyglot tool, but my comment was specifically to @KaungZawHtet post, which talks about supporting different programming languages.

I face the exact same scenario as you do, and that’s why VSCode/Fleet being polyglot doesn’t mean anything to me, except being the same tool for every language I use. That’s why I’m pretty sure a file based approach to enable extensions (the original request of this issue) won’t work for me.

I use VS Code at home and at work, with almost a dozen of different profiles. Most of the extensions I developed to VS Code are language agnostic, like Bookmarks, Project Manager and Separators, and I want them to be enabled all the time. But others like the Delphi related, only when some Delphi project is opened (which doesn’t happens too often anymore). Most of the extensions I installed are language related, for each kind of project I have to work with. But I would like some agnostic extensions to be enabled only when working with frontend (like Prettier) or backend (like DB Connectivity).

Unfortunately, I have low expectations about this file based approach to work the way I need.

In fact, I hope the upcoming Profiles feature will, probably, be the best solution.