vite-plus v0.2.1

Restores support for older Node.js (back to 20.19.0) and makes vp exec --fail-if-no-match fail correctly on unmatched filters.

Fixes & Enhancements

• Stop blocking older Node.js versions: v0.2.0 blocked commands when the resolved Node.js version fell outside the declared range. This reverts that enforcement and widens engines.node to ^20.19.0 || ^22.18.0 || >=24.11.0, matching Vite's own ^20.19.0 floor, so older Node that works in practice (e.g. Node 20 in rolldown CI) is no longer rejected (#1865), by @fengmk2
• vp exec --fail-if-no-match: exit non-zero when one or more --filter expressions match no workspace packages. Strict mode previously only warned and returned success, so typoed filters looked successful in CI even though no package command ran (#1859), by @jong-kyung

Bundled Versions

Tool	Version	Source
vite	8.0.16	f94df87
rolldown	1.1.1	d7f919c
tsdown	0.22.3	npm
vitest	4.1.9	npm
oxlint	1.70.0	npm
oxlint-tsgolint	0.23.0	npm
oxfmt	0.55.0	npm

Upgrade

vp upgrade

Upgrading from 0.1.x to 0.2.1 Prompt

You are upgrading a project that uses Vite+ (the `vp` CLI) from v0.1.x to v0.2.1.

v0.2.1 has one breaking change vs v0.1.x: it consumes upstream Vitest directly. The `@voidzero-dev/vite-plus-test` wrapper package is removed. `vitest` and the base browser runtime (`@vitest/browser`, `@vitest/browser-preview`) now come in transitively through `vite-plus`. The opt-in browser providers (`@vitest/browser-playwright`, `@vitest/browser-webdriverio`) are NOT shipped by `vite-plus`: any project that runs browser-mode tests must install the provider it uses itself.

Do not run `vp migrate` for this upgrade; it is not reliable enough yet. Make the changes yourself by editing the project's files, then verify by running the tools.

How to run vp: if a global `vp` is available, use it. Otherwise this project only ships the local CLI from the `vite-plus` package, so run vp as the project-local binary (for example via the package manager's exec: pnpm exec, npx, yarn, or bunx). After any install, re-resolve vp so you always run the version currently in the project.

Do the following:

1. Set the `vite-plus` dependency to the exact version `0.2.1` and reinstall, so the new toolchain is installed and the lockfile moves off 0.1.x. In a monorepo, do this for every workspace package that depends on `vite-plus` (a shared `catalog:` entry covers them all at once). Changing the spec to `0.2.1` is what moves the lockfile off the old resolution; a reinstall that leaves the spec unchanged would keep the old version.

2. Remove the `@voidzero-dev/vite-plus-test` wrapper from the project. Search everywhere it could appear: package.json, the lockfile, any workspace or catalog config (such as pnpm-workspace.yaml or .yarnrc.yml), and the source files. Then classify the project and apply the matching case. Note these are not exclusive: a browser-mode project is also handled by case C in addition to removing the wrapper config.

   First, determine the project's Vitest usage:
   - BROWSER MODE: the project runs Vitest in the browser. It does if a config or test file imports a real browser provider (`vite-plus/test/browser-playwright` or `vite-plus/test/browser-webdriverio`, or the pre-upgrade raw forms `@vitest/browser-playwright` / `@vitest/browser-webdriverio`), or sets `test.browser.enabled`. This needs extra deps regardless of anything below; see case C.
   - DIRECT vitest usage: a source or test file imports directly from `vitest` or `@vitest/...`, or a `@vitest/*` package is listed in its dependencies (for example a coverage provider). Plain imports from `vite-plus/test` and `vite-plus/test/*` do NOT count as direct usage; a `vite-plus/test/browser-*` provider import is a browser-mode signal (case C), not direct usage.

   Case A - node-mode only (no direct vitest usage, no browser mode; the common case): remove the vitest configuration entirely. In package.json, delete the `vitest` entry from `dependencies` / `devDependencies` in whatever form it takes (a `@voidzero-dev/vite-plus-test` alias, a `catalog:` reference, or a plain version). Also remove the `vitest` entry from every dependency-resolution mechanism in the project: both `overrides` and `resolutions`, pnpm `overrides`/`catalog` (in package.json or pnpm-workspace.yaml), and any catalog entry. If `vitest` appears in more than one of these, remove all of them. Do not add a pinned `vitest`; it arrives transitively through `vite-plus` and the node-mode test command works without it.

   Case B - direct vitest usage: pin upstream vitest to the version bundled with vite-plus (4.1.9 for v0.2.1), and upgrade every vitest ecosystem package the project depends on so the whole tree resolves to a single vitest. Set each `@vitest/*` package the project lists (for example `@vitest/coverage-v8`, `@vitest/ui`, `@vitest/browser`) to that same version (4.1.9), since those are pinned to an exact vitest version. Also update any other vitest integration package (such as `vitest-browser-*`) to a release compatible with that vitest version. Leaving an ecosystem package on an older version pulls in a second copy of vitest, which Vitest rejects at runtime.

   Case C - browser mode (in addition to removing the wrapper config): you MUST add two deps to the workspace package that runs the browser tests (not the repo root, unless that is where the tests live), both pinned to the bundled vitest version so the tree still resolves to a single vitest:
     - The browser provider the project actually uses: `@vitest/browser-playwright@4.1.9` and/or `@vitest/browser-webdriverio@4.1.9`. Without it, config load fails with `Cannot find package '@vitest/browser-playwright'` from `vite-plus/test/browser-playwright`. Make sure its framework peer is present too (`playwright` for Playwright, `webdriverio` for WebdriverIO); the project usually already has it.
     - A direct `vitest@4.1.9`. This is the one case where you DO add a pinned vitest, and it contradicts the "never add vitest" rule that holds for node mode. Reason: under pnpm's isolated node_modules, `vitest` is only a transitive dep of `vite-plus`, so the browser-tester Vite server (rooted at the consumer project) cannot resolve `vitest/internal/browser` or the `vitest > ...` optimizeDeps entries. The symptom is `Failed to resolve import "vitest/internal/browser"` followed by `Failed to connect to the browser session ... within the timeout` and a `no tests` run. vite-plus 0.2.1 ships a `vite-plus:vitest-resolver` plugin meant to rescue this, but it does not reach the separate `@vitest/browser` orchestrator server, so a direct `vitest@4.1.9` (matching the bundled version, single copy preserved) is required. (If a future vite-plus fixes the resolver to cover the browser-tester server, this direct `vitest` may become unnecessary; re-check.)

   In all cases, also delete any dependency-resolution config that existed only to accommodate the wrapper or the old vitest, for example pnpm `peerDependencyRules` entries (`allowedVersions` / `ignoreMissing`) referencing `vitest`, `@vitest/*`, or `@voidzero-dev/vite-plus-test`, and the equivalent peer-tweak config in other package managers (such as yarn `packageExtensions`). Leave rules that are unrelated to vitest or the wrapper untouched.

3. Keep the `vite` -> Vite+ core override (it is still required) and set it to the matching exact version: map `vite` to `npm:@voidzero-dev/vite-plus-core@0.2.1` in whatever override, resolution, or catalog form the project already uses. `@voidzero-dev/vite-plus-core` is released in lockstep with `vite-plus`.

4. Leave imports from `vite-plus/test` (and `vite-plus/test/*`, including `vite-plus/test/browser-playwright`) unchanged; that is the stable public API. Only if a file imports directly from `@voidzero-dev/vite-plus-test`, repoint it to `vite-plus/test`. Leave `declare module 'vitest'` / `declare module '@vitest/browser*'` type augmentations pointing at the upstream module (they must target the upstream identity to merge).

5. Reinstall so the lockfile reflects your edits, then verify:
   - No reference to `@voidzero-dev/vite-plus-test` remains anywhere outside node_modules (source, configs, lockfile).
   - The dependency tree resolves to a single `vitest` version (4.1.9) with no duplicate copies. Note that one `vitest@4.1.9:` entry in the lockfile `packages:` section plus one `vitest@4.1.9(...)` key in `snapshots:` is still a single version, not a duplicate.
   - The project's tests pass with Vitest's native banner; for browser mode, confirm the suite actually runs in the browser (you get passing test files, not `no tests` or a session timeout). Browser tests also need the browser binary installed (e.g. `npx playwright install chromium`).
   - The Vite+ check workflow passes (exit 0). A pre-existing lint/format warning in a file you did not touch is not a failure; report it but do not fix it.

   Troubleshooting: if you hit `vitest/internal/browser` resolution errors, or see duplicate `@vitest/browser` / `vite-plus` peer-variant directories under `node_modules/.pnpm` after several sequential installs across this dependency-graph change, do a clean reinstall (remove `node_modules` in the root and all workspaces, remove the Vite optimize caches `node_modules/.vite`, then reinstall) to collapse the stale variants before concluding it is a code problem.

Constraints:
- Do not run `vp migrate`.
- Do not bypass git hooks. If a pre-existing failure blocks you, report it rather than forcing through.
- Make the smallest set of edits that reaches the end state above; do not reformat unrelated files. (For browser mode, the added `vitest` + provider pins ARE part of that minimal end state.)
- When done, give me a short summary: old vs new `vite-plus` version, the files you changed, the test/check results, and call out explicitly any dependency you added beyond the wrapper removal (especially a direct `vitest`) with the reason.

Full Changelog: v0.2.0...v0.2.1

Published Packages

• @voidzero-dev/vite-plus-core@0.2.1
• vite-plus@0.2.1

Installation

macOS/Linux:

curl -fsSL https://vite.plus | bash

Windows:

irm https://vite.plus/ps1 | iex

Or download and run vp-setup.exe from the assets below.