Keep the E2E state file bridge out of production extension builds

[Adam Ratzman (adamint)]

Description

extension/src/testing/e2eStateFileBridge.ts is a test control channel. It registers a wildcard debug adapter tracker factory and executes commands read from a file whose path comes from an environment variable. extension.ts imports it unconditionally and webpack.config.js had no build-time gate, so the entire channel was bundled into the published VSIX and gated only at runtime by ASPIRE_EXTENSION_E2E_ENABLE_BRIDGE.

This replaces the bridge with a no-op stub in production builds using NormalModuleReplacementPlugin, so the code is not present in the shipped bundle at all.

vscode:prepublish runs webpack --mode production and vsce package runs vscode:prepublish, so every packaging path gets the stub. yarn compile (mode none) and yarn watch keep the real bridge, so local development and the E2E runner are unaffected.

NormalModuleReplacementPlugin is used rather than DefinePlugin plus dead code elimination because dropping the module through tree shaking would require adding a sideEffects declaration to package.json.

Validation

Verified with three real webpack builds, counting bridge-only symbols in the emitted dist/extension.js:

build	proveMauiResourceDebugging	stoppingPathEvents	atomicWriteSequence
stock config, --mode production	1	1	present
gated config, yarn package	0	0	0
gated config, yarn compile	3	6	2

getResourceDebugProofRequest and clipboardExpectation are also 0 in the gated production bundle.

From extension/:

yarn run compile-tests   Done in 2.96s
yarn run lint            Done in 3.68s
yarn run unit-test       1458 passing, 4 pending, 0 failing

The new unit test was negative-tested in both directions: breaking the replacement pattern and removing an export from the stub each produced a failing assertion naming the specific problem.

Checklist

• Is this feature complete?
  • Yes. Ready to ship.
• Are you including unit tests for the changes and scenario tests if relevant?
  • Yes
• Did you add public API?
  • No
• Does the change make any security assumptions or guarantees?
  • Yes
    • If yes, have you done a threat model and had a security review?
      • No. This removes an unnecessary surface rather than adding one, so no new assumption is introduced.

[github-actions]

🚀 Dogfood this PR with:

⚠️ WARNING: Do not do this without first carefully reviewing the code of this PR to satisfy yourself it is safe.

curl -fsSL https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.sh | bash -s -- 19147

Or

• Run remotely in PowerShell:

iex "& { $(irm https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.ps1) } 19147"

[Copilot]

Pull request overview

Prevents the E2E control bridge from shipping in production VS Code extension bundles.

Changes:

• Replaces the bridge with a production-only no-op module.
• Preserves the real bridge for development and E2E builds.
• Adds focused configuration and export compatibility tests.

Show a summary per file

File	Description
extension/webpack.config.js	Adds production module replacement.
extension/src/testing/e2eStateFileBridge.production.ts	Provides the no-op production implementation.
extension/src/test/e2eBridgeProductionGate.test.ts	Tests build-mode gating and stub compatibility.

Review details

• Files reviewed: 3/3 changed files
• Comments generated: 0
• Review effort level: Balanced

[github-actions]

Retrying the failed CI jobs for this pull request from the CI run attempt. The rerun is being tracked in the rerun attempt.

[github-actions]

Retrying the failed CI jobs for this pull request from the CI run attempt. The rerun is being tracked in the rerun attempt.

[github-actions]

Retrying the failed CI jobs for this pull request from the CI run attempt. The rerun is being tracked in the rerun attempt.

[Copilot]

Review details

• Files reviewed: 3/3 changed files
• Comments generated: 0 new
• Review effort level: Balanced

[github-actions]

Retrying the failed CI jobs for this pull request from the CI run attempt. The rerun is being tracked in the rerun attempt.