void 0.10.5 → 0.10.7

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

@@ -18,42 +18,18 @@ If you are migrating an existing project and it still depends on older Vite or V
 ## `vp check` does not run type-aware lint rules or type checks
 
 - Confirm that `lint.options.typeAware` and `lint.options.typeCheck` are enabled in `vite.config.ts`
-- Check whether your `tsconfig.json` uses `compilerOptions.baseUrl`
+- Check whether your `tsconfig.json` still uses `compilerOptions.baseUrl`
 
-The Oxlint type checker path powered by `tsgolint` does not support `baseUrl`, so Vite+ skips `typeAware` and `typeCheck` when that setting is present.
+The Oxlint type checker path powered by `tsgolint` does not support `baseUrl`.
+`vp migrate` and `vp lint --init` try to run the `vp dlx @andrewbranch/ts5to6 --fixBaseUrl .`
+fix before enabling type-aware linting. If that fix fails or is declined, Vite+
+skips `typeAware` and `typeCheck`.
 
-
-## `vp lint` / `vp fmt` may fail to read `vite.config.ts`
-
-`vp lint`, `vp fmt`, and the Oxc VS Code extension all read the `lint` / `fmt` blocks from `vite.config.ts`. Today that support has important limitations.
-
-### What is currently supported
-
-- Static object export:
-  - `export default { ... }`
-  - `export default defineConfig({ ... })`
-
-### What can fail in current integrations
-
-- Functional or async config:
-  - `defineConfig((env) => ({ ... }))`
-  - `defineConfig(async (env) => ({ ... }))`
-- Config files that rely on Vite transform/bundling behavior to execute.
-
-In scenarios reported in issue #930, Oxc-side integrations that read `vite.config.ts` can behave closer to native ESM loading (similar to Vite `--configLoader native`) than Vite's bundled default loader. That means configs depending on bundling/transforms can fail to load for lint/fmt/editor paths. See: https://github.com/voidzero-dev/vite-plus/issues/930
-
-### Workarounds
-
-- Prefer a static `defineConfig({ ... })` export when you need `lint` / `fmt` in `vite.config.ts`.
-- Avoid Node-specific globals (`__dirname` in ESM), unresolved TS-only imports, or JSON imports without import attributes in config code used by lint/fmt.
-- If needed, keep `.oxlintrc.*` / `.oxfmtrc.*` as temporary fallback, [although we do not recommend doing this normally](/guide/lint##configuration), while this integration behavior is being improved.
-
-### VS Code multi-root workspace note
+## VS Code extension does not read `vite.config.ts`
 
 If VS Code has multiple folders open, the shared Oxc language server may pick a different workspace than expected. That can make it look like `vite.config.ts` support is missing.
 
 - Confirm the extension is using the intended workspace.
-- Confirm the workspace resolves to a recent Oxc/Oxlint/Oxfmt toolchain.
 
 ## `vp build` does not run my build script
 
@@ -79,7 +55,7 @@ If `vp staged` fails or your pre-commit hook does not run:
 
 A minimal staged config looks like this:
 
-```ts
+```ts [vite.config.ts]
 import { defineConfig } from 'vite-plus';
 
 export default defineConfig({
@@ -91,11 +67,11 @@ export default defineConfig({
 
 ## Slow config loading caused by heavy plugins
 
-When `vite.config.ts` imports heavy plugins at the top level, every `import` is evaluated eagerly, even for commands like `vp lint` or `vp fmt` that don't need those plugins. This can make config loading noticeably slow.
+When `vite.config.ts` imports plugins at the top level, they are evaluated for every command, including `vp lint`, `vp fmt`, editor integrations, and long-lived background processes. This can make config loading slow and may trigger plugin setup side effects, such as reading files, starting watchers, or connecting to services.
 
-Use `lazyPlugins` to wrap plugin loading. Plugins are only loaded for commands that need them (`dev`, `build`, `test`, `preview`), and skipped for everything else:
+Use `lazyPlugins` to skip the plugin factory when vite-plus loads your config only to read a metadata block (`lint`, `fmt`, `check`, `staged`, `pack`, `create`, the `run`/`cache` task lookup, and editor tooling). The plugins still load whenever Vite actually runs, `dev`, `build`, `test`, `preview`, and any build your own scripts spawn (a `vp run` task, `vp exec`):
 
-```ts
+```ts [vite.config.ts]
 import { defineConfig, lazyPlugins } from 'vite-plus';
 import myPlugin from 'vite-plugin-foo';
 
@@ -106,7 +82,7 @@ export default defineConfig({
 
 For heavy plugins that should be lazily imported, combine with dynamic `import()`:
 
-```ts
+```ts [vite.config.ts]
 import { defineConfig, lazyPlugins } from 'vite-plus';
 
 export default defineConfig({

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

@@ -14,36 +14,88 @@ You can upgrade both of them independently.
 ## Global `vp`
 
 ```bash
-vp upgrade
+vp upgrade                        # upgrade to the latest version
+vp upgrade --check                # check for updates without installing
+vp upgrade <version>              # install a specific version
+vp upgrade --registry <registry>  # use a custom npm registry
 ```
 
+### Rollback
+
+Vite+ keeps the **3 most recent** versions installed so you can revert quickly:
+
+```bash
+vp upgrade --rollback
+```
+
+Older versions are pruned automatically after each upgrade. The active version and the previous version are always kept, so a rollback target is never removed.
+
 ## Local `vite-plus`
 
-Update the project dependency with the package manager commands in Vite+:
+The recommended way to upgrade an existing Vite+ project is `vp migrate`:
 
 ```bash
-vp update vite-plus
+vp migrate
 ```
 
-You can also use `vp add vite-plus@latest` if you want to move the dependency explicitly to the latest version.
+On a project that is already on Vite+, migrate does a toolchain version upgrade only: it re-pins `vite-plus`, the `vite` -> `@voidzero-dev/vite-plus-core` alias, and the `vitest` pin to the versions the global `vp` now bundles, across every workspace package. It skips the first-time setup steps (git hooks, editor and agent files, lint migration), so a version bump does not re-touch things you already configured. Pass `--full` to also run that setup.
+
+### Updating the Vitest Pin
 
-### Updating Aliased Packages
+If you migrated with `vp migrate`, your project pins `vitest` to an exact version so the whole project shares a single Vitest copy with the bundled `vp test` runner. The pin lives in your package manager's override block:
 
-Vite+ sets up npm aliases for its core packages during installation:
+- **npm / Bun:** a `vitest` entry under `overrides` in `package.json`
+- **Yarn:** a `vitest` entry under `resolutions` in `package.json`
+- **pnpm:** a `vitest` entry under `overrides` in `pnpm-workspace.yaml` — unless your `package.json` already had a `pnpm` field, in which case it lives under `pnpm.overrides` in `package.json` instead (pnpm ignores `pnpm-workspace.yaml` overrides when `package.json` defines `pnpm.overrides`)
 
-- `vite` is aliased to `npm:@voidzero-dev/vite-plus-core@latest`
-- `vitest` is aliased to `npm:@voidzero-dev/vite-plus-test@latest`
+A Vite+ release can bump the bundled Vitest. Because that pin also applies to `vite-plus`'s own `vitest` dependency, an out-of-date pin keeps installing the previous runner even after you upgrade `vite-plus` — splitting Vitest's internals (mocks, `expect`, runner state) between the pinned copy and the one `vp test` loads.
 
-`vp update vite-plus` does not re-resolve these aliases in the lockfile. To fully upgrade, update them separately:
+After upgrading `vite-plus`, re-pin `vitest` to the version Vite+ now bundles. Check that version with:
 
 ```bash
-vp update @voidzero-dev/vite-plus-core @voidzero-dev/vite-plus-test
+vp --version
 ```
 
-Or update everything at once:
+Then set the `vitest` override to that exact version, or rerun `vp migrate` to update the pin for you.
+
+## Preview Builds
+
+Some Vite+ pull requests publish temporary packages for testing before an npm release. Treat these as nightly or bleeding-edge builds: they are useful when you want to verify a specific fix, test a fresh upstream dependency bump, or confirm a change before the next release. For day-to-day work, prefer the published `latest` release.
+
+Each commit on an eligible pull request is published to [pkg.pr.new](https://pkg.pr.new) and registered with the [registry bridge](https://registry-bridge.viteplus.dev/). The bridge serves these builds as ordinary npm versions of the form `0.0.0-commit.<sha>` and proxies every other package to the npm registry. That means you install a preview with normal version specs instead of mutable URLs, and the same versions resolve in CI.
+
+Both `vite-plus` and `@voidzero-dev/vite-plus-core` publish under the same `0.0.0-commit.<sha>` version. Each pull request carries a comment listing the exact version for its latest commit, along with ready-to-copy install steps.
+
+You can find preview builds in pull requests that automatically update upstream dependencies. For examples, search the merged pull requests for [upstream dependency updates](https://github.com/voidzero-dev/vite-plus/pulls?q=is%3Apr+is%3Amerged+upgrade+upstream+dependencies).
+
+Preview builds are addressed by pull request number or commit SHA. They are not a stable version range, and you should avoid leaving them in long-lived branches unless a maintainer asks you to.
+
+### Global `vp` Preview
+
+Install a preview build of the global CLI by passing `VP_PR_VERSION` to the installer. Pass a pull request number or a commit SHA:
+
+```bash
+curl -fsSL https://vite.plus | VP_PR_VERSION=<pr-or-sha> bash
+```
+
+On Windows:
+
+```powershell
+$env:VP_PR_VERSION = "<pr-or-sha>"
+irm https://vite.plus/ps1 | iex
+Remove-Item Env:\VP_PR_VERSION
+```
+
+The installer resolves the ref to its `0.0.0-commit.<sha>` build through the registry bridge and installs it like any other version. Run `vp --version` afterward to confirm which build and bundled tool versions are active. When you are done testing, return to the published release with `vp upgrade --force` or by running the installer again without `VP_PR_VERSION`.
+
+### Local `vite-plus` Preview
+
+After installing the preview global CLI above, run migrate in the project to move its local `vite-plus` onto the same build:
 
 ```bash
-vp update vite-plus @voidzero-dev/vite-plus-core @voidzero-dev/vite-plus-test
+vp migrate
 ```
 
-You can verify with `vp outdated` that no Vite+ packages remain outdated.
+Migrate points the project at the bridge registry (writing it to `.npmrc`, or `.yarnrc.yml` for Yarn Berry) and pins `vite-plus` and the `vite` -> `@voidzero-dev/vite-plus-core` alias to the matching `0.0.0-commit.<sha>` version. That registry line is what lets the same versions resolve in the project's own CI, so commit it if you want CI to test the preview too.
+
+After installing, check the bundled versions with `vp --version`. When testing is complete, restore the published release: set `vite-plus` back to `latest`, remove the bridge `registry` line from `.npmrc` (or `.yarnrc.yml`), and reinstall with `vp install`.

package/skills/void/docs/reference/cli.md

@@ -579,7 +579,11 @@ void github link
 
 Link your current Void account to a GitHub identity. Opens your browser to authorize Void on GitHub (a localhost + PKCE handshake, the same mechanics as `void auth login`), then binds that GitHub identity to the logged-in account. Requires an authenticated CLI (`void auth login` first).
 
-You normally don't need to run this directly — `void github install` runs the link automatically when your account has no GitHub identity yet. Run it on its own to link ahead of time, or to link a GitHub identity without installing the App. If that GitHub account is already linked to a different Void account, the command fails and asks you to use a different GitHub account.
+You normally don't need to run this directly — `void github install` runs the link automatically when your account has no GitHub identity yet. Run it on its own to link ahead of time, or to link a GitHub identity without installing the App.
+
+::: warning Existing GitHub sign-in
+Void accounts cannot be merged. If the GitHub account you authorize is already linked to a different Void account, including one created through GitHub sign-in, `void github link` is refused with `This GitHub account is already linked to another Void account.` Run `void auth logout` and sign in to that existing account, or authorize a different GitHub account. The command is also refused if your current Void account is already linked to a different GitHub identity. Re-authorizing the GitHub account attached to your current Void account is allowed and reports `GitHub account already linked.`
+:::
 
 ### `void github install`
 

package/dist/agents-MhSzNMiC.mjs

@@ -1,151 +0,0 @@
-import { a as join } from "./pathe.M-eThtNZ-BrPhGF_K.mjs";
-import { existsSync, readFileSync } from "node:fs";
-import { fileURLToPath } from "node:url";
-//#region src/cli/agents.ts
-function getPackageDir() {
-	let dir = join(fileURLToPath(import.meta.url), "..");
-	for (let i = 0; i < 5; i++) {
-		if (existsSync(join(dir, "package.json"))) {
-			if (JSON.parse(readFileSync(join(dir, "package.json"), "utf-8")).name === "void") return dir;
-		}
-		dir = join(dir, "..");
-	}
-	throw new Error("Could not find void package root");
-}
-const agents = {
-	"claude-code": {
-		displayName: "Claude Code",
-		skillsDir: ".claude/skills",
-		detect: (root) => existsSync(join(root, ".claude")) || existsSync(join(root, "CLAUDE.md")),
-		mcpConfig: [{
-			filePath: ".claude/settings.json",
-			rootKey: "mcpServers"
-		}, {
-			filePath: ".claude/settings.local.json",
-			rootKey: "mcpServers"
-		}]
-	},
-	amp: {
-		displayName: "Amp",
-		skillsDir: ".agents/skills",
-		detect: (root) => existsSync(join(root, ".agents")),
-		mcpHint: "Run `npx void mcp` — this starts a stdio MCP server. See your agent's docs for how to add a local MCP server."
-	},
-	codex: {
-		displayName: "Codex",
-		skillsDir: ".agents/skills",
-		detect: (root) => existsSync(join(root, ".codex")),
-		mcpHint: "codex mcp add void -- npx void mcp"
-	},
-	cursor: {
-		displayName: "Cursor",
-		skillsDir: ".agents/skills",
-		detect: (root) => existsSync(join(root, ".cursor")),
-		mcpConfig: [{
-			filePath: ".cursor/mcp.json",
-			rootKey: "mcpServers"
-		}]
-	},
-	windsurf: {
-		displayName: "Windsurf",
-		skillsDir: ".windsurf/skills",
-		detect: (root) => existsSync(join(root, ".windsurf")),
-		mcpConfig: [{
-			filePath: ".windsurf/mcp.json",
-			rootKey: "mcpServers"
-		}]
-	},
-	"gemini-cli": {
-		displayName: "Gemini CLI",
-		skillsDir: ".agents/skills",
-		detect: (root) => existsSync(join(root, ".gemini")),
-		mcpHint: "gemini mcp add void -- npx void mcp"
-	},
-	"github-copilot": {
-		displayName: "GitHub Copilot",
-		skillsDir: ".agents/skills",
-		detect: (root) => existsSync(join(root, ".github", "copilot-instructions.md")) || existsSync(join(root, ".vscode", "mcp.json")),
-		mcpConfig: [{
-			filePath: ".vscode/mcp.json",
-			rootKey: "servers",
-			extraFields: { type: "stdio" }
-		}]
-	},
-	cline: {
-		displayName: "Cline",
-		skillsDir: ".cline/skills",
-		detect: (root) => existsSync(join(root, ".cline")),
-		mcpHint: "Run `npx void mcp` — this starts a stdio MCP server. See your agent's docs for how to add a local MCP server."
-	},
-	roo: {
-		displayName: "Roo Code",
-		skillsDir: ".roo/skills",
-		detect: (root) => existsSync(join(root, ".roo")),
-		mcpConfig: [{
-			filePath: ".roo/mcp.json",
-			rootKey: "mcpServers"
-		}]
-	},
-	kilo: {
-		displayName: "Kilo Code",
-		skillsDir: ".kilocode/skills",
-		detect: (root) => existsSync(join(root, ".kilocode")),
-		mcpHint: "Run `npx void mcp` — this starts a stdio MCP server. See your agent's docs for how to add a local MCP server."
-	},
-	continue: {
-		displayName: "Continue",
-		skillsDir: ".continue/skills",
-		detect: (root) => existsSync(join(root, ".continue")),
-		mcpHint: "Run `npx void mcp` — this starts a stdio MCP server. See your agent's docs for how to add a local MCP server."
-	},
-	goose: {
-		displayName: "Goose",
-		skillsDir: ".goose/skills",
-		detect: (root) => existsSync(join(root, ".goose")),
-		mcpHint: "Run `npx void mcp` — this starts a stdio MCP server. See your agent's docs for how to add a local MCP server."
-	},
-	opencode: {
-		displayName: "OpenCode",
-		skillsDir: ".agents/skills",
-		detect: (root) => existsSync(join(root, ".opencode")),
-		mcpHint: "Run `npx void mcp` — this starts a stdio MCP server. See your agent's docs for how to add a local MCP server."
-	},
-	trae: {
-		displayName: "Trae",
-		skillsDir: ".trae/skills",
-		detect: (root) => existsSync(join(root, ".trae")),
-		mcpHint: "Run `npx void mcp` — this starts a stdio MCP server. See your agent's docs for how to add a local MCP server."
-	},
-	junie: {
-		displayName: "Junie",
-		skillsDir: ".junie/skills",
-		detect: (root) => existsSync(join(root, ".junie")),
-		mcpHint: "Run `npx void mcp` — this starts a stdio MCP server. See your agent's docs for how to add a local MCP server."
-	},
-	"kiro-cli": {
-		displayName: "Kiro CLI",
-		skillsDir: ".kiro/skills",
-		detect: (root) => existsSync(join(root, ".kiro")),
-		mcpHint: "Run `npx void mcp` — this starts a stdio MCP server. See your agent's docs for how to add a local MCP server."
-	},
-	zencoder: {
-		displayName: "Zencoder",
-		skillsDir: ".zencoder/skills",
-		detect: (root) => existsSync(join(root, ".zencoder")),
-		mcpHint: "Run `npx void mcp` — this starts a stdio MCP server. See your agent's docs for how to add a local MCP server."
-	},
-	"qwen-code": {
-		displayName: "Qwen Code",
-		skillsDir: ".qwen/skills",
-		detect: (root) => existsSync(join(root, ".qwen")),
-		mcpHint: "Run `npx void mcp` — this starts a stdio MCP server. See your agent's docs for how to add a local MCP server."
-	}
-};
-function getAgentById(id) {
-	return agents[id];
-}
-function detectAgents(root) {
-	return Object.values(agents).filter((a) => a.detect(root));
-}
-//#endregion
-export { getAgentById as n, getPackageDir as r, detectAgents as t };

package/dist/collect-9rO3JFNM.mjs

@@ -1,55 +0,0 @@
-import { n as __exportAll } from "./chunk-DJd-R1mw.mjs";
-import { a as join, n as dirname } from "./pathe.M-eThtNZ-BrPhGF_K.mjs";
-import { existsSync, mkdirSync, readFileSync, readdirSync, writeFileSync } from "node:fs";
-//#region src/migrations/collect.ts
-var collect_exports = /* @__PURE__ */ __exportAll({
-	collectMigrations: () => collectMigrations,
-	readJournal: () => readJournal,
-	stripSqlExt: () => stripSqlExt,
-	writeJournal: () => writeJournal
-});
-/**
-* Collect all .sql migration files from the migrations directory,
-* sorted by filename (lexicographic order).
-*/
-function collectMigrations(migrationsDir) {
-	if (!existsSync(migrationsDir)) return [];
-	return readdirSync(migrationsDir).filter((f) => f.endsWith(".sql") && f !== "seed.sql").sort().map((name) => ({
-		name,
-		sql: readFileSync(join(migrationsDir, name), "utf-8")
-	}));
-}
-/**
-* Read `db/migrations/meta/_journal.json` if it exists. Drizzle maintains
-* this file whenever `drizzle-kit generate` runs; every `.sql` migration
-* under `db/migrations/` should correspond to an entry whose `tag` is the
-* filename without the `.sql` suffix.
-*/
-function readJournal(migrationsDir) {
-	const journalPath = join(migrationsDir, "meta", "_journal.json");
-	if (!existsSync(journalPath)) return;
-	try {
-		return JSON.parse(readFileSync(journalPath, "utf-8"));
-	} catch (err) {
-		throw new Error(`db: Failed to parse db/migrations/meta/_journal.json: '${err.message}'.`);
-	}
-}
-/**
-* Write `db/migrations/meta/_journal.json` with pretty-printed JSON and a
-* trailing newline, matching the format Drizzle itself emits. Creates the
-* `meta/` directory if it does not yet exist.
-*/
-function writeJournal(migrationsDir, journal) {
-	const journalPath = join(migrationsDir, "meta", "_journal.json");
-	mkdirSync(dirname(journalPath), { recursive: true });
-	writeFileSync(journalPath, JSON.stringify(journal, null, 2) + "\n");
-}
-/**
-* Drop the `.sql` extension from a migration filename, leaving any other
-* suffix untouched. Used to line filenames up with journal `tag` values.
-*/
-function stripSqlExt(name) {
-	return name.endsWith(".sql") ? name.slice(0, -4) : name;
-}
-//#endregion
-export { writeJournal as a, stripSqlExt as i, collect_exports as n, readJournal as r, collectMigrations as t };

package/dist/config-hhMYPVRT.mjs

@@ -1,21 +0,0 @@
-import { n as readProjectPaths } from "./project-paths-CCMrHYQm.mjs";
-import { existsSync, readFileSync } from "node:fs";
-import { pathToFileURL } from "node:url";
-//#region src/auth/config.ts
-function isVoidAuthConfigSource(code) {
-	return /\bfrom\s+["']void\/auth["']/.test(code);
-}
-function findVoidAuthConfig(root, paths = readProjectPaths(root)) {
-	for (const absPath of paths.authConfigCandidates) {
-		if (!existsSync(absPath)) continue;
-		if (isVoidAuthConfigSource(readFileSync(absPath, "utf-8"))) return absPath;
-	}
-	return null;
-}
-async function loadVoidAuthConfig(configPath) {
-	if (!configPath) return;
-	const mod = await import(pathToFileURL(configPath).href);
-	return mod.default ?? mod.auth ?? mod.config;
-}
-//#endregion
-export { loadVoidAuthConfig as n, findVoidAuthConfig as t };