void 0.10.5 → 0.10.7

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

@@ -0,0 +1,165 @@
+# 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

@@ -71,7 +71,7 @@ You can also manually set up the Zed config:
     "oxfmt": {
       "initialization_options": {
         "settings": {
-          "configPath": "./vite.config.ts",
+          "fmt.configPath": "./vite.config.ts",
           "run": "onSave"
         }
       }
@@ -98,4 +98,4 @@ You can also manually set up the Zed config:
 }
 ```
 
-Setting `oxfmt.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.
+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/index.md

@@ -4,6 +4,10 @@ Vite+ is the unified toolchain and entry point for web development. It manages y
 
 Vite+ ships in two parts: `vp`, the global command-line tool, and `vite-plus`, the local package installed in each project. If you already have a Vite project, use [`vp migrate`](/guide/migrate) to migrate it to Vite+, or paste our [migration prompt](/guide/migrate#migration-prompt) into your coding agent.
 
+Building with an AI assistant? Copy a ready-made setup prompt:
+
+<CopyPrompt />
+
 ## Install `vp`
 
 ### macOS / Linux
@@ -100,10 +104,11 @@ Vite+ can handle the entire local frontend development cycle from starting a pro
 ### Execute
 
 - [`vp run`](/guide/run) runs tasks across workspaces with caching.
-- [`vp cache clean`](/guide/cache) clears task cache entries.
-- [`vpx`](/guide/vpx) downloads and runs binaries globally.
 - [`vp exec`](/guide/vpx) runs local project binaries.
+- [`vp node`](/guide/env) runs Node.js scripts with the resolved Vite+ environment.
 - [`vp dlx`](/guide/vpx) downloads and runs package binaries without adding them as dependencies.
+- [`vp cache clean`](/guide/cache) clears task cache entries.
+- [`vpx`](/guide/vpx) downloads and runs binaries globally.
 
 ### Build
 
@@ -113,7 +118,8 @@ Vite+ can handle the entire local frontend development cycle from starting a pro
 
 ### Manage Dependencies
 
-- [`vp add`](/guide/install), [`vp remove`](/guide/install), [`vp update`](/guide/install), [`vp dedupe`](/guide/install), [`vp outdated`](/guide/install), [`vp why`](/guide/install), and [`vp info`](/guide/install) wrap package-manager workflows.
+- [`vp add`](/guide/install), [`vp remove`](/guide/install), [`vp update`](/guide/install), [`vp dedupe`](/guide/install), [`vp outdated`](/guide/install), [`vp list`](/guide/install), [`vp why`](/guide/install), and [`vp info`](/guide/install) wrap package-manager workflows.
+- [`vp link`](/guide/install), [`vp unlink`](/guide/install), and [`vp rebuild`](/guide/install) cover local package links and native module rebuilds.
 - [`vp pm <command>`](/guide/install) calls other package manager commands directly.
 
 ### Maintain

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

@@ -9,16 +9,37 @@ Use Vite+ to manage dependencies across pnpm, npm, Yarn, and Bun. Instead of swi
 Vite+ detects the package manager from the workspace root in this order:
 
 1. `packageManager` in `package.json`
-2. `pnpm-workspace.yaml`
-3. `pnpm-lock.yaml`
-4. `yarn.lock` or `.yarnrc.yml`
-5. `package-lock.json`
-6. `bun.lock` or `bun.lockb`
-7. `.pnpmfile.cjs` or `pnpmfile.cjs`
-8. `bunfig.toml`
-9. `yarn.config.cjs`
+2. `devEngines.packageManager` in `package.json`
+3. `pnpm-workspace.yaml`
+4. `pnpm-lock.yaml`
+5. `yarn.lock` or `.yarnrc.yml`
+6. `package-lock.json`
+7. `bun.lock` or `bun.lockb`
+8. `.pnpmfile.cjs` or `pnpmfile.cjs`
+9. `bunfig.toml`
+10. `yarn.config.cjs`
+
+If none of those files are present, `vp` falls back to `pnpm` by default. Vite+ automatically downloads the matching package manager and uses it for the command you ran. When detection comes from lockfiles or config files, the resolved version is written to `devEngines.packageManager` so future runs are deterministic; projects that already declare `packageManager` or `devEngines.packageManager` are left as-is.
+
+The [`devEngines.packageManager`](https://docs.npmjs.com/cli/v11/configuring-npm/package-json#devengines) field accepts a single object or an array of objects, and its `version` may be a semver range:
+
+```json
+{
+  "devEngines": {
+    "packageManager": {
+      "name": "pnpm",
+      "version": "^11.0.0",
+      "onFail": "download"
+    }
+  }
+}
+```
+
+A range resolves to an already-downloaded satisfying version when possible, otherwise to the latest satisfying version from the npm registry. The range itself stays the source of truth; Vite+ never freezes it into an exact `packageManager` pin. When both `packageManager` and `devEngines.packageManager` are declared, the `packageManager` field drives selection and Vite+ warns when it does not satisfy the devEngines constraint (`vp env doctor` shows details).
 
-If none of those files are present, `vp` falls back to `pnpm` by default. Vite+ automatically downloads the matching package manager and uses it for the command you ran.
+Vite+ currently downloads the declared package manager (the `onFail: "download"` behavior); the other `onFail` values are accepted but not yet differentiated.
+
+The explicit `packageManager` field (or the `devEngines.packageManager` declaration) also affects matching package-manager shims. If a project has `packageManager: "npm@10.9.4"`, `npm` and `npx` use npm 10.9.4. Other generated alias pairs behave the same way: `pnpm`/`pnpx`, `yarn`/`yarnpkg`, and `bun`/`bunx`. Mismatched tools are not translated; `npm` in a `pnpm` project still resolves as npm.
 
 ## Usage
 
@@ -46,6 +67,15 @@ Use the `-g` flag for installing, updating or removing globally installed packag
 - `vp uninstall -g <pkg>` removes a global package
 - `vp update -g [pkg]` updates one global package or all of them
 - `vp list -g [pkg]` lists global packages
+- `vp outdated -g [pkg]` prints outdated packages
+
+::: warning
+These commands do **NOT** interact with the underlying package manager's global installation directory.
+
+Instead, Vite+ manages its own global packages under `~/.vite-plus/packages`, allowing them to remain available across different Node.js versions.
+
+As a result, commands such as `vp link` do not affect Vite+'s global packages and will not appear in `vp list -g`.
+:::
 
 ## Managing Dependencies
 
@@ -88,6 +118,7 @@ Use these commands when you want package-manager-managed tools available outside
 - `vp uninstall -g typescript`
 - `vp update -g`
 - `vp list -g`
+- `vp outdated -g`
 
 #### Add and Remove
 
@@ -121,15 +152,19 @@ Use these when you need to understand the current state of dependencies.
 Use `vp rebuild` when native modules need to be recompiled, for example after switching Node.js versions or when a C/C++ addon fails to load.
 
 - `vp rebuild` rebuilds all native modules
+- `vp rebuild <package...>` rebuilds the listed packages only
 - `vp rebuild -- <args>` passes extra arguments to the underlying package manager
 
 ```bash
 vp rebuild
+vp rebuild better-sqlite3 sharp
 vp rebuild -- --update-binary
 ```
 
 `vp rebuild` is a shorthand for `vp pm rebuild`.
 
+With pnpm v10+, bare `vp rebuild` only rebuilds packages whose build scripts are listed in `onlyBuiltDependencies` (or approved via `pnpm approve-builds`); name the package explicitly to force a rebuild that bypasses the approval gate.
+
 #### Advanced
 
 Use these when you need lower-level package-manager behavior.
@@ -142,6 +177,23 @@ Examples:
 
 ```bash
 vp pm config get registry
-vp pm cache clean --force
-vp pm exec tsc --version
+vp pm cache clean -- --force
+vp pm audit --json
 ```
+
+#### Staged publishing
+
+`vp pm stage` exposes [npm's staged publishing](https://docs.npmjs.com/staged-publishing) workflow: a build is uploaded to a staging area (no 2FA, CI-friendly), then a maintainer approves or rejects it from a trusted device (2FA). It adapts to the detected package manager.
+
+```bash
+vp pm stage publish              # upload the package to staging (no 2FA)
+vp pm stage list                 # list staged versions
+vp pm stage view <stage-id>      # inspect a staged version
+vp pm stage download <stage-id>  # download the staged tarball
+vp pm stage approve <stage-id>   # promote to the live registry (2FA)
+vp pm stage reject <stage-id>    # discard a staged version (2FA)
+```
+
+- pnpm (`pnpm stage`, requires pnpm ≥ 11.3) and npm (`npm stage`, requires npm ≥ 11.15 and Node ≥ 22.14) pass through directly.
+- yarn (Berry) uses its npm plugin (`yarn npm publish --staged`, `yarn npm stage …`); `view`/`download` fall back to npm.
+- yarn Classic and bun have no staged-publishing support and fall back to `npm stage`.