If you scaffold new projects with npm create vite@latest, you pulled in version 9.1.2 as of July 30, 2026. It's a small release, but one of the two fixes matters if you've hit a specific crash.
The --eslint Crash Fix
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.
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.
Should You Update?
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.
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 create-vite Fits 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.
Why This Kind of Release Is 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.