yeoman/yo: the CLI that runs Yeoman generators

The problem yo solves: one command in front of many generators

A generator in the Yeoman ecosystem is a plugin, not a template folder you copy. The README describes it plainly: "A generator is basically a plugin that can be run with the `yo` command to scaffold complete projects or useful parts." That split is the whole design. Generator authors publish npm packages named `generator-*`, and yo is the piece that finds them, shows their options and hands control to the generator's own prompting and file-writing code.

The audience follows from that. yo is for developers who already know which generator they want, and for teams that publish one internally so new services start from the same layout. If you have no generator installed, yo has nothing to scaffold. That is not a defect; it is the boundary of the tool. The homepage at yeoman.io points to a generator directory, and the README sends people who want to build their own to the authoring documentation rather than explaining generator internals here.

How yo finds and runs a generator

The package is an ES module (`"type": "module"`) whose binary entry is `lib/cli.js`, and it depends on `yeoman-environment` for the actual generator lifecycle, `@yeoman/adapter` for terminal interaction, `meow` for argument parsing and `cli-list`, `npm-keyword` and `package-json` for discovery. The dependency list is the architecture: yo is a thin shell around the environment, plus the lookup logic that decides which generators exist.

Discovery has two sources. Globally installed npm packages whose names match the generator keyword are one; a path on disk is the other, which is why `yo ./path/to/local/generator` works. The `--local-only` flag switches the global lookup off, which matters in CI or on a machine where a stale global generator would otherwise shadow the one in your working tree. `--generators` prints what was found, and `--help` prints the help menu with the list of found generators attached. `update-notifier` and `configstore` handle the version notice and cached state, and `global-agent` is present so that lookups and installs can go through a proxy.

One detail worth knowing before you file a bug: `package.json` defines `postinstall` and `postupdate` scripts that both run `yodoctor`, so a diagnostic pass runs automatically after installation and after updates, not only when you type `yo doctor`.

Install yo and scaffold a first project

The README gives the install as a global npm package. Two commands are needed, because yo and the generator are separate packages.

npm install --global yo
npm install --global generator-webapp

The first installs the runner; the second installs the generator that supplies the templates. After the second command finishes, `yo --generators` should list `webapp` among the available generators. If it does not, the package either failed to install or landed somewhere npm's global prefix does not expose to yo.

Running it is a single word:

yo webapp

The generator takes over from there, asking its own questions and writing files into the current directory. yo does not decide the questions or the output; the generator does. Homebrew users get an alternative path from the README:

brew install yo

Local generators skip the global install entirely, which is the fastest way to try one you are editing:

yo ./path/to/local/generator

When something goes wrong, the README points at a diagnostic command before anything else:

yo doctor

If doctor does not explain the failure, the README asks for `yo --version` and `node --version` in the issue, and states that problems occurring only inside a generator belong on that generator's repository.

Where yo stops helping

The most common wrong turn is expecting yo to be the scaffolder. It is not. The npm package is named `yo`, described as a CLI tool for running generators, and its `files` field ships only `lib`. There are no templates in this repository. Installing yo alone gives you a command with nothing to run.

Version compatibility is the second trap. yo 7.0.1 depends on `yeoman-environment` ^6.0.1, and a generator written against an older environment may not load cleanly. The README does not document a compatibility matrix or a rollback procedure, so the practical fallback is pinning an older yo version yourself and testing the generator against it.

Third, the troubleshooting section is explicit about where responsibility ends: if an issue only appears with one generator, the README says to report it on the generator's repository. That is a reasonable boundary, but it means a broken generator can look like a broken yo to anyone who has not read this far. The `--no-color` flag exists for terminals and log capture that mangle escape sequences, and `--local-only` exists for the shadowing case described above; neither is a fix for a generator that simply does not work.

yo compared with create-* scaffolders

The closest alternative pattern is the single-purpose scaffolder, the kind published as `create-something` and run through a package runner. The difference is scope, not quality. A create-* package bundles the runner and the templates together and produces exactly one kind of project. yo is a runner with no templates, and its value is that one installed command addresses every generator on the machine, whether it came from npm or from a path you passed on the command line.

That trade cuts both ways. With a create-* scaffolder you install nothing globally and pin the version in the invocation. With yo you install globally once, then add generators as separate global packages, which is convenient on a workstation and awkward in a container image where every generator becomes another layer. The generator ecosystem is also the reason yo exists: the README's whole pitch is the plugin model, and a scaffolder that only ever generates one project type has no equivalent problem to solve. If your organisation maintains several project templates and wants one entry point, yo's model fits. If you need one template, once, a create-* package involves fewer moving parts.

Maintenance, licence and upgrade cost

The repository is not archived, and the last push was on 2026-08-01. Releases are spaced out rather than continuous: v6.0.0 on 2025-11-12, v7.0.0 on 2026-02-28, and v7.0.1 on 2026-04-09. A major version roughly once a year, with patch releases in between, is the shape to plan around.

Upgrading yo is not the expensive part; upgrading the generators is. Because yo delegates to `yeoman-environment`, a major yo release can move the environment version underneath generators you did not write, and the README does not publish a support window for older generator APIs. Budget for testing each generator you depend on against a new major before rolling it out across a team, and keep the previous version pinned somewhere you can return to. The `postupdate` script running `yodoctor` gives you a diagnostic signal right after an upgrade, which is a small but real help.

The licence is BSD-2-Clause, a permissive licence that permits use and redistribution with the copyright notice and disclaimer retained. That is a summary of the identifier in `package.json` and the LICENSE file, not legal advice; if you redistribute yo inside a product, have your own counsel read the actual licence text. Note also that yo's dependencies carry their own licences, so an audit of the dependency tree is separate work.

Editorial conclusion

Adopt yo if your team already publishes or maintains a generator and wants a single, stable entry point for scaffolding, or if you are learning how Yeoman generators are structured. Do not adopt it expecting a scaffolder out of the box: the package ships the runner, not the templates, so a project with no generator gains nothing from installing it. Before you commit, run yo --generators to confirm what is actually visible on the machine, check that the generator you intend to use is compatible with yeoman-environment 6, and read the generator's own repository for its Node.js requirements, since yo's troubleshooting section points bug reports at the generator rather than at yo itself.

Frequently asked questions

Official sources

1. License: BSD-2-Clause
2. Project website
3. README
4. Releases
5. yeoman/yo on GitHub