Description
packages/databricks-vscode/package.json declares only a main entry (out/extension.js) and no browser entry, so the extension is a Node.js-only extension and cannot be loaded in the web extension host used by:
Today, opening a Databricks bundle project in vscode.dev results in the extension being installed but never activating, with no obvious hint that only the desktop client is supported.
Rationale
Databricks users increasingly work in browser-based editors (especially GitHub Codespaces web fallback and quick-view via github.dev on a mobile/loaner machine). The subset of extension functionality that's viable in a web extension host is meaningful even without local CLI:
- Read-only Bundle Resources Explorer (calls Databricks REST API, no CLI needed)
- YAML schema hints for
databricks.yml
- Workspace file browser via WSFS (already REST-backed)
- "Open in Databricks" URL routing (no local CLI)
- Auth via OAuth U2M using the browser's redirect flow
Features that legitimately need the desktop host (Databricks Connect debug, local databricks bundle deploy via the bundled CLI binary, local sync) can be gated with when: !isWeb on their commands/views, matching how e.g. the Python extension and GitHub Pull Requests extension partition their surface.
Suggested approach
- Add a
browser entry to package.json pointing at a web-specific bundle (e.g. out/extension.web.js).
- Split platform-dependent code (
child_process, fs, native CLI invocation) behind an interface that has a node and a web implementation; the web implementation stubs out CLI-only paths.
- Configure the bundler (esbuild/webpack) to emit both a Node bundle and a browser bundle, matching the pattern in the VS Code sample: https://github.com/microsoft/vscode-extension-samples/tree/main/web-extension-sample
- Gate CLI-dependent commands and views with
"when": "!isWeb" in contributes.
This is a substantial change; filing so the ask is tracked, not to imply it's trivial.
Verification
Checked packages/databricks-vscode/package.json on main (commit 133c453, 2026-06-26) via the GitHub Contents API — no browser key. main: out/extension.js only. Searched existing issues for "web extension", "vscode.dev", "browser" — no prior filing.
Filed via automated audit.
Description
packages/databricks-vscode/package.jsondeclares only amainentry (out/extension.js) and nobrowserentry, so the extension is a Node.js-only extension and cannot be loaded in the web extension host used by:github.dev-style URLsToday, opening a Databricks bundle project in
vscode.devresults in the extension being installed but never activating, with no obvious hint that only the desktop client is supported.Rationale
Databricks users increasingly work in browser-based editors (especially GitHub Codespaces web fallback and quick-view via
github.devon a mobile/loaner machine). The subset of extension functionality that's viable in a web extension host is meaningful even without local CLI:databricks.ymlFeatures that legitimately need the desktop host (Databricks Connect debug, local
databricks bundle deployvia the bundled CLI binary, local sync) can be gated withwhen: !isWebon their commands/views, matching how e.g. the Python extension and GitHub Pull Requests extension partition their surface.Suggested approach
browserentry topackage.jsonpointing at a web-specific bundle (e.g.out/extension.web.js).child_process,fs, native CLI invocation) behind an interface that has anodeand awebimplementation; the web implementation stubs out CLI-only paths."when": "!isWeb"incontributes.This is a substantial change; filing so the ask is tracked, not to imply it's trivial.
Verification
Checked
packages/databricks-vscode/package.jsononmain(commit 133c453, 2026-06-26) via the GitHub Contents API — nobrowserkey.main: out/extension.jsonly. Searched existing issues for "web extension", "vscode.dev", "browser" — no prior filing.Filed via automated audit.