void 0.10.12 → 0.20.0

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

@@ -1,347 +0,0 @@
-# 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

@@ -1,197 +0,0 @@
-# Migrate to Vite+
-
-`vp migrate` helps move existing projects onto Vite+.
-
-## Overview
-
-This command is the starting point for consolidating separate Vite, Vitest, Oxlint, Oxfmt, ESLint, and Prettier 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.
-
-## Usage
-
-```bash
-vp migrate
-vp migrate <path>
-vp migrate --no-interactive
-```
-
-## Target Path
-
-The positional `PATH` argument is optional.
-
-- If omitted, `vp migrate` migrates the current directory
-- If provided, it migrates that target directory instead
-
-```bash
-vp migrate
-vp migrate my-app
-```
-
-## Options
-
-- `--agent <name>` writes agent instructions into the project
-- `--no-agent` skips agent instruction setup
-- `--editor <name>` writes editor config files into the project
-- `--no-editor` skips editor config setup
-- `--hooks` sets up pre-commit hooks
-- `--no-hooks` skips hook setup
-- `--no-interactive` runs the migration without prompts
-
-## Migration Flow
-
-The `migrate` command is designed to move existing projects onto Vite+ quickly. Here is what the command does:
-
-- Updates project dependencies
-- Rewrites imports where needed
-- Merges tool-specific config into `vite.config.ts`
-- 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`.
-
-## Recommended Workflow
-
-Before running the migration:
-
-- Upgrade to Vite 8+ and Vitest 4.1+ first
-- Make sure you understand any existing lint, format, or test setup that should be preserved
-
-After running the migration:
-
-- Run `vp install`
-- Run `vp check`
-- Run `vp test`
-- Run `vp build`
-
-## Migration Prompt
-
-If you want to hand this work to a coding agent (or the reader is a coding agent!), use this migration prompt:
-
-```md
-Migrate this project to Vite+. Vite+ replaces the current split tooling around runtime management, package management, dev/build/test commands, linting, formatting, and packaging. Run `vp help` to understand Vite+ capabilities and `vp help migrate` before making changes. Use `vp migrate --no-interactive` in the workspace root. Make sure the project is using Vite 8+ and Vitest 4.1+ before migrating.
-
-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
-- Move remaining tool-specific config into the appropriate blocks in `vite.config.ts`
-
-Command mapping to keep in mind:
-
-- `vp run <script>` is the equivalent of `pnpm run <script>`
-- `vp test` runs the built-in test command, while `vp run test` runs the `test` script from `package.json`
-- `vp install`, `vp add`, and `vp remove` delegate through the package manager declared by `packageManager`
-- `vp dev`, `vp build`, `vp preview`, `vp lint`, `vp fmt`, `vp check`, and `vp pack` replace the corresponding standalone tools
-- Prefer `vp check` for validation loops
-
-Finally, verify the migration by running: `vp install`, `vp check`, `vp test`, and `vp build`
-
-Summarize the migration at the end and report any manual follow-up still required.
-```
-
-## Tool-Specific Migrations
-
-### Vitest
-
-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`:
-
-```ts [tsdown.config.ts] {4-6}
-import { defineConfig } from 'tsdown';
-
-export default defineConfig({
-  entry: ['src/index.ts'],
-  dts: true,
-  format: ['esm', 'cjs'],
-});
-```
-
-```ts [vite.config.ts] {4-8}
-import { defineConfig } from 'vite-plus';
-
-export default defineConfig({
-  pack: {
-    entry: ['src/index.ts'],
-    dts: true,
-    format: ['esm', 'cjs'],
-  },
-});
-```
-
-After merging, delete `tsdown.config.ts`. See the [Pack guide](/guide/pack) for the full configuration reference.
-
-### lint-staged
-
-Vite+ replaces lint-staged with its own `staged` block in `vite.config.ts`. Only the `staged` config format is supported. Standalone `.lintstagedrc` in non-JSON format and `lint-staged.config.*` are not migrated automatically.
-
-Move your lint-staged rules into the `staged` block:
-
-```ts [vite.config.ts]
-import { defineConfig } from 'vite-plus';
-
-export default defineConfig({
-  staged: {
-    '*.{js,ts,tsx,vue,svelte}': 'vp check --fix',
-  },
-});
-```
-
-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
-# Migrate the current project
-vp migrate
-
-# Migrate a specific directory
-vp migrate my-app
-
-# Run without prompts
-vp migrate --no-interactive
-
-# Write agent and editor setup during migration
-vp migrate --agent claude --editor zed
-```