# vscode: the repository you clone is not the product you install

> microsoft/vscode holds Code - OSS, the MIT licensed tree that Visual Studio Code is built from, and the two ship under different licenses and different versions. Building it means Node, a gulp pipeline and a machine with four cores, and the test command you would reach for first deliberately refuses to run.

**microsoft/vscode** — Source code for Visual Studio Code (Code - OSS), the MIT-licensed editor that combines a simple code editor with debugging, navigation, and a rich extensibility model.

- Repository: https://github.com/microsoft/vscode
- Website: https://code.visualstudio.com
- Stars: 192,903 · Forks: 43,331
- Language: TypeScript
- License: MIT
- Published: 2026-08-08 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/microsoft-vscode

## Code - OSS is the tree, Visual Studio Code is the distribution

The first distinction in the repository is the one that trips people up. The source here is called `Code - OSS`, it is developed in the open with the community, and it is MIT licensed through LICENSE.txt. Visual Studio Code, the thing most people download, is described as a distribution of this repository with Microsoft-specific customizations, released under a Microsoft product license instead.

So the permissions differ by artifact. You can read, modify and redistribute the tree under MIT, and the binary you install carries different terms. The root package.json underlines the split by carrying a `distro` field with a commit hash, and a product.json sits beside it for the distribution's own configuration. Consequence: a fix you find on main is not the fix in the build on your machine, and a bug report that does not name a build will be measured against a tree that has moved on.

## main runs ahead of the release on your disk

The version in the root package.json reads 1.141.0 while the recent release tags are 1.139.1 on 2026-09-25, 1.139.0 on 2026-09-23, and 1.138.0 on 2026-09-16. The last push to the repository was on 2026-09-25, on the main branch. Releases move monthly, and the project ships an Insiders build for people who want the newest releases every day.

The gap between a version on main and a version you can download is the thing to internalize before you file anything. A crash you see in your installed copy may already be fixed in the tree, and a patch you write against main targets code two minors ahead of what most people run. Consequence for contributors and reporters: say which build you are on, and if you need the tip without waiting for the monthly release, install Insiders rather than compiling the whole tree.

## npm test exists only to tell you not to use it

The scripts in the root package.json are a map of a large build, and the first one is a refusal. `test` runs a short node script whose message is 'Run a test script from the scripts folder, for example: ./scripts/test.sh --run <file>.' and then exits with a failure status. The real entry points sit beside it, one per test surface.

```json
  "scripts": {
    "compile": "npm-run-all2 -lp compile-client compile-copilot",
    "compile-client": "npm run gulp compile",
    "typecheck-client": "tsc --project ./src/tsconfig.json --noEmit --skipLibCheck",
    "check-cyclic-dependencies": "node build/lib/checkCyclicDependencies.ts out"
  }
```

Node tests run through mocha against test/unit/node/index.js, browser tests need playwright installed first, extension tests go through vscode-test, and build script tests change directory into build and run its own npm test. A dependency cycle check exists too. What you cannot do is type one command and test everything, so a newcomer who trusts npm test learns the layout the hard way.

## preinstall and postinstall run repository code on npm install

Two lifecycle hooks are wired into this package: `preinstall` runs node build/npm/preinstall.ts and `postinstall` runs node build/npm/postinstall.ts. The tree carries package-lock.json, an .npmrc, an .nvmrc and package.json marked private, and the scripts call npm directly, gulp and mocha, so npm is the expected installer here rather than an afterthought.

Consequence: installing this repository is not a pure download. Repository code executes on both sides of the install, which is fine on a workstation you control and awkward on a locked-down machine, an offline builder, or a CI image that mirrors the registry. Read build/npm/preinstall.ts and build/npm/postinstall.ts before you wire this into a pipeline, because whatever they do runs before you get to choose anything.

## extensions/ splits grammar from language features by suffix

Built-in extensions live in the extensions folder, and the naming rule tells you what each one is for. Grammar and snippet work carries a plain language name: the json extension provides coloring for JSON. Rich language support, such as inline suggestions and Go to Definition, takes the `language-features` suffix, which is why json-language-features exists next to json. The same convention shows up in the script names, with markdown-language-features and the copilot extension compiled separately from the client.

The convention is neat, and it creates a problem for anyone trying to reproduce a build. The front page does not enumerate which extensions ship in which release, and the folder on main holds whatever the current iteration plan calls for. Consequence: you cannot reconstruct the extension set of release 1.138.0 from this branch; if you need that exact list, take it from the tagged commit rather than from main.

## A full build wants 4 cores and 6 GB of RAM, 8 GB recommended

The repository ships a development container in .devcontainer, and the front page is specific about the hardware: the Docker container or the Codespace should have at least 4 cores and 6 GB of RAM, with 8 GB recommended, to run a full build. On macOS and Windows the recommended path is the Dev Containers command that clones the repository into a container volume for better disk I/O. For Codespaces you install the GitHub.codespaces extension and use the create-new-codespace command. Details sit in .devcontainer/README.md.

That is a real floor, not a suggestion, and it is the number to plan against. A two-core laptop or a small CI container will not complete a full build, and the front page offers no lighter documented path. Consequence: before you promise a contribution, check the machine, or use the Codespaces route where the sizing is somebody else's problem.

## The debug adapters are separate repositories, not subfolders

Many core components and extensions that look like part of the editor are maintained elsewhere. The front page names two examples: the node debug adapter and the mono debug adapter, each in its own repository, separate from this one and from each other, with a complete list on the Related Projects wiki page.

This boundary is easy to miss when you are new, and it decides where your work belongs. A change to how the editor drives a debug session is in scope here; a change to the Node debug adapter is not, and a pull request against the wrong tree will be closed rather than reviewed. Consequence: before you write a patch for anything debugger related, check Related Projects, then file it in the repository that owns the component. The same split applies to extensions, which live in their own repositories.

## Feedback is five channels, and none of them is the wiki

The front page hands out several distinct routes. Questions go to Stack Overflow under the vscode tag, feature requests go through CONTRIBUTING.md, open bugs and requests are filed as issues, and popular feature requests are upvoted on a page already sorted by reactions. The extension author community is reached on GitHub Discussions or Slack, and the wiki has a Feedback Channels page describing each of them.

What that structure does not do is tell you, for your specific case, which door to walk through, and the split follows the artifacts: documentation pull requests belong to the microsoft/vscode-docs repository, while roadmap, monthly iteration plans and endgame plans live in the wiki. Consequence for a reporter: a misrouted issue can sit unnoticed for weeks. Check the wiki page first, and note that conduct questions go to the Microsoft Open Source Code of Conduct, with opencode@microsoft.com as the published contact.

## Conclusion

Use this repository when you need to change the editor itself, patch a bundled extension, or follow a fix before it ships. Stay on the released build if you only need an editor, because the source tree and the product diverge on schedule. Verify two things first: the version in package.json against the release you actually run, and the .devcontainer requirements, 4 cores and 6 GB of RAM, before you plan a build machine.

## FAQ

### Is VS Code an IDE or an editor?

The project describes it as combining the simplicity of a code editor with what developers need for the core edit-build-debug cycle. It calls its debugging lightweight and its extensibility model rich, which places it between the two categories.

### Is the VS Code repository the same thing as Visual Studio Code?

No. The repository is Code - OSS, MIT licensed, and Visual Studio Code is a distribution of it with Microsoft-specific customizations released under a Microsoft product license. The same split shows up in the codebase itself, with a distro field in package.json and a separate product.json.

### How do I install VS Code?

Downloads for Windows, macOS and Linux are on the code.visualstudio.com website, and an Insiders build delivers the latest releases every day for people who want the newest code. Building from source is a separate path, documented on the How to Contribute page of the project wiki.

### How do I use the VS Code debugger?

For development against this repository, the How to Contribute page covers the workflow including debugging and running tests. The debug adapters themselves are maintained in separate repositories, with the node debug adapter and the mono debug adapter named as examples on the front page.

### How do I use VS Code with GitHub?

Two paths are documented. Documentation changes go to the separate microsoft/vscode-docs repository, and a Codespace can host the editor build after you install the GitHub.codespaces extension and use its create-new-codespace command. The repository also has a development container in .devcontainer for the same purpose.

## Sources

- [Official documentation](https://code.visualstudio.com)
- [Official README](https://github.com/microsoft/vscode#readme)
- [Project repository](https://github.com/microsoft/vscode)
- [Release notes](https://github.com/microsoft/vscode/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/microsoft-vscode