# Yo Code: A practical guide to generating VS Code extensions

> Yo Code is a Yeoman generator for creating Visual Studio Code extensions and several customization types from prompts. It saves manual scaffolding work, but its output still requires extension-specific development, testing, and packaging.

**microsoft/vscode-generator-code** — Visual Studio Code extension generator

- Repository: https://github.com/microsoft/vscode-generator-code
- Stars: 1,641 · Forks: 265
- Language: JavaScript
- License: NOASSERTION
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/microsoft-vscode-generator-code

## What Yo Code removes from VS Code extension setup

Yo Code addresses the initial scaffolding problem faced by Visual Studio Code extension developers. A new extension needs more than an empty directory: it requires package metadata, source files, and development configuration. Yo Code collects the basic choices through prompts and writes a starting structure that can then be opened and modified in VS Code.

The supported scope is broader than ordinary command extensions. The command-line reference lists `ts`, `js`, `colortheme`, `language`, `snippets`, and `keymap` as possible extension types. The documentation also refers broadly to extension and customization templates, although it does not enumerate every type or guarantee that every listed option has the same feature depth. A developer choosing this project should inspect the generated output rather than infer identical behavior from each type name.

This is primarily a project initializer, not a framework that handles an extension's complete lifecycle. The documented output includes a base folder structure, a preliminary `package.json`, required assets such as textMate bundles or the VS Code Library when applicable, and a `launch.json` configuration for extension debugging. Nothing in the README describes automatic publishing to the Visual Studio Marketplace, production releases, telemetry, or an extension architecture. Those remain outside the generator's documented responsibility.

The most obvious users are developers starting their first VS Code extension, maintainers who repeatedly create similarly structured projects, and teams standardizing how new extensions begin. The generator is less useful for an experienced developer with an established internal scaffold, because its main value is replacing initial setup rather than managing an extension after creation.

## How Yo Code turns Yeoman prompts into files

Yo Code is implemented as the Yeoman package `generator-code`. Its `package.json` points to `./generators/app/index.js`, making the application generator the package entry point. The dependency on `yeoman-generator` supplies the generator model and prompt lifecycle, while `yosay` handles the terminal presentation. The repository also contains a `generators/` directory and a test suite, consistent with a Yeoman generator organized around reusable templates.

The documented data flow starts with `yo code`. Yeoman asks for the information required by the selected customization or extension type, then renders the corresponding template into an absolute or relative destination. If no destination is supplied, the generator uses a folder in the current working directory whose name comes from the extension display name. Supplying `.` targets the current folder instead.

The prompts affect concrete files. The README says the templates create a base folder and render a rough `package.json`. They also import assets required by the selected project, such as `tmBundles` or the VS Code Library. For extension projects, the generated `.vscode/launch.json` configuration lets VS Code launch the extension and attach to a process for debugging.

The package is an ES module, and its declared Node.js range is `>=20.5.0`. Its tests use the built-in Node.js test runner, while Yeoman packages provide the generator test environment. This makes Yo Code a source generator rather than a runtime library that ships inside the resulting extension. Generated projects still have their own dependencies, build process, and package manager.

## Installing Yo Code and creating the first extension

The README installs Yeoman and the VS Code extension generator globally through npm:

```bash
npm install -g yo generator-code
```

The command requires a Node.js installation compatible with the package's declared `>=20.5.0` engine. It makes both `yo` and the `generator-code` package available to the Yeoman command line. The documentation does not describe a separate configuration step after installation.

Start the interactive generator with:

```bash
yo code
```

Yeoman then presents the prompts. The reader should supply the extension type and metadata requested by the terminal, choose any applicable development options, and select a destination. Without a destination argument, the generated folder is based on the extension display name.

For a quicker first generation, the documented command below creates `./Hello` as a TypeScript extension, skips optional prompts, and uses defaults:

```bash
yo code Hello -t=ts -q
```

The resulting directory should contain the initial package metadata, source structure, and any files required by that template. If the project is an extension, its `.vscode/launch.json` should support launching it and attaching to a process.

Several options can be combined at invocation. The following documented command targets the current directory and opens the result in VS Code Insiders:

```bash
yo code . -O
```

This option changes the editor used to open the generated project. It does not itself indicate that the extension should be released for the Insiders build. The README does not describe publishing or release automation.

## Interactive, quick, and Docker-based generation paths

Yo Code offers three practical entry paths. The interactive command exposes the generator's questions and is the best fit when the developer has not settled the project name, type, package manager, or bundler. Quick mode accepts defaults for optional choices, which makes it useful for inspecting the current template quickly or generating a repeatable starting point in scripts.

The documented options include `--pkgManager` for `npm`, `yarn`, or `pnpm`, and `--bundle` for `webpack` or `esbuild`. These are selections, not independent build systems bundled by Yo Code itself. The README states that the generated project can be configured to bundle the extension with webpack or esbuild. It does not publish a complete list of generated dependencies or explain all bundler defaults.

A Docker route is also documented. From the relevant project directory, build the image with:

```bash
docker build -t vscode-generator-code .
```

The repository's `Dockerfile` uses `node:22-alpine`, installs Git, installs `yo` and `generator-code` globally, copies the repository, and declares `yo code` as its entry point. Run the built image with the current directory mounted at `/usr/src/app`:

```bash
docker run -it -v $(pwd):/usr/src/app vscode-generator-code
```

The mount lets the interactive generator write results into the host directory. This approach avoids installing Node.js packages on the host, but it still requires Docker and Git inside the image. The documented `docker run` command also does not pass generator options such as destination, extension type, or package manager, so those selections normally come from prompts.

## Generated choices and their maintenance consequences

The selected JavaScript or TypeScript mode determines the starting language of an extension project, while the package manager choice establishes how its dependencies and scripts will be handled. The bundler choice can also alter later build requirements. These decisions affect generated configuration and the work required to release an extension, so selecting them only by habit may leave the project carrying avoidable tooling complexity.

Yo Code also supports optional Git initialization through `--gitInit`. The README does not specify whether this option creates a repository, adds files to staging, or makes an initial commit. Developers who need a precise commit or branch policy should inspect the repository after generation instead of assuming the option performs a complete repository setup.

For local generator development, the README gives a specific workflow. After changes, run `npm link` before invoking `yo code` to expose the local package to the command line:

```bash
npm link
```

Then launch the local generator:

```bash
yo code
```

This workflow is for maintainers of the generator itself, not a prerequisite for ordinary extension development. The package runs its tests before publishing through the `prepublishOnly` script:

```bash
npm test
```

The test command uses `node --enable-source-maps --test test/*.mjs`. For adopters, the relevant upgrade cost comes from reviewing generated templates after a new `generator-code` release and adapting existing internal conventions. The README does not provide a migration procedure for projects already generated by earlier versions.

The repository is not archived, and its last push was on 2026-10-12. Recent releases include `v1.12.0` on 2026-06-23, `v1.11.18` on 2026-02-28, and `v1.11.17` on 2026-02-03. These dates show recent repository activity and published versions, but they do not establish that any generated extension will remain compatible without review.

## Where hand-written scaffolding or another generator is preferable

The clearest alternative is assembling the VS Code extension structure manually. That approach takes more initial work, but it gives the developer direct control over `package.json`, source layout, build scripts, bundler configuration, and `.vscode/launch.json`. It is usually the better choice when a repository must follow a strict organizational template or when generated defaults would need to be removed immediately.

Another alternative is a different Yeoman generator, provided that project offers the exact extension type and toolchain required. Yo Code does not claim to be the only Yeoman path to a VS Code extension. The decision should be based on documented prompts, generated files, package-manager support, bundler support, and the extension templates themselves. A generic project initializer is useful only if its output matches the expected `contributes` structure and development entry points for the intended extension.

Yo Code has a clear failure mode if it is treated as an application framework. It creates files and can open or initialize parts of a project, but the documentation does not describe watching source files, recompiling after edits, packaging a VSIX, publishing an extension, or managing extension updates. Those steps remain part of the generated project's development setup.

It is also the wrong tool when the desired project cannot be represented by its prompt choices. The README does not document arbitrary templates, a plugin API for adding custom generator types, or a configuration file that defines a house layout. In such cases, adapting another scaffold or maintaining a small internal generator will usually be more predictable than fighting the available options.

## Yo Code licensing and repository boundaries

The licensing information needs direct inspection. The repository metadata classifies `LICENSE` as Other, while both the README badge and `package.json` identify the project as MIT. The repository contains a dedicated `LICENSE` file and a `thirdpartynotices.txt`, so an engineer should review those files directly for the exact terms applicable to this version.

This is not legal advice. It is a documentation consistency issue. The README links to the MIT license URL, and the npm package metadata declares `"license": "MIT"`, but those statements do not replace reading the repository's own `LICENSE` file. The generated extension may also depend on third-party packages with separate terms, so its final dependency set is a separate licensing consideration from the generator package.

The package's repository URL points to `Microsoft/vscode-generator-code`, and its declared homepage points to the Visual Studio Code site. There is no separate project homepage documented for Yo Code. Support information is not described in the README, while `SECURITY.md`, GitHub workflows, and the `bugs` URL indicate that repository administration exists outside the installation tutorial.

## Conclusion

Yo Code fits developers who want a conventional VS Code extension or customization scaffold without assembling every file by hand. It is a poor fit for projects that need an unusual repository layout or expect the generated extension to be production-ready. Before adoption, inspect the LICENSE file to resolve its reported classification, confirm Node.js 20.5.0 or newer is available, and generate one project in quick mode to check that its prompts, bundler choices, and package manager match the intended workflow.

## FAQ

### How do I install Yo Code for Visual Studio Code extensions?

Install Yeoman and the generator globally with `npm install -g yo generator-code`. The package requires Node.js 20.5.0 or newer.

### Which VS Code extension types can Yo Code generate?

The documented options include `ts`, `js`, `colortheme`, `language`, `snippets`, and `keymap`. The README presents the list with an ellipsis, so it should not be treated as a complete inventory of every template.

### Can Yo Code create a TypeScript extension without prompts?

Yes. The documented command `yo code Hello -t=ts -q` creates a TypeScript project in `./Hello` and skips optional prompts by using defaults.

## Sources

- [Issues](https://github.com/microsoft/vscode-generator-code/issues)
- [microsoft/vscode-generator-code on GitHub](https://github.com/microsoft/vscode-generator-code)
- [README](https://github.com/microsoft/vscode-generator-code/blob/main/README.md)
- [Releases](https://github.com/microsoft/vscode-generator-code/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-generator-code
