Ship the Monaco editor as a builtin plugin

[andrewkchan]

Human comments

This basically upstreams https://github.com/andrewkchan/bb-plugin-monaco as a built-in plugin.

• Optimized so that it gets bundled instead of lazy loaded with AMD loader, now it should add only ~6MB (the typescript language services are stripped)
• One functional difference from external monaco is that hovering symbols in typescript files no longer shows diagnostics and CMD+click does not work to gotodef in the same file. This is because we're stripping the builtin monaco typescript language service. The plan is to make the language diagnostics optional (first, add back in the monaco builtins, then add an interface for custom LSPs as plugins, see Language intelligence should be plugin-contributed, not built into the editor #2438)

---

What was wrong

BB's file panel is read-only. Opening a file from chat, the file search, or bb thread open gives a preview, so any edit means leaving BB for an editor — even for a one-line change to a file the agent just wrote. This upstreams the Monaco plugin I built out-of-tree (andrewkchan/bb-plugin-monaco) so the panel can edit as well as show.

What changed

New builtin: plugins/monaco-editor. A fileOpener that replaces the preview with Monaco for ~86 text and code extensions:

• Editing with ⌘S saves guarded by expectedSha256, so a save that would clobber a concurrent write (usually the agent's) stops and offers Reload or Overwrite.
• Find (⌘F), line numbers, syntax highlighting, and Monaco's usual editing affordances.
• A file tree with path filtering, expand/collapse, reveal-the-open-file, and a right-click menu to copy absolute path / relative path / filename.
• Quick-palette rows for folding, sorting selected lines, and copying the current file's path, via the commandPaletteAction slot from Let plugins add rows to the quick palette #2270.
• Type and theme matched to BB's own preview (font-mono text-xs leading-5, --font-mono, light/dark).

Registered defaultEnabled: true under Interface. That is the significant product change: the file panel becomes an editor for nearly every text file by default. Per-extension opt-out lives in Settings → File openers, and binaries fall through to BB's preview via the Original prop.

The plugin id is monaco-editor, not monaco. The id derives from the package name, and monaco is what the external plugin this upstreams already uses. Reconcile refuses to displace a user's own install, so sharing the id would have meant anyone holding that plugin got the builtin silently skipped — nothing but a server log — until they removed theirs and restarted. Renaming sidesteps it: the two coexist, and removing the external one needs no special handling. The display name is "Monaco editor" so they are tellable apart in Settings during the transition.

Monaco is built here, not bundled into app.js and not copied from its prebuilt tree. scripts/stage-assets.mjs runs esbuild over monaco-bundle/editor.js and emits dist/monaco/{editor.js,editor.css,editor.worker.js}; lib/monaco-loader.ts loads those from a files.createPreview URL the first time a file tab opens.

Bundling into app.js is not an option: bb plugin build emits one file with no code splitting, so Monaco would parse at app boot for every user including those who never open a file, and its worker could not be emitted at all. Building it separately keeps it lazy — app.js is 24 KB — while letting esbuild prove reachability, which is what makes the trimming safe.

Size: the packaged builtin is 6.3 MB, of which Monaco is 4.6 MB. The entry is Monaco's own editor.main — the API, its contribution modules, and every Monarch grammar — minus the CSS, HTML, JSON, and TypeScript language services, which this plugin has no use for (its checker sees only the open file, so its "cannot find module" errors would be wrong). An earlier revision of this branch shipped Monaco's whole prebuilt AMD tree at 25 MB.

A generic staging hook (apps/server/scripts/copy-builtin-plugins.ts). Packaging copies only a builtin's dist/ and skills/, and builds plugins itself without running per-plugin scripts — so a plugin needing runtime files on disk has nowhere to put them. copyBuiltinPlugin now runs <pluginRoot>/scripts/stage-assets.mjs when present. Optional, and this plugin is currently the only user. A source checkout never runs that path, so the plugin also builds its own bundle when it is missing or older than its sources.

Also updated: smoke-tarball.mjs, and the two "declare metadata for every builtin" tables in the server tests (both failed before I added the entries, which is them working as intended). No other core code is touched — plugin-service.ts and plugin-registration.ts are unchanged from main.

How you verified

pnpm exec turbo run typecheck test --filter=bb-plugin-monaco-editor    # 11 tests
pnpm exec turbo run test --filter=@bb/server -- builtin-plugins official-plugins   # 33 tests
pnpm exec turbo run test --filter=@bb/app -- useThreadFileTabs         # 20 tests

Unit tests cover the tree logic that is easy to get subtly wrong — nesting flat paths, synthesising directories a truncated listing omitted, case-insensitive sorting, and filtering, which must expand every ancestor of a match or the match stays hidden behind a collapsed row. Another asserts every claimed extension maps to a language the built bundle actually registers; it failed on its first run, catching that json was absent from the trimmed bundle and package.json would have rendered as plain text.

The build script asserts the bundle is complete, because trimming it is how this went wrong twice. It fails when the output lacks the find widget, folding, word navigation, line sorting, grammars, or contributions. An earlier entry (editor.api alone) shipped without Monaco's contribution modules: the editor opened, highlighted, and typed, so it looked correct, while ⌘F, the option+arrow word motions, and every folding command silently did not exist. The guard reports that entry precisely. Note it checks for the find widget's own class name rather than actions.find, which is present with or without the widget and would have passed.

Ran the real packaging path (tsx apps/server/scripts/copy-builtin-plugins.ts) and confirmed the shipped builtin contains dist/monaco/{editor.js,editor.css,editor.worker.js} beside dist/server.js and dist/app.js, totalling 6.3 MB, with Monaco absent from app.js.

Manual testing is in progress in a dev desktop build. Two paths are new in the port and have never run: project-backed workspace sources (no environment, resolved through the project's sources[]) and the experimental_hostId field on PluginFileOpenerSource — the plugin's schema was .strict() and would have rejected those files outright before this branch.

Known gaps

Documented in the plugin README, with upstream issues where the fix is not ours:

• No language server: no go-to-definition, find-references, or type checking. Monaco's own TypeScript service would restore single-file navigation, but it costs a 6.7 MB worker for one language, runs whether or not anyone wants it, and still cannot resolve an import. Language intelligence should be plugin-contributed, not built into the editor #2438 proposes making language intelligence plugin-contributed instead — a toggle for Monaco's in-browser services, and a contribution point so people can bring their own servers. Occurrence highlighting is restored here with a textual provider, which needs none of that.
• The tree cannot show hidden files or node_modules (Path listing hides every dotfile and node_modules unconditionally, so file search cannot find .github/workflows/ci.yml #2093), and is read-only — no rename/create/delete.
• Opening a file from the tree reuses the tab, so its title goes stale (A fileOpener cannot open another file or retitle its tab, so navigating inside one leaves a stale tab title #2102).
• No "open in editor" button; that capability is not exposed to plugins.

Fixes #

AGENT GENERATED: by Claude Opus 5