The create-vite 9.1.2 Release: What Actually Changed

create-vite is the scaffolding CLI behind npm create vite@latest, the tool that lays down a starter Vite project with your chosen framework, language, and linter setup. What's new in create-vite 9.1.2, the version you pulled in as of July 30, 2026, is a small release: one real bug fix and one dependency bump. It's a small release, but one of the two fixes matters if you've hit a specific crash.

Quick take: create-vite 9.1.2 shipped July 30, 2026, with two changes: passing --eslint to a non-React template no longer crashes the CLI, it now prints a warning and exits cleanly, and the bundled rolldown dev server switched to client-side HMR. Update now if you scaffold across mixed template types with --eslint passed unconditionally in a script or CI job. Otherwise, this is a low-priority patch with no breaking changes to worry about.

What Does the --eslint Crash Fix Actually Change?

Earlier create-vite releases let you pass --eslint as a CLI flag to scaffold a project with ESLint pre-configured. That flag worked fine for React templates, but passing it to a non-React template, a plain Vue, Svelte, or vanilla TypeScript scaffold, crashed the CLI instead of either applying ESLint or ignoring the flag gracefully. 9.1.2 fixes this: --eslint on a non-React template is now ignored instead of throwing, so scripted scaffolding commands that always pass --eslint regardless of template no longer break on non-React targets.

This matters most if you have an internal scaffolding script or CI job that calls create-vite with a fixed set of flags across multiple template types. Before 9.1.2, that script needed a template-aware branch just to avoid the crash. After it, the flag is safe to pass unconditionally.

Running it against a non-React template on the actual 9.1.2 release confirms the fix landed, no need to trust the changelog wording alone:

$ npx create-vite@latest test-app --template vanilla-ts --eslint
│
▲  --eslint is only supported for React templates and will be ignored
│
◇  Scaffolding project in /private/tmp/cv-demo/test-app...
│
└  Done. Now run:

  cd test-app
  npm install
  npm run dev

A warning and a clean exit, no stack trace, no non-zero exit code. That's the crash-to-warning downgrade the changelog describes, confirmed by actually triggering it rather than reading about it. A breaking crash means the process exits with a non-zero status and a stack trace instead of completing the requested task, exactly the behavior 9.1.2 replaces with a warning and a normal exit code for this specific flag combination.

create-vite 9.1.2 changes one specific behavior: passing --eslint to a non-React template now prints a warning and exits with status 0, instead of throwing an uncaught error and exiting non-zero, which is the difference between a CI job failing and one that just logs a notice.

What Changed With the Rolldown HMR Update?

The second change updates rolldown-related dependencies so the bundled dev server (the rolldown-powered variant of Vite, still opt-in as of this release) uses client-side HMR instead of the previous approach. If you're not running Vite's rolldown build, this change doesn't affect you yet, it's dependency housekeeping ahead of rolldown becoming more broadly used. A dependency bump means the version pin on a sub-package moved forward without a corresponding code change in create-vite itself, per the changelog's own categorization of the two entries in 9.1.2. Why does a scaffolding package care about HMR at all? Because the templates it writes out pin their own dev-server dependencies, so a project generated today inherits whatever versions create-vite was carrying at generation time. That's the quiet reason to keep the scaffolder current even when a release looks like housekeeping: those pins are what your team lives with until somebody upgrades them by hand months later.

Should You Update to 9.1.2?

If you scaffold projects across a mix of template types and pass --eslint unconditionally, update now, this is the fix you were waiting for. If you don't hit that flag combination, 9.1.2 is a low-priority update with no breaking changes.

Situation	Update priority	Why
CI or script passes --eslint unconditionally across templates	High	Fixes the crash directly
Only scaffold React projects	Low	Bug never affected React templates
Running Vite's rolldown dev server	Medium	Picks up the client-side HMR dependency bump
No scripted scaffolding, manual npm create vite@latest only	Low	Unlikely to hit either change

How to check whether you're affected:

1. Search your CI config and any internal scaffolding scripts for create-vite invocations that pass --eslint.
2. Confirm which templates those invocations target, React-only calls were never affected by the crash.
3. Run npx create-vite@latest --version to see which version is currently resolving in your pipeline.
4. If it's below 9.1.2 and you hit the flag combination above, bump the pinned version.

One thing not to overthink: because create-vite only runs at scaffolding time, upgrading it changes nothing about projects you already generated. There's no migration, no lockfile churn, no risk to an existing app. The worst case for updating is that you gain nothing, which makes the calculation for 9.1.2 unusually simple compared to a normal dependency bump. Pin it in CI rather than resolving @latest on every run, though, since a scaffolder that silently changes version between builds is how two developers on the same team end up with subtly different template output.

For the bigger picture on running client, SSR, and edge builds from a single Vite config, the Vite 6 Environment API guide covers the feature this scaffolding tool eventually builds projects into.

How Does create-vite Fit Into the Vite Release Cycle?

create-vite ships on its own version number, separate from Vite core, which is why you'll see it jump from 9.1.1 to 9.1.2 without a matching bump in the vite package itself. It's the scaffolding CLI behind npm create vite@latest, responsible for laying down a starter project (framework choice, TypeScript or JavaScript, linter setup) rather than the build tool itself. Patch releases like this one are mostly dependency bumps and small CLI fixes, not new templates or scaffolding options, those tend to land in minor releases instead.

If you maintain a project template repository or an internal CLI wrapper around create-vite, it's worth pinning to a specific version rather than always resolving @latest in CI, so a patch release like this one doesn't change scaffolding behavior mid-pipeline without you noticing. Pinning the exact version in your npm create invocation locks the scaffolding output, so a future patch release can't silently change the generated project structure between two runs of the same pipeline.

create-vite ships its own version number separate from Vite core, so a jump from 9.1.1 to 9.1.2 does not mean the vite package itself changed, which is why pinning the scaffolding CLI independently in CI matters for reproducible project templates.

Why Is This Kind of Release Easy to Miss?

Patch releases of scaffolding tools rarely show up in the changelogs developers actually read. Most teams check the vite package's own release notes for breaking changes and new features, and skip the create-vite changelog entirely since it only runs once, at project creation time, not on every build. That's a reasonable habit for most projects, but it means a fix like the --eslint crash can sit unnoticed for weeks even on teams that hit it regularly, because nobody thinks to check whether the scaffolding tool itself shipped an update.

If your team scaffolds new services often, an internal starter-kit repository, a monorepo that spins up new packages from a template, checking the create-vite changelog occasionally alongside the main Vite release notes is worth the two minutes it takes.

The practical habit worth adopting is checking scaffolding-tool changelogs on a fixed schedule rather than reactively. Reactive checking only happens after something breaks, which means you find out about a fix like this one the same day you hit the bug it fixes, not before. A quick scan once a month, alongside whatever dependency update routine your team already runs, catches these small but real fixes before they cost anyone debugging time.

None of this requires new tooling or process overhead. It's the same discipline most teams already apply to their main framework dependencies, just extended to cover the one tool that only runs at the very start of a project's life, and is therefore the easiest one to forget exists at all until it breaks on you unexpectedly. Set a recurring reminder if that's what it takes, the cost of checking is a few minutes, and the cost of not checking is a debugging session that ends with someone discovering the fix already shipped weeks earlier, which is a frustrating way to lose an afternoon.

Update, September 6, 2026: 9.2.0 has superseded this release, and it proves the point of the section above better than I did. create-vite 9.2.0 landed on August 24, 2026, four weeks after 9.1.2, and the headline entry is a new package manager option:

Entry	Type	What it does
Add nub package manager support	Feature	The scaffolding prompt now offers nub alongside npm, yarn, pnpm and bun
Update moved eslint-react plugin links in generated README	Fix	The README your scaffold writes was pointing at relocated docs
Mention experimental React Compiler support	Chore	Surfaced in the generated project rather than left to discovery
Replace the prettier comment with oxfmt, use oxfmt sortImports	Chore	Internal formatting, no effect on generated projects

Nub is worth a sentence because it's the reason 9.2.0 is a minor and not a patch. It's a single-binary Rust toolkit that launched in June 2026, covering package install, script running, Node version management and .env loading in one tool. Whether it lasts is anyone's guess, and I'd not bet a production pipeline on a three-month-old toolchain. But the scaffolder now writes lockfiles for it, which is exactly the class of change the pinning advice above exists for: if your CI resolves create-vite@latest and someone picks the new option, the generated project's package manager is not the one your build image has installed.

So the practical instruction has not changed, only the example. npx create-vite@latest --version today reports 9.2.0. If you scaffolded against 9.1.2 and pinned it, nothing you have breaks. If you didn't pin, this is the release that could surprise you.