OpenCode Beta (opencode-v2) extension broken: VSIX missing dist/extension.js, sidebar view never renders

[ideabib]

OpenCode Beta (opencode-v2) extension is broken: published VSIX ships without dist/extension.js, and the sidebar view never renders

Summary

The OpenCode Beta extension (sst-dev.opencode-v2, v0.1.1) is broken out of the box. The published VSIX does not include the compiled dist/extension.js that package.json declares as "main". As a result the extension can never activate, and the activity-bar icon / sidebar view does nothing.

I diagnosed and fixed this locally (by hand-patching the installed bundle), and I'm filing this issue so the source can be fixed properly and the next release ships a working extension.

Root causes found

1. The VSIX is missing dist/extension.js entirely

The installed extension directory contains only:

• package.json
• readme.md
• images/
• .vsixmanifest

There is no dist/ directory and no node_modules. The .vsixmanifest <Assets> only lists package.json, readme.md, and icon.png — the compiled bundle was never included in the package. Since package.json declares "main": "./dist/extension.js", VS Code cannot load the extension at all.

2. The sidebar view is missing "type": "webview"

The opencode-v2.panel view is declared without "type": "webview":

"views": {
  "opencode-v2": [
    { "id": "opencode-v2.panel", "name": "OpenCode", "when": "true" }
  ]
}

Without "type": "webview", VS Code treats the view as a plain tree view and never invokes the WebviewViewProvider. Compare with the working tanishqkancharla.opencode-vscode and saoudrizwan.claude-dev extensions, which both declare "type": "webview" on their webview views. The fix is:

"views": {
  "opencode-v2": [
    { "type": "webview", "id": "opencode-v2.panel", "name": "OpenCode", "when": "true" }
  ]
}

3. Missing onView activation event

activationEvents only lists the two commands. Clicking the activity-bar icon fires onView:opencode-v2.panel, which is not declared, so the extension may not activate when the view is opened. Add:

"activationEvents": [
  "onCommand:opencode-v2.openPanel",
  "onCommand:opencode-v2.refreshPanel",
  "onView:opencode-v2.panel"
]

4. Windows: spawning the npm-installed CLI fails

On Windows, opencode installed via npm lands as a .cmd shim (e.g. C:\Users\<user>\AppData\Roaming\npm\opencode.cmd). Spawning a .cmd/.bat file directly with child_process.spawn() fails with ENOENT. It must be launched through cmd.exe /c (via process.env.ComSpec).

5. Avoid blocking calls during activation

The extension host became unresponsive (logged Extension host is unresponsive) when activation used blocking calls like execSync("npm root -g") and synchronous fs.existsSync PATH scanning. All CLI discovery and server startup should be asynchronous.

Suggested source-level fixes

• Ensure the build/package step actually emits and includes dist/extension.js in the VSIX (check esbuild.js output and .vscodeignore).
• Add "type": "webview" to the opencode-v2.panel view contribution.
• Add "onView:opencode-v2.panel" to activationEvents.
• Use cmd.exe /c (via ComSpec) when spawning .cmd/.bat CLI shims on Windows.
• Keep activation non-blocking (no execSync, no sync fs.existsSync loops).

Environment

• VS Code: latest stable
• OS: Windows 11
• Extension: sst-dev.opencode-v2 v0.1.1
• opencode CLI: v1.18.14 (installed via npm at C:\Users\<user>\AppData\Roaming\npm\opencode)

Note

The opencode-v2 source does not appear to be present in this repository — only the older terminal-based sdks/vscode extension is in the tree (checked main and 2.0 branches). Please confirm where the opencode-v2 source lives so it can be fixed and republished.

[github-actions]

This issue might be a duplicate of existing issues. Please check:

• VSCode extension "OpenCode Beta" - "There is no data provider registered that can provide view data." #10119: Same symptom — OpenCode Beta sidebar view never renders ("There is no data provider registered that can provide view data."), same extension version v0.1.1 on Windows
• VS Code extension: spawn opencode ENOENT on Windows #38376: Covers the Windows spawn opencode ENOENT root cause (root cause feat: add configuration persistence for model selections #4 described in this issue) with the same analysis and workaround

You may want to consolidate your findings there or confirm whether your issue adds new root causes not yet tracked.

[ideabib]

Thanks for the triage. I compared against #10119 and #38376 before filing, and there is meaningful overlap, but this issue also adds root causes not tracked in either thread.

Agreed overlap (fine to deduplicate):

• Root cause feat: add configuration persistence for model selections #4 (Windows ENOENT spawning .cmd shims) is already well covered by VS Code extension: spawn opencode ENOENT on Windows #38376 with the same analysis and workaround.
• VSCode extension "OpenCode Beta" - "There is no data provider registered that can provide view data." #10119 covers the symptom of the sidebar view never rendering; that thread does not include the underlying package/view-provider root causes below.

New root causes this issue adds that are not tracked elsewhere:

1. The published VSIX ships WITHOUT dist/extension.js entirely. This is the most severe finding: package.json declares "main": "./dist/extension.js", but the installed package contains no dist/ directory at all (and the .vsixmanifest assets list only package.json, readme.md, icon.png). An extension whose main module is absent cannot activate regardless of the ENOENT or view-type fixes above. This packaging defect is worth tracking as its own item.
2. The webview view is missing "type": "webview" (declared as a plain tree view), so WebviewViewProvider is never invoked even after activation succeeds.
3. Missing onView:opencode-v2.panel activation event for the activity-bar view.
4. Blocking synchronous calls during activation (e.g. execSync("npm root -g"), synchronous PATH scanning) caused the extension host to become unresponsive - a separate failure mode from the ENOENT issue.

Because of #1, #3, and #4 above, I'd suggest keeping this open as a packaging + view-registration fix, while deferring the Windows spawn behavior to #38376. Happy to consolidate or cross-link the comments as the maintainers prefer.