docs: align migrate guide and bundling notes with actual rewrite/shim behavior

Earlier drafts of this branch claimed the migrator stopped rewriting `vitest`
runtime imports and that the browser-provider subpaths were no longer
re-exported. That landed in docs/guide/migrate.md, rfcs/migration-command.md,
and packages/cli/BUNDLING.md, but the implementation kept the forward rewrites
(`vitest` → `vite-plus/test`, `@vitest/browser*` → `vite-plus/test/browser*`)
and added the inlined-d.ts shim infrastructure that *does* re-export every
provider subpath under both `./test/<pkg>` and `./test/browser/providers/<short>`.

The only thing actually preserved is `declare module 'vitest'` / `declare
module '@vitest/browser*'` — those have to target the upstream module identity
to merge into the types `vite-plus/test*` re-exports.

This commit restores the migrate guide's "import { vi } from 'vite-plus/test'"
example, restores the full rewrite-rule list in the migration-command RFC,
fixes the bundling doc's "provider subpaths are not re-exported" claim, and
adds a short subsection explaining why the provider d.ts shims are inlined
instead of bare re-exports (the pnpm-edge type-identity split that would
otherwise break user `provider: playwright()` typechecks).

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

Author: Brooooooklyn

docs/guide/migrate.md

@@ -75,8 +75,8 @@ Migrate this project to Vite+. Vite+ replaces the current split tooling around r
 After the migration:
 
 - Confirm `vite` imports were rewritten to `vite-plus` where needed
-- Confirm `vitest/config` imports were rewritten to `vite-plus` (other `vitest` and `@vitest/browser*` imports are intentionally left as-is)
-- Remove the old `vite` dependency only after those rewrites are confirmed; keep `vitest` and any `@vitest/browser*` providers
+- 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,27 +96,25 @@ Summarize the migration at the end and report any manual follow-up still require
 
 ### Vitest
 
-`vp migrate` is the recommended path. It only rewrites `vitest/config` imports to `vite-plus`; all other Vitest imports are left untouched and resolve through the upstream `vitest` package as usual (`vite` is aliased to `@voidzero-dev/vite-plus-core` via overrides, so Vitest picks up the Vite+ core transparently).
-
-If you are migrating manually, update only the config entry point:
+Vitest is automatically migrated through `vp migrate`. `vite-plus` re-exports upstream `vitest@4.x` under `vite-plus/test*` (including the browser-provider subpaths), so a single `vite-plus` install is enough — you no longer need to install `vitest` or any `@vitest/browser*` provider directly. 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';
 
-Runtime imports stay as-is:
-
-```ts
-import { describe, expect, it, vi } from 'vitest';
-
-const { page } = await import('@vitest/browser/context');
+const { page } = await import('vite-plus/test/browser/context');
 ```
 
-Do not rewrite bare `vitest`, `vitest/*` subpaths, or `@vitest/browser*` — Vitest's mock hoister requires the literal string `'vitest'`, and the browser/provider subpaths are not re-exported by `vite-plus`.
+`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
 

packages/cli/BUNDLING.md

@@ -90,15 +90,22 @@ export type * from '@voidzero-dev/vite-plus-core/types/importMeta.d.ts';
 
 ### Step 4: Test Package Export Sync (`syncTestPackageExports`)
 
-Reads vitest's exports and creates shim files that re-export everything under `./test/*`:
+Reads vitest's exports plus the three `@vitest/browser-*` provider packages and creates shim files that re-export everything under `./test/*`:
 
 ```typescript
-// For each vitest export like "./browser-playwright"
-// Creates a shim file: dist/test/browser-playwright.js
-export * from 'vitest/browser-playwright';
+// For each vitest export like "./node"
+// Creates a shim file: dist/test/node.js
+export * from 'vitest/node';
+
+// For each @vitest/browser-* provider, two shim surfaces are projected:
+//   dist/test/browser-playwright.js          (matches old wrapper path)
+//   dist/test/browser/providers/playwright.js (alias path)
+export * from '@vitest/browser-playwright';
 ```
 
-**Input**: resolved `vitest/package.json` exports (resolved via `createRequire`)
+Provider `.d.ts` shims are NOT bare re-exports — see the [Provider Type Identity](#why-provider-dts-shims-are-inlined) note below.
+
+**Input**: resolved `vitest/package.json` exports plus each `@vitest/browser-*` package's exports (all resolved via `createRequire`)
 **Output**: `dist/test/*.js`, `dist/test/*.d.ts`, updated `package.json` exports
 
 ---
@@ -354,7 +361,23 @@ Every entry under vitest's own `exports` is shimmed under `./test/*` (wildcard e
 | `vitest/config`    | `vite-plus/test/config`    |
 | `vitest/reporters` | `vite-plus/test/reporters` |
 
-The full set is regenerated on every build from the upstream vitest `package.json`, so the exact list tracks vitest itself. Browser provider packages (`@vitest/browser-playwright`, `@vitest/browser-preview`, `@vitest/browser-webdriverio`) and `@vitest/browser/context` are **not** re-exported — consume those directly from their original specifiers.
+The full set is regenerated on every build from the upstream vitest `package.json`, so the exact list tracks vitest itself.
+
+In addition to vitest's own exports, the three `@vitest/browser-*` provider packages are projected under two parallel surfaces so existing user code keeps resolving after the deleted `@voidzero-dev/vite-plus-test` wrapper:
+
+| Provider Package              | CLI Package Exports                                                         |
+| ----------------------------- | --------------------------------------------------------------------------- |
+| `@vitest/browser-playwright`  | `vite-plus/test/browser-playwright`, `vite-plus/test/browser/providers/playwright`   |
+| `@vitest/browser-preview`     | `vite-plus/test/browser-preview`, `vite-plus/test/browser/providers/preview`         |
+| `@vitest/browser-webdriverio` | `vite-plus/test/browser-webdriverio`, `vite-plus/test/browser/providers/webdriverio` |
+
+Each provider's own subpaths (e.g. `./context`) are mirrored under both alias prefixes.
+
+#### Why provider d.ts shims are inlined
+
+Provider `.d.ts` shims are NOT plain `export * from '@vitest/browser-playwright'` re-exports — they inline the upstream `.d.ts` content with `vitest/node` / `vitest/browser` / `@vitest/browser*` bare specifiers rewritten to relative paths inside `dist/test/`. The two private shims `dist/test/_at-vitest-browser.d.ts` and `dist/test/_at-vitest-browser/context.d.ts` re-export `@vitest/browser`/`@vitest/browser/context` and are referenced from those rewrites.
+
+This avoids a pnpm-edge type-identity split: when the upstream `.d.ts` is loaded by reference (`export * from '@vitest/browser-playwright'`), TypeScript resolves its internal `import { BrowserProvider } from 'vitest/node'` through the provider package's own pnpm-edge, which can be a different vitest copy than the one a user's `vite.config.ts` sees through `vite-plus`. The mismatch produces two structurally identical but nominally distinct `BrowserProvider` types, so `provider: playwright()` fails the user's typecheck. Rewriting the specifiers routes every type import through vite-plus's own subpath shims, guaranteeing a single vitest identity across the user's whole config.
 
 ### Conditional Export Handling
 

rfcs/migration-command.md

@@ -274,8 +274,14 @@ Projects that already have a `pnpm` field in `package.json` (e.g., with `overrid
 - For pnpm with existing `pnpm` config in `package.json`, the existing location is respected
 - rewrite `import from 'vite'` to `import from 'vite-plus'`
 - rewrite `import from 'vite/{name}'` to `import from 'vite-plus/{name}'`, e.g.: `import from 'vite/module-runner'` to `import from 'vite-plus/module-runner'`
+- rewrite `import from 'vitest'` to `import from 'vite-plus/test'`
 - rewrite `import from 'vitest/config'` to `import from 'vite-plus'`
-- bare `vitest`, other `vitest/{name}` subpaths, and all `@vitest/browser*` imports are intentionally **not** rewritten — vite-plus consumes upstream `vitest@4.x` directly (via overrides on `vite`), Vitest's mock hoister requires the literal string `'vitest'`, and the browser/provider subpaths are not re-exported by vite-plus
+- rewrite `import from 'vitest/{name}'` to `import from 'vite-plus/test/{name}'`, e.g.: `import from 'vitest/node'` to `import from 'vite-plus/test/node'`
+- rewrite `import from '@vitest/browser'` to `import from 'vite-plus/test/browser'`
+- rewrite `import from '@vitest/browser/{name}'` to `import from 'vite-plus/test/browser/{name}'`, e.g.: `import from '@vitest/browser/context'` to `import from 'vite-plus/test/browser/context'`
+- rewrite `import from '@vitest/browser-playwright'` to `import from 'vite-plus/test/browser-playwright'`
+- rewrite `import from '@vitest/browser-playwright/{name}'` to `import from 'vite-plus/test/browser-playwright/{name}'`
+- `declare module 'vitest'`, `declare module 'vitest/{name}'`, and `declare module '@vitest/browser*'` 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
 
 **Note**: For Yarn, use `resolutions` instead of `overrides`.