Skip to content

fix(vscode): prefer the live dev sidecar over a stale bundle in dev mode#71

Merged
matze4u merged 1 commit into
mainfrom
fix/v1-0-vscode-dev-sidecar-path
Jun 3, 2026
Merged

fix(vscode): prefer the live dev sidecar over a stale bundle in dev mode#71
matze4u merged 1 commit into
mainfrom
fix/v1-0-vscode-dev-sidecar-path

Conversation

@matze4u

@matze4u matze4u commented Jun 3, 2026

Copy link
Copy Markdown
Contributor

Problem

resolveSidecarPath returned the bundled sidecar/server.js whenever it
existed, falling back to the dev path only if absent. In development
(task vscode:run--extensionDevelopmentPath) this means a stale
bundle
from an earlier vscode:package shadows the live
packages/core/dist/server.js:

This caused real confusion this session — a stale Jun-1 bundle ran
instead of the current build.

Fix

When context.extensionMode === vscode.ExtensionMode.Development and the
dev path exists, prefer it. A packaged VSIX has no dev path, so it still
uses the bundled sidecar (ADR-017) — production behaviour is unchanged.

Verification

  • clients/vscode typecheck + eslint + prettier + build all green.
  • Production path unchanged (no dev path in a VSIX → bundle, as before).

`resolveSidecarPath` preferred the bundled `sidecar/server.js` whenever
it existed, so in development (`--extensionDevelopmentPath`) a stale
bundle left by an earlier `vscode:package` shadowed the live
`packages/core/dist/server.js` — core edits silently didn't take effect,
and a broken bundle (see the ESM-load fix) couldn't be worked around by
rebuilding. Prefer the dev path when `context.extensionMode ===
ExtensionMode.Development` and it exists; a packaged VSIX has no dev path
so it still uses the bundle (ADR-017).
@matze4u matze4u merged commit 0963568 into main Jun 3, 2026
8 checks passed
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.

1 participant