fix(web): build browser extension as CommonJS so activate() is exported (#418 root cause)

[zknpr]

Summary

This is the root cause of #418 — the vscode.dev web build never worked.

out/extension-browser.js was built with format: 'iife', which exports nothing on module.exports. The VS Code Web extension host loads the extension entry as a CommonJS module and calls module.exports.activate(context). With no activate export, it found nothing to call — so the extension's activate() never ran, the custom editor was never registered, and every database spun forever on the loading screen.

Proof (direct, not inferred)

1. Old bundle exported nothing: grep -c 'module.exports' out/extension-browser.js (iife) → 0; no activate export anywhere.
2. Real vscode.dev Extension Host log: showed _doActivateExtension zknpr.sqlite-explorer … onCustomEditor:sqlite-explorer.view and then dead silence — no "SQLite Explorer" output channel created, no webview iframe, spinner forever. That's the exact signature of activate() never running.
3. cjs rebuild exports it: the new bundle's export map is {GlobalOutputChannel, activate, activateProviders, deactivate} with a module.exports = … assignment.

Fix

scripts/build.mjs → compileBrowserMain uses format: 'cjs' (matching the desktop compileNodeMain). One line.

Why the prior #418 work was necessary but not sufficient

Activation never ran, so nothing downstream could fix it. But the prior changes remain correct groundwork:

• 1.3.7 in-process engine is still required — Trusted Types blocks new Worker(blob) in the web ext-host (confirmed live), so the worker approach can't be restored.
• 1.3.8 open-sequence instrumentation is intentionally retained for now and will be removed once 1.3.9 is verified working in real vscode.dev.

Verification

• Build OK — extension-browser.js now exports activate (verified in bundle); browser path still worker-free (in-process engine intact).
• tsc --noEmit -p tsconfig.json clean · npm test 334/334.
• ⚠️ Full "grid renders" proof still requires the published build in real vscode.dev (a dev build can't be sideloaded; @vscode/test-web can't mount the workspace FS under automation). Plan: publish 1.3.9, open a DB in vscode.dev, confirm the grid.

Refs #418.

Summary by CodeRabbit

• Bug Fixes

  • Fixed VS Code Web extension getting stuck on the loading screen on vscode.dev and github.dev.

• Chores

  • Version bumped to 1.3.9.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
sq-lite-explorer	Ready	Preview, Comment	Jun 1, 2026 8:59am

[coderabbitai]

📝 Walkthrough

Walkthrough

Build configuration for the VS Code web extension browser bundle changed from IIFE to CommonJS format to enable module activation. Version incremented to 1.3.9 with changelog documenting the fix for the loading hang on web-based editors.

Changes

VS Code Web Extension Loading Fix Release

Layer / File(s)	Summary
CommonJS build format for browser activation scripts/build.mjs	The compileBrowserMain esbuild configuration now outputs CommonJS (format: 'cjs') instead of IIFE, with added comments explaining that VS Code web extension host calls module.exports.activate(context), which IIFE bundles prevented from executing.
Release 1.3.9 version and changelog documentation CHANGELOG.md, package.json	Version field updated from 1.3.8 to 1.3.9, and changelog documents the fix for the web extension loading hang caused by IIFE bundle preventing activate() invocation, with issue reference [#418].

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~3 minutes

Poem

🐰 A bundle once trapped in IIFE's cage,
Would load but never stage the page,
Now CommonJS sets the web extension free,
And vscode.dev runs happily—hooray, version 1.3.9! 🎉

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Linked Issues check	⚠️ Warning	The pull request addresses issue #418 (root cause of web extension getting stuck), but the linked issue #39 about optimizing iterator handling in native-worker.js is not addressed in the changeset.	Either implement the iterator optimization in natives/native-worker.js as specified in #39, or update the linked issues to remove #39 if it belongs to a different PR.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately describes the main change: fixing the web browser extension build by using CommonJS format instead of IIFE, enabling the activate() function export.
Out of Scope Changes check	✅ Passed	All changes (CHANGELOG.md version bump, package.json version update, build configuration fix) are directly related to fixing issue #418 and are in scope.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/418-browser-ext-cjs

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[gemini-code-assist]

Code Review

This pull request updates the browser extension build format from IIFE to CommonJS (cjs) in scripts/build.mjs to resolve an issue where the VS Code Web extension failed to activate, causing databases to hang on the loading screen. It also bumps the package version to 1.3.9 and documents the fix in the changelog. I have no feedback to provide as there are no review comments to assess.