create-vue is a scaffolder, and the Vue team wants you to know it

Three commands, and one rule you should not break

The README's usage section is short enough to state fully. To create a new Vue project you run:

npm create vue@latest

To see the available feature flags and options:

npm create vue@latest -- --help

To create a Vue 2 project, for cases where you must support IE11:

npm create vue@legacy

The rule sits in a callout right under the first command: `@latest` or `@legacy` MUST NOT be omitted, otherwise `npm` may resolve to a cached and outdated version of the package. That is a specific and correct warning about npm's package resolution, and it is the kind of detail that causes otherwise inexplicable confusion when a team member runs a setup doc from six months ago and gets an old scaffold.

There is a platform-specific footnote too. PowerShell users need to quote the double dashes as `npm create vue@latest '--' --help`, because PowerShell treats the bare `--` as a switch terminator rather than passing it through. Small thing, but it is exactly the kind of note that gets lost in internal docs.

The help output is described as showing feature flags such as `--typescript` and `--router`, plus options such as `--bare` for a minimal boilerplate project. Running in interactive mode by default is a deliberate choice, and the flags exist so the same tool works in CI without a human at the prompt.

Vite-powered, and only a scaffolder

The README's Difference from Vue CLI section draws two distinctions, and the second one is the important one.

The first is the build tool. Vue CLI is webpack-based, while `create-vue` is based on Vite, and the README argues that Vite supports most of the configured conventions found in Vue CLI projects out of the box while providing a significantly better development experience through fast startup and hot-module replacement speed. That argument is linked to Vite's own documentation rather than asserted on its own, which is fair.

The second distinction is about scope. Unlike Vue CLI, `create-vue` itself is just a scaffolding tool: it creates a pre-configured project based on the features you choose and delegates the rest to Vite. The README also notes that projects scaffolded this way can directly use the Vite plugin ecosystem, which is Rollup-compatible.

That is the framing to keep in your head. There is no Vue CLI-style webpack configuration layer to understand, no service layer, no `vue.config.js` convention with magic. What you get is a Vite project with some decisions already made for you. If you were expecting the Vue CLI feature set, the gap is not a missing feature so much as a different category of tool.

What the repository looks like from the outside

The tree tells you more about the design than the README does. There is `index.ts` as the entry, `template/` for the project templates, `locales/` for prompt translations, `__test__/` for tests, `playground/` for local experimentation, and `scripts/` for the tooling the package.json scripts call, including `snapshot.mjs`, `release.mjs` and `test.mjs`. Build config lives in `rolldown.config.ts`, `vite.config.ts` and `vitest.config.ts`, with `tsconfig.json`, `pnpm-workspace.yaml`, `pnpm-lock.yaml` and `.pre-commit-config.yaml` alongside. `utils/`, `.vite-hooks/` and `.vscode/` round it out.

Several of those entries are worth a second look. The build uses Rolldown rather than Rollup directly, with `rollup-plugin-license` as a dependency, which is a sign of how the toolchain has moved. `vite-plus` and `vitest` are pinned through a `catalog:` reference rather than explicit versions, which is the pnpm workspace catalog feature and explains the `pnpm-workspace.yaml`. Scripts use `zx` for shell automation, and the `packageManager` field pins pnpm at 12.4.1.

The `locales/` directory is the quietly interesting one for a scaffolder. Prompt text is translated rather than hardcoded, which is a level of care that shows up in the release history too, in the form of a fix to clarify that the overwrite prompt deletes all existing files.

Package metadata is worth reading directly. The version is 3.24.0, the bin maps `create-vue` to `bundle.js`, `type` is `module`, published files are limited to `bundle.js`, `locales`, `template` and an exclusion for template `node_modules/.bin` entries, and `publishConfig` sets public access with provenance enabled.

Recent releases are about Node versions and TypeScript plumbing

The three most recent releases read as maintenance with one feature that matters for how you invoke the tool.

Version 3.24.0, published 2026-09-16, added a `tsgo` option to replace TypeScript with typescript-native-bridge, clarified that the overwrite prompt deletes all existing files, kept Oxlint dependencies aligned, and added an extension to the Vitest config import. Version 3.23.0, published 2026-07-21, enabled TypeScript with a default flag, added detection of the `nub` package manager, replaced a Vue 3.6 beta option with the release candidate, updated the vscode settings in the template, and moved the Pinia dependency to v4. Version 3.22.4, published 2026-06-17, dropped Node 20 support and advanced minor version requirements, quoted a glob in a package script to fix bun and yarn issues on Windows, and added a missing `vue-eslint-parser` dependency to avoid warnings.

Two patterns stand out. The first is that scaffold templates are themselves software with their own bug reports: the missing eslint parser dependency and the Windows glob quoting fix are both real defects in generated projects that the maintainers tracked down and fixed. The second is that the Node floor moved, which is the operational detail most likely to bite a team with an older CI image. The `engines` field in package.json now reads `^22.18.0 || >=24.12.0`, consistent with dropping Node 20.

The GitHub description on the repository carries a crossed-tools emoji ahead of the text, which is a small reminder that these repositories are also npm package landing pages, not only code.

Vue 2 support still exists, with a warning attached

The Vue 2 path is documented rather than removed, which is unusual for a project this closely aligned with the framework's current line. The README says that if you need to support IE11 you can create a Vue 2 project with `npm create vue@legacy`, and immediately follows it with a warning callout linking to Vue 2's end-of-life notice at v2.vuejs.org/eol.

So the shape is deliberate: the capability is maintained for a specific compatibility need, and the documentation tells you plainly that the target is end of life. A team maintaining an IE11-reachable product knows exactly why they are running that command, and everyone else is nudged away from it.

This also connects to the Node floor question. `@legacy` is a separate tag from `@latest`, so the two commands resolve to different package versions, and the warning about not omitting the tag becomes more important rather than less: running `npm create vue` with no tag during the legacy window was exactly the kind of ambiguity the callout is guarding against.

Where the documentation stops and external guides take over

Migration is where this repository stops being a self-contained source of answers. The README has a Migrating from Vue CLI section that links out rather than explains. It points to a Vue CLI to Vite migration guide hosted on VueSchool, and to tools and plugins for migration collected on the Awesome Vite GitHub page. Both are third-party destinations, which means the authoritative migration knowledge for a Vue CLI codebase lives outside the project.

That is a reasonable division for a team of this size, and it is not unusual: scaffolding guides get written once and then drift, whereas the bundler ecosystem changes faster than a repo README can follow. But it means a reader evaluating `create-vue` should read the Vite documentation and, if coming from Vue CLI, the migration guide, rather than expecting the repository to answer those questions.

On licensing, there is a mismatch worth recording rather than resolving. GitHub reports NOASSERTION for this repository, while `package.json` declares `"license": "MIT"` and the tree contains a `LICENSE` file at the root. As with many npm-first projects, the package manifest is the more specific source, since that field is what consumers' tooling reads, and the presence of the license file means the terms are written down. If you are vendoring the generated templates rather than the CLI itself, note that generated projects carry their own license choice, which the scaffolder offers as a feature flag rather than deciding for you.

The project was last pushed on 2026-09-21, is not archived, and reports 4,405 stars with 45 open issues. For a project whose entire runtime surface is one command, that issue count is a good sign that the templates and the prompts are being exercised.

Editorial conclusion

create-vue is a deliberately thin tool, and that is the correct shape for a scaffolder: it makes a decision tree, writes a template, and gets out of the way. Treat it that way rather than as a framework, and the main thing to get right is passing feature flags instead of accepting every default, because a scaffolded router, store or TypeScript setup all become code you own. Two practical notes before you scaffold: the README insists that `@latest` or `@legacy` must not be omitted, because npm can otherwise resolve to a cached older package, and the package's `engines` field requires Node `^22.18.0 || >=24.12.0`, which matches the 3.22.4 release that dropped Node 20 support.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. vuejs/create-vue on GitHub