Persisting "disable by workspace" settings in source control

[unional]

• VSCode Version: 1.8.1

Can this setting be saved in the workspace setting.json so I don't need to ask every developer to disable the extension (if installed)?

In my company, our main product is stored in perforce so I use the perforce extension.
However, there are many small projects stored in git (bitbucket).

Optimally, I would like to "enable by workspace" and "disable by default", but if that is not available, then storing the setting would be the second best option.

Or maybe I should just suggest that feature instead? 🌷

[mjbvz]

I do not think this is currently possible. We allow workspaces to recommend extensions using .vscode/extensions.json, but not disable or enable installed extensions.

@joaomoreno or @sandy081 Any thoughts?

[joaomoreno]

Yup, not possible today. But I definitely see the need.

[jcrben]

I'd also like this. For disable by default, see #15611

[esetnik]

This is also crucial for projects which use tslint not prettier. Most of my JS work is done using prettier but when I open a new javascript project which does not use prettier the extension loads by default and starts formatting everything. Disabling editor.formatOnSave for the workspace is not ideal because it assumes there are no other project formatters in use. It'd be great to be able to configure extension loading (and maybe even default extension settings) on a per-project basis so that one can simply clone a repo and get the correct vscode configuration. One option would be to split settings.json into two files (one which is expected to be committed into the repository and one that allows power users to override settings locally. E.g. settings.json and settings.overrides.json where the order of precedence is:

1. .vscode/settings.overrides.json <- local workspace overrides not meant to be commmitted
2. .vscode/settings.json <- defaults for project
3. user settings <- defaults for vscode user
4. vscode defaults

[sandy081]

@esetnik Did you try doing following:

• Disable the prettier extension completely
• Enable it only for the workspaces you need it for.

@unional You can fulfil your requirement already now using these steps. Let me know if you still need to store in the workspace and if so why?

[esetnik]

@sandy081 Yes but this should be configurable by some file which I can commit into my repository. Otherwise every dev on my team would have to do the above procedure for each of our projects.

[sandy081]

@esetnik I think it is hard to know the extensions installed by others. There could be many other extensions each user could have installed. It should be the user choice to disable an extension if it does not work. I also think it is not a general scenario and you can fix it either by communicating to the team or have a custom extension that looks for the extensions you do not want and notify the team.

[esetnik]

@esetnik I think it is hard to know the extensions installed by others. There could be many other extensions each user could have installed. It should be the user choice to disable an extension if it does not work. I also think it is not a general scenario and you can fix it either by communicating to the team or have a custom extension that looks for the extensions you do not want and notify the team.

@sandy081 I believe the extension recommendation system should be used for this purpose. When the user first opens vscode which includes extension requirements they don't have it should inform the user to install those extensions and then reload. My goal is to get to a 100% working vscode setup for any particular project from git clone as quickly as possible. Having mixed extension configuration / installation / loading across team is bad for consistency.

[sandy081]

@esetnik I agree that extension recommendation should be used to set up a project quickly in VS Code and is doing exactly what you mentioned.

But, I do not agree to have a black list of extensions to uninstall/disable which will remove the extension from user window. IMO this is not a good experience. As said, the list is open ended and it cannot be complete.

Having mixed extension configuration / installation / loading across team is bad for consistency.

Looks like you want to restrict the extensions your team want to use for a project like a strict mode?

[bradzacher]

An example is for projects that use prettier. If a user has the prettier extension installed, then everything is fine - we can use the extension recommendation system to help people discover the prettier extension.

However if the user has already got an extension like beautify, then it causes undefined behaviour in vscode because both extensions implement format on save functionality.

I've run into this problem before - I've setup a project level vscode config which turned on formatOnSave so that people didn't have to manually configure it. However this caused a lot of issues for contributors because many had both prettier and beautify installed, so I had to remove the project level config.

If we had a way to disable user's extensions, then the whole thing could have been avoided.

There are many cases where as a project author/maintainer, I don't want people to use certain extensions. Right now I can only put them in the readme and hope that contributors read it and disable them (hint - they almost never do).

Most people already have their VSCode setup how they like it when they open up a new repository to contribute, so they do not look at the extensions screen. So providing recommendations to have users manually enable/disable extensions is kind of useless in that regard.

Another use case for a feature like this would be to let me disable and enable extensions across computers. Like @esetnik said, I want to be able to get from clone to working as quick as possible. If I've got my vscode setup with many extensions installed, I might want to turn some extensions on/off depending on the type of code in the project. For example if I open a C# project, I want a suite of C# extensions turned on, but I don't want my suite of JavaScript extensions turned on, and vice versa.

If you're really worried about it being abused or people not liking it, you can always add a user setting to vscode which ignores it, so that if someone gets annoyed by a project disabling their extension, they can toggle the setting to ignore workspace configs.

Personally, I don't see how this sort of extension config is any worse than project vscode config. I reckon that I can do a lot more to create a bad user experience for a user by putting random settings in the project vscode config than I can by simply disabling extensions.

[JeremyVyska]

Hiya!

So, working with VSC with Dynamics 365 Business Central, we have to install from VSIX the appropriate version of the Extension do our development work with BC for on-premise customers.

Microsoft currently releases a new version of BC and the VSIX every month. This means that we have to constantly switch out and in a VSIX file for development to match the project. It would be a HUGE help to be able to tie what extensions are enabled/disabled per workspace from the settings.json file, as we could simply install ALL the relevant VSIX versions we are needing, then let the settings.json file that is in our SCM repo for that project drive which version of the Extension we're using.

The existing recommendation and Enabled/Disable per workspace is great, but we very, very much need this functionality in the per-workspace settings.json in our industry use.

[sandy081]

@bradzacher Nicely summarised.

I like the idea of having workspace specific extension profiles. If a workspace has a profile, opening that in VS Code should run with that list excluding some already installed user extensions. How somebody can define that some extensions as it varies from user to user? It lacks some kind of generalisation. What I do not like is listing extension by extension in that list. May be instead of listing one by one why not the list can be those extensions listed in workspace + installed UI extensions.

On a related note to those who are complaining about multiple formatters, I think it is a different issue and is being tracked here - #41882. I do not want this issue drives this feature.

If everybody agrees that they need workspace extension profiles, I would update the issue accordingly.

[robbiespeed]

@sandy081 I really don't like the idea of a workspace shutting off all extensions it doesn't have listed. Although I do understand a workspace extension exclusion list, would be problematic especially for open source projects, I could foresee a lot of pull requests to add exclusions. Still I like the exclusion list better than a only allow these extensions list.

Another alternative could be a change to extensions themselves, allowing extensions to list other extensions they conflict with. Then based on the workspace's recommended extensions list it turns on all of those, and turns off all extensions that may conflict.

[bradzacher]

My thinking that the feature would at least let us expressly blacklist extensions.

A whitelist could work, but that would imply that a user's extensions are disabled by default and are selectively turned on when you open a project, which seems kind of backwards?

Essentially I want to be able to force disable certain extensions in my project because:

• I know they cause problems in the project for whatever reason (i.e. disabling beautify because it conflicts with our usage of prettier).
• I know they don't apply to my current project (i.e. it's a C# project and I don't want JS extensions running).

Maybe it would also be good to provide a better way to notify users of recommended extensions for this workspace, because the current one relies on users specifically going into the extensions tab and opening the recommended section (which, like I said, from my experience almost never happens).

[TriMoon]

Request renewed #91885

[TriMoon]

@sandy081 what is taking so long to implement the functionality to disable extensions from a workspace config file?
You already have the functionality to disable per workspace, you just need to save and load the setting from the workspace config file instead of the internal cache/state or whatever you are using...
I honestly DON'T understand why it is being held back for so long...

[sandy081]

Definitely because of other high priority stuff.

[obedm503]

@TriMoon you could always submit a PR

[TriMoon]

@obedm503

@TriMoon you could always submit a PR

Sorry but i am already over my ears in aiding other non-profit projects...

[AdamJel]

Hi @sandy081 any update on this?

This seems to be troubling a lot of people (lot of duplicate issues, lots of comments). It also seems, that there is some resistance from vscode developers side - lots of counter-comments disagreeing with the need of code based definition of enabled/disabled extensions, whilst it seems to be the only correct way to treat extensions in the same manner as all '<fill_word> as a Code' best practises. It is actually a lot unintuitive, that I can not define enabled/disabled extensions in .code-workspace settings.

So, let me ask, just for clarification of vscode-developers point of view:
Do we agree, that there is a need for disable-by-default-all-extensions in settings.json AND enable-per-extension in .code-workspace settings?
And it is on your to-do list, you just work on more high-priority stuff first?

Thank you for clarification and all the great work on vscode so far.

[sandy081]

Sorry 😐 , no updates unfortunately.

[dantman]

IMHO bad extensions (like the suggestion of the Angular one slowing down React projects) should be fixed rather than disabled by the workspace.

The linter and formatter issues should be fixed with settings. i.e. A workspace setting declaring what formatter/linter to use or whether it should be enabled.

I am in favor of a way to add workspace settings recommendations to source control.

That solves other issues beyond just disabling a few troublesome extensions:

• I can recommend an extension for editing i18n files, but I can't recommend a configuration for it to find the files and know what format they are in.
• I can recommend the user install the BitBucket+Jira extension but not recommend which parts should be enabled/disabled in the current project
• I can use something like Prettier, but I can't recommend vscode indentation settings for the correct indentation for new files without something external like setting up EditorConfig, even though the indentation settings are already there
• I can fix the setting that makes "Optimize Imports" strip the space Prettier puts in between the import { ... } brackets, but I can't share that with the rest of my team
• etc

[heartacker]

I want to disable some extensions in some of my team workspace because those extensions have performance problem(or other issues). I hope that I can add the disable setting to vscode-workspace file to disable for those team mates. just like I can recommend extensions.

and teammates should show a message that settings want to disable those extension? YES/NO. Just like recommend

[zeeforum]

Hi,

I have an idea that is easy to implement for you, I think.

I also faced the issue to enable recommended extensions for my Workspace. I work on different technologies according to which I have to switch to different environment. For that I need to disable and enable some extensions.

The idea is simple.

• You can do: create a button in extensions menu below "Enable All Extensions" for "Enable Recommended Extension for this Workspace".
• You can check whether a user have installed recommended extension or not and enable those which were installed.
• A button for "Disable Extension Those Not Recommended", through this user can disabled all the extension which is not recommended.

I think it's simple to implement.

Thank You
Regards:
Zartash

[astrolemonade]

Hi @sandy081 any update on this?

[mayrholu]

Our company works in an enclosed environment so we provide vscode with several pre-installed extensions to our users. In the case of python we have pylint, flake8 and ruff as possible linters. So far one could just toggle the extensions "python.linting.pylintEnabled": true entry in .vscode/settings.json. With the python extension about to drop linters/formatters and move them to separate extensions this option will no longer be available. Having the enabled/disabled state in a file would really help!
SO PLEASE @sandy081 can you give this a higher priority? Thank you!

[TriMoon]

Looking at the age of this issue, with no fix yet, (Jan '17 that's 6½ years back now)

• Until this M$ owned project reinvents the wheel that has been working in the Linux community with package managers for decades which all implement dependencies and conflicts.

I think it is best to advise that people use a different IDE/Editor instead of this M$ one.
It ain't that hard to find good alternatives to this editor.
i'm already using a free alternative for years now...
🖖

[vscodenpa]

We closed this issue because we don't plan to address it in the foreseeable future. If you disagree and feel that this issue is crucial: we are happy to listen and to reconsider.

If you wonder what we are up to, please see our roadmap and issue reporting guidelines.

Thanks for your understanding, and happy coding!

[IronGeek]

And... All it took was 7 years to conclude that this feature is out-of-scope... 😮‍💨

[aranda-adapptor]

This is a pity. The rise of AI assistant extensions highlights another reason to have this feature. Our company is a consultancy/agency that uses VSCode almost exclusively. We're rolling out the use of Copilot and hence our devs will all have the extension installed and enabled by default. The problem occurs because some clients have explicitly disallowed the use of AI assistants. Without the ability to blacklist the Copilot extension in the workspace, we run the risk of developers forgetting to disable it, and having to remember to disable/enable it when they switch between projects.

I don't agree with the argument that extension blacklisting should not be implemented because "the list is open ended and it cannot be complete". Yes, we cannot guarantee our developers won't be using other disallowed extensions, but we can disable the ones we know we do commonly use. A useful feature shouldn't be ignored just because it isn't perfect.