void 0.10.13 → 0.20.1

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

@@ -1,60 +0,0 @@
-# Check
-
-`vp check` runs format, lint, and type checks together.
-
-## Overview
-
-`vp check` is the default command for fast static checks in Vite+. It brings together formatting through [Oxfmt](https://oxc.rs/docs/guide/usage/formatter.html), linting through [Oxlint](https://oxc.rs/docs/guide/usage/linter.html), and TypeScript type checks through [tsgolint](https://github.com/oxc-project/tsgolint). By merging all of these tasks into a single command, `vp check` is faster than running formatting, linting, and type checking as separate tools in separate commands.
-
-When `typeCheck` is enabled in the `lint.options` block in `vite.config.ts`, `vp check` also runs TypeScript type checks through the Oxlint type-aware path powered by the TypeScript Go toolchain and [tsgolint](https://github.com/oxc-project/tsgolint). `vp create` and `vp migrate` enable both `typeAware` and `typeCheck` by default.
-
-We recommend turning `typeCheck` on so `vp check` becomes the single command for static checks during development.
-
-## Usage
-
-```bash
-vp check
-vp check --fix             # Format and run autofixers.
-vp check --no-fmt          # Skip format; run lint (and type-check if enabled).
-vp check --no-lint         # Skip lint rules; keep type-check when enabled.
-vp check --no-fmt --no-lint # Type-check only (requires `typeCheck` enabled).
-```
-
-## Configuration
-
-`vp check` uses the same configuration you already define for linting and formatting:
-
-- [`lint`](/guide/lint#configuration) block in `vite.config.ts`
-- [`fmt`](/guide/fmt#configuration) block in `vite.config.ts`
-- TypeScript project structure and tsconfig files for type-aware linting
-
-Recommended base `lint` config:
-
-```ts [vite.config.ts]
-import { defineConfig } from 'vite-plus';
-
-export default defineConfig({
-  lint: {
-    options: {
-      typeAware: true,
-      typeCheck: true,
-    },
-  },
-});
-```
-
-### Disabling a step by default
-
-To make `vp check` skip formatting or linting without passing a flag every time, set the [`check`](/config/check) block in `vite.config.ts`. This is handy when a project wants the rest of the toolchain but not, say, formatting:
-
-```ts [vite.config.ts]
-import { defineConfig } from 'vite-plus';
-
-export default defineConfig({
-  check: {
-    fmt: false, // `vp check` lints (and type-checks) but does not format
-  },
-});
-```
-
-These options only affect `vp check`; standalone `vp fmt` and `vp lint` still run normally. A step is skipped if it is disabled in config or the matching `--no-fmt` / `--no-lint` flag is passed. Because the defaults apply to every `vp check` run, a pre-commit hook that calls `vp check` will skip the disabled step too. See [Check config](/config/check) for the full reference.

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

@@ -1,62 +0,0 @@
-# Continuous Integration
-
-You can use `voidzero-dev/setup-vp` to use Vite+ in CI environments.
-
-## Overview
-
-For GitHub Actions, the recommended setup is [`voidzero-dev/setup-vp`](https://github.com/voidzero-dev/setup-vp). It installs Vite+, sets up the required Node.js version and package manager, and can cache package installs automatically.
-
-That means you usually do not need separate `setup-node`, package-manager setup, and manual dependency-cache steps in your workflow.
-
-## GitHub Actions
-
-```yaml [.github/workflows/ci.yml]
-- uses: voidzero-dev/setup-vp@v1
-  with:
-    node-version: '24'
-    cache: true
-- run: vp install
-- run: vp check
-- run: vp test
-- run: vp build
-```
-
-With `cache: true`, `setup-vp` handles dependency caching for you automatically.
-
-::: tip
-`setup-vp` caches package-manager data. To reuse Vite Task results across CI runs, add a separate [GitHub Actions cache for Vite Task](/guide/github-actions-cache).
-:::
-
-## 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.
-
-#### Before:
-
-```yaml [.github/workflows/ci.yml]
-- uses: pnpm/action-setup@v6
-  with:
-    version: 11
-
-- uses: actions/setup-node@v6
-  with:
-    node-version: '24'
-    cache: pnpm
-
-- run: pnpm ci && pnpm dev:setup
-- run: pnpm check
-- run: pnpm test
-```
-
-#### After:
-
-```yaml [.github/workflows/ci.yml]
-- uses: voidzero-dev/setup-vp@v1
-  with:
-    node-version: '24'
-    cache: true
-
-- run: vp install && vp run dev:setup
-- run: vp check
-- run: vp test
-```

package/skills/void/docs/node_modules/void/node_modules/vite-plus/docs/guide/commit-hooks.md

@@ -1,60 +0,0 @@
-# Commit Hooks
-
-Use `vp config` to install commit hooks, and `vp staged` to run checks on staged files.
-
-## Overview
-
-Vite+ supports commit hooks and staged-file checks without additional tooling.
-
-Use:
-
-- `vp config` to set up project hooks and related integrations
-- `vp staged` to run checks against the files currently staged in Git
-
-If you use [`vp create`](/guide/create) or [`vp migrate`](/guide/migrate), Vite+ prompts you to set this up for your project automatically.
-
-## Commands
-
-### `vp config`
-
-`vp config` configures Vite+ for the current project. It installs Git hooks, sets up the hook directory, and can also handle related project integration such as agent setup. By default, hooks are written to `.vite-hooks`:
-
-```bash
-vp config
-vp config --hooks-dir .vite-hooks
-vp config --no-hooks
-vp config --no-agent
-```
-
-Use `--no-hooks` when you want `vp config` to leave existing Git hook setup 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.
-
-You can also set `VITE_GIT_HOOKS=0` to disable hook installation from lifecycle scripts such as
-`prepare` or `postinstall`.
-
-### `vp staged`
-
-`vp staged` runs staged-file checks using the `staged` config from `vite.config.ts`. If you set up Vite+ to handle your commit hooks, it will automatically run when you commit your local changes.
-
-```bash
-vp staged
-vp staged --verbose
-vp staged --fail-on-changes
-```
-
-## Configuration
-
-Define staged-file checks in the `staged` block in `vite.config.ts`:
-
-```ts [vite.config.ts]
-import { defineConfig } from 'vite-plus';
-
-export default defineConfig({
-  staged: {
-    '*.{js,ts,tsx,vue,svelte}': 'vp check --fix',
-  },
-});
-```
-
-This is the default Vite+ approach and should replace separate `lint-staged` configuration in most projects. 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.

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

@@ -1,341 +0,0 @@
-# Creating a Project
-
-`vp create` interactively scaffolds new Vite+ projects, monorepos, and apps inside existing workspaces.
-
-## Overview
-
-The `create` command is the fastest way to start with Vite+. It can be used in a few different ways:
-
-- Start a new Vite+ monorepo
-- Create a new standalone application or library
-- Add a new app or library inside an existing project
-
-This command can be used with built-in templates, community templates, or remote GitHub templates.
-
-## Usage
-
-```bash
-vp create
-vp create <template>
-vp create <template> -- <template-options>
-```
-
-## Built-in Templates
-
-Vite+ ships with these built-in templates:
-
-- `vite:monorepo` creates a new monorepo
-- `vite:application` creates a new application
-- `vite:library` creates a new library
-- `vite:generator` creates a new code generator (monorepo only, see [Code Generators](#code-generators))
-
-## Template Sources
-
-`vp create` is not limited to the built-in templates.
-
-- Use shorthand templates like `vite`, `@tanstack/start`, `svelte`, `next-app`, `nuxt`, `react-router`, and `vue`
-- Use full package names like `create-vite` or `create-next-app`
-- Use local monorepo templates declared in [`create.templates`](#code-generators) (for example an internal component or service generator)
-- Use remote templates such as `github:user/repo` or `https://github.com/user/template-repo`
-
-Run `vp create --list` to see the built-in templates and the common shorthand templates Vite+ recognizes.
-
-## Options
-
-- `--directory <dir>` writes the generated project into a specific target directory
-- `--agent <name>` creates agent instructions files during scaffolding
-- `--no-agent` skips agent instruction setup
-- `--editor <name>` writes editor config files
-- `--no-editor` skips editor config setup
-- `--git` initialize a git repository
-- `--no-git` skips git repository initialization
-- `--hooks` enables pre-commit hook setup
-- `--no-hooks` skips hook setup
-- `--package-manager <name>` uses a specified package manager (`pnpm`, `npm`, `yarn`, or `bun`)
-- `--approve-builds` approves and runs gated dependency build scripts without prompting
-- `--no-interactive` runs without prompts
-- `--verbose` shows detailed scaffolding output
-- `--list` prints the available built-in and popular templates
-
-### Dependency build scripts
-
-For security, pnpm, bun, and yarn (Berry) do not run a dependency's build scripts (`install` / `postinstall`, e.g. native builds like `better-sqlite3`) until you approve them. When a template adds such a dependency directly, `vp create` surfaces it after installing instead of leaving the project in a half-built state:
-
-- Interactive: you are asked which of those dependencies to approve and build (nothing is selected by default).
-- Non-interactive: a note lists them and points at `vp pm approve-builds`.
-- `--approve-builds`: approves and builds them automatically, so non-interactive runs (CI) can produce a ready-to-use project.
-
-Approval is recorded the way each package manager expects: pnpm's `allowBuilds`, bun's `trustedDependencies`, or yarn's `dependenciesMeta.<pkg>.built` (in the workspace root manifest). Transitive build scripts you did not choose (e.g. `esbuild` pulled in by Vite) are left at the package manager's defaults and are not surfaced. npm runs build scripts by default, so there is nothing to approve there.
-
-## Template Options
-
-Arguments after `--` are passed directly to the selected template.
-
-This matters when the template itself accepts flags. For example, you can forward Vite template selection like this:
-
-```bash
-vp create vite -- --template react-ts
-```
-
-## Examples
-
-```bash
-# Interactive mode
-vp create
-
-# Create a Vite+ monorepo, application, library, or generator
-vp create vite:monorepo
-vp create vite:application
-vp create vite:library
-vp create vite:generator
-
-# Use shorthand community templates
-vp create vite
-vp create @tanstack/start
-vp create svelte
-
-# Use full package names
-vp create create-vite
-vp create create-next-app
-
-# Use remote templates
-vp create github:user/repo
-vp create https://github.com/user/template-repo
-```
-
-## Code Generators
-
-Monorepos often need to scaffold their own building blocks: a UI component, a service, or an internal package that follows house conventions. Vite+ supports this through generator packages powered by [Bingo](https://www.create.bingo/) templates.
-
-### Scaffold a generator
-
-Inside a Vite+ monorepo, run:
-
-```bash
-vp create vite:generator
-```
-
-This requires a monorepo workspace. If you don't have one yet, create it first with `vp create vite:monorepo`.
-
-The scaffolded generator package contains:
-
-- `src/template.ts` defines the template using `createTemplate` from `bingo`: an options schema built with [Zod](https://zod.dev/) and a `produce()` function that returns the files to generate
-- `bin/index.ts` is the CLI entry, powered by Bingo's `runTemplateCLI`
-
-If the monorepo has a parent directory matching `generators` or `tools`, the new package is placed there by default.
-
-### Registration
-
-Local generators are declared in [`create.templates`](/config/create#create-templates) in the monorepo's `vite.config.ts`. This is the source of truth: only registered templates appear in the `vp create` picker.
-
-`vp create vite:generator` registers the generator for you, adding an entry to `create.templates` in the root `vite.config.ts`:
-
-```ts
-import { defineConfig } from 'vite-plus';
-
-export default defineConfig({
-  create: {
-    templates: [
-      { name: 'my-generator', description: 'Generate new components', template: 'my-generator' },
-    ],
-  },
-});
-```
-
-Re-running is idempotent (no duplicate entries), and an existing `create.defaultTemplate` is preserved. You can also add entries by hand, for example to register a template you didn't scaffold this way. The `template` value is the generator's workspace package name, or a relative `./path` to it.
-
-### Run a generator
-
-Inside the monorepo, run `vp create` and pick the generator from the template list, or pass its entry `name` directly:
-
-```bash
-# Interactive mode lists registered local templates alongside the built-ins
-vp create
-
-# Run a registered template by its name
-vp create component
-
-# Pass options to the generator after --
-vp create component -- --name @your-org/button
-```
-
-When the generator depends on `bingo`, Vite+ appends `--skip-requests` automatically so it skips Bingo's outbound network requests (such as GitHub API calls).
-
-After the generator runs, the created package goes through the regular monorepo integration: workspace registration, dependency installation, and formatting.
-
-### Customize a generator
-
-Edit `src/template.ts` to define the options and the files to produce:
-
-```ts
-import { createTemplate } from 'bingo';
-import { z } from 'zod';
-
-export default createTemplate({
-  options: {
-    name: z.string().describe('Package name'),
-  },
-  async produce({ options }) {
-    return {
-      files: {
-        'package.json': JSON.stringify({ name: options.name, version: '0.0.0' }, null, 2),
-        src: {
-          'index.ts': `export const name = '${options.name}';\n`,
-        },
-      },
-    };
-  },
-});
-```
-
-- `options` defines the generator's prompts and flags using Zod schemas
-- `produce()` returns the [files](https://www.create.bingo/build/concepts/creations#files) to create, plus optional [scripts](https://www.create.bingo/build/concepts/creations#scripts) to run after generation and [suggestions](https://www.create.bingo/build/concepts/creations#suggestions) to print for the user
-
-See the [Bingo documentation](https://www.create.bingo/) for the full template API.
-
-## Organization Templates
-
-An organization can publish a curated set of templates under a single npm scope by shipping an `@org/create` package whose `package.json` carries a `createConfig.templates` manifest. Once published, `vp create @org` opens an interactive picker over those templates.
-
-### Pick from an org
-
-```bash
-# Open an interactive picker over @your-org/create's manifest
-vp create @your-org
-
-# Run a specific manifest entry directly
-vp create @your-org:web
-
-# Pin to an exact version or a dist-tag
-vp create @your-org@1.2.3
-vp create @your-org:web@next
-
-# Set the org as the default for a repo (see create.defaultTemplate config)
-vp create
-```
-
-Behind the scenes, `vp create @org` maps to `@org/create` (the existing npm `create-*` convention). If that package has no `createConfig.templates` field, Vite+ falls back to running the package normally — so adopting the manifest is zero-risk for orgs that already publish `@org/create`.
-
-Private registries work automatically: Vite+ reads `.npmrc` files from the project root and `~/`, honoring `@your-org:registry=...` scope mappings and `//host/:_authToken=...` credentials.
-
-### Authoring `@org/create`
-
-There are two common layouts. Pick the one that matches the org's template count and release cadence.
-
-**Bundled (recommended for most orgs).** All templates live as subdirectories of `@org/create` itself. Manifest entries use relative `./path` values. One repo, one publish, one versioning story — the same pattern used by `create-vite` and `create-next-app`.
-
-```
-@your-org/create/
-├── package.json              # "createConfig": { "templates": [{ "template": "./templates/web" }, ...] }
-├── templates/
-│   ├── web/
-│   │   ├── package.json
-│   │   └── src/...
-│   └── library/...
-└── README.md
-```
-
-**Manifest-only.** When the org already publishes independent `@org/template-*` packages (or hosts them on GitHub), `@org/create` stays a thin index.
-
-```
-@your-org/create/
-├── package.json              # "createConfig": { "templates": [{ "template": "@your-org/template-web" }, ...] }
-└── README.md
-```
-
-The two layouts can be mixed — a manifest can point most entries at external packages and keep a few as bundled subdirectories.
-
-Optionally, provide a `bin` script so `npm create @org` (the legacy path) keeps working for non-Vite+ users. `vp create @org` reads the manifest directly and never runs the `bin`.
-
-### Manifest schema
-
-The manifest lives at `createConfig.templates` in `@org/create`'s `package.json`:
-
-```json
-{
-  "name": "@your-org/create",
-  "version": "1.0.0",
-  "createConfig": {
-    "templates": [
-      {
-        "name": "monorepo",
-        "description": "Monorepo",
-        "template": "@your-org/template-monorepo",
-        "monorepo": true
-      },
-      {
-        "name": "web",
-        "description": "Web app template (Vite + React)",
-        "template": "@your-org/template-web"
-      },
-      {
-        "name": "demo",
-        "description": "Bundled demo template",
-        "template": "./templates/demo"
-      }
-    ]
-  }
-}
-```
-
-Each entry supports:
-
-| Field         | Required | Notes                                                                                                                                                                                                                                      |
-| ------------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
-| `name`        | yes      | Kebab-case identifier. Used by `vp create @org:<name>` for direct selection. Must be unique within the array.                                                                                                                              |
-| `description` | yes      | One-line description shown in the picker.                                                                                                                                                                                                  |
-| `template`    | yes      | An npm specifier (`@org/template-foo`, optionally `@version`), a GitHub URL (`github:user/repo`), a `vite:*` builtin, a local workspace package name, or a relative path (`./templates/foo`) that resolves against the `@org/create` root. |
-| `monorepo`    | no       | If `true`, marks this entry as a monorepo-creating template. Hidden from the picker when `vp create` runs inside an existing monorepo, mirroring the built-in `vite:monorepo` filter.                                                      |
-
-An invalid manifest is a hard error, not a silent fall-through — a maintainer who shipped a manifest should hear about the offending field, e.g. `@your-org/create: createConfig.templates[2].template must be a non-empty string`.
-
-### Bundled subdirectory templates
-
-Relative `./...` paths resolve against the enclosing `@org/create` package root — **not** the user's cwd. The referenced directory is copied into the target project as-is (no template-engine processing); the only exception is that a small set of underscore-prefixed scaffold files (`_gitignore`, `_npmrc`, `_yarnrc.yml`) are renamed to their dotfile equivalents. Paths that escape the package root are rejected.
-
-### Make the org the default in a repo
-
-Commit this in `vite.config.ts` at the project root:
-
-```ts
-import { defineConfig } from 'vite-plus';
-
-export default defineConfig({
-  create: { defaultTemplate: '@your-org' },
-});
-```
-
-Now `vp create` (with no argument) drops straight into the `@your-org` picker. See [`create.defaultTemplate`](/config/create) for details.
-
-The picker always appends a trailing **Vite+ built-in templates** entry so `vite:monorepo` / `vite:application` / `vite:library` / `vite:generator` stay reachable from the picker — selecting it routes to the standard built-in flow. For scripts and CI, explicit specifiers (`vp create vite:library`) bypass the configured default.
-
-### Non-interactive inspection
-
-`vp create @org --no-interactive` prints the manifest as a table and exits 1:
-
-```
-A template name is required when running `vp create @your-org` in non-interactive mode.
-
-Available templates in @your-org/create:
-
-  NAME     DESCRIPTION                          TEMPLATE
-  web      Web app template (Vite + React)      @your-org/template-web
-  library  TypeScript library template          @your-org/template-library
-  demo     Bundled demo template                ./templates/demo
-
-Examples:
-  # Scaffold a specific template from the org
-  vp create @your-org:web --no-interactive
-
-  # Or use a Vite+ built-in template
-  vp create vite:application --no-interactive
-```
-
-### Publishing checklist
-
-1. Create `@org/create` (scoped npm package) if you don't already have one.
-2. Add a `createConfig.templates` array to `package.json`. (Bundle the templates under `./templates/...` or point at external packages.)
-3. (Optional) Provide a `bin` launcher for `npm create @org` compatibility.
-4. Publish.
-5. Verify: `vp create @org --no-interactive` prints the manifest table; `vp create @org` opens the picker.
-6. (Optional) Commit `create: { defaultTemplate: '@org' }` in your internal template repos.

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

@@ -1,24 +0,0 @@
-# Dev
-
-`vp dev` starts the Vite development server.
-
-## Overview
-
-`vp dev` runs the standard Vite development server through Vite+, so you keep the normal Vite dev experience while using the same CLI entry point as the rest of the toolchain. For more information about using and configuring the dev server, see the [Vite guide](https://vite.dev/guide/).
-
-## Usage
-
-```bash
-vp dev
-```
-
-## Configuration
-
-Use standard Vite config in `vite.config.ts`. For the full configuration reference, see the [Vite config docs](https://vite.dev/config/).
-
-Use it for:
-
-- [plugins](https://vite.dev/guide/using-plugins)
-- [aliases](https://vite.dev/config/shared-options#resolve-alias)
-- [`server`](https://vite.dev/config/server-options)
-- [environment modes](https://vite.dev/guide/env-and-mode)