vite-plus 0.2.8 → 0.3.0

package/dist/{tsconfig-CVUKLfL8.js → tsconfig-LD2QhQ0O.js}

@@ -1,6 +1,7 @@
-import { t as BASEURL_TSCONFIG_FIX_PACKAGE, u as createBaseUrlTsconfigFixArgs } from "./constants-BppDcRc1.js";
-import { A as isCancel, C as log, M as runCommandSilently, t as cancelAndExit, x as confirm } from "./prompts-DYap08te.js";
-import { c as parse, o as applyEdits, s as modify } from "./json-BU88uu6o.js";
+import { p as createBaseUrlTsconfigFixArgs, t as BASEURL_TSCONFIG_FIX_PACKAGE } from "./constants-Bn-U8o4v.js";
+import { A as isCancel, C as log, t as cancelAndExit, x as confirm } from "./prompts-DF3yU-eU.js";
+import { c as parse, o as applyEdits, s as modify } from "./json-cULBl7Pi.js";
+import { n as runCommandSilently } from "./command-CguLh2KL.js";
 import path from "node:path";
 import { styleText } from "node:util";
 import fs from "node:fs";
@@ -148,4 +149,4 @@ function rewriteTypesInTsconfig(filePath) {
 	return true;
 }
 //#endregion
-export { hasTypesToRewriteInTsconfig as a, rewriteTypesInTsconfig as c, hasBaseUrlInTsconfig as i, findTsconfigFiles as n, hasVitestTypesInTsconfig as o, fixBaseUrlInTsconfig as r, removeDeprecatedTsconfigFalseOption as s, confirmBaseUrlFix as t };
+export { hasBaseUrlInTsconfig as a, hasVitestTypesInTsconfig as c, fixBaseUrlInTsconfig as i, removeDeprecatedTsconfigFalseOption as l, findTsconfigFiles as n, hasBaseUrlInTsconfigFile as o, findTsconfigFilesWithBaseUrl as r, hasTypesToRewriteInTsconfig as s, confirmBaseUrlFix as t, rewriteTypesInTsconfig as u };

package/dist/tsgolint-path.js

@@ -1,2 +1,2 @@
-import { n as resolveWindowsTsgolintExecutable, t as resolveTsgolintExecutable } from "./tsgolint-path-eMZT-oea.js";
+import { n as resolveWindowsTsgolintExecutable, t as resolveTsgolintExecutable } from "./tsgolint-path-CbDReEOx.js";
 export { resolveTsgolintExecutable, resolveWindowsTsgolintExecutable };

package/dist/version.js

@@ -1,6 +1,7 @@
-import { a as printHeader, c as renderCliDoc, r as log, t as accent } from "./terminal-CrqqK8WT.js";
-import { m as version } from "./constants-BppDcRc1.js";
-import { i as hasVitePlusDependency, n as detectPackageMetadata } from "./package-hV-77cBb.js";
+import { t as renderCliDoc } from "./help-BmKpeOP9.js";
+import { i as log, o as printHeader, t as accent } from "./terminal-MKGAuy-p.js";
+import { _ as version } from "./constants-Bn-U8o4v.js";
+import { i as hasVitePlusDependency, n as detectPackageMetadata } from "./package-CBe9EWPY.js";
 import path from "node:path";
 import fs from "node:fs";
 //#region src/version.ts
@@ -40,7 +41,7 @@ function isVitePlusDeclaredInAncestors(cwd) {
 }
 /**
 * Resolve all tool versions from the locally installed vite-plus package.
-* Uses the `vite-plus/versions` export generated by `syncVersionsExport()`.
+* Uses the `vite-plus/versions` export generated by `syncToolchainExports()`.
 */
 async function resolveToolVersions(localPackagePath) {
 	try {

package/dist/versions.d.ts

@@ -1,9 +1,9 @@
 export declare const versions: {
   readonly 'vite': string;
   readonly 'rolldown': string;
-  readonly 'tsdown': string;
-  readonly 'oxlint': string;
+  readonly 'vitest': string;
   readonly 'oxfmt': string;
+  readonly 'oxlint': string;
   readonly 'oxlint-tsgolint': string;
-  readonly 'vitest': string;
+  readonly 'tsdown': string;
 };

package/dist/versions.js

@@ -1,9 +1,9 @@
 export const versions = {
-  "vite": "8.2.0",
-  "rolldown": "1.2.2",
-  "tsdown": "0.22.14",
-  "oxlint": "1.76.0",
-  "oxfmt": "0.61.0",
+  "vite": "8.2.2",
+  "rolldown": "1.2.5",
+  "vitest": "4.1.11",
+  "oxfmt": "0.64.0",
+  "oxlint": "1.79.0",
   "oxlint-tsgolint": "7.0.2001",
-  "vitest": "4.1.10"
+  "tsdown": "0.22.14"
 };

package/docs/guide/ci.md

@@ -6,12 +6,43 @@ You can use `voidzero-dev/setup-vp` to use Vite+ in CI environments.
 
 [`voidzero-dev/setup-vp`](https://github.com/voidzero-dev/setup-vp) provides integrations for GitHub Actions and GitLab CI/CD. Both install Vite+ and can install project dependencies. The GitHub Action can also set up Node.js and cache package manager data automatically, while the GitLab CI/CD template uses the Node.js runtime and cache configuration provided by the job.
 
+## setup-vp Versioning
+
+Set `<setup-vp-version>` in each example to an exact version from the [`setup-vp` releases page](https://github.com/voidzero-dev/setup-vp/releases). You can use a commit SHA instead. Do not use the `v1` tag. The `v1` tag no longer receives updates.
+
+### Automatic Version Updates
+
+Dependabot and Renovate can update exact versions in GitHub Actions workflows.
+
+To use [Dependabot version updates](https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuring-dependabot-version-updates), add a `github-actions` entry to `.github/dependabot.yml`:
+
+```yaml [.github/dependabot.yml]
+version: 2
+updates:
+  - package-ecosystem: github-actions
+    directory: /
+    schedule:
+      interval: weekly
+```
+
+Dependabot checks `uses:` entries in `.github/workflows` each week.
+
+[Renovate's GitHub Actions manager](https://docs.renovatebot.com/modules/manager/github-actions/) detects `uses:` entries by default. You do not need a package rule for `setup-vp`.
+
+When you use a commit SHA, add the exact release tag in a comment. Renovate uses the comment to find updates:
+
+```yaml
+- uses: voidzero-dev/setup-vp@<commit-sha> # <setup-vp-version>
+```
+
+These settings apply only to GitHub Actions workflows. For GitLab CI/CD, update both version values together.
+
 ## GitHub Actions
 
 The GitHub Action sets up Vite+, the required Node.js version, and the package manager. This means you usually do not need separate `setup-node`, package-manager setup, or manual dependency caching steps in your workflow.
 
 ```yaml [.github/workflows/ci.yml]
-- uses: voidzero-dev/setup-vp@v1
+- uses: voidzero-dev/setup-vp@<setup-vp-version>
   with:
     node-version: '24'
     cache: true
@@ -29,11 +60,13 @@ With `cache: true`, `setup-vp` handles dependency caching for you automatically.
 
 ## GitLab CI/CD
 
-Use the reusable `setup-vp` remote template in your GitLab CI/CD configuration:
+Use the reusable `setup-vp` remote template in your GitLab CI/CD configuration. Set the remote URL and `setup-ref` to the same release tag or commit SHA:
 
 ```yaml [.gitlab-ci.yml]
 include:
-  - remote: 'https://raw.githubusercontent.com/voidzero-dev/setup-vp/v1/gitlab/setup-vp.yml'
+  - remote: 'https://raw.githubusercontent.com/voidzero-dev/setup-vp/<setup-vp-version>/gitlab/setup-vp.yml'
+    inputs:
+      setup-ref: '<setup-vp-version>'
 
 test:
   extends: .setup-vp
@@ -76,7 +109,7 @@ If you are migrating an existing GitHub Actions workflow, you can often replace
 #### After:
 
 ```yaml [.github/workflows/ci.yml]
-- uses: voidzero-dev/setup-vp@v1
+- uses: voidzero-dev/setup-vp@<setup-vp-version>
   with:
     node-version: '24'
     cache: true

package/docs/guide/commit-hooks.md

@@ -1,7 +1,7 @@
 # Commit Hooks
 
-Use `vp config` to install the Git hook dispatcher, and `vp staged` to run checks on staged
-files.
+Use `vp hooks` to manage the Git hook dispatcher, `vp config` for project setup
+(hooks + agent integration), and `vp staged` to run checks on staged files.
 
 ## Overview
 
@@ -9,18 +9,65 @@ Vite+ supports commit hooks and staged-file checks without additional tooling.
 
 Use:
 
-- `vp config` to install generated hook infrastructure and related integrations
+- `vp hooks enable` / `disable` / `status` to manage the generated hook dispatcher
+- `vp config` to install the dispatcher (when not disabled) and update agent integration
 - `vp staged` to run checks against the files currently staged in Git
 
 If you use [`vp create`](/guide/create) or [`vp migrate`](/guide/migrate), Vite+ prompts you to set this up for your project automatically.
 
+### Quick start
+
+```bash
+# Install or refresh the dispatcher
+vp hooks enable
+
+# Check what is active in this clone
+vp hooks status
+
+# Turn hooks off in this clone (survives npm install / prepare)
+vp hooks disable
+
+# Turn them back on
+vp hooks enable
+```
+
 ## Commands
 
+### `vp hooks`
+
+Manage the Vite+ Git hook dispatcher for the current repository:
+
+```bash
+vp hooks enable
+vp hooks enable --hooks-dir .custom-hooks
+vp hooks disable
+vp hooks status
+```
+
+| Command   | Behavior                                                                                                                                                                                                           |
+| --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| `enable`  | Install or refresh the generated dispatcher under `<hooks-dir>/_` and set `core.hooksPath`. Clears a previous disable preference.                                                                                  |
+| `disable` | Tear down the dispatcher (unset `core.hooksPath` when it points at Vite+, remove `<hooks-dir>/_`) and **persist** the disable decision in local git config so `vp config` / lifecycle scripts do not reinstall it. |
+| `status`  | Show preference, `core.hooksPath`, dispatcher presence, and project-owned hook scripts.                                                                                                                            |
+
+By default, project hooks live in `.vite-hooks`. Pass `--hooks-dir` to use another subdirectory. After the first successful enable, the directory is remembered in local git config for later `enable` / `disable` / `status` / `vp config` calls in this clone.
+
+`status` reports preference as:
+
+- `not set` — no disable preference and no prior enable in this clone
+- `enabled` — enable has run (or the dispatcher is currently owned)
+- `disabled (local)` — after `vp hooks disable`
+
+Check the `Dispatcher` and `core.hooksPath` lines to see whether hooks are actually active.
+
+`disable` / `enable` do **not** delete project-owned hook scripts (for example `.vite-hooks/pre-commit`), the `staged` block in `vite.config.ts`, or lifecycle scripts that call `vp config`.
+
 ### `vp config`
 
 `vp config` configures Vite+ for the current project. It installs the generated Git hook
-dispatcher and can also handle related project integration such as agent setup. By default,
-project hooks are read from `.vite-hooks`:
+dispatcher (unless hooks were disabled with `vp hooks disable`) and can also handle related
+project integration such as agent setup. The hooks directory defaults to `.vite-hooks`, or the
+last directory used by `vp hooks` / `vp config` in this clone:
 
 ```bash
 vp config
@@ -31,14 +78,17 @@ vp config --no-agent
 
 Use `--no-hooks` when you want `vp config` to leave the Git hook dispatcher unchanged. Use
 `--no-agent` when you want it to skip updates to existing coding agent instruction files. You can
-pass both flags when you want `vp config` to skip both setup steps.
+pass both flags when you want `vp config` to skip both setup steps. After `vp hooks disable`,
+`vp config` skips reinstalling the dispatcher and points you at `vp hooks enable` instead of
+prompting again.
 
 You can also set `VP_GIT_HOOKS=0` to disable hook installation from lifecycle scripts such as
 `prepare` or `postinstall`.
 
 Project-owned hook scripts such as `.vite-hooks/pre-commit` should be committed to the repository.
-The generated dispatcher and shims under `.vite-hooks/_` are ignored and recreated by `vp config`.
-`vp config` does not create or modify project hook scripts or staged-file configuration.
+The generated dispatcher and shims under `.vite-hooks/_` are ignored and recreated by `vp config`
+or `vp hooks enable`. Neither command creates or modifies project hook scripts or staged-file
+configuration.
 
 ### `vp staged`
 
@@ -88,7 +138,7 @@ Set `VP_GIT_HOOKS=0` in the environment of the process that runs `git commit`, a
 VP_GIT_HOOKS=0 git commit -m "content update"
 ```
 
-`HUSKY=0` is honored the same way for ecosystem tooling compatibility. Setting `VP_GIT_HOOKS=0` in an environment also keeps `vp config` from reinstalling hooks there when a lifecycle script such as `prepare` runs.
+`HUSKY=0` is honored the same way for ecosystem tooling compatibility. Setting `VP_GIT_HOOKS=0` in an environment also keeps `vp config` / `vp hooks enable` from reinstalling hooks there when a lifecycle script such as `prepare` runs.
 
 ### Init script
 
@@ -107,21 +157,44 @@ Because the hook itself reads this file, it works even when the committing proce
 
 ## Removing commit hooks
 
-To stop using the Vite+ hook dispatcher:
+To stop using the Vite+ hook dispatcher in this clone (and keep `prepare` / `vp config` from
+reinstalling it):
 
-1. Remove `vp config` from the `prepare` or `postinstall` script in `package.json`.
+```bash
+vp hooks disable
+# or, if you used a custom directory:
+vp hooks disable --hooks-dir .custom-hooks
+```
 
-2. Unset the Git hooks path that points at the Vite+ dispatcher:
+This:
+
+1. Unsets `core.hooksPath` when it points at the Vite+ dispatcher
+2. Removes the generated `<hooks-dir>/_` directory
+3. Records a **local** disable preference so lifecycle scripts skip reinstall until you run
+   `vp hooks enable` again
+
+To re-enable:
 
 ```bash
-git config --unset core.hooksPath
+vp hooks enable
 ```
 
-3. Remove the generated dispatcher directory (use your `--hooks-dir` value if you changed it):
+If you no longer want hooks for the project at all (shared with teammates), also remove `vp config`
+from the `prepare` or `postinstall` script in `package.json`.
+
+### Manual equivalent
+
+If you prefer to do it by hand:
 
 ```bash
+git config --unset core.hooksPath
 rm -rf .vite-hooks/_
+# optional: prevent prepare/vp config from reinstalling in this clone
+git config --local vp.hooks.disabled true
+# optional: remembered hooks directory (set by enable/disable)
+# git config --local vp.hooks.dir .vite-hooks
 ```
 
 Project-owned scripts such as `.vite-hooks/pre-commit` and the `staged` block in `vite.config.ts`
 can remain for later use, or you can remove them separately if the project no longer needs them.
+`vp hooks disable` does **not** delete those project-owned files.

package/docs/guide/create.md

@@ -49,23 +49,26 @@ Run `vp create --list` to see the built-in templates and the common shorthand te
 - `--no-editor` skips editor config setup
 - `--git` initialize a git repository
 - `--no-git` skips git repository initialization
-- `--hooks` enables pre-commit hook setup
-- `--no-hooks` skips hook setup
 - `--package-manager <name>` uses a specified package manager (`pnpm`, `npm`, `yarn`, or `bun`)
 - `--approve-builds` approves and runs gated dependency build scripts without prompting
 - `--no-interactive` runs without prompts
 - `--verbose` shows detailed scaffolding output
 - `--list` prints the available built-in and popular templates
+- `--hooks` enables pre-commit hook setup (dispatcher + `.vite-hooks` + `staged` config)
+- `--no-hooks` skips hook setup
+
+After create, manage the dispatcher with `vp hooks status`, `vp hooks disable`, and `vp hooks enable`.
+See the [Commit hooks guide](/guide/commit-hooks).
 
 ### Dependency build scripts
 
-For security, pnpm, bun, and yarn (Berry) do not run a dependency's build scripts (`install` / `postinstall`, e.g. native builds like `better-sqlite3`) until you approve them. When a template adds such a dependency directly, `vp create` surfaces it after installing instead of leaving the project in a half-built state:
+For security, pnpm, bun, yarn (Berry), and npm (v12+) do not run a dependency's build scripts (`install` / `postinstall`, e.g. native builds like `better-sqlite3`) until you approve them. When a template adds such a dependency directly, `vp create` surfaces it after installing instead of leaving the project in a half-built state:
 
 - Interactive: you are asked which of those dependencies to approve and build (nothing is selected by default).
 - Non-interactive: a note lists them and points at `vp pm approve-builds`.
 - `--approve-builds`: approves and builds them automatically, so non-interactive runs (CI) can produce a ready-to-use project.
 
-Approval is recorded the way each package manager expects: pnpm's `allowBuilds`, bun's `trustedDependencies`, or yarn's `dependenciesMeta.<pkg>.built` (in the workspace root manifest). Transitive build scripts you did not choose (e.g. `esbuild` pulled in by Vite) are left at the package manager's defaults and are not surfaced. npm runs build scripts by default, so there is nothing to approve there.
+Approval is recorded the way each package manager expects: pnpm's `allowBuilds`, bun's `trustedDependencies`, npm's `allowScripts`, or yarn's `dependenciesMeta.<pkg>.built` (in the workspace root manifest). Transitive build scripts you did not choose (e.g. `esbuild` pulled in by Vite) are left at the package manager's defaults and are not surfaced. npm 11 and older run build scripts during install, so there is nothing to approve there.
 
 ## Template Options
 

package/docs/guide/env.md

@@ -21,7 +21,12 @@ latest LTS.
 
 When a project declares `packageManager` (or `devEngines.packageManager`) in `package.json`, matching package-manager shims also use that package-manager version. For example, `packageManager: "npm@10.9.4"` makes both `npm` and `npx` run through npm 10.9.4. Alias pairs follow the installed package-manager shims: `npm`/`npx`, `pnpm`/`pnpx`, `yarn`/`yarnpkg`, and `bun`/`bunx`. Vite+ does not translate mismatched commands, so a project pinned to `pnpm` still lets `npm` fall back to the npm that comes with the resolved Node.js runtime.
 
-By default, Vite+ stores its managed runtime and related files in `~/.vite-plus`. If needed, you can override that location with `VP_HOME`.
+A fresh install uses the split platform layout by default. On Unix, Vite+
+stores managed runtimes and related files in `~/.local/share/vite-plus`. It
+stores executables in the Vite+-owned `~/.local/share/vite-plus/bin` directory.
+On Windows, Vite+ uses `%LOCALAPPDATA%\vite-plus\data` for data and
+`%LOCALAPPDATA%\vite-plus\bin` for executables. Vite+ does not move an existing
+`~/.vite-plus` install. `VP_HOME` puts all categories under one custom root.
 
 If you want to keep that behavior, run:
 
@@ -43,7 +48,7 @@ This switches to system-first mode, where the shims prefer your system Node.js a
 
 ### Setup
 
-- `vp env setup` creates or updates shims in `VP_HOME/bin` (and writes the per-shell setup scripts under `VP_HOME`)
+- `vp env setup` creates or updates shims in the resolved bin directory. It writes shell setup scripts in the config directory.
 - `vp env on` enables managed mode so shims always use Vite+-managed Node.js
 - `vp env off` enables system-first mode so shims prefer system Node.js first
 - `vp env print` prints the shell snippet for the current session
@@ -51,9 +56,12 @@ This switches to system-first mode, where the shims prefer your system Node.js a
 PowerShell needs to dot-source the generated setup script in the current shell before `vp env use` can affect only that shell session:
 
 ```powershell
-. "$env:USERPROFILE\.vite-plus\env.ps1"
+. "$env:APPDATA\vite-plus\env.ps1"
 ```
 
+If an older Vite+ install uses `%USERPROFILE%\.vite-plus`, source the `env.ps1`
+file in that directory instead.
+
 Add that line to the end of your PowerShell `$PROFILE` to apply it automatically in new shells. It does not require elevated privileges.
 
 Create the profile file if it does not already exist:
@@ -76,9 +84,11 @@ node --version
 vp-use --unset
 ```
 
-Only `vp env use` needs this alternate command. Other `vp env` commands work normally in Command Prompt. `vp env setup` creates `vp-use.cmd` under `VP_HOME/bin` on Windows.
+Only `vp env use` needs this alternate command. Other `vp env` commands work normally in Command Prompt. `vp env setup` creates `vp-use.cmd` in the bin directory on Windows.
 
-In CI, `vp env use` can still run without shell initialization. It writes a temporary session file under `VP_HOME` so later shim calls in the same job can resolve the selected Node.js version.
+In CI, `vp env use` can run without shell initialization. It writes a temporary
+session file in the resolved state directory. Later shim calls in the same job
+use this file to select the Node.js version.
 
 ### Manage
 
@@ -144,7 +154,11 @@ Vite+ creates a `corepack` shim by default, so corepack works without a system N
 - On Node.js 25 and later, where corepack is no longer bundled, Vite+ installs corepack as a managed global package on first use. Only the `corepack` binary is linked; run `vp install -g corepack` yourself if you also want the package's pnpm/yarn launchers exposed directly.
 - If you install corepack explicitly with `vp install -g corepack`, that installation is always preferred.
 
-`corepack enable` normally creates `pnpm`/`yarn` launchers next to the corepack binary, which under Vite+ would not be on `PATH`. The shim fixes this by defaulting `--install-directory` to `VP_HOME/bin`, so after `corepack enable` the launchers are available everywhere and still resolve the project's Node.js and package-manager versions:
+`corepack enable` normally creates `pnpm` and `yarn` launchers next to the
+corepack binary. Vite+ does not add that location to `PATH`. The shim sets
+`--install-directory` to the resolved bin directory by default. The launchers
+are then available on `PATH`. They still use the Node.js and package-manager
+versions for the project:
 
 ```bash
 corepack enable               # pnpm and yarn now resolve via corepack

package/docs/guide/fmt.md

@@ -20,11 +20,11 @@ vp fmt . --write
 
 Put formatting configuration directly in the `fmt` block in `vite.config.ts` so all your configuration stays in one place. We do not recommend using `.oxfmtrc.json` with Vite+.
 
-For editors, point the formatter config path at `./vite.config.ts` so format-on-save uses the same `fmt` block:
+For editors, disable nested formatter configs so format-on-save uses the root Vite+ `fmt` block:
 
 ```json [.vscode/settings.json]
 {
-  "oxc.fmt.configPath": "./vite.config.ts"
+  "oxc.fmt.disableNestedConfig": true
 }
 ```
 

package/docs/guide/github-actions-cache.md

@@ -63,6 +63,10 @@ vp run lint # should print "cache hit"
 
 Restore `node_modules/.vite/task-cache` after `vp install`, because package installation can recreate or modify `node_modules`.
 
+Set `<setup-vp-version>` below to an exact version from the [`setup-vp` releases page](https://github.com/voidzero-dev/setup-vp/releases). You can use a commit SHA instead.
+
+See [Automatic Version Updates](/guide/ci#automatic-version-updates) to configure Dependabot or Renovate.
+
 ```yaml [.github/workflows/ci.yml]
 name: CI
 
@@ -80,7 +84,7 @@ jobs:
     steps:
       - uses: actions/checkout@v4
 
-      - uses: voidzero-dev/setup-vp@v1
+      - uses: voidzero-dev/setup-vp@<setup-vp-version>
         with:
           node-version: '24'
           cache: true

package/docs/guide/ide-integration.md

@@ -26,7 +26,8 @@ You can also manually set up the VS Code config:
   "[javascriptreact]": { "editor.defaultFormatter": "oxc.oxc-vscode" },
   "[typescript]": { "editor.defaultFormatter": "oxc.oxc-vscode" },
   "[typescriptreact]": { "editor.defaultFormatter": "oxc.oxc-vscode" },
-  "oxc.fmt.configPath": "./vite.config.ts",
+  "oxc.disableNestedConfig": true,
+  "oxc.fmt.disableNestedConfig": true,
   "editor.formatOnSave": true,
   "editor.formatOnSaveMode": "file",
   "editor.codeActionsOnSave": {
@@ -35,7 +36,7 @@ You can also manually set up the VS Code config:
 }
 ```
 
-This gives the project a shared default formatter and enables Oxc-powered fix actions on save. The language-specific override blocks (`[javascript]`, `[typescript]`, etc.) are required because VS Code prioritizes user-level `[language]` settings over the workspace-level `editor.defaultFormatter` — without them, a global Prettier configuration would silently take over. Setting `oxc.fmt.configPath` to `./vite.config.ts` keeps editor format-on-save aligned with the `fmt` block in your Vite+ config. Vite+ uses `formatOnSaveMode: "file"` because Oxfmt does not support partial formatting.
+This gives the project a shared default formatter and enables Oxc-powered fix actions on save. The language-specific override blocks (`[javascript]`, `[typescript]`, etc.) are required because VS Code prioritizes user-level `[language]` settings over the workspace-level `editor.defaultFormatter` — without them, a global Prettier configuration would silently take over. Setting `oxc.disableNestedConfig` and `oxc.fmt.disableNestedConfig` prevents nested Oxlint and Oxfmt configs from diverging from the root Vite+ config. Vite+ uses `formatOnSaveMode: "file"` because Oxfmt does not support partial formatting.
 
 To let the VS Code NPM Scripts panel run scripts through `vp`, add the following to your `.vscode/settings.json`:
 
@@ -99,3 +100,61 @@ You can also manually set up the Zed config:
 ```
 
 Setting `oxfmt.fmt.configPath` to `./vite.config.ts` keeps editor format-on-save aligned with the `fmt` block in your Vite+ config. The full generated config covers additional languages (CSS, HTML, JSON, Markdown, etc.) — run `vp create` or `vp migrate` to get the complete file written automatically.
+
+## JetBrains (IntelliJ, WebStorm, etc...)
+
+For the best Vite+ experience with JetBrains IDEs such as IntelliJ & WebStorm, install the [Oxc](https://plugins.jetbrains.com/plugin/27061-oxc) plugin from the JetBrains marketplace.
+
+When you create or migrate a project, Vite+ prompts you to choose whether you want the editor config written for JetBrains IDEs.
+
+::: tip Vite+ does not merge with existing config files
+Due to some complexities with merging XML files, Vite+ currently does not merge your current files if the files already exist.
+You'll be given the opportunity to replace any existing files, instead of merging.
+:::
+
+You can also manually set up the IDE configuration to match your Vite+ setup:
+
+```xml [.idea/externalDependencies.xml]
+<?xml version="1.0" encoding="UTF-8"?>
+<project version="4">
+  <component name="ExternalDependencies">
+    <plugin id="com.github.oxc.project.oxcintellijplugin" />
+  </component>
+</project>
+```
+
+```xml [.idea/workspace.xml]
+<?xml version="1.0" encoding="UTF-8"?>
+<project version="4">
+  <!-- other settings... -->
+  <component name="PropertiesComponent">
+    <![CDATA[{
+      "keyToString": {
+        // other settings
+        "javascript.nodejs.core.library.configured.version": "24.18.0", // Replace with your selected Node.js version
+        "javascript.nodejs.core.library.typings.version": "24.13.3", // Replace with the version of @types/node that corresponds to your runtime (or omit if you don't want it)
+        "javascript.preferred.runtime.type.id": "node",
+        "nodejs_interpreter_path": "$USER_HOME$/.vite-plus/bin/node",
+        "nodejs_package_manager_path": "pnpm" // Replace with your package manager of choice
+      }
+    }]]>
+  </component>
+</project>
+```
+
+```xml [.idea/OxfmtSettings.xml]
+<?xml version="1.0" encoding="UTF-8"?>
+<project version="4">
+  <component name="OxfmtSettings">
+    <option name="preferOxfmtCodeStyleSettings" value="true" />
+  </component>
+</project>
+```
+
+Often, `.idea` folders are gitignored in a project, even the `externalDependencies.xml` file, which is used to tell your IDE what plugins should be used for the workspace.
+
+Please make sure to add this line to your main `.gitignore` file, to ensure that the file will be included:
+
+```gitignore [.gitignore]
+!.idea/externalDependencies.xml
+```

package/docs/guide/index.md

@@ -4,7 +4,7 @@ Vite+ is the unified toolchain and entry point for web development. It manages y
 
 Vite+ ships in two parts: `vp`, the global command-line tool, and `vite-plus`, the local package installed in each project. If you already have a Vite project, use [`vp migrate`](/guide/migrate) to migrate it to Vite+, or paste our [migration prompt](/guide/migrate#migration-prompt) into your coding agent.
 
-Building with an AI assistant? Copy a ready-made setup prompt:
+Building with an AI assistant? View and copy a ready-made setup prompt:
 
 <CopyPrompt />
 
@@ -93,6 +93,7 @@ Vite+ can handle the entire local frontend development cycle from starting a pro
 - [`vp create`](/guide/create) creates new apps, packages, and monorepos.
 - [`vp migrate`](/guide/migrate) moves existing projects onto Vite+.
 - [`vp config`](/guide/commit-hooks) installs the Git hook dispatcher and configures agent integration.
+- [`vp hooks`](/guide/commit-hooks) manages the Git hook dispatcher (`enable`, `disable`, `status`).
 - [`vp staged`](/guide/commit-hooks) runs checks on staged files.
 - [`vp install`](/guide/install) installs dependencies with the right package manager.
 - [`vp env`](/guide/env) manages Node.js versions.
@@ -126,6 +127,7 @@ Vite+ can handle the entire local frontend development cycle from starting a pro
 
 ### Maintain
 
+- [`vp toolchain`](/guide/upgrade#show-the-toolchain) shows the versions and relationships in the active Vite+ toolchain.
 - [`vp upgrade`](/guide/upgrade) updates the `vp` installation itself.
 - [`vp implode`](/guide/implode) removes `vp` and related Vite+ data from your machine.
 

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
@@ -74,7 +81,8 @@ Updates keep the version spec a package was installed with: a package installed
 ::: warning
 These commands do **NOT** interact with the underlying package manager's global installation directory.
 
-Instead, Vite+ manages its own global packages under `VP_HOME/packages`, allowing them to remain available across different Node.js versions.
+Instead, Vite+ stores its global packages in `packages/` under the resolved data
+directory. These packages remain available across different Node.js versions.
 
 As a result, commands such as `vp link` do not affect Vite+'s global packages and will not appear in `vp list -g`.
 :::
@@ -149,6 +157,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 +180,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.