void 0.10.5 → 0.10.6

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

@@ -42,3 +42,19 @@ export default defineConfig({
   },
 });
 ```
+
+### 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/@void/md/node_modules/vite-plus/docs/guide/ci.md

@@ -10,10 +10,10 @@ That means you usually do not need separate `setup-node`, package-manager setup,
 
 ## GitHub Actions
 
-```yaml
+```yaml [.github/workflows/ci.yml]
 - uses: voidzero-dev/setup-vp@v1
   with:
-    node-version: '22'
+    node-version: '24'
     cache: true
 - run: vp install
 - run: vp check
@@ -23,36 +23,34 @@ That means you usually do not need separate `setup-node`, package-manager setup,
 
 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
-- uses: actions/setup-node@v4
+```yaml [.github/workflows/ci.yml]
+- uses: pnpm/action-setup@v6
   with:
-    node-version: '24'
+    version: 11
 
-- uses: pnpm/action-setup@v4
+- uses: actions/setup-node@v6
   with:
-    version: 10
-
-- name: Get pnpm store path
-  run: pnpm store path
-
-- uses: actions/cache@v4
-  with:
-    path: ~/.pnpm-store
-    key: ${{ runner.os }}-pnpm-${{ hashFiles('pnpm-lock.yaml') }}
+    node-version: '24'
+    cache: pnpm
 
-- run: pnpm install && pnpm dev:setup
+- run: pnpm ci && pnpm dev:setup
+- run: pnpm check
 - run: pnpm test
 ```
 
 #### After:
 
-```yaml
+```yaml [.github/workflows/ci.yml]
 - uses: voidzero-dev/setup-vp@v1
   with:
     node-version: '24'

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

@@ -22,8 +22,17 @@ If you use [`vp create`](/guide/create) or [`vp migrate`](/guide/migrate), Vite+
 ```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.

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

@@ -27,7 +27,7 @@ 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 generator
+- `vite:generator` creates a new code generator (monorepo only, see [Code Generators](#code-generators))
 
 ## Template Sources
 
@@ -35,7 +35,7 @@ Vite+ ships with these 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 templates such as `./tools/create-ui-component` or `@acme/generator-*`
+- 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.
@@ -44,13 +44,29 @@ Run `vp create --list` to see the built-in templates and the common shorthand te
 
 - `--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.
@@ -86,3 +102,240 @@ vp create create-next-app
 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/@void/md/node_modules/vite-plus/docs/guide/docker.md

@@ -0,0 +1,175 @@
+# 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).