vite-plus 0.1.24 → 0.2.1

package/dist/tsgolint-path-B-yOos8p.js

@@ -0,0 +1,32 @@
+import { dirname, join } from "node:path";
+import { existsSync, realpathSync } from "node:fs";
+import { fileURLToPath } from "node:url";
+//#region src/utils/tsgolint-path.ts
+function resolveWindowsTsgolintExecutable(pathCandidates, options) {
+	let oxlintTsgolintPath = pathCandidates.find((p) => options.exists(p)) ?? "";
+	if (!oxlintTsgolintPath && options.getRealpathCandidates) try {
+		oxlintTsgolintPath = options.getRealpathCandidates().find((p) => options.exists(p)) ?? "";
+	} catch {}
+	if (!oxlintTsgolintPath) throw new Error("Unable to resolve oxlint-tsgolint executable, tried:\n" + pathCandidates.map((path) => `- ${path}`).join("\n"));
+	return oxlintTsgolintPath;
+}
+function resolveTsgolintExecutable(tsgolintBinPath, scriptUrl) {
+	if (process.platform !== "win32") return tsgolintBinPath;
+	const scriptDir = dirname(fileURLToPath(scriptUrl));
+	const localBinDir = join(scriptDir, "..", "node_modules", ".bin");
+	const projectBinDir = join(dirname(dirname(tsgolintBinPath)), "..", ".bin");
+	return resolveWindowsTsgolintExecutable([
+		join(localBinDir, "tsgolint.exe"),
+		join(localBinDir, "tsgolint.cmd"),
+		join(projectBinDir, "tsgolint.exe"),
+		join(projectBinDir, "tsgolint.cmd")
+	], {
+		exists: existsSync,
+		getRealpathCandidates: () => {
+			const realBinDir = join(dirname(realpathSync(join(scriptDir, ".."))), ".bin");
+			return [join(realBinDir, "tsgolint.exe"), join(realBinDir, "tsgolint.cmd")];
+		}
+	});
+}
+//#endregion
+export { resolveWindowsTsgolintExecutable as n, resolveTsgolintExecutable as t };

package/dist/tsgolint-path.d.ts

@@ -0,0 +1,8 @@
+//#region src/utils/tsgolint-path.d.ts
+declare function resolveWindowsTsgolintExecutable(pathCandidates: string[], options: {
+  exists: (path: string) => boolean;
+  getRealpathCandidates?: () => string[];
+}): string;
+declare function resolveTsgolintExecutable(tsgolintBinPath: string, scriptUrl: string): string;
+//#endregion
+export { resolveTsgolintExecutable, resolveWindowsTsgolintExecutable };

package/dist/tsgolint-path.js

@@ -0,0 +1,2 @@
+import { n as resolveWindowsTsgolintExecutable, t as resolveTsgolintExecutable } from "./tsgolint-path-B-yOos8p.js";
+export { resolveTsgolintExecutable, resolveWindowsTsgolintExecutable };

package/dist/version.js

@@ -1,11 +1,11 @@
-import "./constants-DCBWlNrn.js";
+import "./constants-CrfJQIUX.js";
 import { a as printHeader, r as log, t as accent } from "./terminal-uTv0ZaMr.js";
-import { i as hasVitePlusDependency, n as detectPackageMetadata } from "./package-PmBUZ-ve.js";
+import { i as hasVitePlusDependency, n as detectPackageMetadata } from "./package-BHirM1_v.js";
 import { t as renderCliDoc } from "./help-YP84FSEz.js";
 import path from "node:path";
 import fs from "node:fs";
 //#region package.json
-var version = "0.1.24";
+var version = "0.2.1";
 //#endregion
 //#region src/version.ts
 /** Tool display names in the order shown by `vp --version`. */

package/dist/versions.d.ts

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

package/dist/versions.js

@@ -1,9 +1,9 @@
 export const versions = {
   "vite": "8.0.16",
-  "rolldown": "1.0.3",
-  "tsdown": "0.22.1",
-  "vitest": "4.1.8",
-  "oxlint": "1.67.0",
-  "oxfmt": "0.52.0",
-  "oxlint-tsgolint": "0.23.0"
+  "rolldown": "1.1.1",
+  "tsdown": "0.22.3",
+  "oxlint": "1.70.0",
+  "oxfmt": "0.55.0",
+  "oxlint-tsgolint": "0.23.0",
+  "vitest": "4.1.9"
 };

package/dist/{workspace-NL-m9wgM.js → workspace-D0AVy4fu.js}

@@ -1,7 +1,8 @@
-import { A as R$1, C as log, E as select, v as PackageManager, w as multiselect } from "./tsconfig-DFb5BKyT.js";
-import { t as require_dist } from "./dist-BgQuvbtq.js";
-import { c as editJsonFile, d as writeJsonFile, r as getScopeFromPackageName, u as readJsonFile } from "./package-PmBUZ-ve.js";
-import { B as editYamlFile, V as readYamlFile } from "./agent-Nuk-9l77.js";
+import { A as select, D as log, O as multiselect, P as R$1, S as PackageManager } from "./tsconfig-BWQPmGKz.js";
+import { i as writeJsonFile, r as readJsonFile, t as editJsonFile } from "./json-Dn87fvjk.js";
+import { t as require_dist } from "./dist-Oxo16Y0q.js";
+import { r as getScopeFromPackageName } from "./package-BHirM1_v.js";
+import { G as editYamlFile, K as readYamlFile } from "./agent--cKmgD_n.js";
 import path, { posix, win32 } from "node:path";
 import { detectWorkspace } from "../binding/index.js";
 import * as actualFS from "node:fs";
@@ -5779,6 +5780,9 @@ async function detectWorkspace$1(rootDir) {
 	}
 	return result;
 }
+function isBingoTemplate(pkg) {
+	return !!pkg.dependencies?.bingo;
+}
 function discoverWorkspacePackages(workspacePatterns, rootDir) {
 	const packages = [];
 	if (workspacePatterns.length === 0) return packages;
@@ -5790,13 +5794,11 @@ function discoverWorkspacePackages(workspacePatterns, rootDir) {
 	for (const packageJsonRelativePath of packageJsonRelativePaths) {
 		const pkg = readJsonFile(path.join(rootDir, packageJsonRelativePath));
 		if (!pkg.name) continue;
-		const isTemplatePackage = pkg.keywords?.includes("vite-plus-template") || pkg.keywords?.includes("bingo-template") || !!pkg.dependencies?.bingo;
 		packages.push({
 			name: pkg.name,
-			path: path.dirname(packageJsonRelativePath),
+			path: path.dirname(packageJsonRelativePath).split(path.sep).join("/"),
 			description: pkg.description,
-			version: pkg.version,
-			isTemplatePackage
+			version: pkg.version
 		});
 	}
 	return packages;
@@ -5825,4 +5827,4 @@ function updateWorkspaceConfig(projectPath, workspaceInfo) {
 	});
 }
 //#endregion
-export { detectExistingEditors as a, writeEditorConfigs as c, detectEditorConflicts as i, updatePackageJsonWithDeps as n, selectEditor as o, updateWorkspaceConfig as r, selectEditors as s, detectWorkspace$1 as t };
+export { detectEditorConflicts as a, selectEditors as c, updateWorkspaceConfig as i, writeEditorConfigs as l, isBingoTemplate as n, detectExistingEditors as o, updatePackageJsonWithDeps as r, selectEditor as s, detectWorkspace$1 as t };

package/docs/_data/team.ts

@@ -30,7 +30,7 @@ export const core: DefaultTheme.TeamMember[] = [
     name: 'Christoph Nakazawa',
     links: [
       { icon: 'github', link: 'https://github.com/cpojer' },
-      { icon: 'x', link: 'https://x.com/cpojer' },
+      { icon: 'x', link: 'https://x.com/cnakazawa' },
       { icon: 'bluesky', link: 'https://bsky.app/profile/christoph.nkzw.tech' },
     ],
   },
@@ -113,6 +113,7 @@ export const core: DefaultTheme.TeamMember[] = [
     name: 'JongKyung Lee',
     links: [
       { icon: 'github', link: 'https://github.com/jong-kyung' },
+      { icon: 'x', link: 'https://x.com/jongkyung_dev' },
       { icon: 'linkedin', link: 'https://www.linkedin.com/in/jong-kyung' },
     ],
   },

package/docs/config/create.md

@@ -16,7 +16,42 @@ export default defineConfig({
 });
 ```
 
-Any value accepted by `vp create` as a first argument works here — `@your-org` for an org picker, `@your-org:web` for a direct manifest entry, `vite:application` for a built-in, etc.
+Any value accepted by `vp create` as a first argument works here: `@your-org` for an org picker, `@your-org:web` for a direct manifest entry, `vite:application` for a built-in, or the `name` of a local `create.templates` entry (see below).
+
+## `create.templates`
+
+Declare local templates available to `vp create` inside a monorepo. Each entry is listed in the `vp create` picker, and selecting it (or passing its `name` as the template argument) runs the resolved `template`.
+
+```ts
+import { defineConfig } from 'vite-plus';
+
+export default defineConfig({
+  create: {
+    templates: [
+      {
+        name: 'component',
+        description: 'Internal UI component',
+        template: './tools/create-component',
+      },
+      { name: 'service', description: 'Backend service', template: 'service-generator' },
+    ],
+  },
+});
+```
+
+Each entry has:
+
+| Field         | Required | Notes                                                                                                                                                                                                                                            |
+| ------------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| `name`        | yes      | Identifier shown in the picker and accepted as `vp create <name>`. Must be unique within the array. The `vite:` prefix is reserved for built-in templates.                                                                                       |
+| `description` | yes      | One-line description shown in the picker.                                                                                                                                                                                                        |
+| `template`    | yes      | A workspace package name, a relative `./path` to a local package's directory (resolved against the workspace root), a `vite:*` built-in, a GitHub URL, or a full npm package name (e.g. `create-foo`). It is run as-is (not shorthand-expanded). |
+
+`create.templates` is the source of truth for local templates: only entries listed here appear in the picker. Vite+ does not infer templates from package.json keywords. A `create.templates` entry whose `template` does not match any workspace package, or resolves to a local package without a `bin`, is reported as an error rather than falling through to an unrelated npm package.
+
+[`vp create vite:generator`](/guide/create#code-generators) adds an entry here automatically (idempotently, preserving `defaultTemplate`); you can also edit the list by hand.
+
+`create.defaultTemplate` can name a local entry, so bare `vp create` opens it directly.
 
 ## Precedence
 

package/docs/config/index.md

@@ -10,10 +10,11 @@ export default defineConfig({
   build: {},
   preview: {},
 
-  test: {},
-  lint: {},
-  fmt: {},
+  create: {},
   run: {},
+  fmt: {},
+  lint: {},
+  test: {},
   pack: {},
   staged: {},
 });
@@ -23,9 +24,10 @@ export default defineConfig({
 
 Vite+ extends the basic Vite configuration with these additions:
 
-- [`lint`](/config/lint) for Oxlint
+- [`create`](/config/create) for project and template scaffolding defaults
+- [`run`](/config/run) for Vite Task
 - [`fmt`](/config/fmt) for Oxfmt
+- [`lint`](/config/lint) for Oxlint
 - [`test`](/config/test) for Vitest
-- [`run`](/config/run) for Vite Task
 - [`pack`](/config/pack) for tsdown
 - [`staged`](/config/staged) for staged-file checks

package/docs/guide/commit-hooks.md

@@ -22,8 +22,17 @@ If you use [`vp create`](/guide/create) or [`vp migrate`](/guide/migrate), Vite+
 ```bash
 vp config
 vp config --hooks-dir .vite-hooks
+vp config --no-hooks
+vp config --no-agent
 ```
 
+Use `--no-hooks` when you want `vp config` to leave existing Git hook setup 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.
+
+You can also set `VITE_GIT_HOOKS=0` to disable hook installation from lifecycle scripts such as
+`prepare` or `postinstall`.
+
 ### `vp staged`
 
 `vp staged` runs staged-file checks using the `staged` config from `vite.config.ts`. If you set up Vite+ to handle your commit hooks, it will automatically run when you commit your local changes.

package/docs/guide/create.md

@@ -27,7 +27,7 @@ Vite+ ships with these built-in templates:
 - `vite:monorepo` creates a new monorepo
 - `vite:application` creates a new application
 - `vite:library` creates a new library
-- `vite:generator` creates a new generator
+- `vite:generator` creates a new code generator (monorepo only, see [Code Generators](#code-generators))
 
 ## Template Sources
 
@@ -35,7 +35,7 @@ Vite+ ships with these built-in templates:
 
 - Use shorthand templates like `vite`, `@tanstack/start`, `svelte`, `next-app`, `nuxt`, `react-router`, and `vue`
 - Use full package names like `create-vite` or `create-next-app`
-- Use local templates such as `./tools/create-ui-component` or `@your-org/generator-*`
+- Use local monorepo templates declared in [`create.templates`](#code-generators) (for example an internal component or service generator)
 - Use remote templates such as `github:user/repo` or `https://github.com/user/template-repo`
 
 Run `vp create --list` to see the built-in templates and the common shorthand templates Vite+ recognizes.
@@ -44,15 +44,29 @@ Run `vp create --list` to see the built-in templates and the common shorthand te
 
 - `--directory <dir>` writes the generated project into a specific target directory
 - `--agent <name>` creates agent instructions files during scaffolding
+- `--no-agent` skips agent instruction setup
 - `--editor <name>` writes editor config files
+- `--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
 
+### 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:
+
+- 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.
+
 ## Template Options
 
 Arguments after `--` are passed directly to the selected template.
@@ -89,6 +103,96 @@ vp create github:user/repo
 vp create https://github.com/user/template-repo
 ```
 
+## Code Generators
+
+Monorepos often need to scaffold their own building blocks: a UI component, a service, or an internal package that follows house conventions. Vite+ supports this through generator packages powered by [Bingo](https://www.create.bingo/) templates.
+
+### Scaffold a generator
+
+Inside a Vite+ monorepo, run:
+
+```bash
+vp create vite:generator
+```
+
+This requires a monorepo workspace. If you don't have one yet, create it first with `vp create vite:monorepo`.
+
+The scaffolded generator package contains:
+
+- `src/template.ts` defines the template using `createTemplate` from `bingo`: an options schema built with [Zod](https://zod.dev/) and a `produce()` function that returns the files to generate
+- `bin/index.ts` is the CLI entry, powered by Bingo's `runTemplateCLI`
+
+If the monorepo has a parent directory matching `generators` or `tools`, the new package is placed there by default.
+
+### Registration
+
+Local generators are declared in [`create.templates`](/config/create#create-templates) in the monorepo's `vite.config.ts`. This is the source of truth: only registered templates appear in the `vp create` picker.
+
+`vp create vite:generator` registers the generator for you, adding an entry to `create.templates` in the root `vite.config.ts`:
+
+```ts
+import { defineConfig } from 'vite-plus';
+
+export default defineConfig({
+  create: {
+    templates: [
+      { name: 'my-generator', description: 'Generate new components', template: 'my-generator' },
+    ],
+  },
+});
+```
+
+Re-running is idempotent (no duplicate entries), and an existing `create.defaultTemplate` is preserved. You can also add entries by hand, for example to register a template you didn't scaffold this way. The `template` value is the generator's workspace package name, or a relative `./path` to it.
+
+### Run a generator
+
+Inside the monorepo, run `vp create` and pick the generator from the template list, or pass its entry `name` directly:
+
+```bash
+# Interactive mode lists registered local templates alongside the built-ins
+vp create
+
+# Run a registered template by its name
+vp create component
+
+# Pass options to the generator after --
+vp create component -- --name @your-org/button
+```
+
+When the generator depends on `bingo`, Vite+ appends `--skip-requests` automatically so it skips Bingo's outbound network requests (such as GitHub API calls).
+
+After the generator runs, the created package goes through the regular monorepo integration: workspace registration, dependency installation, and formatting.
+
+### Customize a generator
+
+Edit `src/template.ts` to define the options and the files to produce:
+
+```ts
+import { createTemplate } from 'bingo';
+import { z } from 'zod';
+
+export default createTemplate({
+  options: {
+    name: z.string().describe('Package name'),
+  },
+  async produce({ options }) {
+    return {
+      files: {
+        'package.json': JSON.stringify({ name: options.name, version: '0.0.0' }, null, 2),
+        src: {
+          'index.ts': `export const name = '${options.name}';\n`,
+        },
+      },
+    };
+  },
+});
+```
+
+- `options` defines the generator's prompts and flags using Zod schemas
+- `produce()` returns the [files](https://www.create.bingo/build/concepts/creations#files) to create, plus optional [scripts](https://www.create.bingo/build/concepts/creations#scripts) to run after generation and [suggestions](https://www.create.bingo/build/concepts/creations#suggestions) to print for the user
+
+See the [Bingo documentation](https://www.create.bingo/) for the full template API.
+
 ## Organization Templates
 
 An organization can publish a curated set of templates under a single npm scope by shipping an `@org/create` package whose `package.json` carries a `createConfig.templates` manifest. Once published, `vp create @org` opens an interactive picker over those templates.

package/docs/guide/env.md

@@ -6,7 +6,16 @@
 
 Managed mode is on by default, so `node`, `npm`, and related shims resolve through Vite+ and pick the right Node.js version for the current project.
 
-When a project declares `packageManager` in `package.json`, matching package-manager shims also use that exact 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.
+The project Node.js version is resolved from these sources, in priority order:
+
+1. `.node-version` file (current or parent directories)
+2. `devEngines.runtime` in `package.json` (the [devEngines standard](https://docs.npmjs.com/cli/v11/configuring-npm/package-json#devengines))
+3. `engines.node` in `package.json`
+4. The global default (`vp env default`), then the latest LTS
+
+`devEngines.runtime` ranks above `engines.node` because it declares the development-environment requirement, while `engines.node` is a consumer-facing support range. `vp env doctor` warns when declared sources conflict.
+
+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`.
 
@@ -60,8 +69,8 @@ In CI, `vp env use` can still run without shell initialization. It writes a temp
 ### Manage
 
 - `vp env default` sets or shows the global default Node.js version
-- `vp env pin` pins a Node.js version in the current directory
-- `vp env unpin` removes `.node-version` from the current directory
+- `vp env pin` pins a Node.js version in the current directory: an existing `.node-version` keeps being updated; otherwise the pin is written to `package.json#devEngines.runtime`; `.node-version` is only created when the directory has no `package.json`. Use `--target node-version` or `--target dev-engines` to choose explicitly. An existing `engines.node` is never modified.
+- `vp env unpin` removes the pin from the same source `vp env pin` would write
 - `vp env use` sets a Node.js version for the current shell session
 - `vp env install` installs a Node.js version
 - `vp env uninstall` removes an installed Node.js version
@@ -78,7 +87,7 @@ In CI, `vp env use` can still run without shell initialization. It writes a temp
 
 ## Project Setup
 
-- Pin a project version with `.node-version`
+- Pin a project version with `vp env pin`
 - Use `vp install`, `vp dev`, and `vp build` normally
 - Let Vite+ pick the right runtime for the project
 
@@ -86,7 +95,7 @@ In CI, `vp env use` can still run without shell initialization. It writes a temp
 
 ```bash
 # Setup
-vp env setup                  # Create shims for node, npm, npx
+vp env setup                  # Create shims for node, npm, npx, corepack
 vp env on                     # Use Vite+ managed Node.js
 vp env print                  # Print shell snippet for this session
 
@@ -111,6 +120,25 @@ vp node script.js             # Shorthand: run a Node.js script with the resolve
 vp node -e "console.log(1+1)" # Shorthand: forward any node flag or argument
 ```
 
+## Corepack
+
+Vite+ creates a `corepack` shim by default, so corepack works without a system Node.js installation:
+
+- On Node.js 24 and earlier, the shim runs the corepack bundled with the resolved Node.js version.
+- 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:
+
+```bash
+corepack enable               # pnpm and yarn now resolve via corepack
+corepack disable              # Remove the pnpm/yarn launchers again
+```
+
+The launchers reference the corepack copy that created them. If that copy is later removed (for example by uninstalling the Node.js version it shipped with), rerun `corepack enable` to recreate them.
+
+Shims owned by Vite+ (`npm`, `npx`, and binaries installed with `vp install -g`) are protected: if corepack removes or replaces them, Vite+ restores them and prints a warning.
+
 ## Custom Node.js Mirror
 
 By default, Vite+ downloads Node.js from `https://nodejs.org/dist`. If you're behind a corporate proxy or need to use an internal mirror (e.g., Artifactory), set the `VP_NODE_DIST_MIRROR` environment variable:

package/docs/guide/index.md

@@ -104,10 +104,11 @@ Vite+ can handle the entire local frontend development cycle from starting a pro
 ### Execute
 
 - [`vp run`](/guide/run) runs tasks across workspaces with caching.
-- [`vp cache clean`](/guide/cache) clears task cache entries.
-- [`vpx`](/guide/vpx) downloads and runs binaries globally.
 - [`vp exec`](/guide/vpx) runs local project binaries.
+- [`vp node`](/guide/env) runs Node.js scripts with the resolved Vite+ environment.
 - [`vp dlx`](/guide/vpx) downloads and runs package binaries without adding them as dependencies.
+- [`vp cache clean`](/guide/cache) clears task cache entries.
+- [`vpx`](/guide/vpx) downloads and runs binaries globally.
 
 ### Build
 
@@ -117,7 +118,8 @@ Vite+ can handle the entire local frontend development cycle from starting a pro
 
 ### Manage Dependencies
 
-- [`vp add`](/guide/install), [`vp remove`](/guide/install), [`vp update`](/guide/install), [`vp dedupe`](/guide/install), [`vp outdated`](/guide/install), [`vp why`](/guide/install), and [`vp info`](/guide/install) wrap package-manager workflows.
+- [`vp add`](/guide/install), [`vp remove`](/guide/install), [`vp update`](/guide/install), [`vp dedupe`](/guide/install), [`vp outdated`](/guide/install), [`vp list`](/guide/install), [`vp why`](/guide/install), and [`vp info`](/guide/install) wrap package-manager workflows.
+- [`vp link`](/guide/install), [`vp unlink`](/guide/install), and [`vp rebuild`](/guide/install) cover local package links and native module rebuilds.
 - [`vp pm <command>`](/guide/install) calls other package manager commands directly.
 
 ### Maintain

package/docs/guide/install.md

@@ -9,18 +9,37 @@ Use Vite+ to manage dependencies across pnpm, npm, Yarn, and Bun. Instead of swi
 Vite+ detects the package manager from the workspace root in this order:
 
 1. `packageManager` in `package.json`
-2. `pnpm-workspace.yaml`
-3. `pnpm-lock.yaml`
-4. `yarn.lock` or `.yarnrc.yml`
-5. `package-lock.json`
-6. `bun.lock` or `bun.lockb`
-7. `.pnpmfile.cjs` or `pnpmfile.cjs`
-8. `bunfig.toml`
-9. `yarn.config.cjs`
-
-If none of those files are present, `vp` falls back to `pnpm` by default. Vite+ automatically downloads the matching package manager and uses it for the command you ran.
-
-The explicit `packageManager` field 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.
+2. `devEngines.packageManager` in `package.json`
+3. `pnpm-workspace.yaml`
+4. `pnpm-lock.yaml`
+5. `yarn.lock` or `.yarnrc.yml`
+6. `package-lock.json`
+7. `bun.lock` or `bun.lockb`
+8. `.pnpmfile.cjs` or `pnpmfile.cjs`
+9. `bunfig.toml`
+10. `yarn.config.cjs`
+
+If none of those files are present, `vp` falls back to `pnpm` by default. Vite+ automatically downloads the matching package manager and uses it for the command you ran. When detection comes from lockfiles or config files, the resolved version is written to `devEngines.packageManager` so future runs are deterministic; projects that already declare `packageManager` or `devEngines.packageManager` are left as-is.
+
+The [`devEngines.packageManager`](https://docs.npmjs.com/cli/v11/configuring-npm/package-json#devengines) field accepts a single object or an array of objects, and its `version` may be a semver range:
+
+```json
+{
+  "devEngines": {
+    "packageManager": {
+      "name": "pnpm",
+      "version": "^11.0.0",
+      "onFail": "download"
+    }
+  }
+}
+```
+
+A range resolves to an already-downloaded satisfying version when possible, otherwise to the latest satisfying version from the npm registry. The range itself stays the source of truth; Vite+ never freezes it into an exact `packageManager` pin. When both `packageManager` and `devEngines.packageManager` are declared, the `packageManager` field drives selection and Vite+ warns when it does not satisfy the devEngines constraint (`vp env doctor` shows details).
+
+Vite+ currently downloads the declared package manager (the `onFail: "download"` behavior); the other `onFail` values are accepted but not yet differentiated.
+
+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
 

package/docs/guide/migrate.md

@@ -75,8 +75,8 @@ Migrate this project to Vite+. Vite+ replaces the current split tooling around r
 After the migration:
 
 - Confirm `vite` imports were rewritten to `vite-plus` where needed
-- Confirm `vitest` imports were rewritten to `vite-plus/test` where needed
-- On pnpm, keep the `vite` / `vitest` entries that `vp migrate` aliased to the Vite+ packages so the workspace override stays effective; with other package managers you can remove them once those rewrites are confirmed
+- Confirm `vitest` imports were rewritten to `vite-plus/test` (and `@vitest/browser*` to `vite-plus/test/browser*`) where needed
+- Remove old `vite`, `vitest`, and `@vitest/browser*` dependencies only after those rewrites are confirmed — `vite-plus` ships them as direct deps
 - Move remaining tool-specific config into the appropriate blocks in `vite.config.ts`
 
 Command mapping to keep in mind:
@@ -96,20 +96,30 @@ Summarize the migration at the end and report any manual follow-up still require
 
 ### Vitest
 
-Vitest is automatically migrated through `vp migrate`. If you are migrating manually, you have to update all the imports to `vite-plus/test` instead:
+Vitest is automatically migrated through `vp migrate`. `vite-plus` re-exports upstream `vitest@4.x` under `vite-plus/test*`, so for node-mode tests a single `vite-plus` install is enough — you no longer need to install `vitest` directly.
+
+Browser mode is more nuanced. `vite-plus` bundles the base browser runtime (`@vitest/browser`) and the preview provider (`@vitest/browser-preview`), but the **Playwright** and **WebdriverIO** providers stay opt-in: `@vitest/browser-playwright` (with its `playwright` peer) and `@vitest/browser-webdriverio` (with its `webdriverio` peer) are **not** shipped with `vite-plus`, so non-browser projects never pull them in. `vp migrate` detects the provider you actually use and adds it — pinned to the bundled vitest version — together with its framework. If you migrate manually and use one of these providers, install the provider package and its framework yourself so `vite-plus/test/browser-playwright` / `vite-plus/test/browser-webdriverio` can resolve.
+
+If you are migrating manually, update all the imports to `vite-plus/test*` instead:
 
 ```ts
 // before
+import { defineConfig } from 'vitest/config';
 import { describe, expect, it, vi } from 'vitest';
+import { playwright } from '@vitest/browser-playwright';
 
 const { page } = await import('@vitest/browser/context');
 
 // after
+import { defineConfig } from 'vite-plus';
 import { describe, expect, it, vi } from 'vite-plus/test';
+import { playwright } from 'vite-plus/test/browser-playwright';
 
 const { page } = await import('vite-plus/test/browser/context');
 ```
 
+`declare module 'vitest'` / `declare module '@vitest/browser*'` augmentations are intentionally **not** rewritten — `vite-plus/test*` is a thin re-export of upstream `vitest*`, so type augmentations have to target the upstream module identity to merge correctly. Leave those `declare module` statements pointing at `'vitest'` / `'@vitest/browser*'`.
+
 ### tsdown
 
 If your project uses a `tsdown.config.ts`, move its options into the `pack` block in `vite.config.ts`:

package/docs/guide/troubleshooting.md

@@ -67,9 +67,9 @@ export default defineConfig({
 
 ## Slow config loading caused by heavy plugins
 
-When `vite.config.ts` imports heavy plugins at the top level, every `import` is evaluated eagerly, even for commands like `vp lint` or `vp fmt` that don't need those plugins. This can make config loading noticeably slow.
+When `vite.config.ts` imports plugins at the top level, they are evaluated for every command, including `vp lint`, `vp fmt`, editor integrations, and long-lived background processes. This can make config loading slow and may trigger plugin setup side effects, such as reading files, starting watchers, or connecting to services.
 
-Use `lazyPlugins` to wrap plugin loading. Plugins are only loaded for commands that need them (`dev`, `build`, `test`, `preview`), and skipped for everything else:
+Use `lazyPlugins` to load plugins only when the Vite pipeline actually runs (`dev`, `build`, `test`, `preview`):
 
 ```ts [vite.config.ts]
 import { defineConfig, lazyPlugins } from 'vite-plus';