void 0.10.5 → 0.10.6

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

@@ -18,42 +18,18 @@ If you are migrating an existing project and it still depends on older Vite or V
 ## `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`
-- Check whether your `tsconfig.json` uses `compilerOptions.baseUrl`
+- Check whether your `tsconfig.json` still uses `compilerOptions.baseUrl`
 
-The Oxlint type checker path powered by `tsgolint` does not support `baseUrl`, so Vite+ skips `typeAware` and `typeCheck` when that setting is present.
+The Oxlint type checker path powered by `tsgolint` does not support `baseUrl`.
+`vp migrate` and `vp lint --init` try to run the `vp dlx @andrewbranch/ts5to6 --fixBaseUrl .`
+fix before enabling type-aware linting. If that fix fails or is declined, Vite+
+skips `typeAware` and `typeCheck`.
 
-
-## `vp lint` / `vp fmt` may fail to read `vite.config.ts`
-
-`vp lint`, `vp fmt`, and the Oxc VS Code extension all read the `lint` / `fmt` blocks from `vite.config.ts`. Today that support has important limitations.
-
-### What is currently supported
-
-- Static object export:
-  - `export default { ... }`
-  - `export default defineConfig({ ... })`
-
-### What can fail in current integrations
-
-- Functional or async config:
-  - `defineConfig((env) => ({ ... }))`
-  - `defineConfig(async (env) => ({ ... }))`
-- Config files that rely on Vite transform/bundling behavior to execute.
-
-In scenarios reported in issue #930, Oxc-side integrations that read `vite.config.ts` can behave closer to native ESM loading (similar to Vite `--configLoader native`) than Vite's bundled default loader. That means configs depending on bundling/transforms can fail to load for lint/fmt/editor paths. See: https://github.com/voidzero-dev/vite-plus/issues/930
-
-### Workarounds
-
-- Prefer a static `defineConfig({ ... })` export when you need `lint` / `fmt` in `vite.config.ts`.
-- Avoid Node-specific globals (`__dirname` in ESM), unresolved TS-only imports, or JSON imports without import attributes in config code used by lint/fmt.
-- If needed, keep `.oxlintrc.*` / `.oxfmtrc.*` as temporary fallback, [although we do not recommend doing this normally](/guide/lint##configuration), while this integration behavior is being improved.
-
-### VS Code multi-root workspace note
+## VS Code extension does not read `vite.config.ts`
 
 If VS Code has multiple folders open, the shared Oxc language server may pick a different workspace than expected. That can make it look like `vite.config.ts` support is missing.
 
 - Confirm the extension is using the intended workspace.
-- Confirm the workspace resolves to a recent Oxc/Oxlint/Oxfmt toolchain.
 
 ## `vp build` does not run my build script
 
@@ -79,7 +55,7 @@ If `vp staged` fails or your pre-commit hook does not run:
 
 A minimal staged config looks like this:
 
-```ts
+```ts [vite.config.ts]
 import { defineConfig } from 'vite-plus';
 
 export default defineConfig({
@@ -91,11 +67,11 @@ export default defineConfig({
 
 ## Slow config loading caused by heavy plugins
 
-When `vite.config.ts` imports heavy plugins at the top level, every `import` is evaluated eagerly, even for commands like `vp lint` or `vp fmt` that don't need those plugins. This can make config loading noticeably slow.
+When `vite.config.ts` imports plugins at the top level, they are evaluated for every command, including `vp lint`, `vp fmt`, editor integrations, and long-lived background processes. This can make config loading slow and may trigger plugin setup side effects, such as reading files, starting watchers, or connecting to services.
 
-Use `lazyPlugins` to wrap plugin loading. Plugins are only loaded for commands that need them (`dev`, `build`, `test`, `preview`), and skipped for everything else:
+Use `lazyPlugins` to skip the plugin factory when vite-plus loads your config only to read a metadata block (`lint`, `fmt`, `check`, `staged`, `pack`, `create`, the `run`/`cache` task lookup, and editor tooling). The plugins still load whenever Vite actually runs, `dev`, `build`, `test`, `preview`, and any build your own scripts spawn (a `vp run` task, `vp exec`):
 
-```ts
+```ts [vite.config.ts]
 import { defineConfig, lazyPlugins } from 'vite-plus';
 import myPlugin from 'vite-plugin-foo';
 
@@ -106,7 +82,7 @@ export default defineConfig({
 
 For heavy plugins that should be lazily imported, combine with dynamic `import()`:
 
-```ts
+```ts [vite.config.ts]
 import { defineConfig, lazyPlugins } from 'vite-plus';
 
 export default defineConfig({

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

@@ -14,36 +14,88 @@ You can upgrade both of them independently.
 ## Global `vp`
 
 ```bash
-vp upgrade
+vp upgrade                        # upgrade to the latest version
+vp upgrade --check                # check for updates without installing
+vp upgrade <version>              # install a specific version
+vp upgrade --registry <registry>  # use a custom npm registry
 ```
 
+### Rollback
+
+Vite+ keeps the **3 most recent** versions installed so you can revert quickly:
+
+```bash
+vp upgrade --rollback
+```
+
+Older versions are pruned automatically after each upgrade. The active version and the previous version are always kept, so a rollback target is never removed.
+
 ## Local `vite-plus`
 
-Update the project dependency with the package manager commands in Vite+:
+The recommended way to upgrade an existing Vite+ project is `vp migrate`:
 
 ```bash
-vp update vite-plus
+vp migrate
 ```
 
-You can also use `vp add vite-plus@latest` if you want to move the dependency explicitly to the latest version.
+On a project that is already on Vite+, migrate does a toolchain version upgrade only: it re-pins `vite-plus`, the `vite` -> `@voidzero-dev/vite-plus-core` alias, and the `vitest` pin to the versions the global `vp` now bundles, across every workspace package. It skips the first-time setup steps (git hooks, editor and agent files, lint migration), so a version bump does not re-touch things you already configured. Pass `--full` to also run that setup.
+
+### Updating the Vitest Pin
 
-### Updating Aliased Packages
+If you migrated with `vp migrate`, your project pins `vitest` to an exact version so the whole project shares a single Vitest copy with the bundled `vp test` runner. The pin lives in your package manager's override block:
 
-Vite+ sets up npm aliases for its core packages during installation:
+- **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`)
 
-- `vite` is aliased to `npm:@voidzero-dev/vite-plus-core@latest`
-- `vitest` is aliased to `npm:@voidzero-dev/vite-plus-test@latest`
+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.
 
-`vp update vite-plus` does not re-resolve these aliases in the lockfile. To fully upgrade, update them separately:
+After upgrading `vite-plus`, re-pin `vitest` to the version Vite+ now bundles. Check that version with:
 
 ```bash
-vp update @voidzero-dev/vite-plus-core @voidzero-dev/vite-plus-test
+vp --version
 ```
 
-Or update everything at once:
+Then set the `vitest` override to that exact version, or rerun `vp migrate` to update the pin for you.
+
+## Preview Builds
+
+Some Vite+ pull requests publish temporary packages for testing before an npm release. Treat these as nightly or bleeding-edge builds: they are useful when you want to verify a specific fix, test a fresh upstream dependency bump, or confirm a change before the next release. For day-to-day work, prefer the published `latest` release.
+
+Each commit on an eligible pull request is published to [pkg.pr.new](https://pkg.pr.new) and registered with the [registry bridge](https://registry-bridge.viteplus.dev/). The bridge serves these builds as ordinary npm versions of the form `0.0.0-commit.<sha>` and proxies every other package to the npm registry. That means you install a preview with normal version specs instead of mutable URLs, and the same versions resolve in CI.
+
+Both `vite-plus` and `@voidzero-dev/vite-plus-core` publish under the same `0.0.0-commit.<sha>` version. Each pull request carries a comment listing the exact version for its latest commit, along with ready-to-copy install steps.
+
+You can find preview builds in pull requests that automatically update upstream dependencies. For examples, search the merged pull requests for [upstream dependency updates](https://github.com/voidzero-dev/vite-plus/pulls?q=is%3Apr+is%3Amerged+upgrade+upstream+dependencies).
+
+Preview builds are addressed by pull request number or commit SHA. They are not a stable version range, and you should avoid leaving them in long-lived branches unless a maintainer asks you to.
+
+### Global `vp` Preview
+
+Install a preview build of the global CLI by passing `VP_PR_VERSION` to the installer. Pass a pull request number or a commit SHA:
+
+```bash
+curl -fsSL https://vite.plus | VP_PR_VERSION=<pr-or-sha> bash
+```
+
+On Windows:
+
+```powershell
+$env:VP_PR_VERSION = "<pr-or-sha>"
+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`.
+
+### Local `vite-plus` Preview
+
+After installing the preview global CLI above, run migrate in the project to move its local `vite-plus` onto the same build:
 
 ```bash
-vp update vite-plus @voidzero-dev/vite-plus-core @voidzero-dev/vite-plus-test
+vp migrate
 ```
 
-You can verify with `vp outdated` that no Vite+ packages remain outdated.
+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.
+
+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`.