vite-plus 0.3.0 → 0.3.2

package/docs/guide/env.md

@@ -1,10 +1,23 @@
 # Environment
 
-`vp env` manages Node.js versions globally and per project.
+`vp env` manages the complete JavaScript environment: one Node.js runtime and one selected package manager. npm, pnpm, Yarn, and Bun are peer package-manager families.
 
 ## Overview
 
-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.
+Managed mode is on by default, so Node.js and configured package-manager shims resolve through Vite+ and pick the right versions for the current project. Fresh installers record managed mode for npm, pnpm, Yarn, and Bun after the user enables environment management.
+
+When an upgrade adds a package-manager shim that has no recorded mode, its first interactive invocation asks what to do only when the corresponding system binary is already on PATH. The current family defaults to managed mode; choosing a system tool or applying a choice to every family remains explicit. Non-interactive invocations use managed mode without recording a choice.
+
+Most commands operate on both components when no selector is given. Add `node`, `pm`, `npm`, `pnpm`, `yarn`, or `bun` to narrow the command. `pm` means all four families for listing and cleanup, but the single selected package manager for project operations.
+
+Unqualified versions remain Node.js versions for compatibility:
+
+```bash
+vp env pin 22.0.0               # Node.js only
+vp env pin pnpm@10.18.0         # pnpm only
+vp env pin node@24 pnpm@12      # Both components
+vp env pin 22.0.0 pnpm@10.18.0  # Also both components
+```
 
 Vite+ checks the current directory first, then walks up through its parents. The nearest directory
 with a supported declaration wins. Within each directory, sources are checked in this order:
@@ -19,7 +32,51 @@ 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.
+::: tip Using pnpm with Vite+ runtime management
+pnpm can also manage the runtime declared in `devEngines.runtime`. When both pnpm and Vite+ manage Node.js, they can download the same version separately or select different versions, causing inconsistent behavior between commands.
+
+If you want Vite+ to manage Node.js, pnpm 11+ supports disabling pnpm's automatic runtime management globally with [`runtimeOnFail`](https://pnpm.io/settings/cli#runtimeonfail):
+
+```bash
+pnpm config set --global runtimeOnFail ignore
+```
+
+This setting also disables pnpm's automatic management of other declared runtimes, including Bun and Deno. Consider whether any of your projects rely on that behavior before setting it globally.
+:::
+
+Package-manager selection uses this priority:
+
+1. Explicit command override
+2. `VP_PACKAGE_MANAGER`
+3. Top-level `packageManager`
+4. `devEngines.packageManager`
+5. Lockfile or manager-specific configuration
+6. The named package manager's global default version
+7. The named shim's latest release
+
+`VP_PACKAGE_MANAGER` selects the manager and version for commands such as `vp install`. Direct package-manager shims ignore this variable and use independent version overrides:
+
+| Variable          | Shims             |
+| ----------------- | ----------------- |
+| `VP_NPM_VERSION`  | `npm`, `npx`      |
+| `VP_PNPM_VERSION` | `pnpm`, `pnpx`    |
+| `VP_YARN_VERSION` | `yarn`, `yarnpkg` |
+| `VP_BUN_VERSION`  | `bun`, `bunx`     |
+
+These variables accept a version or range, such as `10.18.0`, `10`, or `latest`, and override the matching shim's project and default versions. They do not change the manager or version selected by `vp install`.
+
+`vp env use pnpm@10.20.0` sets `VP_PNPM_VERSION` for the current shell, just as `vp env use node@22` sets `VP_NODE_VERSION`. Each package manager has its own override, so switching Yarn does not clear a pnpm override. `vp env use` does not set or clear `VP_PACKAGE_MANAGER`.
+
+Direct shims resolve their version from the matching environment variable, then the matching session file when no shell wrapper is available, then project configuration and the family default. `vp env current pnpm` and `vp env which pnpm` inspect this shim selection; `vp env current pm` reports the manager selected for vp commands.
+
+```bash
+VP_PACKAGE_MANAGER=pnpm@10.18.0 vp install
+VP_PNPM_VERSION=10.20.0 pnpm --version
+```
+
+The overrides apply in managed mode. A package manager can also perform its own version switching after Vite+ launches it; for example, pnpm's `managePackageManagerVersions` setting may switch back to the version in `package.json`.
+
+A project selection applies only to its matching shims. For example, pnpm controls `pnpm` and `pnpx`; invoking `npm` still resolves npm independently. Without a matching project selection, a named shim uses its configured default version and otherwise uses the latest release without prompting. The resolved version is cached for one hour and an expired cache remains available when the registry cannot be reached. The directly invoked npm shim keeps its Node-bundled fallback, while an explicit `vp env ... npm` family scope uses standalone npm's latest release.
 
 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
@@ -34,7 +91,14 @@ If you want to keep that behavior, run:
 vp env on
 ```
 
-This enables managed mode, where the shims always use the Vite+-managed Node.js installation.
+This enables managed mode for both components. Their modes can also be changed independently, including one package-manager family:
+
+```bash
+vp env on node
+vp env off pm
+vp env off pnpm
+vp env on bun
+```
 
 If you do not want Vite+ to manage Node.js first, run:
 
@@ -42,16 +106,17 @@ If you do not want Vite+ to manage Node.js first, run:
 vp env off
 ```
 
-This switches to system-first mode, where the shims prefer your system Node.js and only fall back to the Vite+-managed runtime when needed.
+This switches both components to system-first mode. Vite+ prefers system tools and falls back to managed installations. Mixed configurations compose: a system package-manager launcher receives the Node.js selected by the Node mode.
+
+Using `pm` records the selected mode for all currently supported package managers and replaces their individual choices. An unscoped `on` or `off` does the same while also changing Node.js. A family without a recorded mode remains undecided until its shim is first used or an `on` / `off` command configures it.
 
 ## Commands
 
 ### Setup
 
-- `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
+- `vp env setup` creates or updates the `node`, `npm`, `npx`, `pnpm`, `pnpx`, `yarn`, `yarnpkg`, `bun`, `bunx`, `vpx`, and `vpr` shims in the resolved bin directory. It writes shell setup scripts in the config directory.
+- `vp env on` / `vp env off` changes both modes; append `node`, `pm`, `npm`, `pnpm`, `yarn`, or `bun` to narrow the change
+- `vp env print` prints PATH setup for both components; append a selector to print one
 
 PowerShell needs to dot-source the generated setup script in the current shell before `vp env use` can affect only that shell session:
 
@@ -87,28 +152,29 @@ 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` in the bin directory on Windows.
 
 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.
+session file per runtime or package manager in the resolved state directory,
+such as `.session-node-version` or `.session-pnpm-version`. Later
+shim calls in the same job use these files to resolve the same environment.
 
 ### 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: 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
-- `vp env clean` removes unused managed Node.js runtimes, all downloaded package managers, and the Corepack cache.
-- `vp env exec` runs a command with a specific Node.js version
-- `vp node` runs a Node.js script — shorthand for `vp env exec node`
+- `vp env default` shows the global Node.js default and each configured package-manager version. Bare versions set Node.js; qualified specs such as `pnpm@10.18.0` set that package manager's shim default without replacing the defaults for Bun, Yarn, or npm. `--unset` clears all defaults unless scoped.
+- `vp env pin` shows or writes project pins. Existing `.node-version` and top-level `packageManager` fields keep being updated for compatibility. An existing `.nvmrc` is updated when it is the effective Node source in the current directory; its comments and other non-version content are preserved. Otherwise Vite+ writes the matching `devEngines` entry. Use `--target node-version`, `--target nvmrc`, `--target dev-engines`, or `--target package-manager` to choose explicitly. Pinning in a child directory does not modify an inherited `.nvmrc`.
+- `vp env unpin` removes both effective pins by default; append a selector to remove one. Lower-priority declarations are not deleted.
+- `vp env use` activates the complete project environment. Explicit specs override selected components; `--unset` clears both unless scoped.
+- `vp env install` installs the complete resolved environment, a selected component, or explicit specs.
+- `vp env uninstall` removes explicit exact Node.js or qualified package-manager versions.
+- `vp env clean` removes unused installs. Use `clean node`, `clean pm`, or a concrete manager. Current and configured-default versions are preserved.
+- `vp env exec` runs a command in the resolved environment. Use `--node` and `--package-manager`; `--npm` is an alias for `--package-manager npm@…`.
+- `vp node` uses the resolved Node.js runtime and exposes the selected package-manager path to child processes.
 
 ### Inspect
 
 - `vp env current` shows the current resolved environment
 - `vp env doctor` runs environment diagnostics
 - `vp env which` shows which tool path will be used
-- `vp env list` shows locally installed Node.js versions
-- `vp env list-remote` shows available Node.js versions from the registry
+- `vp env list` shows separate Node.js, npm, pnpm, Yarn, and Bun sections; selectors narrow output
+- `vp env list-remote` fetches Node.js and all four PM registries concurrently; selectors narrow network work. `--lts` implicitly selects Node.js.
 
 ## Project Setup
 
@@ -120,54 +186,84 @@ use this file to select the Node.js version.
 
 ```bash
 # Setup
-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
+vp env setup                  # Create Node.js and package-manager shims
+vp env on                     # Manage Node.js and package managers
+vp env off pm                 # Prefer system package managers only
+vp env off pnpm               # Prefer system pnpm only
+vp env print                  # Print PATH setup for both components
 
 # Manage
-vp env pin lts                # Pin the project to the latest LTS release
-vp env install                # Install the version from .node-version, package.json, or .nvmrc
-vp env default lts            # Set the global default version
-vp env use 20                 # Use Node.js 20 for the current shell session
-vp env use --unset            # Remove the session override
-vp env clean                  # Remove unused managed caches
+vp env pin lts pnpm@10        # Pin both project components to exact versions
+vp env install                # Install the complete resolved environment
+vp env default node@24        # Set the global Node.js default
+vp env default pnpm@10        # Set pnpm's global default version
+vp env use 20 pnpm@10         # Override both components for this shell
+vp env use --unset pnpm       # Remove only the pnpm session version
+vp env use --unset pm         # Remove all package-manager session versions
+vp env clean                  # Remove unused managed Node.js and package manager versions
 
 # Inspect
 vp env current                # Show current resolved environment
 vp env current --json         # JSON output for automation
 vp env which node             # Show which node binary will be used
 vp env which npx              # Show pinned package-manager alias when packageManager matches
-vp env list-remote --lts      # List only LTS versions
+vp env list                   # Show every locally installed component
+vp env list node              # Show only Node.js installations
+vp env list-remote --lts      # List only Node.js LTS versions
 
 # Execute
-vp env exec --node lts npm i  # Execute npm with latest LTS
+vp env exec --node lts --package-manager pnpm@10 pnpm install
 vp env exec node -v           # Use shim mode with automatic version resolution
 vp node script.js             # Shorthand: run a Node.js script with the resolved version
 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` 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
-corepack disable              # Remove the pnpm/yarn launchers again
+## JSON output
+
+The JSON output for `current`, `list`, and `list-remote` is organized by component. `current --json` returns sibling `node` and `package_manager` objects:
+
+```json
+{
+  "node": {
+    "version": "22.0.0",
+    "source": "devEngines.runtime",
+    "source_path": "/project/package.json",
+    "project_root": "/project",
+    "bin_path": "/home/.vite-plus/js_runtime/node/22.0.0/bin/node",
+    "installed": true,
+    "mode": "managed"
+  },
+  "package_manager": {
+    "name": "pnpm",
+    "version": "10.18.0",
+    "source": "packageManager",
+    "source_path": "/project/package.json",
+    "project_root": "/project",
+    "bin_paths": {
+      "pnpm": "/home/.vite-plus/package_manager/pnpm/10.18.0/pnpm/bin/pnpm",
+      "pnpx": "/home/.vite-plus/package_manager/pnpm/10.18.0/pnpm/bin/pnpx"
+    },
+    "installed": true,
+    "mode": "managed"
+  }
+}
 ```
 
-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.
+`list --json` and `list-remote --json` group the component arrays:
+
+```json
+{
+  "node": [],
+  "package_managers": {
+    "npm": [],
+    "pnpm": [],
+    "yarn": [],
+    "bun": []
+  }
+}
+```
 
-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.
+Selectors omit unselected top-level fields or PM families. Registry listing is all-or-error: Vite+ prints no partial human or JSON result when any selected registry request fails.
 
 ## Custom Node.js Mirror
 

package/docs/guide/fmt.md

@@ -18,7 +18,9 @@ vp fmt . --write
 
 ## Configuration
 
-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+.
+Put formatting configuration directly in the `fmt` block in the root `vite.config.ts` so all your configuration stays in one place. We do not recommend using `.oxfmtrc.json` with Vite+.
+
+Vite+ does not currently support nested format configuration. For now, use [`fmt.overrides`](/guide/monorepo#format-overrides) in the root `vite.config.ts` for file- or package-specific options. The long-term behavior is open for discussion; [share your use case and expectations](/guide/troubleshooting#nested-lint-or-format-config-is-not-applied) to help shape it.
 
 For editors, disable nested formatter configs so format-on-save uses the root Vite+ `fmt` block:
 

package/docs/guide/ide-integration.md

@@ -82,14 +82,26 @@ You can also manually set up the Zed config:
     "JavaScript": {
       "format_on_save": "on",
       "prettier": { "allowed": false },
-      "formatter": [{ "language_server": { "name": "oxfmt" } }],
-      "code_action": "source.fixAll.oxc"
+      "formatter": [
+        { "language_server": { "name": "oxfmt" } },
+        { "code_action": "source.fixAll.oxc" }
+      ]
+    },
+    "JSX": {
+      "format_on_save": "on",
+      "prettier": { "allowed": false },
+      "formatter": [{ "language_server": { "name": "oxfmt" } }]
     },
     "TypeScript": {
       "format_on_save": "on",
       "prettier": { "allowed": false },
       "formatter": [{ "language_server": { "name": "oxfmt" } }]
     },
+    "TSX": {
+      "format_on_save": "on",
+      "prettier": { "allowed": false },
+      "formatter": [{ "language_server": { "name": "oxfmt" } }]
+    },
     "Vue.js": {
       "format_on_save": "on",
       "prettier": { "allowed": false },

package/docs/guide/index.md

@@ -96,7 +96,7 @@ Vite+ can handle the entire local frontend development cycle from starting a pro
 - [`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.
+- [`vp env`](/guide/env) manages Node.js and package-manager environments.
 
 ### Develop
 

package/docs/guide/install.md

@@ -19,7 +19,9 @@ Vite+ detects the package manager from the workspace root in this order:
 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.
+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, but package-manager detection never rewrites `package.json`. Use `vp env pin <package-manager>@<version>` when the project should declare an exact version explicitly.
+
+After selecting the package manager, Vite+ forwards the command without separately validating whether `package.json` exists. Missing-manifest behavior therefore matches the selected package manager.
 
 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:
 
@@ -138,6 +140,7 @@ Use `vp add` and `vp remove` for day-to-day dependency edits instead of editing
 - `vp add -D typescript vitest`
 - `vp add -O fsevents`
 - `vp add --save-peer react`
+- `vp add react --ignore-scripts`
 - `vp remove react`
 - `vp remove --filter web react`
 

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

@@ -81,7 +81,7 @@ These variables control the installer scripts and the standalone Windows install
 
 ### `VP_NODE_MANAGER`
 
-- **Purpose**: Control Node.js version manager setup during installation
+- **Purpose**: Control Node.js version manager setup during installation.
 - **Values**: `yes` or `no`
 - **Default**: Auto-detected
 - **CLI equivalent**: `--no-node-manager` (inverted)
@@ -91,6 +91,40 @@ These variables control the installer scripts and the standalone Windows install
   curl -fsSL https://vite.plus | VP_NODE_MANAGER=no bash
   ```
 
+### `VP_PM_MANAGER`
+
+- **Purpose**: Set the management preference for all four package-manager
+  families: npm, pnpm, Yarn, and Bun.
+- **Values**: `yes` uses Vite+ management; `no` prefers system tools, with
+  managed tools as a fallback when a system tool is unavailable.
+- **Default**: Unset. The installer's combined Node.js and package-manager
+  choice remains the default. With the script installers, setting only
+  `VP_NODE_MANAGER` preserves existing package-manager preferences.
+
+### `VP_NPM_MANAGER` / `VP_PNPM_MANAGER` / `VP_YARN_MANAGER` / `VP_BUN_MANAGER`
+
+- **Purpose**: Set the management preference for an individual package-manager
+  family. Each variable overrides `VP_PM_MANAGER` for that family.
+- **Values**: `yes` or `no`, with the same meaning as `VP_PM_MANAGER`.
+- **Default**: Unset (use `VP_PM_MANAGER`, then the combined installer choice,
+  or preserve the existing preference).
+- **Example**:
+
+  ```bash
+  # Keep system Node.js and package managers, but let Vite+ manage pnpm.
+  curl -fsSL https://vite.plus | VP_NODE_MANAGER=no VP_PM_MANAGER=no VP_PNPM_MANAGER=yes bash
+  ```
+
+These management variables are installation choices, saved in Vite+'s config.
+The interactive prompt still controls both Node.js and package managers;
+explicit package-manager variables override that combined choice. The standalone
+`vp-setup` installer uses its existing combined option as the default for both
+variables, in interactive and silent installations alike.
+In-place upgrades preserve the saved choices. Unrecognized values are ignored.
+They select management behavior, not package-manager versions, and do not
+prevent the installer from creating shims. Older releases installed through
+the legacy installer retain their original behavior.
+
 ### `VP_PR_VERSION`
 
 - **Purpose**: Install a preview build from a pull request or commit SHA
@@ -127,6 +161,16 @@ These variables configure the installed Vite+ CLI. `VP_HOME` (above) also applie
   VP_NODE_VERSION=22 vp env exec node -v
   ```
 
+### `VP_PACKAGE_MANAGER`
+
+- **Purpose**: Override the selected package manager and version
+- **Default**: None (resolved from the project or global default)
+- **Format**: `npm|pnpm|yarn|bun@<version>`
+- **Example**:
+  ```bash
+  VP_PACKAGE_MANAGER=pnpm@10.18.0 vp install
+  ```
+
 ### `VP_NODE_SKIP_SIGNATURE_VERIFY`
 
 - **Purpose**: Skip PGP signature verification of Node.js downloads

package/docs/guide/lint.md

@@ -18,7 +18,9 @@ vp lint --type-aware
 
 ## Configuration
 
-Put lint configuration directly in the `lint` block in `vite.config.ts` so all your configuration stays in one place. We do not recommend using `oxlint.config.ts` or `.oxlintrc.json` with Vite+.
+Put lint configuration directly in the `lint` block in the root `vite.config.ts` so all your configuration stays in one place. We do not recommend using `oxlint.config.ts` or `.oxlintrc.json` with Vite+.
+
+Vite+ does not currently support nested lint configuration. For now, use [`lint.overrides`](/guide/monorepo#root-config-with-overrides) in the root `vite.config.ts` for file- or package-specific rules. The long-term behavior is open for discussion; [share your use case and expectations](/guide/troubleshooting#nested-lint-or-format-config-is-not-applied) to help shape it.
 
 For the upstream rule set, options, and compatibility details, see the [Oxlint docs](https://oxc.rs/docs/guide/usage/linter.html).
 
@@ -50,3 +52,58 @@ This path is powered by [tsgolint](https://github.com/oxc-project/tsgolint) on t
 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.
+
+### Writing Your Own Rules
+
+Import the plugin authoring API from `vite-plus/lint/plugins`:
+
+```js [lint/my-plugin.js]
+import { definePlugin, defineRule } from 'vite-plus/lint/plugins';
+
+const noFoo = defineRule({
+  meta: { messages: { noFoo: 'Do not name things "foo".' } },
+  create(context) {
+    return {
+      Identifier(node) {
+        if (node.name === 'foo') {
+          context.report({ node, messageId: 'noFoo' });
+        }
+      },
+    };
+  },
+});
+
+export default definePlugin({
+  meta: { name: 'my' },
+  rules: { 'no-foo': noFoo },
+});
+```
+
+Register it under `lint.jsPlugins` and enable its rules:
+
+```ts [vite.config.ts]
+import { defineConfig } from 'vite-plus';
+
+export default defineConfig({
+  lint: {
+    jsPlugins: ['./lint/my-plugin.js'],
+    rules: {
+      'my/no-foo': 'error',
+    },
+  },
+});
+```
+
+For rule tests, `RuleTester` is available from `vite-plus/lint/plugins-dev`.
+
+Both entrypoints re-export the copy that ships with Vite+. The API therefore
+always matches the bundled Oxlint.
+
+Use them instead of adding `@oxlint/plugins` or `oxlint` as a direct
+dependency. A separately pinned copy can drift from the linter that loads your
+plugin. It also does not resolve from a plugin file under pnpm's strict layout,
+unless every package that holds a plugin declares it.
+
+`vp migrate` rewrites existing `oxlint` and `@oxlint/plugins` imports for you.
+See [Oxlint JS Plugin Imports](/guide/migrate-rules#oxlint-js-plugin-imports).
+The `vite-plus/prefer-vite-plus-imports` rule reports any that come back.

package/docs/guide/migrate-rules.md

@@ -39,6 +39,52 @@ When a default upgrade skips setup actions that would apply, it prints a hint
 to run `vp migrate --full`. Fresh (non Vite+) projects always run the full
 migration.
 
+## Pack Configuration
+
+`vp migrate` updates static `pack` objects in `vite.config.*` and exported
+objects in `tsdown.config.*` for [tsdown 0.23](https://github.com/rolldown/tsdown/releases/tag/v0.23.0).
+This also runs on existing Vite+ projects without `--full`, including workspace
+packages. Arrays and direct objects returned by `defineConfig` callbacks are
+supported. JSON tsdown configs receive the same updates after they merge into
+`vite.config.ts`.
+
+| Previous option                                                    | Updated option                                                                        |
+| ------------------------------------------------------------------ | ------------------------------------------------------------------------------------- |
+| `bundle: false`                                                    | `unbundle: true`                                                                      |
+| `bundle: true`                                                     | Removed; bundling remains the default                                                 |
+| `outExtension`                                                     | `outExtensions`                                                                       |
+| `publicDir`                                                        | `copy`                                                                                |
+| `removeNodeProtocol: true`                                         | `nodeProtocol: 'strip'`                                                               |
+| `injectStyle`                                                      | `css.inject`                                                                          |
+| `inlineOnly` / `deps.onlyAllowBundle`                              | `deps.onlyBundle`                                                                     |
+| `noExternal`                                                       | `deps.alwaysBundle`                                                                   |
+| `skipNodeModulesBundle: true` / `deps.skipNodeModulesBundle: true` | `deps.neverBundle: true`                                                              |
+| `dts.tsgo` / `dts.oxc`                                             | Select with `dts.generator`; retain generator option objects and remove boolean flags |
+| `dts.cjsReexport`                                                  | Removed; tsdown generates CJS declarations separately                                 |
+| `--public-dir` in `tsdown` or `vp pack` scripts                    | `--copy`                                                                              |
+
+Migration preserves the previous defaults by setting `deps.resolveDepSubpath`
+to `true` when absent. Enabled ATTW checks receive `profile: 'strict'` when
+no profile is set. Explicit values, including `false`, remain unchanged.
+
+`noExternal` moves to `deps.alwaysBundle`, preserving matcher expressions,
+references, and callback methods. Existing `deps.alwaysBundle` values remain
+unchanged.
+
+When `external` accompanies either `skipNodeModulesBundle` form, static matchers
+and references to local constants move to `inputOptions.external` before
+`deps.neverBundle` is set. Constant declarations and references stay intact.
+This preserves the original matching rules, including external file paths. Unsupported matchers,
+conflicting `inputOptions`, and declaration-specific dependency rules leave the
+pack object unchanged and produce a manual-migration warning.
+
+The transform does not evaluate configuration code. Objects with spreads,
+computed keys, or duplicate keys, and conflicting old and new options require
+manual review. Dynamic boolean selectors remain unchanged. Unrelated Vite and
+plugin options remain unchanged. Run `vp pack` after migration to check the
+result. Node.js requirements, TypeScript module resolution, and programmatic
+`build()` return values require separate review.
+
 ## Dependency Rules
 
 What happens to each toolchain dependency, at a glance:
@@ -204,6 +250,44 @@ surface are written against `vite-plus` by hand.
   needed.
 - Existing `vite-plus/test*` imports are left unchanged.
 
+### Oxlint JS Plugin Imports
+
+Vite+ bundles Oxlint, so the migration removes a standalone `oxlint`
+dependency. Your own Oxlint JS plugins import the authoring API by name. That
+import stops resolving when the dependency goes away. `vp lint` then fails to
+load the plugin.
+
+The migration repoints those imports at Vite+:
+
+- It rewrites `@oxlint/plugins` to `vite-plus/lint/plugins`.
+- It rewrites `oxlint/plugins-dev` to `vite-plus/lint/plugins-dev`.
+- It rewrites `oxlint` to `vite-plus/lint/plugins` when the import names a
+  binding from the authoring API, such as `defineRule`, `definePlugin`, or
+  `Context`. Older Oxlint releases exposed that API from the main entry. It now
+  lives in `@oxlint/plugins`.
+
+An import through Vite+ always matches the version of Oxlint that Vite+
+bundles. You pin no second package. The import also resolves from any package
+that already depends on `vite-plus`.
+
+The migration leaves three forms alone:
+
+- `oxlint` imports that name only the config surface, such as `defineConfig`,
+  `OxlintConfig`, or `OxlintOverride`. These still resolve against the
+  standalone package.
+- Default and namespace `oxlint` imports. They name no binding, so the
+  migration cannot tell the two surfaces apart.
+- Bare side-effect `oxlint` imports, for the same reason.
+
+The migration also skips a package that declares `oxlint` or `@oxlint/plugins`
+in `dependencies` or `peerDependencies`, or `@oxlint/plugins` in
+`optionalDependencies`. These dependencies can supply a published Oxlint plugin.
+Its consumers may not run Vite+.
+
+The cleanup retains a development dependency on `@oxlint/plugins` when source,
+package import aliases, or built plugins still reference it. This includes
+ignored output in directories such as `dist`, `build`, and `out`.
+
 ### What Is Never Rewritten
 
 - `declare module 'vitest'` and `declare module '@vitest/browser*'`: module
@@ -252,6 +336,14 @@ as `run` or `--`:
 
 Unrelated `bunx` commands and other package-executor forms remain unchanged.
 
+## Continuous Integration Rules
+
+Migration replaces exact `voidzero-dev/setup-vp@v1` references in GitHub
+Actions workflows and composite actions under `.github` with the latest exact
+`setup-vp` release known to that Vite+ version. The frozen `v1` tag does not
+receive new releases. Existing exact versions and commit SHAs are left
+unchanged.
+
 ## Node.js Version Rules
 
 Migration converts legacy Node.js version-manager files to `.node-version`,
@@ -263,8 +355,9 @@ migrations run it unconditionally.
   existing `.node-version` is kept.
 - When `.nvmrc` is removed, any `actions/setup-node` `node-version-file:
 .nvmrc` reference in `.github/workflows/*.{yml,yaml}` and composite actions
-  (`.github/actions/**/action.{yml,yaml}`) is repointed to `.node-version` so
-  CI does not fail with "node version file ... does not exist".
+  under `.github` (`.github/**/action.{yml,yaml}`) is repointed to
+  `.node-version` so CI does not fail with "node version file ... does not
+  exist".
 
 ## Package-Manager Rules
 

package/docs/guide/migrate.md

@@ -117,7 +117,7 @@ After the migration:
 
 - Confirm `vite` imports were rewritten to `vite-plus` where needed
 - 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
+- On pnpm, keep the `vite`, `vitest` dependency entries configured by `vp migrate` so the workspace aliases and overrides stay effective; with other package managers, you can remove them once those rewrites are confirmed
 - Move remaining tool-specific config into the appropriate blocks in `vite.config.ts`
 
 Command mapping to keep in mind:

package/docs/guide/monorepo.md

@@ -6,6 +6,8 @@ Because `vite.config.ts` is just JavaScript, you can choose to put your entire c
 
 ## Root Config With Overrides
 
+Vite+ does not currently support nested lint or format configuration. Package-level `lint` and `fmt` blocks are not automatically applied. For now, define file- or package-specific settings with overrides in the root `vite.config.ts`. The long-term behavior is open for discussion; [share your use case and expectations](/guide/troubleshooting#nested-lint-or-format-config-is-not-applied) to help shape it.
+
 Use `lint.overrides` for Oxlint rules that only apply to some packages:
 
 ```ts [vite.config.ts]