monaco-vscode-api

@codingame/monaco-vscode-api brings VSCode’s real service layer to the standalone Monaco editor, replacing Monaco’s simplified default services with fully-functional implementations pulled directly from the VSCode source tree. Instead of reimplementing themes, language features, configuration, keybindings, and the quickaccess menu on top of Monaco, this package exposes them as swappable service overrides you opt into individually.

It also exposes the real vscode extension API (aliased as vscode) so extensions written for actual VSCode - using the LSP-based vscode-languageclient, contribution points, and manifest-driven registration - can run unmodified inside a browser-hosted editor, alongside a growing catalog of published default-extension packages (themes, language grammars, localization packs) that mirror what ships in VSCode itself.

What You Get

• Service overrides - Drop-in replacements for Monaco’s simplified services (files, search, debug, configuration, keybindings, quickaccess) backed by real VSCode implementations.
• Real vscode extension API - Import vscode (aliased to @codingame/monaco-vscode-extension-api) and run genuine VSCode extensions, including LSP-based ones via vscode-languageclient, unmodified in the browser.
• Default extension packages - Published, installable packages that mirror VSCode’s bundled default extensions (language grammars, theme-defaults, etc.), imported individually as needed.
• Localization packs - Fourteen monaco-vscode-language-pack-* packages for full VSCode/extension UI translation.
• vsix loader - A rollup/vite-compatible plugin for importing .vsix extension bundles directly.
• Shadow DOM and sandbox modes - Beta support for running the workbench inside shadow DOM or an isolated iframe sandbox for reloadable, style-contained embedding.

Common Use Cases

• Building an in-browser IDE - Teams building web-based development environments (online coding platforms, internal tooling) that need real VSCode language features, not Monaco’s limited defaults.
• Powering monaco-languageclient - Projects using monaco-languageclient to connect Monaco to a Language Server Protocol backend rely on this package’s real vscode extension API instead of a fake/partial implementation.
• Embedding VSCode extensions in a web app - Product teams that want to run existing VSCode extensions (linters, formatters, custom language support) inside a web product without an Electron/desktop VSCode instance.
• Multi-instance or reloadable editors - Apps needing to mount/unmount full VSCode-backed editors dynamically use the sandbox mode since standard VSCode initialization can only happen once per page.

Under The Hood

Architecture The package is a thin integration layer (src/services.ts, src/workbench.ts, src/extensions.ts, src/lifecycle.ts) sitting on top of a patched, vendored copy of the actual VSCode source (resolved via vs/* path aliases against a ./vscode checkout pulled in by scripts/install-vscode), with src/service-override/* providing one module per VSCode service (accessibility, base, configuration, debug, extensions, files, host, and more) that each construct an IEditorOverrideServices object consumed by a single initialize() entry point. src/override/vs/* houses source-level patches to specific vs/* internals needed to make Monaco’s standalone-services runtime accept VSCode’s real service implementations, while lifecycle.ts gates startup ordering so initialize() can only run once, before any editor is created. A large rollup/ configuration set drives the publish step, compiling this layer plus dozens of default-extension and language-pack bundles into the many dependent packages released in lockstep. The core fragility point is that override files reach directly into unofficial vs/platform/* and vs/workbench/* internals pinned to an exact VSCode commit, so upstream VSCode changes can break overrides between releases.

Tech Stack TypeScript (99%+ of the codebase), built with Rollup rather than tsc/webpack across many purpose-specific configs (default extensions, language packs, monaco languages, the rollup plugins themselves), with mise pinning the toolchain and patch-package patching both the vendored VSCode source and node_modules dependencies. Linting runs via oxlint (a Rust-based ESLint alternative) with its correctness category set to error, and commit messages are enforced with commitlint in CI. The demo app uses Vite for local development and a separate Netlify-targeted build, and releases are cut through a custom release.ts script. CI installs native build dependencies (libkrb5-dev, libxkbfile-dev, libx11-6), reflecting that it’s compiling a real VSCode checkout for browser use.

Code Quality No unit test files exist anywhere in the repository - correctness is instead validated by a mandatory full compile-and-demo-build check on every pull request rather than unit tests, since this is a build/integration layer over vendored VSCode source rather than a library with its own isolated business logic. Guard functions in lifecycle.ts (checkServicesNotInitialized, checkServicesReady) throw rather than fail silently, TypeScript runs in strict mode with verbatimModuleSyntax and explicit type-only imports throughout, and the linter’s correctness rules are configured to fail the build. The lack of tests is a real gap, offset by strict typing, an enforced linter, and a CI-gated build check on every PR.

What Makes It Unique Unlike Monaco extensions that reimplement VSCode-like behavior from scratch, this project vendors actual VSCode source, patches it, and rebuilds it to run standalone in a browser bundle - publishing the real vscode extension API surface so genuine, unmodified VSCode extensions and LSP clients built against vscode-languageclient run against a bundler-friendly package instead of a simplified stub. The sandbox/iframe mode (running the real workbench in an iframe while projecting into the parent window’s DOM) and shadow-DOM CSS injection support are comparatively novel solutions to VSCode’s single-initialization constraint.