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.

[muuvmuuv]

@Sti2nd settings.json should be source controlled too unless it is the workpsace setting because it just makes sense. Imagine a python project with venv where you need to tell the python extension to use autopep and python inside the venv. If you would not source control it. Everyone in your project would need to manually adapt your settings.json.

_{Sent with GitHawk}

[Sti2nd]

@muuvmuuv You could source control it if you want everyone on your team to have the exact same settings. If there is only one setting you need to enforce across the team, I would say it is overkill to sacrifice everyone's customisation freedom. I guess there are several settings in your case, just points out a different way to work. I do understand that when I wrote "individual settings.json" in my original comment it is confusing, since workspace settings.json can both be individual and shared, so I rewrote that 😊

Maybe https://github.com/microsoft/vscode/issues/15909 is a feature you are looking for?

[tpaksu]

I would also add my desire about this feature, I'm coding Laravel and want to learn Django, or .NET Core, but I don't want to have Laravel Extension Pack enabled on those, instead I would use Python Extension Pack in Django projects, I would like to group these extensions and choose the environment by using global settings, or auto detection or workspace settings file etc..

So, question, can we control extension loading/unloading with some extension? I guess any extension written to do this would need to have a priority to load before any others to prevent loading of further extensions. So it's more likely to be handled by core. Am I right?

[austonpramodh]

I would also add my desire about this feature, I'm coding Laravel and want to learn Django, or .NET Core, but I don't want to have Laravel Extension Pack enabled on those, instead I would use Python Extension Pack in Django projects, I would like to group these extensions and choose the environment by using global settings, or auto detection or workspace settings file etc..

So, question, can we control extension loading/unloading with some extension? I guess any extension written to do this would need to have a priority to load before any others to prevent loading of further extensions. So it's more likely to be handled by core. Am I right?

+1

[Sti2nd]

@tpaksu You are right in that extensions do not have access to disable extensions today. The profile switcher extension installs and uninstalls extensions as a work around https://marketplace.visualstudio.com/items?itemName=aaronpowell.vscode-profile-switcher

[tpaksu]

How about grouping the extensions in a directory and choosing the directory path when loading specific workspaces as the extension directory? When installing an extension in the related workspace active, it can move the extension to that directory automatically, and there might be a global extension directory for loading the common extensions for all groups.

[Pandawan]

Good idea. But I think the implementation isn’t much of an issue. It’s how you set it up that’s main problem.

On one hand, you could keep all global extensions enabled by default and read the workspaces’ unwantedExtensions setting to disable those that you don’t need.

On the other hand, you could have a list of the extensions that should be enabled and disable all by default (which might not be good if users install extensions for themselves).

[tpaksu]

@PandawanFr the implementation is an issue because I'm thinking about a way without modifying the core and make it work in everywhere (even in the older versions of VSCode. Last night another option came to my mind, it's not related with any core or extension but it'll consume some space on the hard drive. The method came to mind is to use the portable mode for each development environment with their own data folders with their own extensions :) Probably the easiest solution right now.

[Luckz]

The method came to mind is to use the portable mode for each development environment with their own data folders with their own extensions :) Probably the easiest solution right now.

There's commandline options for user data and extensions, https://code.visualstudio.com/docs/editor/command-line#_advanced-cli-options , as mentioned above in https://github.com/microsoft/vscode/issues/40239#issuecomment-525193644 etc.

[tpaksu]

@Luckz sorry I've missed that detail. It's a bit better than different portable folders. I guess there might be a way to make it being read from the workspace file and load extensions and user data from that folder. Will look.

[basickarl]

Any update on this? Would be awesome for teams to have the exact same vscode setup on every machine.

[tpaksu]

@basickarl you can do this with sync extension.

[TheryFouchter]

I use some kind of workaround to be able to use the extensions I want.

According to the vscode-cli your can specify the folders for extensions and user-data:

Options                  Description

--extensions-dir <dir>   Set the root path for extensions.
--user-data-dir <dir>    Specifies the directory that user data is kept in. Can be used to open multiple distinct instances of Code.

Basically, I create a specific folder for my specific tasks (one of front, one for back, ..) and set basic extensions to my default vscode.

To launch my custom config:

code --extensions-dir "$HOME/.vscode/profiles/my-super-profile/extensions" --user-data-dir "$HOME/.vscode/profiles/my-super-profile/data"

The problem are that:

• It's not really a project config file but a global preference file
• I had to install manually the extensions. I believe there is a hackish way to do this
• It use more size than necessary (multiple vscode data / duplicate extensions)
• It doesn't solve in a clean way the team-sharing problem

[fourpastmidnight]

I hate to add yet another voice to this already long issue, but I also feel strongly about this. I work on many different types of projects and I have a TON of extensions installed. Startup of VS Code is extremely slow and the UI is often locked up waiting on tasks to complete (or more likely, it's just heavily CPU bound and unable to respond to user input), and usually, 20% - 30% of the time, the extension host dies while all the extensions are being loaded. Also, VS Code consumes GBs of RAM. In reality, for each project, I only need a few extensions enabled at any one time.

The ideal situation for me is that I could install all of the extensions I wish to have installed which are intended to be used across various different workloads. I could disable globally (for my user profile) all project-specific extensions (e.g. C#, F#, docker, azure, linters, beautifiers, etc.) while leaving others enabled (i.e. color themes, SettingsSync, pomodoro timer, etc.). Now I acknowledge that we can already do this today--basically, disable all extensions, then re-enable the ones you always want to be enabled.

But the next part: only enabling extensions required for a certain workspace—this is not possible to do, automatically, today without some kludge (like the aforementioned profile switcher extension or specifying the extensions and user directory as command-line switches to VS Code (i.e. a shortcut per project/environment type), which in my view is hardly desirable for several obvious reasons).

I submit that this information may need to live in two different places

• One is a shared location meant to be distributed amongst members of the team (i.e. checked in to source code control): this file would contain the names of extensions, that if installed, will be enabled when the folder is opened (so, if this file is present, VS Code would need to process this file when opening the folder). If the extension is not installed, nothing happens. I imagine extensions which are not installed would also be specified in the extensions.json file and would recommend the installation of such an extension. (Perhaps the existing extensions.json file is already the correct location for this information?) The obvious place for this is in the .vscode folder.
• The other location would hold a user-specific workspace extensions settings file. Perhaps, in addition to the recommended workspace enabled extensions, there are other extensions you personally like to use to aid your productivity for a given workspace/workload. They're not expressly forbidden by your organization/team nor do they conflict in any way with other project extensions (e.g. linters, beautifiers)—I mean, I suppose it's possible they could, but then your use of these extensions is between you and your team 😉. This file would also be read upon folder open and enable those extensions, too. The trick is—where does this proposed file live?

Thinking about the proposed user-specific workspace extensions settings file: on the one hand, it could be stored to the same location where your personal VS Code settings are stored in your user profile (i.e. another file in your User settings folder for VS Code--not in the settigs.json file). But then you have the issue of mapping settings to workspaces. (Do workspaces have a name/id? And what about when Visual Studio Code forgets about your workspace? I can't tell you how many times I've lost my "context" due to VS Code not properly recording which files were open in a session when VS Code goes down hard.)

But then it occurred to me: I've heard it suggested that the .vscode folder shouldn't be checked into source code control. But then, there are clearly files in there that are meant to be shared. Perhaps this folder is too big of a "catch-all" folder for "settings". Perhaps we need a folder such as .vscode-user that holds personal workspace settings not meant to be committed to source code control. While that could help with user-level workspace configuration settings, the downside is "yet another folder to ignore" in our .gitignore files. But, not only are extensions something that might be user-specific, but Tasks, Launch configurations, and other general VS Code settings as well. This suggestion alone might neatly resolve a lot of the issues with requests of this nature.

[ghost]

user-specific workspace extensions settings file

@fourpastmidnight You can use a .code-workspace file for that. That's how I personally configure my workspaces, with one single Project.code-workspace file (where Project will be the name of the workspace) which holds all workspace specific editor settings, theme settings, extension settings, extension recommendations, even tasks and launch configs. (VSCode will also launch the workspace when you open the file). I exclude this file from source control since it's specific to my preferences.

The trick is—where does this proposed file live?

Technically it can live anywhere, as you can specify the directories of your project files inside this file (relative or absolute paths). I keep it in the root workspace folder though.

As for this issue, an extension whitelist setting would be the ideal solution (to save workspace-enabled extensions in the workspace settings, and globally enabled extensions in the user settings). Currently I just use the recommendations setting to keep track of workspace specific extensions and enable/disable what I need manually when I set up the project.

[fourpastmidnight]

@raz-avr Ah, I have never used the "multi-root workspace" feature, so I didn't even know about the existence of this file.

However, is this file intended to be shared amongst team members? It looks like the answer to this question is "it depends". If this file is shared, then it would not serve as a good place for user-specific extension preferences for a workspace. (I'm thinking of something akin to the Visual Studio .vs folder that holds things like the solution .suo file for holding user-specific solution settings, such as IISExpress host/port settings, for example.)

[ghost]

is this file intended to be shared amongst team members? It looks like the answer to this question is "it depends".

@fourpastmidnight Yes, it depends. It's a configuration file that stores settings, so it depends on whether you want to share the specific settings that are in it. The extension recommendations setting for example feels like it's intended to be shared in that regard. In any case I think that generally it makes more sense for users to have individual workspace settings, rather than shared.

[fourpastmidnight]

@raz-avr I agree it makes sense for users to have individual workspace settings, including what extensions he/she would like to have enabled for a given workspace (which may be a subset of or in addition to extensions already globally enabled for that user). I don't see the .code-workspace file fulfilling this purpose particularly well—unless a user-specific version of the file lives in the proposed .vscode-user folder I mentioned above, in which case, it becomes user-specific workspace settings.

[ghost]

@fourpastmidnight For me, it achieves its purpose perfectly. I see the .vscode folder as an alternative to the .code-workspace file, in case multiple similarly user-specific and workspace-specific files are needed. If there are settings/files within these that are intended to be shared, they should simply be put somewhere else (and thus added to source control). But, I suppose what is intended to be shared or not is ultimately subjective (and out of scope for this particular issue).

[fourpastmidnight]

I think sharing is a big part of the problem, however.

Ensuring that user-specific settings (especially as it pertains to extensions to be automatically enabled upon a folder being opened by VS Code—what the main topic of this issue is about) have a well-defined place to live and is explicitly known that it should not be checked into source code control.

As already mentioned, I started this off with thinking about the initial problem at hand: automatically enabling installed extensions upon folder open (both extensions specified by workspace-specific configuration settings (in .vscode) shared amongst a team as well as user-specific settings)—but I came to realize that there are other settings such as tasks, and debug launchers which could also have "shared/team" configurations (again, currently stored in .vscode) as well as personal configurations for any given workspace (which don't have an explicitly defined place to exist).

Sure, you can hijack the .code-workspace file—and that all works until your team has a git repository containing multiple folders and checks in a .code-workspace file to make it easier for the team to work on the repo.

[ghost]

Perhaps there could be a third layer of settings named Shared, in addition to User and Workspace. It would override any User and Workspace settings similarly to how Workspace overrides User, and support both a single-file multi-root structure (i.e. .code-workspace) and a folder structure (i.e. .vscode). The file names would have to be different of course, (e.g. .code-workspace-shared and .vscode-shared). That way the default .code-workspace/.vscode would become explicitly defined to not be checked into source control.

It would be yet another file/folder to have in your project directory, yes, but it would give users freedom to have both user-specific workspace settings and shared workspace settings. Those who only need one of the two would only keep the one file/folder they need.

[diegosomar]

This is a great feature. I have a use case here. When I'm working in a PHP project, I always have to manually disable all extensions for Ruby, Angular, Node (etc). When I'm working in a Ruby on Rails project, I have to disable manually all extensions for PHP, Angular, Node (etc). When I'm working in a Node/Angular project, I have to disable manually extensions for PHP, Ruby......

Why I'm doing this? Because I want my environment fluid and every byte saved is very important to my RAM.

If we have an extensions blacklist file in project (like workspace file), always the project (or workspace) are opened, the specifics extensions are disabled automatically.

That makes sense?

[fourpastmidnight]

@diegosomar I get where you're coming from, but I think it should be the other way around, and is what I was proposing: most extensions are disabled by default, and then one or more workspace files (a shared team file and/or a user-specific file) can "whitelist" extensions that should be enabled for that workspace.

Using an "opt-in" model will ensure that:

1. VS Code startup is quick and minimize Extension Host crashes
2. Extensions globally enabled by the user are always enabled (e.g. Themes, productivity extenions such as pomodoro timer, etc.)
3. The workspace then defines the other workspace-specific extensions that should be enabled (upon folder open), ensuring that only extensions required for the workspace are enabled, also saving precious RAM/CPU resources.

The only "Gotcha" here is that some extensions require a reload when they're enabled. So these could be problematic for this "opt-in" model of extension auto-enabling/disablling.

[diegosomar]

I agree with you @fourpastmidnight! The fewer extensions are active at startup, the faster it opens and the less resources it allocates. Whitelist or blacklist solves the problem. Now, the VS Code team can decide which one is the better implementation.

[JohnGalt1717]

What I'm hoping for out of this is that I can disable in a specific window, all of my angular extensions that tack on right click menus etc. while working in our C# REST api, and in the angular project disable the extensions for C# to get rid of the distractions.

Especially useful for Test Runners. I don't need the protractor test running enabled taking up space and confusing things when I'm doing C# work.

[ldsands]

Note: crossposted here

Could we not also base this upon the language as well. For example, if you open a folder and there are .csproj and fs files then all the c#/.net extensions load and then also the f# extensions as well?

A lot of the options that have been discussed in similar issues I think would be a lot easier to deal with if they took into account the languages in the folder that is being worked on.

Some example options that I have thought of could look something like one or more options below:

{
    // language settings option
    "[python]": {
        "editor.defaultFormatter": "ms-python.python",
        "editor.rulers": [
            88
        ],
        "extensions.activation": [
            "magicstack.magicpython"
            "ms-python.python"
            "njpwerner.autodocstring"
            "frhtylcn.pythonsnippets"
        ]
    },
    // global whitelist option
    "extension.global.activation": [
        "akamud.vscode-theme-onelight",
        "salbert.copy-text"
    ],
    // global blacklist option
    "extension.global.deactivation": [
        "akamud.vscode-theme-onelight",
        "salbert.copy-text"
    ],
    // per extension whitelist option
    "extension.global.activation": {
        "akamud.vscode-theme-onelight": [
            "python",
            "markdown"
        ],
    }
}

I also like the idea of using user defined extension groups that can be used instead of the more verbose way that I show above as mentioned in this post.

Others have suggest similar solutions or discussed this in comments [here],(https://github.com/microsoft/vscode/issues/40239#issuecomment-521186857), here, here, here, here and many more.

[KaungZawHtet]

Any update on this issue? We are struggling in managing different-characteristic projects everyday

[guushamann]

I would be very happy with this option!

[chrisroat]

I also would find this useful. I have a multi-root project where different folders use different languages. The python extensions really want an interpreter and wants to find tests, even though a folder has no python code. Whether this is done via settings.json, another json, or another mechanism is no matter.

I'd like to see the ability to turn off extensions in some manner on a per-folder basis.

[junaideqbal]

I also find this useful. This feature would be a great addition.

[alsaibie]

With VSCode being a versatile tool for many independent work environments. This would be a very useful feature, a setting flag in the .code-workspace such as "enable-extensions-only": ["extension 1", "extension 2" etc] would be a good start to opt-in the workspace-specific extensions settings.

[c0nd3v]

Good idea

[jpz]

I have a use case here. I have some C++ projects, sometimes I use the clang compiler on Windows, and sometimes I use the Microsoft compiler on Windows. Each environment has different plug-in set up, but both at C++.

So differentiation by language isn't sufficient. I want to set up one project to load the clang C++ extensions, and I want to set up another project to load the Microsoft C++ extensions. It simply makes sense this activation/deactivation of extensions is project specific and should exist locally to my projects which have these requirements.

[webdog]

This would be really nice, adding the choir here.

I would like to organize my projects folder by an overarching type (Let's say I'm writing a whole bunch of serverless apps, as an example)

(Lines prefixed with $ indicate a project name, those that do not have the prefix represent the extension that I would like at that level, and would flow down to dependents)

$PROJECT_ROOT
├── vim
├── Markdown All in One
├── AWS Toolkit
├── Remote SSH
├── $Super-Awesome-Python-Lambda-Function
│   ├── Python Extension
│   └── Pylance
├── $Incredible-MQ-Service-Deployed-With-Node
│   ├── node-snippets
│   ├── Node Debug
└── $NoSQL-Using-golang
    ├── Go Extension
    ├── vscode-dynamodb

While not impossible today, I have to install all of these packages at the top level, and then disable in each project with the GUI. What I would prefer to do is the inverse: A minimal set of self-defined-as-required extensions across all of my projects, and then capability to incrementally add-on or disable when appropriate for my project (Maybe I decide I don't want to use vim in one project because it conflicts with another extension, but I'd still like to keep it globally.)

Interestingly, this functionality is already somewhat available with Visual Studio/GitHub Codespaces through the use of .devcontainers here: https://github.com/microsoft/vscode-dev-containers/tree/master/containers/codespaces-linux

Supported codespace configuration keys

You can use configuration keys supported by Codespaces in devcontainer.json. General settings

name
settings
**extensions**
forwardPorts
devPort
postCreateCommand

extensions being available in the Codespace container to configure at these lines of code

[KaungZawHtet]

Now I m using Profile Switcher for different projects with different natures. But sadly, the extension is still in early stage and buggy.

[alexkreidler]

Reading through this thread, it's clear this is a much-needed feature, and I've longed for something like this for a while. It seems like there are a few considerations:

• @sandy081 mentioned earlier that "recommended extensions" should be shared among a team, but that tracking each individual extension (e.g. serializing the Extensions pane into the .vscode folder) would cause issues because most users have different extension needs at any given time
• as @webdog mentioned above, the ability to cascade extensions in nested projects. Of course, if one were to open the entire project in VSCode, it follows logically that it would need to load all the extensions of both the root and every sub-folder, such that extensions could properly emit activate events for different file types. However, it makes sense that cascading might be important for defining a base set of extensions like he mentioned, and then adding several on only when opening one of the sub-folders as the project in VSCode.

Proposal

Here's a strawman proposal that tries to achieve the following goals:

• serialize the default state of all extensions at the user level
• provide a config for folders (projects) to enable or disable extensions
• support either keeping that config at the project level (using .vscode/<some-config-file>.json) OR solely at the user level to avoid the side-effects effects on multiple users of tracking it in Git.

In the user level config

1. Have a user-level configuration file such as extensions.json Serialize the state of all installed extensions in an extensions key, a map from the extension ID to true or false, indicating whether the extension is enabled or disabled
2. In this file, add have an enable list
3. The list would contain test objects that have a test value for a pattern matching system like Regex or globs to match new project opened folder names (likely would want absolute path to allow using parent folder names as information)
4. If a folder name matches, add the extensions that in the object to a set of activated extensions for that folder
5. Repeat 4 for all valid matches (this would effectuate the cascading logic mentioned above, accumulating extensions)
6. Since there's also a "Disable for this workspace" option, add a disable map that disables extensions. This should have a higher priority that 5 (e.g. remove a value if in 5). We can bikeshed over whether the disable option should support regexes,

Example

Based on the data/extensions from the comment above. Uses extension names from the example. In real life, this would likely use extension IDs.

{
    "extensions": {
        "vim": false,
        "pylance": true,
        "Python Extension": false,
        "Node Debug": true
    },
    "enable": [
        {
            "test": "PROJECT_ROOT/.*",
            "extensions": [
                "vim",
                "Markdown All in One",
                "AWS Toolkit"
            ]
        },
        {
            "test": "PROJECT_ROOT/Super-Awesome-Python-Lambda-Function",
            "extensions": [
                "Python Extension",
                "Pylance"
            ]
        }
    ],
    "disable": [
        {
            "test": "Incredible-MQ-Service-Deployed-With-Node",
            "extensions": [
                "Node Debug"
            ]
        }
    ]
}

In this example PROJECT_ROOT has no special meaning, as it is not a regex operator. It's simply an example folder path.

In the project config

We could simply have two lists of extension IDs: enable and disable in the project-level config in .vscode. Theoretically, since enable could decrease performance, it should be accompianied by a warning, unless a user-level config for trustedEnableExtensions: ["project-name"] or trustAllProjectsEnableExtensions or similar is set.

With user-level extensions in a separate config file, and every project containing its own enable and disable keys, that would be enough to serialize the 4 current options (Enable/Disable (for this workspace)). We should also show an error if a user tries to put the same extension in both enable and disable

For teams that don't want to track individual extension enables/disables in the .vscode folder, they could add a flag like noExtensionTrack that shows an error if users add an enable or disable keys to the appropriate config file in .vscode.

This would then result in the 4 options being serialized as user-level enables or disables in the top extensions map in the user config, or as something like

"enable": [
  {
            "test": "Super-Awesome-Python-Lambda-Function",
            "extensions": [
                "Python Extension",
                "Pylance"
            ]
  }
]

Of course, it would be an important decision what the specificity of the regex should be, because we likely wouldn't want to enable/disable extensions from the 4 options for all projects with the same name. However VSCode currently does it (e.g. absolute path) is probably how it should be done.

The next step would be supporting both methods: tracking project-level extension state in both the user and project config. The project config would override user config where they conflict. Other than that, if user config also specifies enabling an extension in a project it should be enabled. There definitely should be more consideration to these interactions here.

Bikeshed questions

• How do the enable and disable extension sets interact? Does disable always cancel out enable?
• Should disable or enable only be "individual project" and not cascading (e.g. regex). Using regex and supporting "cascading"- just having multiple regexes match and add the set of extensions is more than the original poster described. This is a powerful feature, but regexes are very general and this could introduce complexity.
• Should enable be cascading but disable not? Or the other way around? Would these promote new ways of working? E.g. where for most for most users every day, all extensions you use are installed but disabled, and then upon opening a project that matches some test, a set of extensions are enabled.

Hopefully this is an interesting starting point for some discussions. I'm very glad that the community is working towards serializing all the extension state in an viewable, editable format, and not just having it be opaque to VSCode and used by Settings Sync behind the scenes. I'll also link to #109430 as it is slightly related.

[mukul29]

Hi everyone, I made a simple Bash script to achieve this. I'll try to work with the source code soon. I would love to get some feedback on this.

Here is the profiles.json for which I've set the path as $HOME/.config/code-oss-profiles/profiles.json

{
    "_common": {
        "enabled_extensions": [
            "vscodevim.vim",
            "extr0py.vscode-relative-line-numbers",
            "PKief.material-icon-theme",
            "CoenraadS.bracket-pair-colorizer"
        ]
    },
    "web_dev": {
        "enabled_extensions": [
            "abusaidm.html-snippets",
            "ecmel.vscode-html-css",
            "Gruntfuggly.todo-tree",
            "Zignd.html-css-class-completion"
        ]
    },
    "godot": {
        "enabled_extensions": [
            "geequlim.godot-tools"
        ]
    },
    "octave": {
        "enabled_extensions": [
            "toasty-technologies.octave"
        ]
    },
    "text": {
        "enabled_extensions": []
    },
    "java": {
        "enabled_extensions": [
            "redhat.java"
        ]
    },
    "cpp": {
        "enabled_extensions": [
            "ms-vscode.cpptools"
        ]
    },
    "python": {
        "enabled_extensions": [
            "ms-python.python"
        ]
    }
}

In the script, the extensions in _common.enabled_extensions are always set to enabled when code-oss starts. Other extensions depend on the profile you provide with the -p flag.

And here is the bash script (named code-oss-profiles)

#! /bin/bash

PROFILE_PATH="$HOME/.config/code-oss-profiles/profiles.json"

while getopts :p: option
do
case "${option}"
in
p) PROFILE=${OPTARG};;
esac
done

installed_extensions=( $(code-oss --list-extensions) )
enabled_extensions=( $(jq -r ".$PROFILE.enabled_extensions[]" $PROFILE_PATH 2>/dev/null) )
common_extensions=( $(jq -r "._common.enabled_extensions[]" $PROFILE_PATH 2>/dev/null) )

enabled_extensions+=( "${common_extensions[@]}" )

disabled_extensions=( $(echo ${installed_extensions[@]} ${enabled_extensions[@]} | tr ' ' '\n' | sort | uniq -u) )
# declare -p disabled_extensions
disable_argument=""

for extension in "${disabled_extensions[@]}"; do
    disable_argument+=" --disable-extension $extension "
done

code $disable_argument $@

On running with:

$ code-oss-profiles -p python
Warning: 'p' is not in the list of known options, but still passed to Electron/Chromium.

The warning is expected but the flag is not in use so there aren't any side effects as of now.

Here is the screenshot of enabled extensions after running the above command.

[LaurentOngaro]

Thanks for this job !

I've also created a bash script that can manage profiles switching for VS code It uses folders to define profiles and symlinks to activate extensions. As it, there is no duplicated extension.

The script can be found at https://gitlab.com/linuxdev_gameamea/public/osscripts/-/blob/master/switchVsCode

It's a part of a repo that contains a library of linux scripts that I've created for my daily work. I have tried to document the code as much as possible to make it as understandable as possible.

To use it:

• clone the whole repo. The script has some light dependencies on other scripts. Note that if you want a monolithic script you could easily remove them by copying and pasting required functions from the other script.
• read the comment the beginning of the script
• create the needed structure for the folders
• change some values of variables at the beginning of the script to match your installation
• launch the command to see basic usage: switchVsCode -h

Feedbacks and PR are welcome !

[gtu-myowin]

Extensions are bloat up overtime. It would be really nice to have an option to create custom extension profiles.

The use case would be that users will be able to create profiles (I would give language or frameworks name) and enable/disable profiles as they wish according to their current workspace.

The extension profiles basically will be just a group actions to enable/disable extensions. The current feature Disable (Workspace) needs a lot of single manual actions and needs to do it all over again if I open another workspace even with the exact same software stacks.

[Dhruv-Garg79]

I also want this feature.

Provide extensions more control over the sequence and grouping of their settings in the settings editor, e.g., support to group commonly used settings

This line from vscode roadmap suggests this is going to be implemented. If I am getting it right.

[Peter-Krebs]

Thanks for you work towards this feature, looking forward to see it implemented 🤓

Please also keep in mind that this feature ideally should work for VS Code workspaces as well, one workspace having several projects with different configurations and enabled/disabled extensions in it. In the case of a workspace it is not practicable to restart VS Code each time the project changes if the projects enable/disable different extensions.
Usually you will have several tabs from the different projects open and the enabled/disabled extenions would need to be loaded dynamically for which file the user is currently looking at. Is initializing / uninitializing extensions within a workspace even a thing without restarting VS Code?

Our use-case for example is backend development in PHP and frontend development in JavaScript / Vue. We have both the project with the backend code and the frontend code in one workspace to quickly switch between the two.
Sometimes the formatting extensions fight over dominance over the source code. Usually the "Prettier" formatting extension for the backend does not cause problems with the "eslint" formatting configuration for the frontend, but it would be cool to have their respective relevant extensions deactivated (or at least ignored) in the other project depending on which tab is currently in view.
Switching between tabs we would have to activate and deactivate the respective extentions from their .vscode configuration, which could take a performance hit when switching tabs (unless the extensions don't get fully deactivated, more "muted" or "ignored" for a certain project).

Having two separate VS Code windows open to make this feature happen is no show-stopper but if this feature cannot handle workspaces with different configurations for each project correctly there needs at least some type of warning that it only works with separate VS Code windows open.

[Peter-Krebs]

Provide extensions more control over the sequence and grouping of their settings in the settings editor, e.g., support to group commonly used settings

This line from vscode roadmap suggests this is going to be implemented. If I am getting it right.

No this reads more like extenions will have an option to group and sort their settings (I'm assuming instead of simply alphabetical), judging from the wording.

[GinoMan]

For some of us, the problem is much simpler: VSCode takes a while to load up, and then complains about PASCAL not loading correctly, and then that no Python tests were found, and then takes a while to scan the entire source directory for ruby gems, and then tells us that we need to upgrade dart because the dart extension just updated, and then the file loads, but we can't type anything into it because yet another extension is loading and then the extension host crashes and VSCode is brought down to a very basic form without extensions and then we restart the host and then it takes forever and maybe it succeeds.....

All so we can change a line in a C# script for Unity.

It would be nice to say in the global config "These set extensions should always load on every VSCode instance" and then in a local config file in the project "Enable these extensions". and as long as the latter exists, all extensions not listed in the former are disabled while those in the latter are re-enabled for that specific workspace. Even if changes to the file required reloading the window, that would be preferable to having everything load and having to trust the extension author was smart enough and considerate enough to get right when the extension should be loaded. This isn't even really a problem because VSCode reloads already upon opening a workspace or folder.

But we can't. why is Pascal loading in a C# Unity workspace? Why is Python loading for that javascript project I'm working on over here? Being able to disable them all except globally enabled ones, and re-enable them by workspace and in user defined groupings (C# group, Unity Group, Python Group, Flask Group, etc) would be the best.

[ackvf]

Since I focused on VSCode for the past few years, my keymaps and snippets in Sublime are pretty much outdated and out of sync up to the point that I don't even care about them any more and every time I open Sublime for some quick text hacking, I cry, because I can't control it any more. Though, it's still much better than Notepad.

I wish I could use VSCode for any text file by default in my system instead of Notepad or Sublime - with a minimalistic UI and very limited set of extensions to make it blazingly fast.

So, that being said, most of the time, I already know what file type or project I will be working with, so I would even imagine setting up multiple VSCode shortcuts with various preferences:

[muuvmuuv]

I like the idea of having a minimal version of VS Code but IMO it should be a separate installation that has no extensions enabled by default to enable it based on you use-case. For example, I open a lot of Markdown files in Sublime, so I would enable extensions like Markdown all in one and Prettier for formatting. Opening a folder would always open the Standard VS Code and the minimal would have two more commands "Open file VS Code IDE" and "Open folder in VS Code IDE". Maybe open another issue for that @ackvf

[Peter-Krebs]

According to the CLI documentation you can start VSCode without any extensions using --disable-extensions for a pure text editor. Of course this will have no extensions activated.

Alternatively, using the --extensions-dir option one can set up different extension directories for varying profiles as suggested above using separate shortcuts for each job.
This sounds good for an individual setting up their own dev environment. But this is not ideal and a little clunky to maintain for a team of developers and an awkward workaround.

Working towards a team-oriented approach is very much appreciated.

[nbfhscl]

this feature will be really helpful.

[generic-user]

Why does this need to take more than 3 years to get implemented? Clearly there are use cases enough. The architecture, the mechanics and logic are already there, all we need now is for the existing function to be exposed as a command that can be called from the plugin API. Then some goodhearted Samaritan can implement the gist. No idea why this does not get more support. There was even an issue asking for just that, but it also got closed ... https://github.com/Microsoft/vscode/issues/15466

[trallnag]

I already can disable extensions for a workspace. Can't this somehow be moved into the .vscode folder?

[SharakPL]

Actually this feature has been already available for almost 4 years now 😱

Requirements: npm install -g yo generator-code vsce

You simply need to create an Extension Pack for specific workspace, add extensions you want enabled in this workspace to its package.json file, make VSIX file, install it in vscode and then simply go to this extension on your extensions list and hit Enable in workscape. This will enable ALL the extensions available in this pack. Enjoy! :)