void 0.10.5 → 0.10.6

package/skills/void/docs/node_modules/void/node_modules/@void/md/node_modules/vite-plus/docs/guide/migrate-rules.md

@@ -0,0 +1,347 @@
+# Migration Rules
+
+This reference describes exactly what `vp migrate` does to a project: how it
+updates dependencies, rewrites source imports and package scripts, and adjusts
+package-manager configuration. See the [migration guide](./migrate.md) for the
+command overview and workflow.
+
+Except for [Before You Migrate](#before-you-migrate), which lists steps you
+take yourself, everything below describes automatic behavior.
+
+## Before You Migrate
+
+1. Run `vp upgrade` so the global CLI has the latest migration rules. A stale
+   local `vite-plus` is not a blocker: when the project's local copy is older,
+   migration delegates to the global CLI.
+2. Upgrade the project to Vite 8+ and Vitest 4.1+ when necessary.
+3. Run `vp migrate` from the workspace root. Use `--no-interactive` in
+   automated environments.
+4. Review every changed manifest, package-manager config, source rewrite, and
+   generated lockfile.
+5. Validate with `vp install`, `vp check`, `vp test`, and `vp build`.
+
+Migration is idempotent: running it again after a successful migration should
+not produce another diff.
+
+## Upgrade vs. Full Setup
+
+On a project that already depends on `vite-plus`, `vp migrate` performs an
+upgrade only: it updates dependencies and package-manager configuration and
+finalizes imports. It does not touch project setup.
+
+- `--full` also runs the setup actions: git hooks, editor config, agent files,
+  ESLint and Prettier migration, framework shims, the tsconfig `baseUrl` fix,
+  and the `.nvmrc`/Volta to `.node-version` conversion.
+- `--hooks`, `--agent`, and `--editor` opt into a single setup action without
+  `--full`.
+
+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.
+
+## Dependency Rules
+
+What happens to each toolchain dependency, at a glance:
+
+| Dependency                     | What happens                                                                                                                                                            |
+| ------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `vite-plus`                    | Added where the package is migrated; plain ranges re-pinned to the concrete target, directly or through a catalog.                                                      |
+| `vite`                         | Existing declarations kept and pointed at the core alias. Under pnpm, added as a direct dev dependency wherever needed (see [Vite and Overrides](#vite-and-overrides)). |
+| `vitest`                       | Removed in the common node-mode case because `vite-plus` provides it transitively. Kept or added only when [directly required](#when-vitest-is-directly-required).      |
+| `@vitest/*`                    | Directly installed lockstep packages aligned to the bundled Vitest version (see [Vitest Ecosystem Packages](#vitest-ecosystem-packages)).                               |
+| `@voidzero-dev/vite-plus-test` | Removed everywhere: dependencies, overrides, resolutions, and catalog aliases. Imports are rewritten to the current `vite-plus/test*` surface.                          |
+
+### Version Selection
+
+- `vite-plus` is pinned to the concrete version of the CLI running the
+  migration, never the `latest` dist-tag.
+- The `vite` alias targets `@voidzero-dev/vite-plus-core` from the same Vite+
+  release.
+- A catalog-backed manifest may contain `catalog:` or a named catalog
+  reference. Migration keeps the reference and updates the referenced catalog
+  value to the concrete toolchain target.
+- Deliberate protocol pins are preserved: `workspace:`, `file:`, `link:`,
+  `npm:`, `github:`, Git URLs, and HTTP URLs.
+- Migration reconciles every workspace package, not only the root manifest.
+  Shared overrides and catalogs stay at the workspace root; dependencies that
+  provide a peer belong in each package that needs them.
+
+### Vite and Overrides
+
+Package-manager overrides do not create dependency edges by themselves. Under
+pnpm, a package that lists `vite-plus` in `dependencies` or `devDependencies`
+but has no `vite` entry anywhere (`dependencies`, `devDependencies`,
+`optionalDependencies`, or `peerDependencies`) lets pnpm auto-install upstream
+Vite to satisfy Vitest's required `vite` peer, splitting the project across
+separate Vite+, Vite, and Vitest instances. To prevent this, `vp migrate` adds
+the missing `vite` entry to `devDependencies` of every such package; the
+workspace override then redirects it to Vite+ core.
+
+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.
+- 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
+  `vite`.
+
+### When Vitest Is Directly Required
+
+Migration keeps or adds a package-local `vitest` at the exact bundled version
+when any of the following is true:
+
+- an installed dependency has a non-optional `vitest` peer, whether exact or a
+  range;
+- the package uses Vitest browser mode or an opt-in browser provider;
+- source or TypeScript configuration retains an upstream `vitest` reference;
+- the package declares `@nuxt/test-utils`; or
+- dependency metadata is unavailable and an existing direct `vitest` might be
+  satisfying an unknown required peer.
+
+Detection reads installed peer metadata, so integrations such as
+`vite-plugin-gherkin` are handled even though their names do not contain
+`vitest`.
+
+When a package qualifies, migration:
+
+- adds `vitest` to that package, not indiscriminately to every workspace
+  package;
+- uses the existing catalog reference when supported, otherwise the exact
+  bundled version; and
+- keeps a matching workspace override or resolution so the graph resolves a
+  single Vitest version.
+
+A peer declaration alone does not install Vitest. If a surviving
+`peerDependencies.vitest` uses a catalog entry that migration will remove, it
+is resolved to the public peer range first.
+
+### Vitest Ecosystem Packages
+
+Official current `@vitest/*` packages generally publish in lockstep with
+Vitest. Migration aligns the ones the project directly installs, including
+`@vitest/coverage-v8`, `@vitest/coverage-istanbul`, `@vitest/ui`, and
+`@vitest/web-worker`:
+
+- when the package manager supports catalogs, they are referenced through the
+  toolchain catalog: an existing `catalog:` / `catalog:<name>` reference is
+  preserved, a catalog entry is added for any package that lacks one, and each
+  entry is updated to the bundled Vitest version;
+- when catalogs are unsupported (npm, a standalone bun project, or a
+  pre-catalog pnpm/Yarn), the concrete bundled version is written instead.
+
+Packages that are **not** aligned:
+
+- `@vitest/eslint-plugin` follows its own version line;
+- `@vitest/coverage-c8` stopped at an older release and has no Vitest 4
+  version; and
+- third-party `vitest-*` integrations keep their own compatible versions,
+  though their required Vitest peer may still trigger
+  [direct provisioning](#when-vitest-is-directly-required).
+
+For browser mode, the base `@vitest/browser` runtime and
+`@vitest/browser-preview` are bundled by Vite+ and are removed as direct
+dependencies. The Playwright and WebdriverIO providers stay opt-in: a kept or
+injected provider is referenced through the preferred toolchain catalog at the
+bundled Vitest version (or written concretely when catalogs are unsupported),
+and its `playwright` or `webdriverio` peer is installed alongside.
+
+Providers are detected before imports are rewritten. This covers legacy
+projects that aliased `vitest` to `@voidzero-dev/vite-plus-test` and import
+from `vitest/browser-<provider>`, `vitest/browser/providers/<provider>`, or
+`vitest/plugins/browser-<provider>`: those imports still install the
+corresponding `@vitest/browser-playwright` or `@vitest/browser-webdriverio`
+dependency and its framework peer.
+
+Object-valued nested npm and Bun overrides are preserved: they are
+user-defined scopes rather than scalar version pins.
+
+## Source Rewrite Rules
+
+### `vite` Imports
+
+`vite` and `vite/*` imports are rewritten to `vite-plus` **only in config
+entry files**: `vite.config.*`, `vitest.config.*`, and any config file the
+migration resolved. Every other file keeps its `vite` imports, for two
+reasons:
+
+- `vite-plus` is not a guaranteed superset of Vite's exposed surface. It owns
+  only `defineConfig`, `defineProject`, and `lazyPlugins`, so rewriting a
+  pass-through symbol such as `createBuilder` or `loadConfigFromFile`
+  (including in `typeof import('vite')` type positions) can break.
+- An unrewritten `vite` import still resolves through the
+  `@voidzero-dev/vite-plus-core` alias in a Vite+ project.
+
+Plugin packages (an unscoped name starting with `vite-plugin-` or
+`unplugin-`, or `vite` in `peerDependencies`/`dependencies`) skip the rewrite
+even in config files. Only the `vite` specifier is in scope for this rule.
+
+`declare module 'vite'` augmentations follow the same rule and are preserved
+outside config files. Through the core alias they reach the same
+`@voidzero-dev/vite-plus-core` module whose `UserConfig` types `defineConfig`
+from `vite-plus`, so they keep working after migration; `vite-plus` itself
+exports no `UserConfig` symbol, so a rewritten `declare module 'vite-plus'`
+augmentation would merge with nothing. Extensions aimed at `vite-plus`'s own
+surface are written against `vite-plus` by hand.
+
+### `vitest` and Browser Imports
+
+- Ordinary `vitest` and `vitest/*` imports are rewritten to
+  `vite-plus/test*`.
+- Legacy Playwright and WebdriverIO provider imports are detected before this
+  rewrite so their optional provider dependencies are not lost.
+- Scoped `@vitest/browser*` imports are rewritten to the corresponding
+  `vite-plus/test/browser*` exports, provisioning opt-in providers when
+  needed.
+- Existing `vite-plus/test*` imports are left unchanged.
+
+### What Is Never Rewritten
+
+- `declare module 'vitest'` and `declare module '@vitest/browser*'`: module
+  augmentation must retain the upstream module identity.
+- References that stay behind, such as `compilerOptions.types`,
+  `require.resolve`, `import.meta.resolve`, and `vitest/package.json`,
+  require package-local Vitest (see
+  [When Vitest Is Directly Required](#when-vitest-is-directly-required)).
+- In a package that declares `@nuxt/test-utils`, every `vitest` and
+  `vitest/*` module specifier is preserved package-wide: the Nuxt transform
+  requires the upstream identity and can otherwise inject a duplicate `vi`
+  import. This exception does not apply to sibling packages or to scoped
+  `@vitest/browser*` imports.
+
+The `prefer-vite-plus-imports` lint rule follows the same Nuxt exception, so
+lint autofix preserves these imports too.
+
+## Package Script Rewrite Rules
+
+Migration rewrites commands provided by the Vite+ toolchain in `package.json`
+scripts while preserving their arguments:
+
+| Before        | After                                       |
+| ------------- | ------------------------------------------- |
+| `vite`        | `vp dev`, or the matching `vp` subcommand   |
+| `vitest`      | `vp test`                                   |
+| `oxlint`      | `vp lint`                                   |
+| `oxfmt`       | `vp fmt`                                    |
+| `tsdown`      | `vp pack`                                   |
+| `lint-staged` | `vp staged`                                 |
+| `eslint`      | `vp lint`, when its optional migration runs |
+| `prettier`    | `vp fmt`, 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
+command. This also works when `bunx` follows a command-launcher delimiter such
+as `run` or `--`:
+
+| Before                                                  | After                                                    |
+| ------------------------------------------------------- | -------------------------------------------------------- |
+| `bunx --bun vite build`                                 | `bunx --bun vp build`                                    |
+| `bunx --bun vitest run`                                 | `bunx --bun vp test run`                                 |
+| `portless --tailscale run bunx --bun vite`              | `portless --tailscale run bunx --bun vp dev`             |
+| `dotenv -e .env.test -- bunx --bun oxlint --type-aware` | `dotenv -e .env.test -- bunx --bun vp lint --type-aware` |
+
+Unrelated `bunx` commands and other package-executor forms remain unchanged.
+
+## Node.js Version Rules
+
+Migration converts legacy Node.js version-manager files to `.node-version`,
+the format Vite+ reads. On an existing Vite+ project this conversion is part
+of the full setup bucket, so it runs with `vp migrate --full`; fresh
+migrations run it unconditionally.
+
+- `.nvmrc` and Volta `volta.node` pins are converted to `.node-version`. An
+  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".
+
+## Package-Manager Rules
+
+### pnpm
+
+**Root settings location.** pnpm 10.6.2+ uses `pnpm-workspace.yaml` as the
+single source for supported root settings. Migration moves recognized
+`package.json#pnpm` fields there, including overrides, peer rules, patch
+settings, package extensions, architecture and build policy, audit/update
+configuration, and configuration dependencies. It removes the `pnpm` object
+when it becomes empty and preserves unknown keys that may belong to other
+tooling.
+
+- When both files define the same migrated setting, object entries are merged
+  recursively and unique array entries are retained. Values from
+  `package.json#pnpm` win at conflicting scalar leaves, while workspace-only
+  sibling entries are preserved.
+- Before pnpm 10.6.2, these settings stay in `package.json#pnpm`. (Workspace
+  settings support arrived incrementally: 10.5.0 in general, 10.5.1 for
+  overrides, 10.6.2 for `peerDependencyRules`. pnpm 11 no longer reads the
+  legacy `package.json` settings.)
+
+**Catalogs.** Catalogs are a separate feature, supported from pnpm 9.5.0,
+independent of the settings boundary above. Even below 10.6.2, where
+overrides stay in `package.json#pnpm`, migration still rewrites the workspace
+catalog off stale wrapper aliases and keeps `catalog:` overrides as
+references rather than inlining them to concrete versions.
+
+- Dependency references, default and named catalogs, overrides, and
+  `peerDependencyRules` are kept consistent with each other.
+- pnpm accepts the logical default catalog as either top-level `catalog` or
+  `catalogs.default`, but not both. Migration preserves the existing form and
+  never creates the other form beside it.
+- When an existing named catalog already owns `vite-plus`, `vite`, or
+  `vitest`, migration reuses that managed toolchain catalog for newly added
+  dependencies and overrides. It creates a top-level default catalog only
+  when no managed or default catalog can be reused.
+
+**Other rules.**
+
+- Each package that declares `vite-plus` also gets a direct `vite` dev
+  dependency (see [Vite and Overrides](#vite-and-overrides)).
+- Unrelated selector-shaped and object-valued overrides are preserved.
+
+### npm
+
+- Direct aliases are normalized before the matching override is added, so npm
+  does not fail with `EOVERRIDE`.
+- When a real Vite installation changes to the core alias, stale Vite install
+  and lockfile state is removed before reinstalling.
+- Opt-in browser-provider layouts get a top-level `vite` edge when nested
+  Vitest packages otherwise cannot resolve it.
+
+### Yarn
+
+- Vite+ does not support Plug'n'Play. Migration detects explicit and implicit
+  PnP and converts the project to `nodeLinker: node-modules`, preserving all
+  unrelated `.yarnrc.yml` settings. `--no-interactive` accepts the
+  conversion; a process-level `YARN_NODE_LINKER=pnp` must be fixed by the
+  caller.
+- Catalog references and user hoisting settings are preserved.
+- Migration avoids split Vitest copies under workspace hoisting isolation: it
+  applies a package-level fix where possible and warns when the isolation
+  cannot be changed safely.
+
+### Bun
+
+- Bun catalogs only resolve inside a workspace (a root `package.json` with a
+  non-empty `workspaces`). In a bun workspace, existing top-level or
+  workspace catalog locations and named catalog references are preserved. A
+  standalone (single-package) bun project keeps concrete specs and gets no
+  catalog field, because `bun install` cannot resolve `catalog:` outside a
+  workspace.
+- The core alias is mirrored as a direct `vite` dependency so Bun sees the
+  peer provider before applying overrides.
+
+## After the Migration
+
+- Each Vite config is inspected for Rolldown-incompatible patterns (such as
+  `manualChunks`). Anything found is reported as a warning; the config is not
+  changed.
+- Dependencies are reinstalled once to refresh the lockfile. If installation
+  fails, migration reports the error and exits with a nonzero status.
+- After a successful migration, `vp fmt` runs on the files changed during
+  migration, excluding paths that were already dirty in the Git worktree.
+  Oxfmt selects the supported formats; non-Git projects retain full-project
+  formatting. Formatting is skipped while the project still uses Prettier. A
+  formatter failure is reported as a warning so the migration result and the
+  manual formatting command remain available.

package/skills/void/docs/node_modules/void/node_modules/@void/md/node_modules/vite-plus/docs/guide/migrate.md

@@ -48,6 +48,10 @@ The `migrate` command is designed to move existing projects onto Vite+ quickly.
 - Updates scripts to the Vite+ command surface
 - Can set up commit hooks
 - Can write agent and editor configuration files
+- Formats the migrated project
+
+See [Migration Rules](./migrate-rules.md) for the exact dependency, source
+rewrite, and package-manager behavior.
 
 Most projects will require further manual adjustments after running `vp migrate`.
 
@@ -75,8 +79,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
-- Remove old `vite` and `vitest` dependencies only after 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 +100,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`:
@@ -156,6 +170,16 @@ export default defineConfig({
 
 After migrating, remove lint-staged from your dependencies and delete any lint-staged config files. See the [Commit hooks guide](/guide/commit-hooks) and [Staged config reference](/config/staged) for details.
 
+### Git hook tools
+
+The `vp migrate` command can set up Vite+ commit hooks for you, but it doesn't automatically migrate every type of Git hook tool. This automatic migration path is specifically designed to handle Husky v9+ and lint-staged-style setups. Projects using Husky versions older than 9.0.0 are skipped and should upgrade to Husky v9 before using the automatic migration path.
+
+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.
+
+You can find more details about the full Vite+ hook setup in the [Commit hooks guide](/guide/commit-hooks).
+
 ## Examples
 
 ```bash

package/skills/void/docs/node_modules/void/node_modules/@void/md/node_modules/vite-plus/docs/guide/monorepo.md

@@ -0,0 +1,176 @@
+# Monorepo
+
+Vite+ supports monorepos with `vite.config.ts` at the root. You can define the defaults for `lint`, `fmt`, etc. at the root, and use `overrides` to apply package-specific lint and format settings.
+
+Because `vite.config.ts` is just JavaScript, you can choose to put your entire config into this file or compose it using regular JavaScript imports. You can still have separate `vite.config.ts` files in each package for the Vite, Vitest, framework or runtime configuration.
+
+## Root Config With Overrides
+
+Use `lint.overrides` for Oxlint rules that only apply to some packages:
+
+```ts [vite.config.ts]
+import { defineConfig } from 'vite-plus';
+
+export default defineConfig({
+  lint: {
+    plugins: ['typescript'],
+    options: {
+      typeAware: true,
+      typeCheck: true,
+    },
+    rules: {
+      'no-console': ['error', { allow: ['warn', 'error'] }],
+    },
+    overrides: [
+      {
+        files: ['apps/web/**', 'packages/ui/**'],
+        plugins: ['typescript', 'react'],
+        rules: {
+          'react/self-closing-comp': 'error',
+        },
+      },
+      {
+        files: ['apps/api/**'],
+        env: {
+          node: true,
+        },
+        rules: {
+          'no-console': 'off',
+        },
+      },
+      {
+        files: ['**/*.test.ts', '**/*.spec.ts'],
+        plugins: ['typescript', 'vitest'],
+        rules: {
+          '@typescript-eslint/no-explicit-any': 'off',
+          'vitest/no-disabled-tests': 'error',
+        },
+      },
+    ],
+  },
+});
+```
+
+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.
+:::
+
+## Format Overrides
+
+Use `fmt.overrides` for file or package-specific Oxfmt options. Formatter overrides put their settings under `options`:
+
+```ts [vite.config.ts]
+import { defineConfig } from 'vite-plus';
+
+export default defineConfig({
+  fmt: {
+    singleQuote: true,
+    semi: true,
+    overrides: [
+      {
+        files: ['apps/api/**'],
+        options: {
+          printWidth: 120,
+        },
+      },
+      {
+        files: ['**/*.md'],
+        options: {
+          proseWrap: 'always',
+        },
+      },
+    ],
+  },
+});
+```
+
+## Composing Configuration Files
+
+You can split configuration across your repository and compose them using JavaScript imports. Export JavaScript objects from nearby files or packages, import them in the root config, and merge them into the matching override.
+
+```ts [tooling/lint/react.ts]
+import type { OxlintOverride } from 'vite-plus/lint';
+
+export const reactLint = {
+  plugins: ['typescript', 'react'],
+  rules: {
+    'react/self-closing-comp': 'error',
+  },
+} satisfies Omit<OxlintOverride, 'files'>;
+```
+
+```ts [tooling/lint/node.ts]
+import type { OxlintOverride } from 'vite-plus/lint';
+
+export const nodeLint = {
+  env: {
+    node: true,
+  },
+  rules: {
+    'no-console': 'off',
+  },
+} satisfies Omit<OxlintOverride, 'files'>;
+```
+
+```ts [vite.config.ts]
+import { defineConfig } from 'vite-plus';
+
+import { nodeLint } from './tooling/lint/node';
+import { reactLint } from './tooling/lint/react';
+
+export default defineConfig({
+  lint: {
+    plugins: ['typescript'],
+    options: {
+      typeAware: true,
+      typeCheck: true,
+    },
+    overrides: [
+      {
+        files: ['apps/web/**', 'packages/ui/**'],
+        ...reactLint,
+      },
+      {
+        files: ['apps/api/**'],
+        ...nodeLint,
+      },
+    ],
+  },
+});
+```
+
+This keeps the behavior centralized while letting each team or package own the pieces of config it needs.
+
+## App Commands
+
+The root `vite.config.ts` is most valuable for shared linting, formatting, staged checks, and task definitions. For project-specific development, build, and test behavior, use the setup that best matches each app:
+
+- Pass a folder to built-in Vite commands when you want to target one app:
+
+```bash
+vp dev apps/web
+vp build apps/web
+```
+
+- Keep package-specific scripts in each package when the command differs per app:
+
+```json [apps/api/package.json]
+{
+  "scripts": {
+    "dev": "tsx watch src/index.ts",
+    "build": "tsc -p tsconfig.json"
+  }
+}
+```
+
+- Run scripts across the workspace with `vp run`:
+
+```bash
+vp run -r build
+vp run -r --parallel dev
+vp run --filter ./apps/web build
+```
+
+See the [Run guide](/guide/run) for recursive, parallel, filtered, and cached workspace tasks.

package/skills/void/docs/node_modules/void/node_modules/@void/md/node_modules/vite-plus/docs/guide/pack.md

@@ -58,4 +58,12 @@ export default defineConfig({
 });
 ```
 
+Executable support is bundled into Vite+, so you do not need to install `@tsdown/exe` separately.
+
+Building executables uses Node's [Single Executable Applications](https://nodejs.org/api/single-executable-applications.html) support and requires Node.js 25.7.0 or later. Switch the active runtime with `vp env use 26` if `vp pack --exe` reports an unsupported version.
+
 See the official [tsdown executable docs](https://tsdown.dev/options/exe#executable) for details about configuring custom file names, embedded assets, and cross-platform targets.
+
+## CSS Bundling
+
+`vp pack` can transform and bundle CSS (including CSS Modules and [Lightning CSS](https://lightningcss.dev/) optimizations) for your entry points. This support is bundled into Vite+, so you do not need to install `@tsdown/css` or `lightningcss` separately, it works out of the box.

package/skills/void/docs/node_modules/void/node_modules/@void/md/node_modules/vite-plus/docs/guide/run.md

@@ -69,7 +69,7 @@ $ node compile-legacy-app.js ✗ cache miss: 'legacy/index.js' modified, executi
 
 ## Task Definitions
 
-Vite Task automatically tracks which files your command uses. You can define tasks directly in `vite.config.ts` to enable caching by default or control which files and environment variables affect cache behavior.
+Vite Task [automatically tracks](/guide/automatic-data-tracking) what each task needs for caching. You can define tasks directly in `vite.config.ts` to enable caching by default or control which files and environment variables affect cache behavior.
 
 ```ts [vite.config.ts]
 import { defineConfig } from 'vite-plus';
@@ -102,10 +102,40 @@ See [Run Config](/config/run) for the full `run` block reference.
 
 ## Task Dependencies
 
-Use [`dependsOn`](#depends-on) to run tasks in the right order. Running `vp run deploy` with the config above runs `build` and `test` first. Dependencies can also target other packages in the same project with the `package#task` notation:
+Use [`dependsOn`](/config/run#dependson) to run tasks in the right order. Running `vp run deploy` with the config above runs `build` and `test` first.
 
-```ts
-dependsOn: ['@my/core#build', '@my/utils#lint'];
+String task names in `dependsOn` reference tasks in the current or another package:
+
+```ts [vite.config.ts]
+dependsOn: [
+  'build', // same package
+  '@my/core#build', // another package
+];
+```
+
+Use the object form when you need to reference all tasks with a given name from the current package's dependencies:
+
+```ts [vite.config.ts]
+import { defineConfig } from 'vite-plus';
+
+export default defineConfig({
+  run: {
+    tasks: {
+      test: {
+        command: 'vp test',
+        dependsOn: [{ task: 'build', from: 'dependencies' }],
+      },
+    },
+  },
+});
+```
+
+In this example, `vp run test` checks the current package's `dependencies`. For each direct workspace dependency that defines `build`, Vite Task runs that dependency's `build` task before `test`.
+
+Use an array when you need more than one dependency field:
+
+```ts [vite.config.ts]
+dependsOn: [{ task: 'build', from: ['dependencies', 'devDependencies'] }];
 ```
 
 ## Running in a Workspace
@@ -171,6 +201,8 @@ vp run --filter "@my/*" --filter "!@my/utils" build
 
 Multiple `--filter` flags are combined as a union. Exclusion filters are applied after all inclusions.
 
+When a `--filter` matches no packages, Vite+ prints a warning and exits successfully. Pass `--fail-if-no-match` to abort the run when any filter matches nothing instead.
+
 ### Workspace Root (`-w`)
 
 Explicitly run the task in the workspace root package: