mirror of
https://github.com/microsoft/vscode.git
synced 2026-08-14 09:45:55 +01:00
179db2cbb5
* fix(server): propagate --enable-proposed-api in serve-web 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 #228781 * cli: forward --enable-proposed-api to serve-web subprocess The Rust CLI parses --enable-proposed-api as a global EditorOptions flag but was not forwarding it to the node server subprocess spawned by serve-web. As a result, the flag never reached the server's argv parser and the server-side plumbing in serverServices.ts and webClientServer.ts had no input to act on. Capture the flag in ConnectionManager from CommandContext and pass it through StartArgs, then append --enable-proposed-api=<id> for each requested extension ID when spawning the server process. * fix(server): update proposed API propagation Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> --------- Co-authored-by: Martin Aeschlimann <martinae@microsoft.com> Co-authored-by: Dmitriy Vasyura <dmitriv@microsoft.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>