On 1 August 2013, Scott Hanselman published a post noticing that some C#, JavaScript and CSS files sitting in his SkyDrive had quietly become editable in the browser — with autocompletion, tooltips and syntax errors. He found the same component in the Windows Azure portal, in Azure Mobile Services, in the TypeScript playground, and in TFS Online rendering diffs. The file names were editor.main.css and editor.main.js, the CSS classes prefixed vs.
That is the piece of Monaco editor history that almost never survives the retelling. The popular version is one sentence long and runs the other way: Monaco is VS Code’s editor, pulled out and published as a standalone widget. The chronology is the reverse. The browser editor existed first, was shipping inside unrelated Microsoft web properties by mid-2013, and VS Code — which Microsoft’s own 1.0 announcement dates to an “initial launch one year ago” as of 14 April 2016, so April 2015 — was built around it.
Getting the order right is not trivia-collecting. This editor’s first delivery target was a browser tab inside somebody else’s web application, and that constraint is still legible in the source tree today.
An editor that turned up in places that were not an IDE
Hanselman’s post is a contemporary blog entry by a Microsoft employee, not an official announcement, and it is worth reading as exactly that: an outsider’s observation, made from the network tab. What makes it useful is the date and the inventory. Three months before Microsoft named the thing publicly, one component was already in production across a consumer file-storage service, a cloud portal, a mobile-backend console, a language playground and a source-control web UI — five products, several divisions, one editor.
The naming came later. On 13 November 2013, at the Visual Studio 2013 launch, Microsoft announced Visual Studio Online, and inside it a feature carrying the codename “Monaco”. TechCrunch’s report that day (timestamped 2013-11-13T15:30Z — contemporary trade press, not a primary Microsoft source) describes it as a cloud-based code editor for lightweight editing of Windows Azure websites, notes it was going out in private preview rather than public, and adds: “The technology behind Monaco, it’s worth noting, is already available in other Microsoft tools, including SkyDrive.” Jon Galloway’s walkthrough the following day, 14 November 2013, is the other contemporary account, and it links straight back to Hanselman’s August post as the earlier sighting.
One naming discipline before going further, because this history is a minefield of near-identical brands. Visual Studio Online was a cloud service. Visual Studio is the Windows IDE. Visual Studio Code is the cross-platform editor that arrived in 2015. Three separate products; Monaco’s origin belongs to the first one, and blurring any two of them produces a wrong sentence immediately.
The chronology, in three acts
Microsoft’s own documentation states the relationship plainly, and it is the load-bearing sentence for all of this. From Why did we build Visual Studio Code? (loaded 2026-09-04):
“VS Code uses a newer, faster version of the same industrial-strength HTML-based editor that has powered the ‘Monaco’ cloud editor, Internet Explorer’s F12 Tools, and other projects.”
Read that as a chronological claim and it settles the argument. VS Code uses a newer version of an editor that has powered prior projects. The editor is the antecedent; VS Code is the consumer. The same sentence adds a deployment nobody remembers — Internet Explorer’s F12 developer tools — which reinforces the shape of the thing: a reusable browser editor component, dropped in wherever Microsoft needed code editing inside a web page.
| Act | Date | Artifact | What it actually was |
|---|---|---|---|
| 1 | Aug–Nov 2013 | The browser editor component, codenamed “Monaco” | A JavaScript code editor embedded in SkyDrive, the Azure portal, Azure Mobile Services, the TypeScript playground, TFS Online and IE’s F12 tools; publicly named at the Visual Studio 2013 launch, 13 Nov 2013 |
| 2 | April 2015 | Visual Studio Code | A desktop application built around that editor. The microsoft/vscode GitHub repository was created 2015-09-03 (GitHub API, checked 2026-09-04) |
| 3 | 31 May 2016 | The monaco-editor npm package | A re-extraction of the editor out of the VS Code source tree, published so other web products could embed it |
Act 3 is the one that gets mistaken for act 1. Date Monaco by its npm package — the most obvious thing to check — and you get 2016, a year after VS Code, at which point “extracted from VS Code” becomes the only story that fits the evidence in front of you.
The npm package is the third act, not the first
The registry is unambiguous about the dates. Checked against registry.npmjs.org on 2026-09-04: monaco-editor was created on 2016-05-31, with 0.0.1 published that day; monaco-editor-core was created one minute later on the same date. The microsoft/monaco-editor GitHub repository itself was created on 2016-06-07 — a week after the packages it houses.
The standalone library therefore postdates VS Code’s launch by roughly thirteen months, and postdates the 2013 browser editor by two and a half years. It is the same source code arriving for the third time, under the original name, in a form other people can install.
The package’s own FAQ, in the microsoft/monaco-editor README (raw file loaded 2026-09-04), describes the relationship in two lines:
“The Monaco Editor is generated straight from VS Code’s sources with some shims around services the code needs to make it run in a web browser outside of its home.”
“What is the relationship between VS Code’s version and the Monaco Editor’s version? None. The Monaco Editor is a library and it reflects directly the source code.”
Take that literally. There is no mapping from a Monaco version to a VS Code version, because the library is not a release of VS Code — it is a build of a subtree, cut whenever the Monaco repository decides to cut one.
There is a precise refinement to that “none”, and it lives in the monaco-editor contributing guide rather than the README: “The nightly builds build a fresh version of monaco-editor-core from the main branch of VS Code. For a stable release, the commit specified in vscodeRef in package.json specifies the commit of VS Code that is used to build monaco-editor-core.” The coupling exists — it is simply expressed as a git SHA instead of a version number. In monaco-editor 0.56.0, published 2026-07-20, vscodeRef is f487add297079a02eb836810185b165e50cadabc, a microsoft/vscode commit dated 2026-06-25 (GitHub API, checked 2026-09-04), and the pinned core dependency is monaco-editor-core@0.56.0-dev-20260625 — a version string that encodes the same date. The release train is a pointer into another repository’s history.
Two package names, and why that is not a packaging detail
The distinction between the two npm names is where the architecture shows through. They are built in different repositories, from different halves of the job.
| Package | monaco-editor-core | monaco-editor |
|---|---|---|
| Built from | microsoft/vscode, via build/monaco/package.json | microsoft/monaco-editor |
| Contents | The editor core, tree-shaken out of src/vs/editor | The core, plus bundled language features |
| Versions published | 1,165 | 943 |
| Role | The extraction | The distribution people install |
(Version counts from registry.npmjs.org, checked 2026-09-04; both packages stood at 0.56.0, published 2026-07-20. The core carries more versions because dated dev builds are cut from VS Code’s main far more often than stable releases go out.)
The generated manifest lives in the VS Code repository, at build/monaco/package.json, and it is a few lines of self-explanation:
{ "name": "monaco-editor-core", "private": true, "version": "0.0.0", "typings": "./esm/vs/editor/editor.api.d.ts", "module": "./esm/vs/editor/editor.main.js"}version: "0.0.0" is not laziness; there is no version to state, because the artifact is defined by the commit it was cut from. And note the entry point — editor.main.js, the same file name Hanselman read off a SkyDrive page in August 2013.
The build step that produces it is extractEditor() in build/lib/standalone.ts, which reads src/tsconfig.monaco.json, runs a tree-shaker over it and writes the result out. VS Code’s Source Code Organization wiki describes the division of labour from the other end: vs/editor is “Monaco Editor Core”, while the separate repository “adds some programming language features on top of the Monaco Editor Core and publishes the combination as an npm package.”
The constraint that came from shipping in a browser first
Here is the part that makes the chronology worth an article rather than a footnote.
An editor whose first job was to run inside SkyDrive and the Azure portal could not assume a Node.js runtime, a filesystem, a terminal, a process it owned, or a window it controlled. It had to be a component that someone else’s page could host. That is a strictly harder starting position than “the text area inside our desktop app”, and it is the position this code started from in 2013.
The constraint is still written down as a rule. From the same Source Code Organization wiki: “the vs/editor folder should not have any node or electron-* dependencies.” The layering is machine-enforced by custom ESLint rules whose configuration carries a literal // !!! Do not relax these rules !!! comment — a companion piece on this site covers that enforcement mechanism in detail.
The sharper evidence is in src/tsconfig.monaco.json, the config extractEditor() reads. Its include list is short — vs/editor/*, vs/base/common/*, vs/base/browser/*, vs/platform/*/common/*, vs/platform/*/browser/* — and vs/workbench simply is not in it. But exclude is the interesting half, because it names, file by file, the machinery the standalone editor has to live without:
"exclude": [ "vs/platform/files/browser/htmlFileSystemProvider.ts", "vs/platform/files/browser/webFileSystemAccess.ts", "vs/platform/telemetry/*", "vs/platform/assignment/*", "vs/platform/terminal/*", "vs/platform/externalTerminal/*"]
No filesystem access, no telemetry, no experiment assignment, no terminal. Those are not features the standalone build happens to omit — they are dependencies the editor was never allowed to acquire in the first place, because acquiring them would have made it unhostable in the environment it was born in.
Two honest qualifications, because this argument is more interesting stated accurately than stated strongly.
First, the boundary is narrower than the slogan. vs/editor is not forbidden from importing vs/platform — tsconfig.monaco.json explicitly includes vs/platform/*/common/* and vs/platform/*/browser/*. The forbidden layer is vs/workbench, and the forbidden environments are Node and Electron. “The editor depends on nothing” is a nicer sentence and a false one.
Second, the causal claim is inference, and should be labelled as such. What is documented is the sequence (a browser editor in 2013, a desktop application built around it in 2015), the rule (vs/editor may not depend on Node or Electron), and the fact that the rule holds well enough that a build script can mechanically cut the layer out and ship it as a product. What is not documented — no maintainer statement was found saying it — is that the 2013 delivery target is why the rule exists. The correlation is strong and the mechanism is obvious; the evidence stops short of a stated motive. Treat “web-first origin produced the boundary” as the best available reading, not as a quotation.
What the library still cannot do, and why that is a process fact
The FAQ answers the obvious follow-up with one word. “I’ve written an extension for VS Code, will it work on the Monaco Editor in a browser?” — “No.” The single exception it allows is an extension built entirely on the Language Server Protocol with a language server authored in JavaScript, because that path never touches the editor’s extension API at all. (The FAQ, incidentally, lives inside the README on main as of 2026-09-04; the separate docs/faq.md path cited in older write-ups returns 404.)
The reason is structural rather than a backlog item: VS Code’s extension model depends on a separate extension host process and an activation lifecycle that live above the editor layer, and the standalone library has no such process to load anything into. Which puts the extension host last in this chronology, not first — Microsoft’s 1.0 post of 14 April 2016 notes “less than 6 months since we made the product extensible”, placing extensibility after October 2015. The editor predates VS Code’s extension model by more than two years.
One more line from the README deserves attention. On installing the package: “monaco.d.ts: this specifies the API of the editor (this is what is actually versioned, everything else is considered private and might break with any release).” The versioned artifact is not the code. It is the type declaration — the API surface — and everything behind it is explicitly reserved.
Where the backwards story comes from
It is not a mystery, and it is nobody’s carelessness. The README’s own opening line reads: “The Monaco Editor is the fully featured code editor from VS Code.” That is accurate about provenance today — the core genuinely is built from the VS Code sources — and entirely silent about chronology. Combine it with an npm package first published in May 2016, thirteen months after VS Code launched, and “extracted from VS Code” is the natural inference from the two most visible facts.
The correction sits on a documentation page most people have no reason to open, in a sentence about industrial-strength HTML-based editors, next to a mention of Internet Explorer’s F12 tools. The record is public, primary and dated. It is just filed somewhere nobody looks.
❓ Frequently Asked Questions
Was Monaco extracted from VS Code? The monaco-editor npm package was, in 2016 — that is a real extraction of src/vs/editor from the VS Code repository, and it is still cut that way. But “Monaco” as an editor predates VS Code by roughly two years: it was a browser code editor shipping inside SkyDrive, the Azure portal and other Microsoft web properties by August 2013, and publicly codenamed at the Visual Studio 2013 launch on 13 November 2013. VS Code, launched April 2015, was built around it.
What is the difference between monaco-editor and monaco-editor-core? monaco-editor-core is produced from the microsoft/vscode repository — its generated manifest is build/monaco/package.json and the build step is extractEditor() in build/lib/standalone.ts. monaco-editor is produced from the microsoft/monaco-editor repository and adds bundled language features on top of the core. You install monaco-editor; the core is the extraction it is built on.
Which VS Code version does a given Monaco release correspond to? None, by the project’s own answer: “The Monaco Editor is a library and it reflects directly the source code.” There is a precise pin, though — just not a version-number one. A stable release records a vscodeRef commit SHA in package.json. For 0.56.0, published 2026-07-20, that is f487add297079a02eb836810185b165e50cadabc, dated 2026-06-25.
Can I run a VS Code extension inside Monaco? No. The FAQ’s answer is that flat. The narrow exception is an extension built entirely on the Language Server Protocol with a JavaScript language server, because that path never touches the editor’s extension API. The blocker is architectural — the standalone library has no extension host process — not a missing feature.
Is vscode.dev just the Monaco editor in a browser? No, and conflating them is the most common follow-up error. vscode.dev is the full VS Code workbench compiled for the browser, panels and all, which is a different artifact from the editor-only library.
Was Visual Studio Online the same thing as Visual Studio? No. Visual Studio Online was a cloud service announced on 13 November 2013; Visual Studio is the Windows IDE; Visual Studio Code is the cross-platform editor from 2015. Monaco’s origin belongs to the cloud service, and the three names are not interchangeable in any sentence.
📚 Recommended Resources
Some links below are affiliate links. If you buy through them, this site earns a small commission at no extra cost to you.
Start with the primary material — it is free, current, and better than any book on this specific subject. The VS Code Source Code Organization wiki is the page that states the vs/editor layering rule in one sentence. The monaco-editor contributing guide carries a diagram of how the two repositories and two npm packages relate — the fastest way to internalise the monaco-editor-core split. And build/lib/standalone.ts plus src/tsconfig.monaco.json in the VS Code repository are, between them, a complete and honest account of what the editor layer is allowed to depend on. Reading those four artifacts takes an evening and settles most arguments about this topic.
For the ideas underneath the story, three books earn their place:
A Philosophy of Software Design, 2nd Edition — John Ousterhout
The best short treatment of why a module’s interface, not its implementation, is the thing you are actually shipping. Monaco’s README says only monaco.d.ts is versioned and everything behind it may break with any release; Ousterhout spends a book explaining why that is the right way round.
Design Patterns: Elements of Reusable Object-Oriented Software — Gamma, Helm, Johnson & Vlissides
Worth reading here for a specific reason: Erich Gamma, its lead author, went on to lead the team behind Monaco and VS Code. Reading the 1994 book against the 2026 source tree is an unusually direct look at how one engineer’s design vocabulary survives contact with a codebase of that size.
Building Evolutionary Architectures: Automated Software Governance — Ford, Parsons, Kua & Sadalage
The subtitle is the relevant part. This book is about encoding architectural rules as automated checks rather than documentation — which is precisely what a build script that can mechanically cut one layer out of a repository and ship it as a separate product demonstrates.