Latest Results
chore(deps): update vite+ to v0.2.1 (#1225)
This PR contains the following updates:
| Package | Change |
[Age](https://docs.renovatebot.com/merge-confidence/) |
[Adoption](https://docs.renovatebot.com/merge-confidence/) |
[Passing](https://docs.renovatebot.com/merge-confidence/) |
[Confidence](https://docs.renovatebot.com/merge-confidence/) |
|---|---|---|---|---|---|
| [vite-plus](https://viteplus.dev/guide)
([source](https://redirect.github.com/voidzero-dev/vite-plus/tree/HEAD/packages/cli))
| [`0.2.0` โ
`0.2.1`](https://renovatebot.com/diffs/npm/vite-plus/0.2.0/0.2.1) |
|
|
|
|
---
### Release Notes
<details>
<summary>voidzero-dev/vite-plus (vite-plus)</summary>
###
[`v0.2.1`](https://redirect.github.com/voidzero-dev/vite-plus/releases/tag/v0.2.1):
vite-plus v0.2.1
[Compare
Source](https://redirect.github.com/voidzero-dev/vite-plus/compare/v0.2.0...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](https://redirect.github.com/voidzero-dev/vite-plus/pull/1865)),
by [@​fengmk2](https://redirect.github.com/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](https://redirect.github.com/voidzero-dev/vite-plus/pull/1859)),
by [@​jong-kyung](https://redirect.github.com/jong-kyung)
##### Bundled Versions
| Tool | Version | Source |
| --------------- | -------- |
-------------------------------------------------------------------------------------------------
|
| vite | `8.0.16` |
[`f94df87`](https://redirect.github.com/vitejs/vite/commit/f94df87ff03b40b65e29bacdc04cc18c7bccaa4a)
|
| rolldown | `1.1.1` |
[`d7f919c`](https://redirect.github.com/rolldown/rolldown/commit/d7f919c18980e6b4a26d06bd071d7cf14cf810a7)
|
| 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**:
<https://github.com/voidzero-dev/vite-plus/compare/v0.2.0...v0.2.1>
##### Published Packages
- `@voidzero-dev/vite-plus-core@0.2.1`
- `vite-plus@0.2.1`
##### Installation
**macOS/Linux:**
```bash
curl -fsSL https://vite.plus | bash
```
**Windows:**
```powershell
irm https://vite.plus/ps1 | iex
```
Or download and run `vp-setup.exe` from the assets below.
</details>
---
### Configuration
๐
**Schedule**: (in timezone Asia/Shanghai)
- Branch creation
- At any time (no schedule defined)
- Automerge
- At any time (no schedule defined)
๐ฆ **Automerge**: Enabled.
โป **Rebasing**: Whenever PR is behind base branch, or you tick the
rebase/retry checkbox.
๐ **Ignore**: Close this PR and you won't be reminded about this update
again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check
this box
---
This PR was generated by [Mend Renovate](https://mend.io/renovate/).
View the [repository job
log](https://developer.mend.io/github/oxc-project/oxc-resolver).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0My4yMTkuMCIsInVwZGF0ZWRJblZlciI6IjQzLjIxOS4wIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6W119-->
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com> feat: track allocation counts for cache-free parse sub-operations
Add a committed allocation-count snapshot gate, mirroring oxc's
`tasks/track_memory_allocations`:
- New `tasks/track_allocations` crate: a counting `#[global_allocator]` over
pinned MiMalloc tallies NUM_ALLOC / NUM_REALLOC.
- Measures `PackageJson::parse` and `TsConfig::parse` over a spread of fixed
inputs and writes a committed `allocs.snap` (counts, not bytes).
- `cargo allocs` alias + `just allocs` recipe regenerate it.
- A step in the `test` job (ubuntu) runs `cargo allocs` and fails on `git diff`.
Coverage / magnitude: 8 fixtures across the parse-input shapes โ package.json
(small, large-mixed, exports x40, imports x15, browser x15) and tsconfig (small,
options-heavy, paths x80). The tsconfig paths-heavy fixture (250 allocs) gives a
high-magnitude base where a per-entry regression is an unmistakable delta.
Determinism: counts (not bytes) are platform-stable. These ops are cache-free on
valid input (no DashMap, no fs walk). Allocation COUNT is a pure function of the
input shape, independent of allocator / SIMD width / core count / hash seed:
parsing pre-sizes containers to the known element count, so the count never
depends on hashbrown's seeded bucket placement. Verified by the intentionally
>32-key `exports x40` fixture, whose count is byte-identical across separate
processes (different per-process hash seeds), and run-to-run.
Whole-resolve() allocation tracking is a follow-up: it needs the resolver cache's
DashMap shard count pinned first (a small core change).hyf0:feat/alloc-count-tracking Latest Branches
+5%
+5%
hyf0:feat/alloc-count-tracking +3%
hyf0:feat/fs-call-tracking ยฉ 2026 CodSpeed Technology