void 0.10.13 → 0.20.1

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

@@ -1,175 +0,0 @@
-# Docker
-
-Vite+ publishes an official Docker image with the `vp` CLI preinstalled:
-
-```bash
-ghcr.io/voidzero-dev/vite-plus
-```
-
-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.
-
-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
-
-Tags track the `vp` version:
-
-| Tag                                                      | Meaning        |
-| -------------------------------------------------------- | -------------- |
-| `ghcr.io/voidzero-dev/vite-plus:latest`                  | Latest release |
-| `ghcr.io/voidzero-dev/vite-plus:<major>`                 | Latest major   |
-| `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 a non-root user by default.
-
-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:
-
-```dockerfile [Dockerfile]
-# syntax=docker/dockerfile:1
-
-# --- build stage: the official Vite+ toolchain image ---
-FROM ghcr.io/voidzero-dev/vite-plus:latest AS build
-WORKDIR /app
-
-# Install dependencies first so this layer is cached across source changes.
-COPY --chown=vp:vp package.json pnpm-lock.yaml .node-version* ./
-RUN vp install --frozen-lockfile
-
-# Build. vp reads .node-version and provisions that exact Node.js automatically.
-COPY --chown=vp:vp . .
-RUN vp build
-
-# Export the exact resolved Node.js binary for the runtime stage.
-RUN cp "$(vp env which node | head -1)" /tmp/node
-
-# --- deps stage: production-only dependencies ---
-# A separate, fresh `--prod` install so devDependencies (including the vite-plus
-# toolchain) are excluded. Running `--prod` over the full install above would not
-# prune the already-installed devDependencies.
-FROM ghcr.io/voidzero-dev/vite-plus:latest AS deps
-WORKDIR /app
-COPY --chown=vp:vp package.json pnpm-lock.yaml .node-version* ./
-RUN vp install --frozen-lockfile --prod
-
-# --- runtime stage: small, glibc, no vp ---
-FROM debian:bookworm-slim AS runtime
-WORKDIR /app
-ENV NODE_ENV=production
-
-# The exact Node.js from .node-version (official, signature-verified build).
-COPY --from=build /tmp/node /usr/local/bin/node
-
-COPY --from=build /app/dist ./dist
-COPY --from=deps /app/node_modules ./node_modules
-COPY --from=build /app/package.json ./
-
-USER nobody
-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.
-
-::: 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.
-:::
-
-::: 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.
-:::
-
-## Production: static SPA / SSG
-
-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
-WORKDIR /app
-COPY --chown=vp:vp package.json pnpm-lock.yaml .node-version* ./
-RUN vp install --frozen-lockfile
-COPY --chown=vp:vp . .
-RUN vp build
-
-FROM nginx:alpine AS runtime
-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):
-
-```yaml [.gitlab-ci.yml]
-build:
-  image: ghcr.io/voidzero-dev/vite-plus:latest
-  script:
-    - vp install --frozen-lockfile
-    - vp check
-    - vp test
-    - vp build
-```
-
-On GitHub Actions, prefer [`setup-vp`](./ci) instead of the image.
-
-## Devcontainers
-
-Use the image as a ready-to-go development container with the toolchain
-preinstalled:
-
-```jsonc [.devcontainer/devcontainer.json]
-{
-  "image": "ghcr.io/voidzero-dev/vite-plus:latest",
-}
-```
-
-## Ad-hoc usage
-
-Run any `vp` command against a project without installing vp on your machine:
-
-```bash
-docker run --rm -it -v "$PWD:/app" -w /app ghcr.io/voidzero-dev/vite-plus vp build
-```
-
-## 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).
-- **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).

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

@@ -1,167 +0,0 @@
-# Environment
-
-`vp env` manages Node.js versions globally and per project.
-
-## Overview
-
-Managed mode is on by default, so `node`, `npm`, and related shims resolve through Vite+ and pick the right Node.js version for the current project.
-
-The project Node.js version is resolved from these sources, in priority order:
-
-1. `.node-version` file (current or parent directories)
-2. `devEngines.runtime` in `package.json` (the [devEngines standard](https://docs.npmjs.com/cli/v11/configuring-npm/package-json#devengines))
-3. `engines.node` in `package.json`
-4. The global default (`vp env default`), then the latest LTS
-
-`devEngines.runtime` ranks above `engines.node` because it declares the development-environment requirement, while `engines.node` is a consumer-facing support range. `vp env doctor` warns when declared sources conflict.
-
-When a project declares `packageManager` (or `devEngines.packageManager`) in `package.json`, matching package-manager shims also use that package-manager version. For example, `packageManager: "npm@10.9.4"` makes both `npm` and `npx` run through npm 10.9.4. Alias pairs follow the installed package-manager shims: `npm`/`npx`, `pnpm`/`pnpx`, `yarn`/`yarnpkg`, and `bun`/`bunx`. Vite+ does not translate mismatched commands, so a project pinned to `pnpm` still lets `npm` fall back to the npm that comes with the resolved Node.js runtime.
-
-By default, Vite+ stores its managed runtime and related files in `~/.vite-plus`. If needed, you can override that location with `VP_HOME`.
-
-If you want to keep that behavior, run:
-
-```bash
-vp env on
-```
-
-This enables managed mode, where the shims always use the Vite+-managed Node.js installation.
-
-If you do not want Vite+ to manage Node.js first, run:
-
-```bash
-vp env off
-```
-
-This switches to system-first mode, where the shims prefer your system Node.js and only fall back to the Vite+-managed runtime when needed.
-
-## Commands
-
-### Setup
-
-- `vp env setup` creates or updates shims in `VP_HOME/bin` (and writes the per-shell setup scripts under `~/.vite-plus/`)
-- `vp env on` enables managed mode so shims always use Vite+-managed Node.js
-- `vp env off` enables system-first mode so shims prefer system Node.js first
-- `vp env print` prints the shell snippet for the current session
-
-PowerShell needs to dot-source the generated setup script in the current shell before `vp env use` can affect only that shell session:
-
-```powershell
-. "$env:USERPROFILE\.vite-plus\env.ps1"
-```
-
-Add that line to the end of your PowerShell `$PROFILE` to apply it automatically in new shells. It does not require elevated privileges.
-
-Create the profile file if it does not already exist:
-
-```powershell
-if (-not (Test-Path $PROFILE)) { New-Item $PROFILE -Force }
-```
-
-Open the profile file for editing:
-
-```powershell
-Invoke-Item $PROFILE
-```
-
-In CI, `vp env use` can still run without shell initialization. It writes a temporary session file under `VP_HOME` so later shim calls in the same job can resolve the selected Node.js version.
-
-### Manage
-
-- `vp env default` sets or shows the global default Node.js version
-- `vp env pin` pins a Node.js version in the current directory: an existing `.node-version` keeps being updated; otherwise the pin is written to `package.json#devEngines.runtime`; `.node-version` is only created when the directory has no `package.json`. Use `--target node-version` or `--target dev-engines` to choose explicitly. An existing `engines.node` is never modified.
-- `vp env unpin` removes the pin from the same source `vp env pin` would write
-- `vp env use` sets a Node.js version for the current shell session
-- `vp env install` installs a Node.js version
-- `vp env uninstall` removes an installed Node.js version
-- `vp env exec` runs a command with a specific Node.js version
-- `vp node` runs a Node.js script — shorthand for `vp env exec node`
-
-### Inspect
-
-- `vp env current` shows the current resolved environment
-- `vp env doctor` runs environment diagnostics
-- `vp env which` shows which tool path will be used
-- `vp env list` shows locally installed Node.js versions
-- `vp env list-remote` shows available Node.js versions from the registry
-
-## Project Setup
-
-- Pin a project version with `vp env pin`
-- Use `vp install`, `vp dev`, and `vp build` normally
-- Let Vite+ pick the right runtime for the project
-
-## Examples
-
-```bash
-# Setup
-vp env setup                  # Create shims for node, npm, npx, corepack
-vp env on                     # Use Vite+ managed Node.js
-vp env print                  # Print shell snippet for this session
-
-# Manage
-vp env pin lts                # Pin the project to the latest LTS release
-vp env install                # Install the version from .node-version or package.json
-vp env default lts            # Set the global default version
-vp env use 20                 # Use Node.js 20 for the current shell session
-vp env use --unset            # Remove the session override
-
-# Inspect
-vp env current                # Show current resolved environment
-vp env current --json         # JSON output for automation
-vp env which node             # Show which node binary will be used
-vp env which npx              # Show pinned package-manager alias when packageManager matches
-vp env list-remote --lts      # List only LTS versions
-
-# Execute
-vp env exec --node lts npm i  # Execute npm with latest LTS
-vp env exec node -v           # Use shim mode with automatic version resolution
-vp node script.js             # Shorthand: run a Node.js script with the resolved version
-vp node -e "console.log(1+1)" # Shorthand: forward any node flag or argument
-```
-
-## Corepack
-
-Vite+ creates a `corepack` shim by default, so corepack works without a system Node.js installation:
-
-- On Node.js 24 and earlier, the shim runs the corepack bundled with the resolved Node.js version.
-- On Node.js 25 and later, where corepack is no longer bundled, Vite+ installs corepack as a managed global package on first use. Only the `corepack` binary is linked; run `vp install -g corepack` yourself if you also want the package's pnpm/yarn launchers exposed directly.
-- If you install corepack explicitly with `vp install -g corepack`, that installation is always preferred.
-
-`corepack enable` normally creates `pnpm`/`yarn` launchers next to the corepack binary, which under Vite+ would not be on `PATH`. The shim fixes this by defaulting `--install-directory` to `VP_HOME/bin`, so after `corepack enable` the launchers are available everywhere and still resolve the project's Node.js and package-manager versions:
-
-```bash
-corepack enable               # pnpm and yarn now resolve via corepack
-corepack disable              # Remove the pnpm/yarn launchers again
-```
-
-The launchers reference the corepack copy that created them. If that copy is later removed (for example by uninstalling the Node.js version it shipped with), rerun `corepack enable` to recreate them.
-
-Shims owned by Vite+ (`npm`, `npx`, and binaries installed with `vp install -g`) are protected: if corepack removes or replaces them, Vite+ restores them and prints a warning.
-
-## Custom Node.js Mirror
-
-By default, Vite+ downloads Node.js from `https://nodejs.org/dist`. If you're behind a corporate proxy or need to use an internal mirror (e.g., Artifactory), set the `VP_NODE_DIST_MIRROR` environment variable:
-
-```bash
-# Install a specific version from your custom mirror
-VP_NODE_DIST_MIRROR=https://my-mirror.example.com/nodejs/dist vp env install 22
-
-# Set the global default version using a custom mirror
-VP_NODE_DIST_MIRROR=https://my-mirror.example.com/nodejs/dist vp env default lts
-
-# Set it permanently in your shell profile (.bashrc, .zshrc, etc.)
-echo 'export VP_NODE_DIST_MIRROR=https://my-mirror.example.com/nodejs/dist' >> ~/.zshrc
-```
-
-## Node.js Signature Verification
-
-When installing Node.js from the official `nodejs.org` distribution, Vite+ downloads the PGP-signed `SHASUMS256.txt.asc` and verifies it against the bundled Node.js release keys before trusting any checksum. This protects against a tampered `SHASUMS256.txt` paired with a matching malicious archive. The SHA-256 checksum of the downloaded archive is always verified afterward.
-
-Custom mirrors (`VP_NODE_DIST_MIRROR`) that publish only the plain `SHASUMS256.txt` fall back to checksum-only verification. A mirror that does publish a `.asc` still has its signature verified, and an invalid signature is a hard error.
-
-If a future keyring or certificate issue blocks downloads, set `VP_NODE_SKIP_SIGNATURE_VERIFY` to temporarily bypass PGP verification. The SHA-256 checksum is still verified, and Vite+ prints a warning when the signature check is skipped:
-
-```bash
-VP_NODE_SKIP_SIGNATURE_VERIFY=1 vp env install 22
-```

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

@@ -1,41 +0,0 @@
-# Format
-
-`vp fmt` formats code with Oxfmt.
-
-## Overview
-
-`vp fmt` is built on [Oxfmt](https://oxc.rs/docs/guide/usage/formatter.html), the Oxc formatter. Oxfmt has full Prettier compatibility and is designed as a fast drop-in replacement for Prettier.
-
-Use `vp fmt` to format your project, and `vp check` to format, lint and type-check all at once.
-
-## Usage
-
-```bash
-vp fmt
-vp fmt --check
-vp fmt . --write
-```
-
-## Configuration
-
-Put formatting configuration directly in the `fmt` block in `vite.config.ts` so all your configuration stays in one place. We do not recommend using `.oxfmtrc.json` with Vite+.
-
-For editors, point the formatter config path at `./vite.config.ts` so format-on-save uses the same `fmt` block:
-
-```json [.vscode/settings.json]
-{
-  "oxc.fmt.configPath": "./vite.config.ts"
-}
-```
-
-For the upstream formatter behavior and configuration reference, see the [Oxfmt docs](https://oxc.rs/docs/guide/usage/formatter.html).
-
-```ts [vite.config.ts]
-import { defineConfig } from 'vite-plus';
-
-export default defineConfig({
-  fmt: {
-    singleQuote: true,
-  },
-});
-```

package/skills/void/docs/node_modules/void/node_modules/@void/md/node_modules/vite-plus/docs/guide/github-actions-cache.md

@@ -1,165 +0,0 @@
-# GitHub Actions Cache
-
-::: warning Experimental
-Reusing Vite Task's cache across GitHub Actions runs is experimental. Test and measure it in your project before relying on it in CI.
-:::
-
-Vite Task stores task results in `node_modules/.vite/task-cache` at the workspace root. Restore that directory in later GitHub Actions runs so Vite Task can reuse previous task results.
-
-GitHub Actions cache and Vite Task make separate decisions:
-
-1. `actions/cache` restores and saves the cache directory based on the key in your workflow.
-2. Vite Task uses the restored cache directory and replays only the tasks whose fingerprints still match.
-
-## Before You Start
-
-Use this workflow when all of these are true:
-
-- The command runs through [`vp run`](/guide/run).
-- An immediate second run reports a cache hit for the task.
-- The task has stable input and output tracking for CI.
-- The workflow installs dependencies before restoring `node_modules/.vite/task-cache`.
-
-If the immediate second run misses, fix the task's tracking config before adding GitHub Actions cache. Check [When To Add Manual Config](/guide/automatic-data-tracking#when-to-add-manual-config) for common causes of unstable caching and fixes.
-
-## Measure Before Caching Across Runs
-
-You may not need to restore Vite Task cache across GitHub Actions runs when:
-
-- The task is already fast enough. Restore and save steps add overhead, so short tasks can finish faster without this workflow.
-- Cache transfer takes longer than rerunning the task. Vite Task can still save time inside one workflow run when the same task runs more than once, but across runs the transfer time is part of the cost.
-
-Measure before you add a GitHub Actions cache for Vite Task. Compare workflow duration with and without the restore and save steps. Check both the GitHub cache step time and the `vp run` time.
-
-## 1. Define Cacheable CI Tasks
-
-Only commands run through `vp run` use Vite Task caching. A direct command such as `vp build` does not use the task cache. Define a task in `vite.config.ts` for each command you want to cache in CI:
-
-```ts [vite.config.ts]
-import { defineConfig } from 'vite-plus';
-
-export default defineConfig({
-  run: {
-    tasks: {
-      build: 'vp build',
-      lint: 'vp lint',
-    },
-  },
-});
-```
-
-This guide assumes each task already hits locally. If a task misses, fix its tracking config in `vite.config.ts` before adding the GitHub Actions cache steps. See [Automatic Data Tracking](/guide/automatic-data-tracking) and [`run.tasks`](/config/run#tasks).
-
-Run each task twice:
-
-```bash
-vp run build
-vp run build # should print "cache hit"
-vp run lint
-vp run lint # should print "cache hit"
-```
-
-## 2. Restore The Cache After Install
-
-Restore `node_modules/.vite/task-cache` after `vp install`, because package installation can recreate or modify `node_modules`.
-
-```yaml [.github/workflows/ci.yml]
-name: CI
-
-on:
-  pull_request:
-  push:
-    branches: [main]
-
-permissions:
-  contents: read
-
-jobs:
-  ci:
-    runs-on: ubuntu-latest
-    steps:
-      - uses: actions/checkout@v4
-
-      - uses: voidzero-dev/setup-vp@v1
-        with:
-          node-version: '24'
-          cache: true
-
-      - run: vp install
-
-      - name: Restore Vite Task cache
-        id: vite-task-cache
-        uses: actions/cache/restore@v6
-        with:
-          path: node_modules/.vite/task-cache
-          key: vite-task-${{ runner.os }}-${{ runner.arch }}-${{ github.run_id }}-${{ github.run_attempt }}
-          restore-keys: |
-            vite-task-${{ runner.os }}-${{ runner.arch }}-
-
-      - run: vp run lint
-      - run: vp run build
-
-      - name: Save Vite Task cache
-        if: success()
-        uses: actions/cache/save@v6
-        with:
-          path: node_modules/.vite/task-cache
-          key: ${{ steps.vite-task-cache.outputs.cache-primary-key }}
-```
-
-The primary key includes `github.run_id` and `github.run_attempt` so each successful run can save a new immutable cache entry. The restore prefix lets GitHub restore the newest cache for the same operating system and architecture.
-
-Leave task inputs, including source files and lockfiles, out of the GitHub Actions key. Vite Task fingerprints them. If they change the Actions key, GitHub can skip useful restores before Vite Task decides which tasks still hit.
-
-For monorepos, restore the task cache from the workspace root. Then run the same `vp run` commands you use locally, such as `vp run -t @my/app#build`. Vite Task can reuse results for the requested package and the packages it depends on.
-
-## 3. Verify In The Logs
-
-On the first run, the restore step should say that no cache was found, and the save step should create one. Pull requests from forks may be restore-only because GitHub can give the cache token read-only access. In that case, the save step warns and exits successfully without writing a cache entry.
-
-On a later run, look for both layers:
-
-```text
-Cache restored from key: vite-task-Linux-X64-...
-$ vp build ◉ cache hit, replaying
-vp run: cache hit, 1.10s saved.
-```
-
-If GitHub restores a cache but Vite Task prints a cache miss, the workflow restored the cache directory, but the task fingerprint changed.
-
-## Keep Task Tracking Stable
-
-If GitHub restores a cache but `vp run` prints a cache miss, fix the task fingerprint before changing the Actions cache key. See [Automatic Data Tracking](/guide/automatic-data-tracking) and [`run.tasks`](/config/run#tasks).
-
-## Choose A Cache Key
-
-Use a rolling primary key plus a restore prefix:
-
-```yaml [.github/workflows/ci.yml]
-key: vite-task-${{ runner.os }}-${{ runner.arch }}-${{ github.run_id }}-${{ github.run_attempt }}
-restore-keys: |
-  vite-task-${{ runner.os }}-${{ runner.arch }}-
-```
-
-The primary key is unique for each run because it contains `github.run_id` and `github.run_attempt`. GitHub then searches the restore prefix and restores the newest matching cache.
-
-Include:
-
-- `runner.os` and `runner.arch`, because outputs and native tools can be platform-specific.
-- A per-run value such as `github.run_id` and `github.run_attempt`, because GitHub cache entries are immutable.
-
-If a dependency file affects a task result, track it in the task fingerprint rather than the GitHub Actions key.
-
-## Manage Cache Eviction And Scope
-
-GitHub evicts caches based on its cache retention and repository storage rules. Cache scope is also branch-aware: workflow runs can restore caches from the current branch and the default branch, while pull request merge-ref caches have limited scope.
-
-Vite Task can clear the whole task cache, but it does not currently evict individual task entries by age or size. As new task entries and output archives are saved, `node_modules/.vite/task-cache` can keep growing.
-
-Manage size at the GitHub Actions cache layer:
-
-- Keep the cached `path` limited to the Vite Task cache directory.
-- Keep the restore prefix scoped to compatible runners, such as the same OS and architecture.
-- Delete stale GitHub Actions cache entries, save caches from fewer workflows, or adjust the repository cache limit if large caches cause frequent evictions.
-
-See [GitHub's cache reference](https://docs.github.com/en/actions/reference/workflows-and-actions/dependency-caching) for the current eviction and scope rules.

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

@@ -1,101 +0,0 @@
-# IDE Integration
-
-Vite+ supports VS Code and Zed through editor-specific settings that `vp create` and `vp migrate` can automatically write into your project.
-
-## VS Code
-
-For the best VS Code experience with Vite+, install the [Vite Plus Extension Pack](https://marketplace.visualstudio.com/items?itemName=VoidZero.vite-plus-extension-pack). It currently includes:
-
-- `Oxc` for formatting and linting via `vp check`
-- `Vitest` for test runs via `vp test`
-
-When you create or migrate a project, Vite+ prompts whether you want editor config written for VS Code. `vp create` additionally sets `npm.scriptRunner` to `vp` so the VS Code NPM Scripts panel runs scripts through the Vite+ task runner. For migrated or existing projects, you can add this setting manually (see below).
-
-You can also manually set up the VS Code config:
-
-```json [.vscode/extensions.json]
-{
-  "recommendations": ["VoidZero.vite-plus-extension-pack"]
-}
-```
-
-```json [.vscode/settings.json]
-{
-  "editor.defaultFormatter": "oxc.oxc-vscode",
-  "[javascript]": { "editor.defaultFormatter": "oxc.oxc-vscode" },
-  "[javascriptreact]": { "editor.defaultFormatter": "oxc.oxc-vscode" },
-  "[typescript]": { "editor.defaultFormatter": "oxc.oxc-vscode" },
-  "[typescriptreact]": { "editor.defaultFormatter": "oxc.oxc-vscode" },
-  "oxc.fmt.configPath": "./vite.config.ts",
-  "editor.formatOnSave": true,
-  "editor.formatOnSaveMode": "file",
-  "editor.codeActionsOnSave": {
-    "source.fixAll.oxc": "explicit"
-  }
-}
-```
-
-This gives the project a shared default formatter and enables Oxc-powered fix actions on save. The language-specific override blocks (`[javascript]`, `[typescript]`, etc.) are required because VS Code prioritizes user-level `[language]` settings over the workspace-level `editor.defaultFormatter` — without them, a global Prettier configuration would silently take over. Setting `oxc.fmt.configPath` to `./vite.config.ts` keeps editor format-on-save aligned with the `fmt` block in your Vite+ config. Vite+ uses `formatOnSaveMode: "file"` because Oxfmt does not support partial formatting.
-
-To let the VS Code NPM Scripts panel run scripts through `vp`, add the following to your `.vscode/settings.json`:
-
-```json [.vscode/settings.json]
-{
-  "npm.scriptRunner": "vp"
-}
-```
-
-This is included automatically by `vp create` but not by `vp migrate`, since existing projects may have team members who do not have `vp` installed locally.
-
-## Zed
-
-For the best Zed experience with Vite+, install the [oxc-zed](https://github.com/oxc-project/oxc-zed) extension from the Zed extensions marketplace. It provides formatting and linting via `vp check`.
-
-When you create or migrate a project, Vite+ prompts you to choose whether you want the editor config written for Zed.
-
-You can also manually set up the Zed config:
-
-```json [.zed/settings.json]
-{
-  "lsp": {
-    "oxlint": {
-      "initialization_options": {
-        "settings": {
-          "run": "onType",
-          "fixKind": "safe_fix",
-          "typeAware": true,
-          "unusedDisableDirectives": "deny"
-        }
-      }
-    },
-    "oxfmt": {
-      "initialization_options": {
-        "settings": {
-          "fmt.configPath": "./vite.config.ts",
-          "run": "onSave"
-        }
-      }
-    }
-  },
-  "languages": {
-    "JavaScript": {
-      "format_on_save": "on",
-      "prettier": { "allowed": false },
-      "formatter": [{ "language_server": { "name": "oxfmt" } }],
-      "code_action": "source.fixAll.oxc"
-    },
-    "TypeScript": {
-      "format_on_save": "on",
-      "prettier": { "allowed": false },
-      "formatter": [{ "language_server": { "name": "oxfmt" } }]
-    },
-    "Vue.js": {
-      "format_on_save": "on",
-      "prettier": { "allowed": false },
-      "formatter": [{ "language_server": { "name": "oxfmt" } }]
-    }
-  }
-}
-```
-
-Setting `oxfmt.fmt.configPath` to `./vite.config.ts` keeps editor format-on-save aligned with the `fmt` block in your Vite+ config. The full generated config covers additional languages (CSS, HTML, JSON, Markdown, etc.) — run `vp create` or `vp migrate` to get the complete file written automatically.

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

@@ -1,23 +0,0 @@
-# Removing Vite+
-
-Use `vp implode` to remove `vp` and all related Vite+ data from your machine.
-
-## Overview
-
-`vp implode` is the cleanup command for removing a Vite+ installation and its managed data. Use it if you no longer want Vite+ to manage your runtime, package manager, and related local tooling state.
-
-::: info
-If you decide Vite+ is not for you, please [share your feedback with us](https://discord.gg/cAnsqHh5PX).
-:::
-
-## Usage
-
-```bash
-vp implode
-```
-
-Skip the confirmation prompt with:
-
-```bash
-vp implode --yes
-```