vite-plus 0.2.8 → 0.3.0

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

@@ -11,6 +11,10 @@ These variables control the installer scripts and the standalone Windows install
 - **Purpose**: Version to install
 - **Default**: `latest`
 - **CLI equivalent**: `--version`
+- **Note**: Vite+ 0.2.x and earlier do not support the split directory layout.
+  The installer always puts these releases in the monolithic root (`VP_HOME` or
+  `~/.vite-plus`). This rule also applies to a fresh machine. The installer
+  checks the downloaded binary and prints a notice.
 - **Example**:
 
   ```bash
@@ -25,9 +29,15 @@ These variables control the installer scripts and the standalone Windows install
 
 ### `VP_HOME`
 
-- **Purpose**: Installation directory; the installed CLI reads the same variable as the Vite+ home directory (see [Environment](/guide/env))
-- **Default**: `~/.vite-plus` (Unix) or `%USERPROFILE%\.vite-plus` (Windows)
-- **CLI equivalent**: `--install-dir`
+- **Purpose**: Optional pin for the single-root layout. Set it to an absolute
+  path. Vite+ then puts bin, data, cache, config, and state under that directory.
+  The installed CLI reads the same variable. See [Environment](/guide/env).
+- **Default**: unset. Vite+ reuses an existing install in `~/.vite-plus` on
+  Unix or `%USERPROFILE%\.vite-plus` on Windows. The directory must contain a
+  `current` link. Otherwise, a fresh install uses the split platform layout. On
+  Unix, it uses `~/.local/share/vite-plus` and its Vite+-owned `bin`
+  subdirectory. On Windows, it uses `%LOCALAPPDATA%\vite-plus\data` and
+  `%LOCALAPPDATA%\vite-plus\bin`.
 - **Example**:
 
   ```bash
@@ -40,6 +50,25 @@ These variables control the installer scripts and the standalone Windows install
   $env:VP_HOME = "D:\vite-plus"; irm https://vite.plus/ps1 | iex
   ```
 
+### `VP_BIN_DIR` / `VP_DATA_DIR` / `VP_CACHE_DIR`
+
+- **Purpose**: Internal absolute directory overrides for integrations that
+  must pin a split install. Set all three variables together. The installer
+  rejects an incomplete group. Vite+ ignores the group when `VP_HOME` is set
+  or when it reuses an existing `~/.vite-plus` install.
+- **Default**: unset (XDG / platform defaults)
+- **Persistence**: The generated environment file does not export these
+  variables. An integration that uses them must provide the complete group to
+  each Vite+ process.
+- **Example**:
+
+  ```bash
+  export VP_DATA_DIR=$HOME/vite-plus-data
+  export VP_BIN_DIR=$VP_DATA_DIR/bin
+  export VP_CACHE_DIR=$HOME/.cache/vite-plus
+  curl -fsSL https://vite.plus | bash
+  ```
+
 ### `NPM_CONFIG_REGISTRY`
 
 - **Purpose**: Custom npm registry URL
@@ -71,7 +100,12 @@ These variables control the installer scripts and the standalone Windows install
 
 ### Development variables
 
-When developing Vite+ itself, `VP_LOCAL_TGZ` (path to a local `vite-plus.tgz`) and `VP_LOCAL_BINARY` (path to a local `vp` binary) feed the installer a local build. The installers also set `VP_INSTALL_STOP` themselves; do not set it manually.
+Use `VP_LOCAL_TGZ` and `VP_LOCAL_BINARY` when you develop Vite+ itself.
+`VP_LOCAL_TGZ` specifies a local `vite-plus.tgz` file. `VP_LOCAL_BINARY`
+specifies a local `vp` binary. The installers use these files for the local
+build. They use `VP_DUMP_DIRS=1` to get the layout mode and all five `EnvConfig`
+category roots from the selected binary. They do not resolve the directory
+variables. The installers set `VP_INSTALL_STOP`; do not set it manually.
 
 ## Runtime Variables
 
@@ -100,6 +134,17 @@ These variables configure the installed Vite+ CLI. `VP_HOME` (above) also applie
 - **Default**: None (verification enabled)
 - **Details**: [Node.js Signature Verification](/guide/env#node-js-signature-verification)
 
+### `VP_DOWNLOAD_TIMEOUT`
+
+- **Purpose**: Per-request timeout, in seconds, for large downloads such as Node.js runtimes and package-manager tarballs
+- **Values**: Positive integer, at most `86400` (24 hours); invalid values are ignored with a warning
+- **Default**: `600` (10 minutes)
+- **Example**:
+  ```bash
+  # Allow up to 30 minutes per download on a slow connection
+  VP_DOWNLOAD_TIMEOUT=1800 vp env install 22
+  ```
+
 ### `VP_SHELL`
 
 - **Purpose**: Specify the current shell
@@ -150,11 +195,13 @@ Vite+ sets additional `VP_*` variables during shim dispatch and shell integratio
 ### `VP_LOG`
 
 - **Purpose**: Log filter string for `tracing_subscriber`
+- **Installer behavior**: When `CI=true`, `install.sh` hides shell file errors.
+  Set `VP_LOG=trace` to show these errors.
 - **Default**: None
 - **Example**:
   ```bash
   VP_LOG=debug vp dev
-  VP_LOG=vite_task=trace vp build
+  VP_LOG=vt=trace vp build
   ```
 
 ### `VP_DEBUG_SHIM`
@@ -184,7 +231,7 @@ Vite+ also respects these standard environment variables:
 ### `HOME` / `USERPROFILE`
 
 - **Purpose**: User home directory
-- **Effect**: Base for the default `~/.vite-plus` path
+- **Effect**: Base for the existing-install probe (`~/.vite-plus`) and for split platform defaults
 
 ## Precedence
 

package/docs/guide/lint.md

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

package/docs/guide/migrate-rules.md

@@ -82,6 +82,14 @@ Related rules:
 - A direct `vite` declaration is never removed merely because a root override
   exists.
 - Plain or stale aliases are normalized; named catalog references are kept.
+- Under pnpm the managed override keys use an explicit `@*` range (`vite@*`,
+  `vitest@*`). pnpm applies an override by replacing the declared spec on every
+  manifest, importer manifests included. A bare key matches any spec, including
+  `catalog:`, and `vp up` then rewrites that reference to a concrete version.
+  The `@*` range keeps the override on the semver ranges that transitive and
+  peer declarations use. It leaves `catalog:` references to the catalog, which
+  already resolves them to Vite+ core. Migration re-keys a project that still
+  holds the bare key, and keeps its named-catalog choice.
 - The direct-entry rule above is pnpm-specific. Bun mirrors its core alias as
   a direct dependency for its peer resolver, and npm browser-provider layouts
   may need a top-level `vite` edge so nested Vitest packages can resolve
@@ -228,6 +236,7 @@ scripts while preserving their arguments:
 | `lint-staged` | `vp staged`                                 |
 | `eslint`      | `vp lint`, when its optional migration runs |
 | `prettier`    | `vp fmt`, when its optional migration runs  |
+| `tsup`        | `vp pack`, when its optional migration runs |
 
 For commands launched through `bunx`, migration preserves `bunx` and its
 `--bun` flag (keeping the user's chosen runtime) and rewrites only the managed

package/docs/guide/migrate.md

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

package/docs/guide/monorepo.md

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

package/docs/guide/test.md

@@ -6,6 +6,14 @@
 
 `vp test` is built on [Vitest](https://vitest.dev/), so you get a Vite-native test runner that reuses your Vite config and plugins, supports Jest-style expectations, snapshots, and coverage, and handles modern ESM, TypeScript, and JSX projects cleanly.
 
+Vitest APIs are available from `vite-plus/test`, so a single `vite-plus` install is enough — you do not need to install `vitest` directly:
+
+```ts [src/example.test.ts]
+import { describe, expect, it, vi } from 'vite-plus/test';
+```
+
+For the browser mode subpaths (`vite-plus/test/browser*`), see [Migrating Vitest](/guide/migrate#vitest).
+
 ::: info
 `vp test` always runs the built-in Vitest command. If your project also has a `test` script in `package.json`, run `vp run test` when you want to run that script instead. See [Built-in Commands vs Scripts](/guide/run#built-in-commands-vs-scripts).
 :::

package/docs/guide/troubleshooting.md

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

package/docs/guide/upgrade.md

@@ -11,6 +11,29 @@ There are two parts to upgrading Vite+:
 
 You can upgrade both of them independently.
 
+## Show the Toolchain
+
+Run `vp toolchain` to show the components for the current directory:
+
+```bash
+vp toolchain
+vp toolchain vite
+vp toolchain vite rolldown oxc
+vp toolchain --json
+```
+
+The command uses the local `vite-plus` package when the project has one. Use
+`--global` to show the release for the global `vp` command:
+
+```bash
+vp toolchain --global
+```
+
+`vp why <package>` shows the dependency graph from the package manager. It
+cannot show code bundled into `@voidzero-dev/vite-plus-core`. It also cannot
+show engines compiled into Vite+. Use `vp toolchain` to show those versions and
+relationships.
+
 ## Global `vp`
 
 ```bash
@@ -20,6 +43,51 @@ vp upgrade <version>              # install a specific version
 vp upgrade --registry <registry>  # use a custom npm registry
 ```
 
+### Move an Existing Install to the Split Directory Layout
+
+Vite+ 0.3.0 is the first release that supports the split directory layout.
+Vite+ 0.2.x and earlier use the single-root layout for fresh installs and
+upgrades.
+
+`vp upgrade` keeps an existing default install in `~/.vite-plus` on Unix or
+`%USERPROFILE%\.vite-plus` on Windows. The command upgrades the CLI in that
+directory. It does not move the install to the split platform directories. You
+can continue to use the existing layout.
+
+To use the split layout now, remove the existing install. Then install Vite+
+again. Run `vp implode` in a shell that uses the current install. The command
+removes the generated environment file and shell profile entries. It does not
+unset directory variables in the current shell. Unset all Vite+ directory
+variables before you run the installer. This can include values from an earlier
+preview environment file. Alternatively, start a new shell after `vp implode`.
+Then run the installer in the new shell.
+
+::: warning
+`vp implode` removes all Vite+-managed Node.js runtimes, global packages,
+configuration, and caches. Keep the existing layout if you do not want to
+recreate that data.
+:::
+
+```bash
+vp implode
+unset VP_HOME VP_DATA_DIR VP_BIN_DIR VP_CACHE_DIR
+curl -fsSL https://vite.plus | bash
+```
+
+On Windows:
+
+```powershell
+vp implode
+Remove-Item Env:\VP_HOME, Env:\VP_DATA_DIR, Env:\VP_BIN_DIR, Env:\VP_CACHE_DIR -ErrorAction SilentlyContinue
+irm https://vite.plus/ps1 | iex
+```
+
+Also remove persistent definitions of `VP_HOME`, `VP_DATA_DIR`, `VP_BIN_DIR`,
+and `VP_CACHE_DIR` from your shell profile or system environment. A fresh
+install uses `VP_HOME` or a complete `VP_*_DIR` group that remains set.
+`VP_HOME` selects the single-root layout. If you install Vite+ 0.2.x or earlier,
+the installer also uses this layout. The installer prints a notice.
+
 ### Rollback
 
 Vite+ keeps the **3 most recent** versions installed so you can revert quickly:
@@ -46,14 +114,16 @@ If you migrated with `vp migrate`, your project pins `vitest` to an exact versio
 
 - **npm / Bun:** a `vitest` entry under `overrides` in `package.json`
 - **Yarn:** a `vitest` entry under `resolutions` in `package.json`
-- **pnpm:** a `vitest` entry under `overrides` in `pnpm-workspace.yaml` — unless your `package.json` already had a `pnpm` field, in which case it lives under `pnpm.overrides` in `package.json` instead (pnpm ignores `pnpm-workspace.yaml` overrides when `package.json` defines `pnpm.overrides`)
+- **pnpm:** a `vitest@*` entry under `overrides` in `pnpm-workspace.yaml`. If your `package.json` already has a `pnpm` field, the entry lives under `pnpm.overrides` in `package.json` instead. pnpm ignores `pnpm-workspace.yaml` overrides when `package.json` defines `pnpm.overrides`.
+
+Under pnpm the managed keys use an explicit `@*` range (`vite@*`, `vitest@*`). pnpm applies an override by replacing the declared spec on every manifest, importer manifests included. A bare key matches any spec, including `catalog:`. The `@*` range keeps the override on the semver ranges that transitive and peer declarations use, and leaves `catalog:` references intact. `vp up` therefore no longer rewrites them to a concrete version.
 
 A Vite+ release can bump the bundled Vitest. Because that pin also applies to `vite-plus`'s own `vitest` dependency, an out-of-date pin keeps installing the previous runner even after you upgrade `vite-plus` — splitting Vitest's internals (mocks, `expect`, runner state) between the pinned copy and the one `vp test` loads.
 
 After upgrading `vite-plus`, re-pin `vitest` to the version Vite+ now bundles. Check that version with:
 
 ```bash
-vp --version
+vp toolchain vitest
 ```
 
 Then set the `vitest` override to that exact version, or rerun `vp migrate` to update the pin for you.
@@ -86,7 +156,7 @@ irm https://vite.plus/ps1 | iex
 Remove-Item Env:\VP_PR_VERSION
 ```
 
-The installer resolves the ref to its `0.0.0-commit.<sha>` build through the registry bridge and installs it like any other version. Run `vp --version` afterward to confirm which build and bundled tool versions are active. When you are done testing, return to the published release with `vp upgrade --force` or by running the installer again without `VP_PR_VERSION`.
+The installer uses the registry bridge to resolve the ref to a `0.0.0-commit.<sha>` build. It installs this build like other versions. Run `vp toolchain --global` to show the active build and tool versions. After testing, run `vp upgrade --force` to restore the published release. You can also run the installer without `VP_PR_VERSION`.
 
 ### Local `vite-plus` Preview
 
@@ -96,6 +166,6 @@ After installing the preview global CLI above, run migrate in the project to mov
 vp migrate
 ```
 
-Migrate points the project at the bridge registry (writing it to `.npmrc`, or `.yarnrc.yml` for Yarn Berry) and pins `vite-plus` and the `vite` -> `@voidzero-dev/vite-plus-core` alias to the matching `0.0.0-commit.<sha>` version. That registry line is what lets the same versions resolve in the project's own CI, so commit it if you want CI to test the preview too.
+Migrate writes the bridge registry to `.npmrc`. For Yarn Berry, it writes the registry to `.yarnrc.yml`. It pins `vite-plus` and the `vite` alias to the matching `0.0.0-commit.<sha>` version. The `vite` alias points to `@voidzero-dev/vite-plus-core`. Commit the registry line if the project CI must test the preview.
 
-After installing, check the bundled versions with `vp --version`. When testing is complete, restore the published release: set `vite-plus` back to `latest`, remove the bridge `registry` line from `.npmrc` (or `.yarnrc.yml`), and reinstall with `vp install`.
+After the install, run `vp toolchain` to show the selected versions. After testing, set `vite-plus` to `latest`. Remove the bridge `registry` line from `.npmrc` or `.yarnrc.yml`. Then run `vp install`.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "vite-plus",
-  "version": "0.2.8",
+  "version": "0.3.0",
   "description": "The Unified Toolchain for the Web",
   "homepage": "https://viteplus.dev/guide",
   "bugs": {
@@ -28,7 +28,6 @@
     "binding/index.d.cts",
     "binding/index.d.ts",
     "binding/index.js",
-    "dist/test",
     "docs",
     "rules",
     "templates"
@@ -85,6 +84,10 @@
     "./pack/client": {
       "types": "./dist/pack-client.d.ts"
     },
+    "./toolchain": {
+      "types": "./dist/toolchain.d.ts",
+      "default": "./dist/toolchain.js"
+    },
     "./versions": {
       "types": "./dist/versions.d.ts",
       "default": "./dist/versions.js"
@@ -347,33 +350,33 @@
     }
   },
   "dependencies": {
-    "@oxc-project/types": "=0.142.0",
-    "@oxlint/plugins": "=1.73.0",
-    "@vitest/browser": "4.1.10",
-    "@vitest/browser-preview": "4.1.10",
-    "@vitest/expect": "4.1.10",
-    "@vitest/mocker": "4.1.10",
-    "@vitest/pretty-format": "4.1.10",
-    "@vitest/runner": "4.1.10",
-    "@vitest/snapshot": "4.1.10",
-    "@vitest/spy": "4.1.10",
-    "@vitest/utils": "4.1.10",
-    "oxfmt": "=0.61.0",
-    "oxlint": "=1.76.0",
+    "@oxc-project/types": "=0.146.0",
+    "@oxlint/plugins": "=1.79.0",
+    "@vitest/browser": "4.1.11",
+    "@vitest/browser-preview": "4.1.11",
+    "@vitest/expect": "4.1.11",
+    "@vitest/mocker": "4.1.11",
+    "@vitest/pretty-format": "4.1.11",
+    "@vitest/runner": "4.1.11",
+    "@vitest/snapshot": "4.1.11",
+    "@vitest/spy": "4.1.11",
+    "@vitest/utils": "4.1.11",
+    "oxfmt": "=0.64.0",
+    "oxlint": "=1.79.0",
     "oxlint-tsgolint": "=7.0.2001",
-    "vitest": "4.1.10",
-    "@voidzero-dev/vite-plus-core": "0.2.8"
+    "vitest": "4.1.11",
+    "@voidzero-dev/vite-plus-core": "0.3.0"
   },
   "devDependencies": {
-    "@emnapi/core": "2.0.0-alpha.3",
-    "@emnapi/runtime": "2.0.0-alpha.3",
+    "@emnapi/core": "2.0.0-alpha.4",
+    "@emnapi/runtime": "2.0.0-alpha.4",
     "@napi-rs/cli": "^3.8.2",
     "@nkzw/safe-word-list": "^3.1.0",
     "@types/cross-spawn": "^6.0.6",
-    "@types/semver": "^7.7.1",
+    "@types/semver": "^7.8.0",
     "@types/validate-npm-package-name": "^4.0.2",
-    "@vitest/browser-playwright": "4.1.10",
-    "@vitest/browser-webdriverio": "4.1.10",
+    "@vitest/browser-playwright": "4.1.11",
+    "@vitest/browser-webdriverio": "4.1.11",
     "bingo": "^0.9.3",
     "cac": "^7.0.0",
     "cross-spawn": "^7.0.5",
@@ -392,11 +395,11 @@
     "yaml": "^2.8.1",
     "zod": "^3.25.76",
     "@voidzero-dev/vite-plus-prompts": "0.0.0",
-    "vite": "npm:@voidzero-dev/vite-plus-core@0.2.8"
+    "vite": "npm:@voidzero-dev/vite-plus-core@0.3.0"
   },
   "peerDependencies": {
-    "@vitest/browser-playwright": "4.1.10",
-    "@vitest/browser-webdriverio": "4.1.10"
+    "@vitest/browser-playwright": "4.1.11",
+    "@vitest/browser-webdriverio": "4.1.11"
   },
   "peerDependenciesMeta": {
     "@vitest/browser-playwright": {
@@ -424,14 +427,14 @@
     "node": "^20.19.0 || ^22.18.0 || >=24.11.0"
   },
   "optionalDependencies": {
-    "@voidzero-dev/vite-plus-darwin-arm64": "0.2.8",
-    "@voidzero-dev/vite-plus-darwin-x64": "0.2.8",
-    "@voidzero-dev/vite-plus-linux-arm64-gnu": "0.2.8",
-    "@voidzero-dev/vite-plus-linux-arm64-musl": "0.2.8",
-    "@voidzero-dev/vite-plus-linux-x64-gnu": "0.2.8",
-    "@voidzero-dev/vite-plus-linux-x64-musl": "0.2.8",
-    "@voidzero-dev/vite-plus-win32-x64-msvc": "0.2.8",
-    "@voidzero-dev/vite-plus-win32-arm64-msvc": "0.2.8"
+    "@voidzero-dev/vite-plus-darwin-arm64": "0.3.0",
+    "@voidzero-dev/vite-plus-darwin-x64": "0.3.0",
+    "@voidzero-dev/vite-plus-linux-arm64-gnu": "0.3.0",
+    "@voidzero-dev/vite-plus-linux-arm64-musl": "0.3.0",
+    "@voidzero-dev/vite-plus-linux-x64-gnu": "0.3.0",
+    "@voidzero-dev/vite-plus-linux-x64-musl": "0.3.0",
+    "@voidzero-dev/vite-plus-win32-x64-msvc": "0.3.0",
+    "@voidzero-dev/vite-plus-win32-arm64-msvc": "0.3.0"
   },
   "scripts": {
     "build": "oxnode -C dev ./build.ts",

package/rules/vite-tools.yml

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

package/dist/dist-DT25H9pj.js

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