vite-plus 0.3.2 → 1.0.0-rc.0

package/dist/version.js

@@ -1,8 +1,9 @@
 import { t as renderCliDoc } from "./help-BmKpeOP9.js";
 import { i as log, o as printHeader, t as accent } from "./terminal-MKGAuy-p.js";
-import { _ as version } from "./constants-IhOditRA.js";
-import { i as hasVitePlusDependency, n as detectPackageMetadata } from "./package-BB-Jh_z3.js";
+import { y as version } from "./constants-CiKwrA0v.js";
+import { i as hasVitePlusDependency, n as detectPackageMetadata } from "./package-B85H2Nw0.js";
 import path from "node:path";
+import { pathToFileURL } from "node:url";
 import fs from "node:fs";
 //#region src/version.ts
 /** Tool display names in the order shown by `vp --version`. */
@@ -45,7 +46,8 @@ function isVitePlusDeclaredInAncestors(cwd) {
 */
 async function resolveToolVersions(localPackagePath) {
 	try {
-		const mod = await import(`${localPackagePath}/dist/versions.js`);
+		const file = path.join(localPackagePath, "dist", "versions.js");
+		const mod = await import(pathToFileURL(file).href);
 		if (mod.versions && typeof mod.versions === "object") return mod.versions;
 	} catch {}
 	return {};

package/dist/versions.js

@@ -1,9 +1,9 @@
 export const versions = {
   "vite": "8.3.0",
-  "rolldown": "1.2.8",
-  "vitest": "4.1.11",
-  "oxfmt": "0.67.0",
-  "oxlint": "1.82.0",
-  "oxlint-tsgolint": "7.0.2001",
+  "rolldown": "1.2.9",
+  "vitest": "5.0.1",
+  "oxfmt": "0.70.0",
+  "oxlint": "1.85.0",
+  "oxlint-tsgolint": "7.0.2002",
   "tsdown": "0.23.0"
 };

package/dist/vitest-ecosystem-BU0AqZq-.js

@@ -0,0 +1,23 @@
+//#region src/utils/vitest-ecosystem.ts
+/** Official packages that share the bundled runner's release version. */
+const VITEST_EXACT_VERSION_PACKAGES = /* @__PURE__ */ new Set([
+	"@vitest/browser",
+	"@vitest/browser-playwright",
+	"@vitest/browser-preview",
+	"@vitest/coverage-v8",
+	"@vitest/coverage-istanbul",
+	"@vitest/mocker",
+	"@vitest/pretty-format",
+	"@vitest/snapshot",
+	"@vitest/spy",
+	"@vitest/ui",
+	"@vitest/utils",
+	"@vitest/web-worker"
+]);
+/** Optional peers fall back to the project; unrelated @vitest packages do not redirect. */
+const VITEST_RESOLVER_PACKAGES = /* @__PURE__ */ new Set(["vitest", ...VITEST_EXACT_VERSION_PACKAGES]);
+function isAlignableVitestEcosystemPackage(name) {
+	return VITEST_EXACT_VERSION_PACKAGES.has(name);
+}
+//#endregion
+export { isAlignableVitestEcosystemPackage as n, VITEST_RESOLVER_PACKAGES as t };

package/dist/vitest-v5-entry-points-DthU1e_O.js

@@ -0,0 +1,25 @@
+//#region src/vitest-v5-entry-points.json
+var vitest_v5_entry_points_default = {
+	"vitest/coverage": "vite-plus/test/node",
+	"vitest/reporters": "vite-plus/test/node",
+	"vitest/environments": "vite-plus/test/runtime",
+	"vitest/snapshot": "vite-plus/test/runtime",
+	"vitest/mocker": "vite-plus/test/mocker",
+	"vite-plus/test/coverage": "vite-plus/test/node",
+	"vite-plus/test/reporters": "vite-plus/test/node",
+	"vite-plus/test/environments": "vite-plus/test/runtime",
+	"vite-plus/test/snapshot": "vite-plus/test/runtime",
+	"vitest/browser-webdriverio": "@vitest/browser-webdriverio",
+	"vitest/browser-webdriverio/context": "vite-plus/test/browser/context",
+	"vitest/browser/providers/webdriverio": "@vitest/browser-webdriverio",
+	"vitest/browser/providers/webdriverio/context": "vite-plus/test/browser/context",
+	"vitest/plugins/browser-webdriverio": "@vitest/browser-webdriverio",
+	"vite-plus/test/browser-webdriverio": "@vitest/browser-webdriverio",
+	"vite-plus/test/browser-webdriverio/context": "vite-plus/test/browser/context",
+	"vite-plus/test/browser/providers/webdriverio": "@vitest/browser-webdriverio",
+	"vite-plus/test/browser/providers/webdriverio/context": "vite-plus/test/browser/context",
+	"vite-plus/test/plugins/browser-webdriverio": "@vitest/browser-webdriverio",
+	"@vitest/browser/providers/webdriverio": "@vitest/browser-webdriverio"
+};
+//#endregion
+export { vitest_v5_entry_points_default as t };

package/docs/config/fmt.md

@@ -1,6 +1,6 @@
 # Format Config
 
-`vp fmt` and `vp check` read Oxfmt settings from the `fmt` block in the root `vite.config.ts`. See [Oxfmt's configuration](https://oxc.rs/docs/guide/usage/formatter/config.html) for details.
+`vp fmt` and `vp check` use the workspace-root `fmt` block, including when run from a package directory. Package configs do not replace these format settings. Use `vp fmt -c <path>` or `vp fmt --config <path>` to select another config. If the root config has no `fmt` block, Oxfmt uses [native discovery](/guide/fmt#configuration). See [Oxfmt's configuration](https://oxc.rs/docs/guide/usage/formatter/config.html) for details.
 
 ## Example
 
@@ -19,4 +19,4 @@ export default defineConfig({
 
 For file- or package-specific formatting settings, use [`fmt.overrides`](/guide/monorepo#format-overrides) from the root `vite.config.ts`.
 
-Vite+ does not currently support nested format configuration. See [troubleshooting](/guide/troubleshooting#nested-lint-or-format-config-is-not-applied) for details and how to give feedback on future support.
+Oxfmt disables nested configs in Vite+ mode, so nested format configs do not override settings for individual files. See [troubleshooting](/guide/troubleshooting#nested-lint-or-format-config-is-not-applied) for details.

package/docs/config/lint.md

@@ -1,6 +1,6 @@
 # Lint Config
 
-`vp lint` and `vp check` read Oxlint settings from the `lint` block in the root `vite.config.ts`. See [Oxlint's configuration](https://oxc.rs/docs/guide/usage/linter/config.html) for details.
+`vp lint` and `vp check` use the workspace-root `lint` block, including when run from a package directory. Package configs do not replace these lint settings. Use `vp lint -c <path>` or `vp lint --config <path>` to select another config. If the root config has no `lint` block, Oxlint uses [native discovery](/guide/lint#configuration). See [Oxlint's configuration](https://oxc.rs/docs/guide/usage/linter/config.html) for details.
 
 ## Example
 
@@ -25,4 +25,4 @@ We recommend enabling both `options.typeAware` and `options.typeCheck` so `vp li
 
 For file- or package-specific lint rules, use [`lint.overrides`](/guide/monorepo#root-config-with-overrides) from the root `vite.config.ts`.
 
-Vite+ does not currently support nested lint configuration. See [troubleshooting](/guide/troubleshooting#nested-lint-or-format-config-is-not-applied) for details and how to give feedback on future support.
+Oxlint disables nested configs in Vite+ mode, so nested lint configs do not override settings for individual files. See [troubleshooting](/guide/troubleshooting#nested-lint-or-format-config-is-not-applied) for details.

package/docs/config/run.md

@@ -219,7 +219,7 @@ Vite Task passes a set of common environment variables to all tasks:
 
 - **System:** `HOME`, `USER`, `PATH`, `SHELL`, `LANG`, `TZ`
 - **Node.js:** `NODE_OPTIONS`, `COREPACK_HOME`, `PNPM_HOME`
-- **CI/CD:** `CI`, `VERCEL_*`, `NEXT_*`
+- **CI/CD:** `CI`, `VERCEL_*`, `NEXT_*`, `GITHUB_*`, `RUNNER_*`, `ACTIONS_ID_TOKEN_REQUEST_URL`, `ACTIONS_ID_TOKEN_REQUEST_TOKEN`
 - **Terminal:** Color variables (`FORCE_COLOR`, `NO_COLOR`, `COLORTERM`, `TERM`, `TERM_PROGRAM`) aren't passed to tasks unless you list them under `env` (the value gets fingerprinted, so changing it invalidates the cache) or `untrackedEnv` (passed without fingerprinting). If `FORCE_COLOR` isn't in either list, the child gets `FORCE_COLOR=1` so cached logs stay colored. Colors get stripped on display when the terminal can't render them.
 
 ### `input`

package/docs/config/staged.md

@@ -1,7 +1,6 @@
 # Staged Config
 
-`vp staged` reads staged-file rules from the `staged` block in `vite.config.ts`. See the
-[Commit hooks guide](/guide/commit-hooks).
+`vp staged` reads staged-file rules from the `staged` block in `vite.config.ts`. See the [Commit hooks guide](/guide/commit-hooks).
 
 ## Example
 

package/docs/guide/check.md

@@ -29,6 +29,8 @@ vp check --no-fmt --no-lint # Type-check only (requires `typeCheck` enabled).
 - [`fmt`](/guide/fmt#configuration) block in `vite.config.ts`
 - TypeScript project structure and tsconfig files for type-aware linting
 
+When run from a workspace package, `vp check` uses the workspace-root `lint` and `fmt` blocks. Package configs cannot replace root format settings, lint rules, or type-check options. File paths and TypeScript projects are still resolved from the package working directory.
+
 Recommended base `lint` config:
 
 ```ts [vite.config.ts]

package/docs/guide/ci.md

@@ -10,37 +10,7 @@ You can use `voidzero-dev/setup-vp` to use Vite+ in CI environments.
 
 Set `<setup-vp-version>` in each example to an exact version from the [`setup-vp` releases page](https://github.com/voidzero-dev/setup-vp/releases). You can use a commit SHA instead. Do not use the `v1` tag. The `v1` tag no longer receives updates.
 
-Run `vp migrate` to replace exact `voidzero-dev/setup-vp@v1` references in
-GitHub Actions workflows and composite actions under `.github` with the latest
-exact release known to your Vite+ version. Existing exact versions and commit
-SHAs remain unchanged.
-
-### Automatic Version Updates
-
-Dependabot and Renovate can update exact versions in GitHub Actions workflows.
-
-To use [Dependabot version updates](https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuring-dependabot-version-updates), add a `github-actions` entry to `.github/dependabot.yml`:
-
-```yaml [.github/dependabot.yml]
-version: 2
-updates:
-  - package-ecosystem: github-actions
-    directory: /
-    schedule:
-      interval: weekly
-```
-
-Dependabot checks `uses:` entries in `.github/workflows` each week.
-
-[Renovate's GitHub Actions manager](https://docs.renovatebot.com/modules/manager/github-actions/) detects `uses:` entries by default. You do not need a package rule for `setup-vp`.
-
-When you use a commit SHA, add the exact release tag in a comment. Renovate uses the comment to find updates:
-
-```yaml
-- uses: voidzero-dev/setup-vp@<commit-sha> # <setup-vp-version>
-```
-
-These settings apply only to GitHub Actions workflows. For GitLab CI/CD and Azure Pipelines, update both version values together.
+Run `vp migrate` to replace exact `voidzero-dev/setup-vp@v1` references in GitHub Actions workflows and composite actions under `.github` with the latest exact release known to your Vite+ version. Existing exact versions and commit SHAs remain unchanged.
 
 ## GitHub Actions
 
@@ -125,6 +95,33 @@ The Azure Pipelines template supports Microsoft-hosted Linux, macOS, and Windows
 
 For advanced configuration and the complete parameter reference, see the [`setup-vp` Azure Pipelines documentation](https://github.com/voidzero-dev/setup-vp#azure-pipelines).
 
+## Automatic Version Updates
+
+Dependabot and Renovate can update exact versions in GitHub Actions workflows.
+
+To use [Dependabot version updates](https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuring-dependabot-version-updates), add a `github-actions` entry to `.github/dependabot.yml`:
+
+```yaml [.github/dependabot.yml]
+version: 2
+updates:
+  - package-ecosystem: github-actions
+    directory: /
+    schedule:
+      interval: weekly
+```
+
+Dependabot checks `uses:` entries in `.github/workflows` each week.
+
+[Renovate's GitHub Actions manager](https://docs.renovatebot.com/modules/manager/github-actions/) detects `uses:` entries by default. You do not need a package rule for `setup-vp`.
+
+When you use a commit SHA, add the exact release tag in a comment. Renovate uses the comment to find updates:
+
+```yaml
+- uses: voidzero-dev/setup-vp@<commit-sha> # <setup-vp-version>
+```
+
+These settings apply only to GitHub Actions workflows. For GitLab CI/CD and Azure Pipelines, update both version values together.
+
 ## Simplifying Existing Workflows
 
 If you are migrating an existing GitHub Actions workflow, you can often replace large blocks of Node, package-manager, and cache setup with a single `setup-vp` step.

package/docs/guide/commit-hooks.md

@@ -1,7 +1,6 @@
 # Commit Hooks
 
-Use `vp hooks` to manage the Git hook dispatcher, `vp config` for project setup
-(hooks + agent integration), and `vp staged` to run checks on staged files.
+Use `vp hooks` to manage the Git hook dispatcher, `vp config` for project setup (hooks + agent integration), and `vp staged` to run checks on staged files.
 
 ## Overview
 
@@ -64,10 +63,7 @@ Check the `Dispatcher` and `core.hooksPath` lines to see whether hooks are actua
 
 ### `vp config`
 
-`vp config` configures Vite+ for the current project. It installs the generated Git hook
-dispatcher (unless hooks were disabled with `vp hooks disable`) and can also handle related
-project integration such as agent setup. The hooks directory defaults to `.vite-hooks`, or the
-last directory used by `vp hooks` / `vp config` in this clone:
+`vp config` configures Vite+ for the current project. It installs the generated Git hook dispatcher (unless hooks were disabled with `vp hooks disable`) and can also handle related project integration such as agent setup. The hooks directory defaults to `.vite-hooks`, or the last directory used by `vp hooks` / `vp config` in this clone:
 
 ```bash
 vp config
@@ -76,24 +72,22 @@ vp config --no-hooks
 vp config --no-agent
 ```
 
-Use `--no-hooks` when you want `vp config` to leave the Git hook dispatcher unchanged. Use
-`--no-agent` when you want it to skip updates to existing coding agent instruction files. You can
-pass both flags when you want `vp config` to skip both setup steps. After `vp hooks disable`,
-`vp config` skips reinstalling the dispatcher and points you at `vp hooks enable` instead of
-prompting again.
+Use `--no-hooks` when you want `vp config` to leave the Git hook dispatcher unchanged. Use `--no-agent` when you want it to skip updates to existing coding agent instruction files. You can pass both flags when you want `vp config` to skip both setup steps. After `vp hooks disable`, `vp config` skips reinstalling the dispatcher and points you at `vp hooks enable` instead of prompting again.
 
-You can also set `VP_GIT_HOOKS=0` to disable hook installation from lifecycle scripts such as
-`prepare` or `postinstall`.
+You can also set `VP_GIT_HOOKS=0` to disable hook installation from lifecycle scripts such as `prepare` or `postinstall`.
 
-Project-owned hook scripts such as `.vite-hooks/pre-commit` should be committed to the repository.
-The generated dispatcher and shims under `.vite-hooks/_` are ignored and recreated by `vp config`
-or `vp hooks enable`. Neither command creates or modifies project hook scripts or staged-file
-configuration.
+Project-owned hook scripts such as `.vite-hooks/pre-commit` should be committed to the repository. The generated dispatcher and shims under `.vite-hooks/_` are ignored and recreated by `vp config` or `vp hooks enable`. Neither command creates or modifies project hook scripts or staged-file configuration.
 
 ### `vp staged`
 
-`vp staged` runs staged-file checks using the `staged` config from `vite.config.ts`. To run it
-before each commit, add it to the project-owned pre-commit hook:
+`vp staged` runs staged-file checks using the `staged` config from `vite.config.ts`. It bundles `lint-staged` 17 and requires:
+
+- Node.js `22.22.1` or later in the `22.x` line, or `24.11.0` or later
+- Git `2.32.0` or later
+
+Node.js `20.x` is no longer supported for staged checks. These requirements also apply when a pre-commit hook runs `vp staged`. Upgrade the project's Node.js runtime and the Git installation on developer machines and CI runners before using the command. See the [lint-staged 17 release notes](https://github.com/lint-staged/lint-staged/releases/tag/v17.0.0) for the upstream changes.
+
+To run it before each commit, add it to the project-owned pre-commit hook:
 
 ```bash
 vp staged
@@ -119,12 +113,7 @@ export default defineConfig({
 });
 ```
 
-This is the default Vite+ approach and should replace separate `lint-staged` configuration in most
-projects. When you opt into hooks during `vp create`, Vite+ scaffolds both this configuration and
-the corresponding pre-commit hook. During `vp migrate`, existing hook policy is preserved, and
-the default is introduced only when no existing hook policy is found. Because
-`vp staged` reads from `vite.config.ts`, your staged-file checks stay in the same place as your
-lint, format, test, build, and task-runner config.
+This is the default Vite+ approach and should replace separate `lint-staged` configuration in most projects. When you opt into hooks during `vp create`, Vite+ scaffolds both this configuration and the corresponding pre-commit hook. During `vp migrate`, existing hook policy is preserved, and the default is introduced only when no existing hook policy is found. Because `vp staged` reads from `vite.config.ts`, your staged-file checks stay in the same place as your lint, format, test, build, and task-runner config.
 
 ## Disabling Hooks in Specific Environments
 
@@ -157,8 +146,7 @@ Because the hook itself reads this file, it works even when the committing proce
 
 ## Removing commit hooks
 
-To stop using the Vite+ hook dispatcher in this clone (and keep `prepare` / `vp config` from
-reinstalling it):
+To stop using the Vite+ hook dispatcher in this clone (and keep `prepare` / `vp config` from reinstalling it):
 
 ```bash
 vp hooks disable
@@ -170,8 +158,7 @@ This:
 
 1. Unsets `core.hooksPath` when it points at the Vite+ dispatcher
 2. Removes the generated `<hooks-dir>/_` directory
-3. Records a **local** disable preference so lifecycle scripts skip reinstall until you run
-   `vp hooks enable` again
+3. Records a **local** disable preference so lifecycle scripts skip reinstall until you run `vp hooks enable` again
 
 To re-enable:
 
@@ -179,8 +166,7 @@ To re-enable:
 vp hooks enable
 ```
 
-If you no longer want hooks for the project at all (shared with teammates), also remove `vp config`
-from the `prepare` or `postinstall` script in `package.json`.
+If you no longer want hooks for the project at all (shared with teammates), also remove `vp config` from the `prepare` or `postinstall` script in `package.json`.
 
 ### Manual equivalent
 
@@ -195,6 +181,4 @@ git config --local vp.hooks.disabled true
 # git config --local vp.hooks.dir .vite-hooks
 ```
 
-Project-owned scripts such as `.vite-hooks/pre-commit` and the `staged` block in `vite.config.ts`
-can remain for later use, or you can remove them separately if the project no longer needs them.
-`vp hooks disable` does **not** delete those project-owned files.
+Project-owned scripts such as `.vite-hooks/pre-commit` and the `staged` block in `vite.config.ts` can remain for later use, or you can remove them separately if the project no longer needs them. `vp hooks disable` does **not** delete those project-owned files.

package/docs/guide/create.md

@@ -57,8 +57,7 @@ Run `vp create --list` to see the built-in templates and the common shorthand te
 - `--hooks` enables pre-commit hook setup (dispatcher + `.vite-hooks` + `staged` config)
 - `--no-hooks` skips hook setup
 
-After create, manage the dispatcher with `vp hooks status`, `vp hooks disable`, and `vp hooks enable`.
-See the [Commit hooks guide](/guide/commit-hooks).
+After create, manage the dispatcher with `vp hooks status`, `vp hooks disable`, and `vp hooks enable`. See the [Commit hooks guide](/guide/commit-hooks).
 
 ### Dependency build scripts
 

package/docs/guide/docker.md

@@ -6,16 +6,11 @@ Vite+ publishes an official Docker image with the `vp` CLI preinstalled:
 ghcr.io/voidzero-dev/vite-plus
 ```
 
-Use it for builds, CI, and devcontainers. It is not intended as a production
-runtime image.
+Use it for builds, CI, and devcontainers. It is not intended as a production runtime image.
 
-`vp` resolves the Node.js version from your project (`.node-version`,
-`devEngines.runtime`, or `engines.node`) and downloads that exact version during
-install/build. This means the image does not need Node-version-specific tags.
+`vp` resolves the Node.js version from your project (`.node-version`, `devEngines.runtime`, or `engines.node`) and downloads that exact version during install/build. This means the image does not need Node-version-specific tags.
 
-For production, use a multi-stage build: build the app with the Vite+ image, then
-copy only the resolved Node.js binary, build output, and production dependencies
-into a smaller runtime image.
+For production, use a multi-stage build: build the app with the Vite+ image, then copy only the resolved Node.js binary, build output, and production dependencies into a smaller runtime image.
 
 ## Image tags
 
@@ -28,19 +23,13 @@ Tags track the `vp` version:
 | `ghcr.io/voidzero-dev/vite-plus:<major>.<minor>`         | Latest minor   |
 | `ghcr.io/voidzero-dev/vite-plus:<major>.<minor>.<patch>` | Exact version  |
 
-The examples use `:latest` to track the newest release; pin an exact tag or a
-digest if you need reproducible builds. The image is published for `linux/amd64`
-and `linux/arm64` and runs as the non-root `vp` user by default. That user has
-passwordless `sudo`, so build/CI steps that need root (extra apt packages,
-`playwright install --with-deps`) work without changing the image user.
+The examples use `:latest` to track the newest release; pin an exact tag or a digest if you need reproducible builds. The image is published for `linux/amd64` and `linux/arm64` and runs as the non-root `vp` user by default. That user has passwordless `sudo`, so build/CI steps that need root (extra apt packages, `playwright install --with-deps`) work without changing the image user.
 
 Browse all published versions and digests on the [GitHub package page](https://github.com/voidzero-dev/vite-plus/pkgs/container/vite-plus).
 
 ## Production: SSR / Node.js server app
 
-For apps that run Node.js in production (SvelteKit, Nuxt, a custom Vite SSR
-server, and so on), build with the toolchain image and copy the resolved Node.js
-and the built app into a slim runtime stage:
+For apps that run Node.js in production (SvelteKit, Nuxt, a custom Vite SSR server, and so on), build with the toolchain image and copy the resolved Node.js and the built app into a slim runtime stage:
 
 ```dockerfile [Dockerfile]
 # syntax=docker/dockerfile:1
@@ -86,28 +75,19 @@ EXPOSE 3000
 CMD ["node", "dist/server.js"]
 ```
 
-The deployed image contains only Node.js plus your app and production
-dependencies, and matches `.node-version` exactly. It is much smaller than the
-default `node:*` image; see the distroless tip below for the smallest result.
+The deployed image contains only Node.js plus your app and production dependencies, and matches `.node-version` exactly. It is much smaller than the default `node:*` image; see the distroless tip below for the smallest result.
 
 ::: warning Prune production dependencies in a separate stage
-Install production dependencies in their own `deps` stage as shown. Running
-`vp install --prod` after a full `vp install` in the same stage does not remove
-the already-installed devDependencies, so the `vite-plus` toolchain would be
-copied into the runtime image. If your server bundle is fully self-contained (no
-un-bundled runtime dependencies), you can skip copying `node_modules` entirely.
+Install production dependencies in their own `deps` stage as shown. Running `vp install --prod` after a full `vp install` in the same stage does not remove the already-installed devDependencies, so the `vite-plus` toolchain would be copied into the runtime image. If your server bundle is fully self-contained (no un-bundled runtime dependencies), you can skip copying `node_modules` entirely.
 :::
 
 ::: tip Smaller still
-For a shell-less, minimal-CVE runtime, swap the runtime base for distroless
-(`gcr.io/distroless/cc`) and keep an `ENTRYPOINT` in vector form. It is glibc
-based, so the copied Node.js binary remains compatible.
+For a shell-less, minimal-CVE runtime, swap the runtime base for distroless (`gcr.io/distroless/cc`) and keep an `ENTRYPOINT` in vector form. It is glibc based, so the copied Node.js binary remains compatible.
 :::
 
 ## Production: static SPA / SSG
 
-A static site needs no Node.js at runtime; serve the build output with any static
-server:
+A static site needs no Node.js at runtime; serve the build output with any static server:
 
 ```dockerfile [Dockerfile]
 FROM ghcr.io/voidzero-dev/vite-plus:latest AS build
@@ -123,8 +103,7 @@ COPY --from=build /app/dist /usr/share/nginx/html
 
 ## Continuous integration
 
-Use the image directly in container-based CI (GitLab CI, Buildkite, CircleCI,
-Jenkins, and others):
+Use the image directly in container-based CI (GitLab CI, Buildkite, CircleCI, Jenkins, and others):
 
 ```yaml [.gitlab-ci.yml]
 build:
@@ -140,11 +119,7 @@ On GitHub Actions, prefer [`setup-vp`](./ci) instead of the image.
 
 ## Browser mode tests (Vitest / Playwright)
 
-Running as the non-root `vp` user is what you want for browsers: Chromium keeps
-its sandbox (running a browser as root disables it). Install the browser and its
-system libraries in the job. `playwright install --with-deps` needs root to
-`apt-get install` those libraries. The `vp` user has passwordless `sudo`, so
-Playwright uses it to install them without changing the image user:
+Running as the non-root `vp` user is what you want for browsers: Chromium keeps its sandbox (running a browser as root disables it). Install the browser and its system libraries in the job. `playwright install --with-deps` needs root to `apt-get install` those libraries. The `vp` user has passwordless `sudo`, so Playwright uses it to install them without changing the image user:
 
 ```yaml [.gitlab-ci.yml]
 test:
@@ -155,15 +130,9 @@ test:
     - vp test
 ```
 
-`vp exec` runs the project's own Playwright (from your lockfile), so it installs
-the browser revision your tests expect. Prefer it over `vpx playwright install`,
-which would download whatever Playwright is latest and can fetch a different
-browser revision.
+`vp exec` runs the project's own Playwright (from your lockfile), so it installs the browser revision your tests expect. Prefer it over `vpx playwright install`, which would download whatever Playwright is latest and can fetch a different browser revision.
 
-To bake the browser and its libraries into a derived image instead of installing
-them on every run, install the project dependencies first so the baked browser
-matches your lockfile, then install with the project's Playwright (root is
-available through `sudo`):
+To bake the browser and its libraries into a derived image instead of installing them on every run, install the project dependencies first so the baked browser matches your lockfile, then install with the project's Playwright (root is available through `sudo`):
 
 ```dockerfile [Dockerfile]
 FROM ghcr.io/voidzero-dev/vite-plus:latest
@@ -173,13 +142,11 @@ RUN vp install --frozen-lockfile
 RUN vp exec playwright install --with-deps chromium
 ```
 
-If Chromium crashes under load in CI, give the container more shared memory with
-`--ipc=host`; see the [Playwright Docker docs](https://playwright.dev/docs/docker).
+If Chromium crashes under load in CI, give the container more shared memory with `--ipc=host`; see the [Playwright Docker docs](https://playwright.dev/docs/docker).
 
 ## Devcontainers
 
-Use the image as a ready-to-go development container with the toolchain
-preinstalled:
+Use the image as a ready-to-go development container with the toolchain preinstalled:
 
 ```jsonc [.devcontainer/devcontainer.json]
 {
@@ -197,23 +164,8 @@ docker run --rm -it -v "$PWD:/app" -w /app ghcr.io/voidzero-dev/vite-plus vp bui
 
 ## Notes
 
-- **Node.js version**: provisioned from `.node-version`, `engines.node`, or
-  `devEngines.runtime` at build time, so there is no Node.js-specific image tag. The
-  dependency `COPY` uses a `.node-version*` glob so the file is optional: projects
-  that pin via `engines.node`/`devEngines.runtime` need no `.node-version`, and
-  those that use one have it available in every stage.
-- **Non-root user**: the image runs as the non-root `vp` user, so copy sources
-  with `COPY --chown=vp:vp ...` as shown. Without it, `COPY` writes root-owned
-  files that `vp install` cannot update (permission denied). The `vp` user has
-  passwordless `sudo` for the occasional root step (installing extra apt packages
-  or `playwright install --with-deps`), so you rarely need to switch the image
-  user. The production runtime stage is a separate, vp-free base image, so this
-  convenience does not reach your deployed image.
-- **Native addons**: the image includes a C/C++ build toolchain (`build-essential`,
-  `python3`), so native dependencies such as `better-sqlite3` compile during
-  `vp install`.
-- **glibc**: the image is glibc based so it uses the official, signature-verified
-  Node.js builds.
-- **Custom base image**: to add `vp` to your own base image instead, run the
-  installer: `curl -fsSL https://vite.plus | bash` (set `VP_VERSION` to pin a
-  version).
+- **Node.js version**: provisioned from `.node-version`, `engines.node`, or `devEngines.runtime` at build time, so there is no Node.js-specific image tag. The dependency `COPY` uses a `.node-version*` glob so the file is optional: projects that pin via `engines.node`/`devEngines.runtime` need no `.node-version`, and those that use one have it available in every stage.
+- **Non-root user**: the image runs as the non-root `vp` user, so copy sources with `COPY --chown=vp:vp ...` as shown. Without it, `COPY` writes root-owned files that `vp install` cannot update (permission denied). The `vp` user has passwordless `sudo` for the occasional root step (installing extra apt packages or `playwright install --with-deps`), so you rarely need to switch the image user. The production runtime stage is a separate, vp-free base image, so this convenience does not reach your deployed image.
+- **Native addons**: the image includes a C/C++ build toolchain (`build-essential`, `python3`), so native dependencies such as `better-sqlite3` compile during `vp install`.
+- **glibc**: the image is glibc based so it uses the official, signature-verified Node.js builds.
+- **Custom base image**: to add `vp` to your own base image instead, run the installer: `curl -fsSL https://vite.plus | bash` (set `VP_VERSION` to pin a version).