Problem
@vscode/vsce is extension packaging/publishing tooling, not an LLxprt runtime dependency and not required to compile or test the VS Code companion.
It is currently declared as a dev dependency in packages/vscode-ide-companion/package.json. Because that package is one of the root npm/Bun workspaces, an ordinary repository install also installs VSCE and its full transitive dependency tree:
packages/vscode-ide-companion
-> @vscode/vsce
-> cheerio
-> encoding-sniffer
-> whatwg-encoding@3.1.1 (deprecated)
The companion currently uses VSCE only for packaging and publication:
packages/vscode-ide-companion/package.json: vsce package --no-dependenciesscripts/build_vscode_companion.ts: invokes the companion package script.github/workflows/release.yml: packages the VSIX and invokes VSCE to publish it
The normal extension compilation scripts use TypeScript/esbuild and do not require VSCE.
This was identified while investigating #2730. It is independent of the Google GenAI, Google Auth, and Google Cloud Storage dependency chains.
Desired outcome
Treat VSCE as release-only VS Code packaging tooling rather than a dependency of the ordinary LLxprt workspace installation.
A normal contributor install, the published LLxprt CLI, and built runtime artifacts should not contain VSCE or dependencies present solely because of VSCE. The release process may install and use a pinned VSCE version in a controlled packaging context.
This issue is about dependency isolation. It does not require fixing Cheerio or VSCE upstream, and a packaging-only VSCE invocation may continue to report an upstream warning until those projects release a fix.
Acceptance matrix
| ID |
Behavior |
Required evidence |
| A1 |
Fresh repository npm install excludes release-only VSCE tooling |
In an OS-temporary clean checkout with a fresh npm cache, ordinary npm install exits 0 and the resulting dependency graph contains no @vscode/vsce path introduced by the companion workspace. |
| A2 |
Fresh repository Bun install excludes release-only VSCE tooling |
In a separate clean checkout/cache, plain bun install exits 0 and the resulting graph/lock contains no VSCE dependency introduced by the companion workspace. |
| A3 |
Companion development build remains independent of VSCE |
Typecheck, lint, tests, development build, and production build for llxprt-code-vscode-ide-companion pass without a workspace-installed VSCE binary. |
| A4 |
Extension packaging remains reproducible |
The approved packaging context uses an explicitly pinned VSCE version and produces a valid .vsix after running the existing prepackage checks. No unpinned npx @vscode/vsce invocation is introduced. |
| A5 |
Extension publication remains supported |
Release dry-run/package verification proves the generated VSIX follows the existing publish path and the marketplace publication command retains Azure credential and duplicate-handling behavior. |
| A6 |
Distribution artifacts exclude the packaging tool |
Inspect the published CLI tarball and generated VSIX contents/manifests. Neither artifact contains VSCE, its executable, or dependencies included solely to run VSCE. |
| A7 |
Lock and workspace policies remain valid |
Any root and packaging-context lockfiles are deterministic and the existing npm/Bun workspace and lockfile checks pass. |
Design constraints
- Removing VSCE from runtime dependencies is not enough if it remains a dev dependency of a root workspace; ordinary root installs will still install it.
optionalDependencies is not isolation because npm installs optional dependencies by default.- Do not replace the current pinned dependency with an unpinned
npx or npm exec call.
- Acceptable designs include a pinned release-only install step or a separate non-workspace packaging-tool context with its own deterministic manifest/lock. Choose the smallest design that satisfies all acceptance rows.
- Keep VSCE out of production/runtime manifests and generated runtime artifacts.
- Preserve current extension prepackage checks, VSIX generation, Azure Marketplace authentication, and
--skip-duplicate publication behavior.
- Do not suppress npm deprecation warnings or use incompatible transitive overrides.
- Do not weaken lint, type, complexity, coverage, safety, cross-platform, or CI requirements.
Expected paths
Likely paths, subject to the approved design:
packages/vscode-ide-companion/package.jsonscripts/build_vscode_companion.ts.github/workflows/release.ymlpackage.jsonpackage-lock.jsonbun.lock- focused behavioral tests under
scripts/tests/
- optionally a dedicated non-workspace packaging manifest and lockfile if that design is selected
Non-goals
- Fixing Cheerio, encoding-sniffer, or VSCE upstream.
- Changing Gemini/Google provider dependencies.
- Changing Google Cloud Storage or A2A persistence.
- Removing, disabling, or redesigning the VS Code companion.
- Changing extension runtime behavior or public commands.
- General dependency cleanup unrelated to VSCE isolation.
Scope and delivery
Follow the bounded issue-delivery policy. Before implementation, record the selected packaging design, exact expected paths, and behavioral RED evidence. Stop for approval before the workflow and dependency changes, and before exceeding the functional scope of this issue.
Problem
@vscode/vsceis extension packaging/publishing tooling, not an LLxprt runtime dependency and not required to compile or test the VS Code companion.It is currently declared as a dev dependency in
packages/vscode-ide-companion/package.json. Because that package is one of the root npm/Bun workspaces, an ordinary repository install also installs VSCE and its full transitive dependency tree:The companion currently uses VSCE only for packaging and publication:
packages/vscode-ide-companion/package.json:vsce package --no-dependenciesscripts/build_vscode_companion.ts: invokes the companion package script.github/workflows/release.yml: packages the VSIX and invokes VSCE to publish itThe normal extension compilation scripts use TypeScript/esbuild and do not require VSCE.
This was identified while investigating #2730. It is independent of the Google GenAI, Google Auth, and Google Cloud Storage dependency chains.
Desired outcome
Treat VSCE as release-only VS Code packaging tooling rather than a dependency of the ordinary LLxprt workspace installation.
A normal contributor install, the published LLxprt CLI, and built runtime artifacts should not contain VSCE or dependencies present solely because of VSCE. The release process may install and use a pinned VSCE version in a controlled packaging context.
This issue is about dependency isolation. It does not require fixing Cheerio or VSCE upstream, and a packaging-only VSCE invocation may continue to report an upstream warning until those projects release a fix.
Acceptance matrix
npm installexits 0 and the resulting dependency graph contains no@vscode/vscepath introduced by the companion workspace.bun installexits 0 and the resulting graph/lock contains no VSCE dependency introduced by the companion workspace.llxprt-code-vscode-ide-companionpass without a workspace-installed VSCE binary..vsixafter running the existing prepackage checks. No unpinnednpx @vscode/vsceinvocation is introduced.Design constraints
optionalDependenciesis not isolation because npm installs optional dependencies by default.npxornpm execcall.--skip-duplicatepublication behavior.Expected paths
Likely paths, subject to the approved design:
packages/vscode-ide-companion/package.jsonscripts/build_vscode_companion.ts.github/workflows/release.ymlpackage.jsonpackage-lock.jsonbun.lockscripts/tests/Non-goals
Scope and delivery
Follow the bounded issue-delivery policy. Before implementation, record the selected packaging design, exact expected paths, and behavioral RED evidence. Stop for approval before the workflow and dependency changes, and before exceeding the functional scope of this issue.