-
Notifications
You must be signed in to change notification settings - Fork 28.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature Request: Enable/disable extensions from config file #40239
Comments
We can re-use the existing extensions.json file for this. Currently the json file looks like this:
We could have new entries in this json file like
All installed extensions would be enabled by default. If there is an entry like the above, then they would be disabled. When user clicks on the Currently we store the list of disabled extensions for each workspace in local storage. @sandy081 Thoughts? |
@ramya-rao-a Extensions recommendation file is meant to be shared (in team). Disabling and enabling extensions is user specific. Merging these two is not a good idea I guess. |
This could be merged with #48743, in that we can prompt a user to enable and disabled extensions which have been marked as recommended, and prompt the user to disable any enabled extensions marked as unwanted. This could be saved per workspace. The control would still be at the hands of the user to accept/reject/permanently ignore those prompts. It could end up with a similar feel to the existing prompt to install recommended extensions, where the team suggests the user do something, but the user is at liberty to ignore those suggestions. |
I think this could be useful, as in large team projects, this would allow to have a different but consisten configuration across all the projects inside an organization. |
I would personally prefer to have a whitelist, not a blacklist, of extensions for a particular workspace. The reason is I might add extensions to Code later and I don't want to go to every workspace and explicitly disable that extension. On top of that, if some extension is disabled and I don't have it installed, no action is required :) I would really like to see this feature implemented. My VS Code has tons of extensions, but some projects use only a small slice of those, so I don't see a reason why they should be enabled and slow everything down/create unnecessary cognitive load. |
@jankalfus I read somewhere that VSCode only loads the extensions that it needs, so having then installed and enable should not slow down your editor if you are not using it, but maybe this can be clarify by the team. |
@michaeljota I would also expect it to work like that, but I remember the C# extension complaining on every VS Code start that it needs to download some files for code completion or something. It didn't matter which project I opened (plain JavaScript). This might have been fixed though, I haven't been using Code for about 6 months, just got back to it a few days ago :) |
@jankalfus Well, yeah, I remember that. But I think that's only the first time it updates or something like that. Like I said, maybe the team can explain a little bit about how/when the extensions are actually being used. |
Each extension declares when it should be activated by VS Code. See Activation Events |
I know you can disable an extension in a Workspace, what I'm asking is a file to do this automatically. |
@michaeljota Just want to understand what is the use case to have this in a file? |
From @FancyBanana Currently it seems that information about which extension is enabled/disabled is stored globally. |
@FancyBanana I think your request is for synchronising workspaces? |
@sandy081 No, my idea is pretty much creating another .json config file inside .vscode folder that overrides enabled/disabled state of extensions. Also a good point form @burtek:
|
@FancyBanana creating a file under |
@sandy081 I understand that there are limitations to what additions we can make to the vscode architecture (even though I don't know the nature and extent of these limitations), therefore I would like to propose a solution that works with the existing implementation of workspace specific enabling/disabling of apps. Why don't we implement a new command that you can run from the command pallete called:
This command should:
The workspace specific settings would still be stored in local storage where it is currently stored. Just the manipulation of those settings would be automated by a command that takes the already existing extensions.json file as input, thereby adding a secondary purpose/utility to it without introducing side effects, because the command has to be explicitly invoked by the user. This would make the recommended extensions feature more complete, because it also provides a convenient way to accept these recommendations. This command should not automatically install recommended extensions found in ".vscode/extensions.json", though, which is not always desirable, but for those that also wish to install extensions that are not yet installed, that could become a separate command too called:
This command should:
Implementing these commands would allow for a workflow where developers have template extensions.json files that they can copy into their respective workspaces, then run at most two commands (which they could even make into an initialization build task) and then be completely set up to work on their desired project. We could even create commands like: Which would allow developers to create and browse through a list of recommended extensions templates for the extensions.json file. These templates would also be saved in local storage. It could look something like this dropdown list where templates are user created:
Sorry if perhaps this comment is a bit lengthy. Bolding is added to highlight, not to shout. |
I'd love this feature implemented and for me it would definitely be to sync workspaces: I use multiple machines for my work, I can already sync installed extensions and a number of config settings using dedicated extensions (e.g. shan.code-settings-sync) but if I want to disable some extensions in specific workspaces then I have to manually replicate the configuration across all machines |
This is basically a good idea, but in my opinion doesn't solve the underlying problem, since it would presumably work in a global, and not in a workspace specific fashion. Using the example above, i would want to use |
I don't really understand this reasoning. Installing and enabling extensions is also "user specific", yet workspaces can advertise extensions, which are recommended to be enabled, with Why not let them also advertise extensions, which are recommended to be disabled with These are 2 sides of the same coin - both might be required for a workspace to work correctly, and both need to be "shared (in team)" for developers to work efficiently and without problems. I would solve this exactly the same way as If this: // .vscode/extensions.json
{
"recommended": [
"Vue.vscode-typescript-vue-plugin"
]
} Why can't this: // .vscode/extensions.json
{
"incompatible": [
"vscode.typescript-language-features"
]
} ...result in this: ? Now if you have both in your To again illustrate the demand for such a feature:
|
I really don't get why some people in this thread try to engineer this "incompatibility" feature like it's a whole new thing all the while everyone else just want's the same behavior that the "recommendations" feature already has. There's absolutely no reinventing the wheel needed here, we want the same thing we already have, but negated. @codeflorist even took the time to mock screenshots to explain it. Can we please have it now? |
I guess, at the time of issue creation, this is for user's convenience. Even if some plugin enabled on local, there's no much problem. (If you use some 3rd party's auto uploading plugin, it's on you.) But now MS has been created some uploding plugings officially (e.g. copilot). This will send data automaticaly if vscode enabled already. If user has some secret data in workspace, it may be sent. Why copilot plugin does not support ignoring list file in local yet and not about disabling plugin feature of workspace too. |
How is the requested feature related to co-pilot? This is just about giving a recommendation to the user about how to change their local project settings to have a better developer experience. They can accept it or they can deny it. Easy as that. It's not different from them making the changes themselves, just that we would improve DX by giving the recommendation so they don't neet to skim through the docs. |
Everyone : I promise not to mention or refer to the P word anywhere in this post. 🤣
Needs refinement because
Suggestions and new attempt at resolving this ticket
In practical use, on first encountering a project with such a config file, the developer will install whatever extensions are required, create a workspace for the project, then reload the project and accept the must_disable directive for other extensions. After that, subsequent loads should not require any new action unless the local configuration changes. Implementation
SummaryThis doesn't do anything new, doesn't modify existing files, doesn't require schema changes, doesn't require new design, doesn't have scope outside of initialization. This could probably be done with an extension. With the exception of a one-time common effort by the developer, I don't believe this imposes special effort on anyone who produces or consumes FOSS, and I believe it addresses all use cases described so far in this thread. Arguments againstIt requires the developer to do something.Yes, automatic installation or deactivations are a non-starter for most environments. This defines a configuration file that requires a one-time effort that everyone here is familiar with, and it's automated from then-forward. The developer may need to manually install extensions.Yes. The tooling can never install or unstall extensions for the user/developer, as this could lead to abuse or confusion. The ticket is about enabling and disabling, not installation or removal. It allows developers to use forbidden extensions.The user/developer should be allowed to continue however they wish with the project. The environment should never prohibit forward movement if the user doesn't accept a mandate. Each time the developer loads the project without environment compliance, they will get the same warnings. The developer could be forking, re-purposing, testing other extensions, or doing something else that the project leader is not aware of. It allows developers to PR incompatible code.Deal with this procedurally like any linting issue. Warn or terminate employees, stop processing PRs from non-compliant contributors. |
Hi all again. I am following this thread a long time already, and I made once an extension which tries to solve some of the problems we mention in here. The extension Unwanted Extensions, allows you to save "unwanted" Extensions, as recommendation. Basically the same, what VSCode already supports for recommendations, just the other way around. It will trigger a warning, if you have one of the unwanted extensions, but it doesn't enforce the user to disable it, just helping guide him. The latest feature I have added allows to define SEMVER ranges for matching version numbers on packages, you don't want as I heard some people do need to define only some versions as deprecated and not the complete extension. Feel free to check out my extension over here and help further improve it, until MS will set some new priority to fix this endless thread once. (It doesn't look like this will be part of the roadmap soon if I understand correctly)... :( Extension |
I don't deny your opinion and don't say unrecomended message feature is useless. I wish this too and it's easier request. e.g. Around 2018 comments too, they want to disable extention to ignore some initialize process. I understand that you are frustrated that simple things are not being implemented. But take it easy. |
Well true. Then we should either split this issue up or just start with the easiest implementation (giving a recommendation) and see how people respond. |
As for me, a recommendation would be an unrelated feature request. For my use cases, I need to have a precise specification per workspace which extensions to keep on/off (preferably, "off" is specified in the user config file for most of the extensions, whereas the workspace configuration selectively enables applicable extensions). For a dozen or two of workspaces that I open and close like 20 times a day, I wouldn't like any pop-up dialogs to confirm that I really want what I configured. Overall, the recommendations are very much orthogonal to enables/disables:
P.S. No, profiles do not fulfill our needs in the company. :-) We need versionable text-based configuration files. Specifically, the user's settings.json and the workspace-specific *.code-workspace. |
@l-inc profiles can be exported to JSON or GH Gist, and you can store the exported thing in the workspace folder... |
@starball5, sorry, let me correct myself. No, profiles do not fulfill our needs in the company because we need versionable text-based configuration files [1]. And exported profiles do not fulfill our needs because then they have to be manually re-applied after every update. [1] Specifically, the user's settings.json and the workspace-specific *.code-workspace. |
I have a feeling this thread is being pushed too much in the "disable extension X" or "mark extension Y as incompatible" direction. This is a blacklisting approach and it does not work because the list of things you don't want is much longer than the list of things you want. What matters to many people following this thread is the following:
The problem/use case is the following (giving examples from my work so as to make it concrete): We work with Vue (Vuetify and Quasar), React, Laravel (Livewire and Inertia), and Nuxt. Sometimes using Tailwind, sometimes not. Each of these requires different extension combinations, different code formatters, different testing extensions, etc. On top of that, every dev in the world experiments with other frameworks and programming languages, which require their own extensions too. The result is an absolute pile of extensions installed on the machine, but each workspace/project only uses about 25% of those extensions. The others either:
Profiles do not solve the problem, because they need to be manually imported, installed, and switched whenever a different workspace is opened. Recommendations do not work because they only increase the pile of installed extensions. Manually "disable extension X in this workspace" does not work because it is unreasonable to manually enable/disable 75% of extensions every time a workspace is created. That is why this issue exists: To address this far too common use case. |
@eta-orionis: this is a very good summary of the issue. Thanks! |
Funny enough, I got a message the other day in VS Code from the Volar extension telling me I no longer need to disable the Typescript extension so I think half of us can put down our pitchforks :D |
@dkattan yeah I'm subscribed to the extension deprecation discussion, so I saw microsoft/vscode-discussions#1 (comment), and thought of the many people here who had that use case. |
This message confused the hell out of me some days ago. It is a great example how it should not be done. Because if I disable the extension as recommended, something else triggers another popup that recommends that the extension should be enabled. So another race condition about who's right. On top of that, the Vue docs on that matter are not up to date (that can't be blamed on VSCode though :-D). |
My use case is efficiently toggling LSP used for a specific language, in this case C++ where I want to easily toggle between clangd and vscode-cpptools. I want to be able to create a task that disables one and enables the other + also in the same task change the current c_cpp_properties config used, one set up for vscode-cpptools usage and one for clangd. |
I'm running into a similar issue as mentioned earlier. In our React-Native project we're using ESLint for code formatting and don't want to use Prettier. If the Prettier extension is installed, it will start formatting files. The Workarounds like using a shared profile or additional extensions to manage extensions are not a proper solutions. If the developer has to take manual action, it is not a matter of if things will go wrong, but just when things will go wrong. |
I can provide another example of when disabling extensions per-project will be really benefitial: We working on monorepo with: nestjs, vue, where some vue projects using tailwind and others vuetify. Like main site is in vue with tailwind and admin interface using vue and vuetify. I dont need tailwind autocomplete when working on admin interface and i dont need nestjs support when working on frontend. So opportunity to disable some extensions when i working on files in specific subdirectories and be able to share that across the whole team is really something that could help. |
When developing a Vue project, I encountered the issue shown in the screenshot. Vue plugins are incompatible with Deno plugins, Lit plugins, and Svelte plugins. In scenarios where multiple people are collaborating on this Vue project, it would be very convenient to disable the Deno, Lit, and Svelte plugins via a configuration file. |
For the record, the new feature of Local workspace extensions may appear useful as a workaround for some here. In particular, it can be misused as follows:
This is likely not how the developers meant the feature of "Local Workspace Extensions" to be used, but this roughly meets the requirement to enable the extensions using a configuration file. Unfortunately, the developers solved one problem (workspace-specific extensions) by introducing another one (security issue due to the extensions being supplied from unverified repositories), which they in turn solved by making such extensions a kind of recommendations (instead of just running them), which in turn brings us back to the original problem: the setup will require manual interaction instead of just working out of the box. The effort of this interaction can be kept low, but putting these extensions under recommendations creates interference with other expectations. In particular, we prefer to use "extensions.ignoreRecommendations": true and even "extensions.showRecommendationsOnlyOnDemand": true . The former suppresses the notification, and the latter hides the desired local workspace extensions from the "Extensions" sidebar. |
Such ability would resolve my question of setting up rapidly created projects. Setting up a single workspace and then simply cloning it will be sufficient to start working on a new lesson without much fiddling. |
I really appreciate all the effort that tries to tackle this issue through extension, I've tried going the same route before too and come to a conclusion:
An extension should not have the capability to enable/ disable another extensions. So I kinda agree that exposing API such as #201672 should not be supported. Imagine if such API is actually supported: What if we ended up with an extension that forcefully enable/ disable some extensions and we want to (forcefully) enable/ disable that extension (or some extensions it enable/ disable)? should we make/ install yet another extension to enable/ disable said extension? ... |
When I converted the VSCode profile file to JSON, I received the following error:
I verified the code and saw that it failed with |
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.
The text was updated successfully, but these errors were encountered: