Skip to content

fix(server): propagate --enable-proposed-api in serve-web#310207

Open
yogeshwaran-c wants to merge 1 commit intomicrosoft:mainfrom
yogeshwaran-c:fix/serve-web-enable-proposed-api-228781
Open

fix(server): propagate --enable-proposed-api in serve-web#310207
yogeshwaran-c wants to merge 1 commit intomicrosoft:mainfrom
yogeshwaran-c:fix/serve-web-enable-proposed-api-228781

Conversation

@yogeshwaran-c
Copy link
Copy Markdown
Contributor

What this PR does

Fixes #228781

The code serve-web CLI accepts --enable-proposed-api EXTENSION_ID but never propagated the allowlist to the workbench environment service or the server-side extension scanner. Extensions declaring enabledApiProposals in their package.json therefore had their proposals wiped at runtime by ExtensionsProposedApi and failed to activate with:

Activating extension 'publisher.myextension' failed: Extension 'publisher.myextension' CANNOT use API proposal: chatParticipantPrivate.
Its package.json#enabledApiProposals-property declares:  but NOT chatParticipantPrivate.

Approach

This wires the flag through two paths so it matches desktop behavior:

  1. Server scanner (src/vs/server/node/serverServices.ts): extend IProductService.extensionsEnabledWithApiProposalVersion in setupServerServices so the node extension scanner (AbstractExtensionsScannerService) keeps the manifest's enabledApiProposals when --enable-proposed-api is passed.

  2. Workbench environment service: add a new enabledExtensionProposedApi field to IWorkbenchConstructionOptions, populate it from the CLI args in webClientServer.ts, and surface it via BrowserWorkbenchEnvironmentService.extensionEnabledProposedApi so the runtime allowlist in ExtensionsProposedApi matches the requested extension IDs.

The existing productConfiguration.extensionsEnabledWithApiProposalVersion propagation in webClientServer.ts is preserved — that field is still needed by the browser-side webExtensionsScannerService for web extensions.

Repro / verification

  1. Install an extension declaring "enabledApiProposals": ["chatParticipantPrivate"] in its package.json.
  2. code --enable-proposed-api="publisher.myextension" serve-web --port 11001 --without-connection-token --accept-server-license-terms
  3. Open the browser URL — extension activates without the proposed-API error.

Without this PR the activation fails as in the issue. With this PR it succeeds, matching the behavior of code desktop with the same flag.

The `code serve-web` CLI accepts `--enable-proposed-api EXTENSION_ID`
but never propagated the allowlist to the workbench environment service
or the server-side extension scanner. As a result, extensions declaring
`enabledApiProposals` in their package.json had their proposals wiped
at runtime by ExtensionsProposedApi and failed to activate.

This wires the flag through two paths so it matches desktop behavior:

1. Server scanner: extend IProductService.extensionsEnabledWithApiProposalVersion
   in setupServerServices so the node extension scanner keeps the manifest's
   enabledApiProposals when --enable-proposed-api is passed.

2. Workbench env service: add a new `enabledExtensionProposedApi` field to
   IWorkbenchConstructionOptions, populate it from the CLI args in
   webClientServer, and surface it via BrowserWorkbenchEnvironmentService
   .extensionEnabledProposedApi so the runtime allowlist in
   ExtensionsProposedApi matches the requested IDs.

Fixes microsoft#228781
@vs-code-engineering
Copy link
Copy Markdown
Contributor

📬 CODENOTIFY

The following users are being notified based on files changed in this PR:

@bpasero

Matched files:

  • src/vs/workbench/browser/web.api.ts
  • src/vs/workbench/services/environment/browser/environmentService.ts

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

code serve-web ignores the --enable-proposed-api flag

2 participants