[Feature Request] Allow SemVer version definition for "wanted" Recommendations

[senhalil]

MS is dragging their feet on this issue microsoft/vscode#138048

Would it be apply the semver logic to the Recommendations field and warn the user?

[Cyclodex]

Thanks for raising this — we looked into it properly.

First, the status upstream: microsoft/vscode#138048 was closed as *out-of-scope, not left pending. So there is no VS Code-side fix coming, which removes the main reason for us to wait. We're planning to implement this.

Approach

The id@range parsing and semver matching already exist for unwantedRecommendations, so most of the machinery is in place. Two things make recommendations different rather than a copy-paste:

1. The logic is inverted. For unwantedRecommendations, matching the range is the problem. For recommendations, the range describes the version you want, so not matching is the problem.

2. Ownership of the config field. We currently read both .vscode/extensions.json and .vscode/extensionsVersionCheck.json(c) and merge them. That is fine for unwantedRecommendations, since VS Code accepts the field but does almost nothing with it. It is not fine for recommendations, which VS Code actively owns and acts on — acting on those entries ourselves would duplicate VS Code's own recommendation prompt for every project that has a normal extensions.json.

So the split will be file-based:

• unwantedRecommendations — read from all config files, unchanged.
• recommendations — read only from our own .vscode/extensionsVersionCheck.json(c), not from extensions.json and not from the *.code-workspace extensions block.

Putting a version into VS Code's own extensions.json would not work anyway: publisher.name@^1.0.0 is simply an unknown extension id to VS Code, producing a dead recommendation. Keeping versioned recommendations in our file avoids that entirely, and mirrors the copy/paste migration the README already describes for unwantedRecommendations.

Notification noise

Warning on every violation is only reasonable if a developer can dismiss a warning they have consciously accepted. That is being split into a separate issue: #19. With that in place, the plan is to notify on any rule violation, for both wanted and unwanted extensions.

Known caveats

• We cannot distinguish "not installed" from "disabled for this workspace". The VS Code API only exposes enabled extensions. Messages will be worded to reflect that ambiguity rather than asserting either.
• Invalid ranges need explicit validation. semver.satisfies() returns false for a malformed range instead of throwing. Under the inverted logic that would turn every typo into a bogus warning, so ranges and versions will be validated up front and reported as config errors in the log instead.
• Caret ranges and VS Code pre-releases. VS Code extensions mark pre-releases with an odd minor version rather than a semver pre-release tag, because the marketplace only accepts plain x.y.z. So @^1.0.0 will happily match 1.1.7, a pre-release build. We'll document pinning the even minor (@~1.2.0, or @>=1.2.0 <1.3.0) as the safe pattern.