-
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
Allow specifying a version for workspace recommended extensions #138048
Comments
I would also like to have this. We have a large monorepo and a new release of the GitLens extension caused ssh to hang and also introduced "premium" features that we don't want and also managed to automatically install another extension! It's difficult to ask everyone to manually go to the extension and "Install another (older) version". Being able to specify a version would fix this issue. |
This is also important for us. As there's a bug in the Azure Account extension (see here) we can only use up to 0.9.11 |
This is very problematic when tools like your own
|
+1 for this |
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! |
@isidorn How exactly is this out of scope? |
I think we can ask https://marketplace.visualstudio.com/items?itemName=GARAIOAG.garaio-vscode-unwanted-recommendations to support it.(Created by @Cyclodex) |
Given even some MS extensions break every now and then and take very long to recover (e.g. microsoft/vscode-remote-release#8157) this (specifying a version range) would be a very valuable addition. |
I cannot provide anything new except that we rely on an extension that breaks in our usecase when using the most recent version - please reconsider @sandy081 @isidorn This goes exactly against the spirit of what i'm trying to evangelize for at work - pinning sdk versions and tooling to make changes to our work environment an explicit change at every opportunity to control these things - may it be global.json, csprojs, package.json. Given we already have the option to switch to a different extension version i dont think this would be much of a hassle to implement - the ideas brought forth here regarding the version strings á la package.json already fit well into the picture and it could be implemented without breaking by defaulting versionless strings to the latest version. I would really like to have a conversation here. |
My specific use case is regarding We're considering dev-containers for this and other projects which thankfully allow us to recommend extensions for the VS Code server. But the latest version of these extensions are installed after confirming the prompt which itself only shows after confirming and opening the workspace once attached to the container (due to microsoft/vscode-remote-release#3665 which is preventing opening workspaces directly). Essentially, this presents a really poor developer UX which could at least be made partially better if this process didn't have to be followed up with rolling back an extension version.
Three steps - and possibly more with time - could be avoided by supporting the ability to specify recommended versions for recommended extensions. Please reconsider support. |
Please consider supporting pinning versions in workspace recommendations. My team is using an extension which pairs with a python package. The extension frequently (but unpredictably) drops support for older versions of the python package and everyone's editors break until we coordinate to upgrade the python package. I think one of the following syntaxes may be friendlier to opt-in than OP's {
"recommendations": [
"ms-python.python", //latest
"ms-python.python@2022.0.0", //with version suffix
{
// as dictionary
"id": "ms-python.python",
"version": "2022.0.0"
}
]
} |
Let's discuss it over here Cyclodex/vscode-unwanted-extensions#1 I already added some ideas and made some changes/progress. |
I think this issue should be reopen, i use flake8 extension for my repo, but after update version it no longer support python 3.7, so i need feature to add extension version for recommendation Related to this issue microsoft/vscode-flake8#219 (comment) |
I agree. I believe this issue may cause problems on long(er) term. Version control is also about the ability to maintain existing software versions. |
This ability is important. Please reopen it and get it done. |
Has there been any reasoning for why this is not being considered by the VS Code team? |
This functionality is essential for working with legacy codebases, especially now that the official Python plugin has dropped support for versions older than 3.8. |
The ability to pin a version of an extension has recently been added to VSCode. I wrote about how it works in an article: |
@mslinn that does not solve this issue. |
Please consider supporting pinning versions in workspace recommendations as this functionality is essential for working with legacy codebases. |
Hi all, current possible workaround suggestion: I just published a pre-release of my extension "Unwanted Extension", where you can also define version numbers, in addition to the extensions. The extension will bring you a notification, if the "unwanted extension" is installed & enabled. The latest pre-release, does support version definitions (SEMVER) where you can define the version ranges which should throw a warning. (Make sure you install the "pre-release" (1.1.1), not the "Release version". Feel free to report issues or further ideas here: https://github.com/SoulcodeAgency/vscode-unwanted-extensions Cheers |
Related on Stack Overflow: VS Code file .vscode/extensions.json select custom version of one extension |
Just to say "me too!" and display my usecase: I need to connect and develop in an old Red Hat machine. I don't have authority to upgrade this machine. Latest VS Code complains that link to the C++ libraries, so I must use an old VSCode and fix the version of the Remote SSH extension I also has an old unsupported Python. Python extension must be an old one to work with it. Latest Python extension uses extensions to format and lint my code. I also must fix pylance version to work with it. Now I have an wiki page so all developers of my team can develop in a sane enviroment. Some of them don't bother and commit unformatted and unlinted code. Its hell. |
Reopening to see if we can plan to support this. Thanks everyone for your feedback |
This is really esstienial! |
I consider this essential. Partly because in my case I'm maintaining a legacy codebase, but mostly because of VSCode extensions themselves. My scenario:
Anyone understands that this won't be solved with a memo on general slack channel. If I cannot set a version in the recommended extensions, engineers are going to be pushing non-compliant formatting and we're gonna keep having merge conflicts in every rebase. Given my experience, I would say this is a requirement for developer teams. I really love VSCode and want the experience it offers to be as holistic as possible. |
+1 |
Some extensions just break functionality on latest - this has happened twice for us even on fairly notable extensions. |
Sometimes we have this issue where a certain extension which the project depends on gets a new release which breaks the extension or other related tooling; we can fix the issue by manually rolling back the version.
It would be nicer if the
extensions.json
, which allows us to set recommended extensions for the workspace/project, would allow us to also pinpoint a specific version of the extension. Even better if this allows us to use semver ranges!The actual
extensions.json
:The proposed version:
The text was updated successfully, but these errors were encountered: