vite-plus 0.2.8 → 0.2.9

package/docs/guide/install.md

@@ -39,6 +39,13 @@ A range resolves to an already-downloaded satisfying version when possible, othe
 
 Vite+ currently downloads the declared package manager (the `onFail: "download"` behavior); the other `onFail` values are accepted but not yet differentiated.
 
+A `packageManager` pin can carry an integrity hash (`yarn@4.17.1+sha512.…`). `corepack use` writes that hash. Vite+ hashes the same artifact as Corepack:
+
+- the extracted CLI binary (`bin/yarn.js`) for Yarn 2 and later
+- the npm package tarball for npm, pnpm, and Yarn Classic
+
+Vite+ hashes the CLI once, when it installs Yarn, and records the pin it verified. A later command compares its own pin against that record. A pin that does not match the record fails the check, and the command stops. Corepack keeps the same kind of record for its own cache.
+
 The explicit `packageManager` field (or the `devEngines.packageManager` declaration) also affects matching package-manager shims. If a project has `packageManager: "npm@10.9.4"`, `npm` and `npx` use npm 10.9.4. Other generated alias pairs behave the same way: `pnpm`/`pnpx`, `yarn`/`yarnpkg`, and `bun`/`bunx`. Mismatched tools are not translated; `npm` in a `pnpm` project still resolves as npm.
 
 ## Usage
@@ -149,6 +156,11 @@ Use these when you need to understand the current state of dependencies.
 - `vp why react` explains why `react` is installed
 - `vp info react` shows registry metadata such as versions and dist-tags
 
+These commands show the packages that the package manager installed. They do
+not show tools that Vite+ bundles or compiles. Run `vp toolchain [tool]` to show
+these tools, including Vite, Rolldown, and Oxc. For readable output, `vp why`
+shows a hint when Vite+ also provides the package.
+
 #### Rebuild
 
 Use `vp rebuild` when native modules need to be recompiled, for example after switching Node.js versions or when a C/C++ addon fails to load.
@@ -167,6 +179,19 @@ vp rebuild -- --update-binary
 
 With pnpm v10+, bare `vp rebuild` only rebuilds packages whose build scripts are listed in `onlyBuiltDependencies` (or approved via `pnpm approve-builds`); name the package explicitly to force a rebuild that bypasses the approval gate.
 
+#### Dependency build scripts (npm v12+)
+
+npm v12 skips dependency install scripts (`preinstall` / `install` / `postinstall`, including implicit `node-gyp` builds) unless the `allowScripts` field in package.json covers them; the install succeeds and npm warns about what it skipped. `vp pm approve-builds` manages that allowlist:
+
+- `vp pm approve-builds <pkg...>` approves the named packages (`npm approve-scripts`)
+- `vp pm approve-builds !<pkg...>` denies them (`npm deny-scripts`)
+- `vp pm approve-builds --all` approves everything currently pending
+- `vp pm approve-builds` lists the packages whose scripts are not yet covered
+
+Approval only records the allowlist: scripts an earlier install skipped do not run until you run `vp rebuild <pkg>`. With npm 11.16 - 11.x the same commands work, but npm treats the allowlist as advisory and still runs scripts.
+
+npm v12 also stops resolving git dependencies (`github:`, `git+https:`) and remote tarball URLs by default; such installs fail with `EALLOWGIT` / `EALLOWREMOTE`. Opt back in per project with npm's `allow-git` / `allow-remote` config.
+
 #### Advanced
 
 Use these when you need lower-level package-manager behavior.

package/docs/guide/installer-env-vars.md

@@ -100,6 +100,17 @@ These variables configure the installed Vite+ CLI. `VP_HOME` (above) also applie
 - **Default**: None (verification enabled)
 - **Details**: [Node.js Signature Verification](/guide/env#node-js-signature-verification)
 
+### `VP_DOWNLOAD_TIMEOUT`
+
+- **Purpose**: Per-request timeout, in seconds, for large downloads such as Node.js runtimes and package-manager tarballs
+- **Values**: Positive integer, at most `86400` (24 hours); invalid values are ignored with a warning
+- **Default**: `600` (10 minutes)
+- **Example**:
+  ```bash
+  # Allow up to 30 minutes per download on a slow connection
+  VP_DOWNLOAD_TIMEOUT=1800 vp env install 22
+  ```
+
 ### `VP_SHELL`
 
 - **Purpose**: Specify the current shell
@@ -154,7 +165,7 @@ Vite+ sets additional `VP_*` variables during shim dispatch and shell integratio
 - **Example**:
   ```bash
   VP_LOG=debug vp dev
-  VP_LOG=vite_task=trace vp build
+  VP_LOG=vt=trace vp build
   ```
 
 ### `VP_DEBUG_SHIM`

package/docs/guide/lint.md

@@ -43,8 +43,10 @@ We recommend enabling both `typeAware` and `typeCheck` in the `lint` block:
 - `typeAware: true` enables rules that require TypeScript type information
 - `typeCheck: true` enables full type checking during linting
 
-This path is powered by [tsgolint](https://github.com/oxc-project/tsgolint) on top of the TypeScript Go toolchain. It gives Oxlint access to type information and allows type checking directly via `vp lint` and `vp check`.
+This path is powered by [tsgolint](https://github.com/oxc-project/tsgolint) on top of the TypeScript 7 (aka TypeScript Go) toolchain. It gives Oxlint access to type information and allows type checking directly via `vp lint` and `vp check`.
 
 ## JS Plugins
 
 If you are migrating from ESLint and still depend on a few critical JavaScript-based ESLint plugins, Oxlint has [JS plugin support](https://oxc.rs/docs/guide/usage/linter/js-plugins) that can help you keep those plugins running while you complete the migration.
+
+JS Plugins also enable [writing your own custom rules](https://oxc.rs/docs/guide/usage/linter/writing-js-plugins.html) for Oxlint.

package/docs/guide/migrate.md

@@ -22,6 +22,9 @@ The positional `PATH` argument is optional.
 
 - If omitted, `vp migrate` migrates the current directory
 - If provided, it migrates that target directory instead
+- For a monorepo, the target must be the workspace root. Vite+ cannot
+  migrate one workspace member, because migration updates the package-manager
+  configuration, the catalogs, and the lockfiles that all members share.
 
 ```bash
 vp migrate
@@ -69,6 +72,40 @@ After running the migration:
 - Run `vp test`
 - Run `vp build`
 
+## Manual Installation & Migration
+
+If you are manually migrating a project to Vite+, install these dev dependencies first:
+
+```bash
+vp install -D vite-plus
+```
+
+You need to add overrides to your package manager so that other packages resolve the Vite+ versions: alias `vite` to `@voidzero-dev/vite-plus-core`, and pin `vitest` to the version Vite+ bundles (run `vp --version`) so the whole project shares a single Vitest copy with `vp test`. Without the `vitest` pin, a dependency or workspace package can pull a different Vitest than the bundled runner, splitting Vitest's internals (mocks, `expect`, runner state):
+
+```json
+"overrides": {
+  "vite": "npm:@voidzero-dev/vite-plus-core@latest",
+  "vitest": "4.1.10"
+}
+```
+
+If you are using `pnpm`, add this to your `pnpm-workspace.yaml`:
+
+```yaml
+overrides:
+  vite: npm:@voidzero-dev/vite-plus-core@latest
+  vitest: 4.1.10
+```
+
+Or, if you are using Yarn:
+
+```json
+"resolutions": {
+  "vite": "npm:@voidzero-dev/vite-plus-core@latest",
+  "vitest": "4.1.10"
+}
+```
+
 ## Migration Prompt
 
 If you want to hand this work to a coding agent (or the reader is a coding agent!), use this migration prompt:
@@ -184,9 +221,9 @@ only when no existing hook policy is found.
 
 If your project currently uses `lefthook`, `simple-git-hooks`, or `yorkie`, `vp migrate` will leave your existing configuration alone and show a warning. This happens even if you choose to set up hooks during the prompt or include the `--hooks` flag.
 
-If you want to move one of those tools over to Vite+ manually, you can follow these steps. First, move your staged-file commands into the `staged` block within `vite.config.ts`. Then, update your lifecycle script so it runs `vp config`. You will also need to create a Vite+ hook at `.vite-hooks/pre-commit` that runs `vp staged`. Finally, once you have confirmed that the Vite+ hook is working as expected, you can remove the old tool's configuration and dependency.
+If you want to move one of those tools over to Vite+ manually, you can follow these steps. First, move your staged-file commands into the `staged` block within `vite.config.ts`. Then, update your lifecycle script so it runs `vp config`. You will also need to create a Vite+ hook at `.vite-hooks/pre-commit` that runs `vp staged`. Run `vp hooks enable` (or `vp config`) to install the dispatcher and set `core.hooksPath`. Finally, once you have confirmed that the Vite+ hook is working as expected, you can remove the old tool's configuration and dependency.
 
-You can find more details about the full Vite+ hook setup in the [Commit hooks guide](/guide/commit-hooks).
+Use `vp hooks status` to verify the dispatcher is active, and `vp hooks disable` if you need to turn it off again in this clone. You can find more details about the full Vite+ hook setup in the [Commit hooks guide](/guide/commit-hooks).
 
 ## Examples
 

package/docs/guide/monorepo.md

@@ -24,7 +24,7 @@ export default defineConfig({
     overrides: [
       {
         files: ['apps/web/**', 'packages/ui/**'],
-        plugins: ['typescript', 'react'],
+        plugins: ['react'],
         rules: {
           'react/self-closing-comp': 'error',
         },
@@ -40,9 +40,9 @@ export default defineConfig({
       },
       {
         files: ['**/*.test.ts', '**/*.spec.ts'],
-        plugins: ['typescript', 'vitest'],
+        plugins: ['vitest'],
         rules: {
-          '@typescript-eslint/no-explicit-any': 'off',
+          'typescript/no-explicit-any': 'off',
           'vitest/no-disabled-tests': 'error',
         },
       },
@@ -54,7 +54,7 @@ export default defineConfig({
 Globs are resolved from the root `vite.config.ts`, so use workspace paths such as `apps/web/**`, `apps/api/**`, and `packages/ui/**`.
 
 ::: tip
-When a `lint.overrides` entry sets `plugins`, that list replaces the base `lint.plugins` list for matched files. Include every plugin needed by that file group, such as `['typescript', 'react']`. Omit `plugins` only when the override should inherit the base list unchanged.
+When a `lint.overrides` entry sets `plugins`, that list will be merged with the base `lint.plugins` list for matched files. Omit `plugins` only when the override should inherit the base list unchanged.
 :::
 
 ## Format Overrides

package/docs/guide/troubleshooting.md

@@ -15,6 +15,9 @@ Vite+ expects modern upstream tool versions.
 
 If you are migrating an existing project and it still depends on older Vite or Vitest versions, upgrade those first before adopting Vite+.
 
+Run `vp toolchain` to show the versions from the local Vite+ package.
+Run `vp toolchain --global` to show the versions from the global Vite+ release.
+
 ## `vp check` does not run type-aware lint rules or type checks
 
 - Confirm that `lint.options.typeAware` and `lint.options.typeCheck` are enabled in `vite.config.ts`
@@ -53,9 +56,14 @@ You can also run custom tasks defined in `vite.config.ts` and migrate away from
 If `vp staged` fails or your pre-commit hook does not run:
 
 - make sure `vite.config.ts` contains a `staged` block
-- make sure the project-owned pre-commit hook runs `vp staged`
-- run `vp config` to install the hook dispatcher
-- check whether hook installation was skipped intentionally through `VP_GIT_HOOKS=0`
+- make sure the project-owned pre-commit hook runs `vp staged` (for example `.vite-hooks/pre-commit`)
+- run `vp hooks status` to see preference, `core.hooksPath`, and whether the dispatcher is installed
+- run `vp hooks enable` (or `vp config`) to install the hook dispatcher
+- if status shows `Preference: disabled (local)`, re-enable with `vp hooks enable`
+- check whether hooks were skipped intentionally through `VP_GIT_HOOKS=0`
+
+To stop hooks in this clone without deleting project policy files, run `vp hooks disable`.
+See the [Commit hooks guide](/guide/commit-hooks) for the full workflow.
 
 A minimal staged config looks like this:
 
@@ -106,7 +114,7 @@ If you are stuck, please reach out:
 
 When reporting a problem, please include:
 
-- The full output of `vp env current` and `vp --version`
+- The full output of `vp env current`, `vp --version`, and `vp toolchain`
 - The package manager used by the project
 - The exact steps needed to reproduce the problem and your `vite.config.ts`
 - A minimal reproduction repository or runnable sandbox

package/docs/guide/upgrade.md

@@ -11,6 +11,29 @@ There are two parts to upgrading Vite+:
 
 You can upgrade both of them independently.
 
+## Show the Toolchain
+
+Run `vp toolchain` to show the components for the current directory:
+
+```bash
+vp toolchain
+vp toolchain vite
+vp toolchain vite rolldown oxc
+vp toolchain --json
+```
+
+The command uses the local `vite-plus` package when the project has one. Use
+`--global` to show the release for the global `vp` command:
+
+```bash
+vp toolchain --global
+```
+
+`vp why <package>` shows the dependency graph from the package manager. It
+cannot show code bundled into `@voidzero-dev/vite-plus-core`. It also cannot
+show engines compiled into Vite+. Use `vp toolchain` to show those versions and
+relationships.
+
 ## Global `vp`
 
 ```bash
@@ -53,7 +76,7 @@ A Vite+ release can bump the bundled Vitest. Because that pin also applies to `v
 After upgrading `vite-plus`, re-pin `vitest` to the version Vite+ now bundles. Check that version with:
 
 ```bash
-vp --version
+vp toolchain vitest
 ```
 
 Then set the `vitest` override to that exact version, or rerun `vp migrate` to update the pin for you.
@@ -86,7 +109,7 @@ irm https://vite.plus/ps1 | iex
 Remove-Item Env:\VP_PR_VERSION
 ```
 
-The installer resolves the ref to its `0.0.0-commit.<sha>` build through the registry bridge and installs it like any other version. Run `vp --version` afterward to confirm which build and bundled tool versions are active. When you are done testing, return to the published release with `vp upgrade --force` or by running the installer again without `VP_PR_VERSION`.
+The installer uses the registry bridge to resolve the ref to a `0.0.0-commit.<sha>` build. It installs this build like other versions. Run `vp toolchain --global` to show the active build and tool versions. After testing, run `vp upgrade --force` to restore the published release. You can also run the installer without `VP_PR_VERSION`.
 
 ### Local `vite-plus` Preview
 
@@ -96,6 +119,6 @@ After installing the preview global CLI above, run migrate in the project to mov
 vp migrate
 ```
 
-Migrate points the project at the bridge registry (writing it to `.npmrc`, or `.yarnrc.yml` for Yarn Berry) and pins `vite-plus` and the `vite` -> `@voidzero-dev/vite-plus-core` alias to the matching `0.0.0-commit.<sha>` version. That registry line is what lets the same versions resolve in the project's own CI, so commit it if you want CI to test the preview too.
+Migrate writes the bridge registry to `.npmrc`. For Yarn Berry, it writes the registry to `.yarnrc.yml`. It pins `vite-plus` and the `vite` alias to the matching `0.0.0-commit.<sha>` version. The `vite` alias points to `@voidzero-dev/vite-plus-core`. Commit the registry line if the project CI must test the preview.
 
-After installing, check the bundled versions with `vp --version`. When testing is complete, restore the published release: set `vite-plus` back to `latest`, remove the bridge `registry` line from `.npmrc` (or `.yarnrc.yml`), and reinstall with `vp install`.
+After the install, run `vp toolchain` to show the selected versions. After testing, set `vite-plus` to `latest`. Remove the bridge `registry` line from `.npmrc` or `.yarnrc.yml`. Then run `vp install`.

package/docs/package.json

@@ -26,5 +26,5 @@
     "tailwindcss": "^4.1.18",
     "vitepress": "2.0.0-alpha.17"
   },
-  "packageManager": "pnpm@10.34.4"
+  "packageManager": "pnpm@11.20.0"
 }

package/docs/pnpm-workspace.yaml

@@ -1,6 +1,13 @@
 packages:
   - .
 
+# pnpm 11 fails installs on unreviewed dependency build scripts
+# (ERR_PNPM_IGNORED_BUILDS). These scripts were already skipped under
+# pnpm 10; keep them skipped explicitly.
+allowBuilds:
+  esbuild: false
+  vue-demi: false
+
 peerDependencyRules:
   allowAny:
     - vitepress

package/docs/vite.config.ts

@@ -3,6 +3,9 @@ export default {
     tasks: {
       'build:site': {
         command: 'vitepress build',
+        // The install-URL rewrite in .vitepress/config.mts depends on this
+        // variable, so different deploy targets must not share cached output.
+        env: ['DOCS_SITE_ORIGIN'],
         input: [
           { auto: true },
           '!.vitepress/.temp/**',

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "vite-plus",
-  "version": "0.2.8",
+  "version": "0.2.9",
   "description": "The Unified Toolchain for the Web",
   "homepage": "https://viteplus.dev/guide",
   "bugs": {
@@ -85,6 +85,10 @@
     "./pack/client": {
       "types": "./dist/pack-client.d.ts"
     },
+    "./toolchain": {
+      "types": "./dist/toolchain.d.ts",
+      "default": "./dist/toolchain.js"
+    },
     "./versions": {
       "types": "./dist/versions.d.ts",
       "default": "./dist/versions.js"
@@ -347,7 +351,7 @@
     }
   },
   "dependencies": {
-    "@oxc-project/types": "=0.142.0",
+    "@oxc-project/types": "=0.143.0",
     "@oxlint/plugins": "=1.73.0",
     "@vitest/browser": "4.1.10",
     "@vitest/browser-preview": "4.1.10",
@@ -358,11 +362,11 @@
     "@vitest/snapshot": "4.1.10",
     "@vitest/spy": "4.1.10",
     "@vitest/utils": "4.1.10",
-    "oxfmt": "=0.61.0",
-    "oxlint": "=1.76.0",
+    "oxfmt": "=0.62.0",
+    "oxlint": "=1.77.0",
     "oxlint-tsgolint": "=7.0.2001",
     "vitest": "4.1.10",
-    "@voidzero-dev/vite-plus-core": "0.2.8"
+    "@voidzero-dev/vite-plus-core": "0.2.9"
   },
   "devDependencies": {
     "@emnapi/core": "2.0.0-alpha.3",
@@ -392,7 +396,7 @@
     "yaml": "^2.8.1",
     "zod": "^3.25.76",
     "@voidzero-dev/vite-plus-prompts": "0.0.0",
-    "vite": "npm:@voidzero-dev/vite-plus-core@0.2.8"
+    "vite": "npm:@voidzero-dev/vite-plus-core@0.2.9"
   },
   "peerDependencies": {
     "@vitest/browser-playwright": "4.1.10",
@@ -424,14 +428,14 @@
     "node": "^20.19.0 || ^22.18.0 || >=24.11.0"
   },
   "optionalDependencies": {
-    "@voidzero-dev/vite-plus-darwin-arm64": "0.2.8",
-    "@voidzero-dev/vite-plus-darwin-x64": "0.2.8",
-    "@voidzero-dev/vite-plus-linux-arm64-gnu": "0.2.8",
-    "@voidzero-dev/vite-plus-linux-arm64-musl": "0.2.8",
-    "@voidzero-dev/vite-plus-linux-x64-gnu": "0.2.8",
-    "@voidzero-dev/vite-plus-linux-x64-musl": "0.2.8",
-    "@voidzero-dev/vite-plus-win32-x64-msvc": "0.2.8",
-    "@voidzero-dev/vite-plus-win32-arm64-msvc": "0.2.8"
+    "@voidzero-dev/vite-plus-darwin-arm64": "0.2.9",
+    "@voidzero-dev/vite-plus-darwin-x64": "0.2.9",
+    "@voidzero-dev/vite-plus-linux-arm64-gnu": "0.2.9",
+    "@voidzero-dev/vite-plus-linux-arm64-musl": "0.2.9",
+    "@voidzero-dev/vite-plus-linux-x64-gnu": "0.2.9",
+    "@voidzero-dev/vite-plus-linux-x64-musl": "0.2.9",
+    "@voidzero-dev/vite-plus-win32-x64-msvc": "0.2.9",
+    "@voidzero-dev/vite-plus-win32-arm64-msvc": "0.2.9"
   },
   "scripts": {
     "build": "oxnode -C dev ./build.ts",

package/rules/vite-tools.yml

@@ -10,7 +10,6 @@ rule:
     regex: 'vite\s+(-v|--version)'
 fix: vp
 
-
 # vite => vp dev (handles all cases: with/without env var prefix and flag args)
 # Match command_name to preserve env var prefix and arguments
 # Excludes subcommands like "vite build", "vite test", etc.
@@ -27,7 +26,6 @@ rule:
       regex: 'vite\s+[^-]'
 fix: vp dev
 
-
 # vite <subcommand> => vp <subcommand> (handles vite build, vite test, vite dev, etc.)
 # Match command_name when followed by a subcommand, replace only the command name
 ---
@@ -41,7 +39,6 @@ rule:
     regex: 'vite\s+[^-]'
 fix: vp
 
-
 # oxlint => vp lint (handles all cases: with/without env var prefix and args)
 # Match command_name to preserve env var prefix and arguments
 ---
@@ -52,7 +49,6 @@ rule:
   regex: '^oxlint$'
 fix: vp lint
 
-
 # oxfmt => vp fmt
 ---
 id: replace-oxfmt
@@ -62,7 +58,6 @@ rule:
   regex: '^oxfmt$'
 fix: vp fmt
 
-
 # vitest => vp test
 ---
 id: replace-vitest
@@ -72,7 +67,6 @@ rule:
   regex: '^vitest$'
 fix: vp test
 
-
 # lint-staged => vp staged
 ---
 id: replace-lint-staged
@@ -82,7 +76,6 @@ rule:
   regex: '^lint-staged$'
 fix: vp staged
 
-
 # tsdown => vp pack
 ---
 id: replace-tsdown

package/dist/dist-DT25H9pj.js

@@ -1,3 +0,0 @@
-import { t as require_dist } from "./dist-CSQWHI6y.js";
-export default require_dist();
-export {};

package/dist/{tsgolint-path-eMZT-oea.js → tsgolint-path-CbDReEOx.js}

@@ -1,6 +1,6 @@
 import { dirname, join } from "node:path";
-import { existsSync, realpathSync } from "node:fs";
 import { fileURLToPath } from "node:url";
+import { existsSync, realpathSync } from "node:fs";
 //#region src/utils/tsgolint-path.ts
 function resolveWindowsTsgolintExecutable(pathCandidates, options) {
 	let oxlintTsgolintPath = pathCandidates.find((p) => options.exists(p)) ?? "";