Allow specifying a version for workspace recommended extensions

[sullyD64]

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:

{
  "recommendations": [
    "johnsoncodehk.volar", // always the latest version
  ]
}

The proposed version:

{
  "recommendations": {
    "johnsoncodehk.volar": "0.29.6",
  }
}

[jcready]

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.

[roldengarm]

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

[n3rdyme]

This is very problematic when tools like your own ms-dotnettools.csharp drop support for, or require newer version of, frameworks to be installed. Please allow either the recommended approach above or consider the following:

{
  "recommendations": [
    "ms-dotnettools.csharp@v1.24.4"
  ]
}

[ghaschel]

+1 for this

[VSCodeTriageBot]

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!

[KholdStare]

@isidorn How exactly is this out of scope?

[johnsoncodehk]

I think we can ask https://marketplace.visualstudio.com/items?itemName=GARAIOAG.garaio-vscode-unwanted-recommendations to support it.(Created by @Cyclodex)

[CaringDev]

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.

[MeikTranel]

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.

[ccampanale]

My specific use case is regarding nrwl.angular-console; an Angular project which my team collaborates on is not remotely prepared to move this codebase to use NX Workspaces but the latest extension (v18+) requires it. Setting the extension version to the latest version of v17 allows us to continue to use this very helpful extension and follow our documented development SOPs.

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.

1. Launch dev container (build and attach using task).
2. Confirm the prompt: "This folder contains a workspace file. Do you want to open it?"
3. Confirm the prompt: "Install recommended workspace extensions?"
4. Open extensions
5. Locate NX Console
6. Install previous 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.

[AlexCLeduc]

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"
        }
    ]
}

[Cyclodex]

I think we can ask https://marketplace.visualstudio.com/items?itemName=GARAIOAG.garaio-vscode-unwanted-recommendations to support it.(Created by @Cyclodex)

Let's discuss it over here Cyclodex/vscode-unwanted-extensions#1

I already added some ideas and made some changes/progress.

[pipinfitriadi]

@sandy081

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)

[marcel-22]

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.

[mslinn]

This ability is important. Please reopen it and get it done.

[uditrana]

Has there been any reasoning for why this is not being considered by the VS Code team?

[andyn]

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.

[mslinn]

The ability to pin a version of an extension has recently been added to VSCode. I wrote about how it works in an article:
https://www.mslinn.com/ruby/4600-vscode-ext-jekyll.html#dbgprob

[jcready]

@mslinn that does not solve this issue.

[rhaladej-cen55759]

Please consider supporting pinning versions in workspace recommendations as this functionality is essential for working with legacy codebases.

[Cyclodex]

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.
There is no automatic "disable" functionality possible in VSCode right now, AFAIK.

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".
More information in the extension description.

Feel free to report issues or further ideas here: https://github.com/SoulcodeAgency/vscode-unwanted-extensions

Cheers

[starball5]

Related on Stack Overflow: VS Code file .vscode/extensions.json select custom version of one extension

[paulobndes]

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.

[sandy081]

Reopening to see if we can plan to support this. Thanks everyone for your feedback