Comparing changes

#1859) ## Summary Fixes #1858. `vp exec --fail-if-no-match` now exits with a non-zero status when one or more `--filter` expressions match no workspace packages. Previously, `vp exec` accepted and documented `--fail-if-no-match`, but the workspace execution path only emitted warnings and returned success. This made typoed filters look successful in CI even though no package command actually ran. ## Changes - Read `fail_if_no_match` before `PackageQueryArgs::into_package_query` consumes package args - Return `ExitStatus(1)` when strict mode sees unmatched package selectors - Match `vp run` / vite-task behavior by emitting an error instead of warnings in strict mode - Add snap coverage for: - single unmatched filter - unmatched + matched filters - multiple unmatched filters - successful matched strict filter

`vp` blocked commands when the resolved Node.js version fell outside the declared range (#1360), rejecting older Node that works in practice (e.g. Node 20 in rolldown CI). This removes the enforcement and widens `engines.node` to `^20.19.0 || ^22.18.0 || >=24.11.0`. The `^20.19.0` floor matches Vite's own minimum supported Node (`^20.19.0 || >=22.12.0`), so the declared range stays consistent with the bundled Vite.

@fengmk2

Release 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](#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](#1859)), by @jong-kyung ### Bundled Versions | Tool | Version | Source | | --- | --- | --- | | vite | `8.0.16` | [`f94df87`](vitejs/vite@f94df87) | | rolldown | `1.1.1` | [`d7f919c`](rolldown/rolldown@d7f919c) | | tsdown | `0.22.3` | [npm](https://npmx.dev/package/tsdown/v/0.22.3) | | vitest | `4.1.9` | [npm](https://npmx.dev/package/vitest/v/4.1.9) | | oxlint | `1.70.0` | [npm](https://npmx.dev/package/oxlint/v/1.70.0) | | oxlint-tsgolint | `0.23.0` | [npm](https://npmx.dev/package/oxlint-tsgolint/v/0.23.0) | | oxfmt | `0.55.0` | [npm](https://npmx.dev/package/oxfmt/v/0.55.0) | ### Upgrade ```bash vp upgrade ``` ### Upgrading from 0.1.x to 0.2.1 Prompt ```md 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` now comes in transitively through `vite-plus`. 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`. 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: - Decide whether the project itself depends on vitest. It does only if 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). Imports from `vite-plus/test` do NOT count. - If the project has no such vitest usage (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 test command still works. - If the project does use vitest directly, 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. - 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/*`) 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`. 5. Reinstall so the lockfile reflects your edits, then verify: confirm that no reference to `@voidzero-dev/vite-plus-test` remains anywhere outside node_modules, confirm the dependency tree resolves to a single `vitest` version (no duplicate copies), run the project's tests and confirm they pass (you will see Vitest's native banner), and run the Vite+ check workflow and confirm it passes. 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. - When done, give me a short summary: old vs new `vite-plus` version, the files you changed, and the test/check results. ``` **Full Changelog**: v0.2.0...v0.2.1 --- Merging this PR will trigger the release workflow. --------- Co-authored-by: voidzero-guard[bot] <278573678+voidzero-guard[bot]@users.noreply.github.com> Co-authored-by: MK <fengmk2@gmail.com>

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Comparing changes

Open a pull request

Commits on Jun 18, 2026

This comparison is taking too long to generate.

Uh oh!