void 0.10.13 → 0.20.0

package/AGENTS_TEMPLATE.md

@@ -0,0 +1,6 @@
+## Void
+
+- This project uses [Void](https://void.cloud), a full-stack Vite framework for Cloudflare Workers with file-based API routing, server-rendered pages, and typed backend services.
+- Deploy to your Cloudflare account with `void deploy --platform cloudflare`, or connect to a Void platform with `void connect <url>` and deploy with `void deploy --platform void`. `void deploy` uses the saved destination.
+- Use Void's CLI and typed APIs for development and infrastructure. Void infers Cloudflare bindings from your imports; use Void commands to manage them.
+- Before working with Void, read the relevant Markdown docs in `node_modules/void/skills/void/docs/`. Start with `guide/quickstart.md` for setup and `reference/cli.md` for commands; consult the other guides and references for any Void feature.

package/{skills/void/docs/node_modules/void/node_modules/pglite-server/LICENSE.md → LICENSE}

@@ -1,6 +1,6 @@
 MIT License
 
-Copyright (c) 2024 Kamil Ogórek
+Copyright (c) 2026-present, Cloudflare, Inc.
 
 Permission is hereby granted, free of charge, to any person obtaining a copy
 of this software and associated documentation files (the "Software"), to deal

package/README.md

@@ -2,6 +2,13 @@
 
 Vite plugin and CLI for building and deploying apps on Void.
 
+You can also administer a team platform with the same CLI. Sign in with
+`void platform auth login`, then manage users, signup access, projects, and logs.
+Commands show a preview before applying changes and support `--json` for scripts.
+See [Platform Administration](../../docs/guide/platform-administration.md) for a
+walkthrough and the [CLI reference](../../docs/reference/cli.md#operator-commands)
+for every command.
+
 ## What It Covers
 
 - file-based API routes from `routes/`
@@ -9,9 +16,10 @@ Vite plugin and CLI for building and deploying apps on Void.
 - typed Drizzle access via `void/db`
 - `crons/` and `queues/`
 - URL redirects, rewrites, and fallbacks (`void.json` / `public/_redirects`, plus `c.rewrite()` from middleware)
-- binding inference for D1, KV, R2, AI, auth, and queues
+- binding inference for D1, KV, R2, AI, auth, queues, and typed Durable Objects
 - remote bindings for local development
-- deploy packaging for Void-hosted apps, static sites, and supported meta-frameworks
+- one target-aware deploy path for Void-hosted and direct Cloudflare apps
+- automatic Cloudflare provisioning, verified Worker Version activation, and operational commands
 
 ## Quick Start
 
@@ -23,7 +31,13 @@ npm install -D void
 
 If you run `void init` in an empty directory, the scaffold flow adds the matching Pages adapter and Vite+ by default.
 
-Then run `npx void init`. In an empty directory, the full interactive flow can scaffold a starter, configure local project files, log you in, and link or create your Void project so the next step is just `npx void deploy`. In an existing app, it configures Void in place by adding missing Vite scripts and creating or patching `vite.config.*` with `voidPlugin()`.
+Init offers to initialize Git and suggests an optional initial commit command. Use `--git` or `--no-git` to choose without the Git prompt. Existing repositories are preserved; Void does not commit automatically.
+
+To install a team platform, use `void platform install`. A domain is recommended; the visible workers.dev testing option is also available as `--workers-dev`. Add a domain later with `void platform domain set example.com`, preserving projects, deployments, and API connections. See the [platform setup guide](../../docs/guide/self-hosted-platform.md).
+
+Init always writes brief coding-agent instructions to `AGENTS.md`, pointing to `node_modules/void/skills/void/docs/`, and links skills for detected agents. Run `void init --agents` to add or refresh just this setup without choosing an agent.
+
+Then run `npx void init`. In an empty directory, the full interactive flow can scaffold a starter and configure local project files. It then asks where to deploy: Cloudflare (the default) creates or augments `wrangler.jsonc`, handles secure browser sign-in through Void's bundled tooling, and saves the selected account; Void asks for the API URL of an explicitly connected company platform (`void connect <url>` or `void platform install`). Back up `~/.void/platforms/` after installing a company platform because its owner-only recovery material contains runtime keys that Cloudflare cannot return. The next app step is just `npx void deploy`. Auth-enabled deploys preserve an existing `BETTER_AUTH_SECRET` or create a persistent encrypted secret when missing on either platform. Root `.env` is local-only; production server keys declared in `env.ts` use encrypted remote secret storage and are rejected as plaintext Worker vars. In an existing app, init configures Void in place by adding missing Vite scripts and creating or patching `vite.config.*` with `voidPlugin()`.
 
 ```ts
 // vite.config.ts
@@ -40,9 +54,12 @@ export default defineConfig({
 - `voidPlugin()` — Vite integration, routing, pages mode, codegen, migrations, packaging
 - `void prepare` — generate `.void` artifacts for CI, editors, and fresh clones
 - `void auth login` — platform auth
-- `void deploy` — build and deploy
+- `void connect [url]` — choose Cloudflare or a Void platform, sign in, and save the deployment destination
+- `void platform *` — list, select, inspect, install, recover, repair, upgrade, disable, and safely uninstall a company platform
+- `void deploy` — build and deploy to the saved Cloudflare or Void target
 - `void db *` — local DB and migration commands
-- `void project *` — link, status, logs, requests, rollback, delete
+- `void project *` — target-aware status, logs, rollback, and managed-project operations
+- `void secret *` / `void domain *` — target-aware Worker secrets and custom domains
 
 Runtime helpers include:
 
@@ -54,6 +71,7 @@ Runtime helpers include:
 - `void/db`
 - `void/kv`
 - `void/storage`
+- `void/durable`
 - `void/ai`
 - `void/isr`
 - `void/client`
@@ -65,22 +83,30 @@ Runtime helpers include:
 - supported meta-framework deploy targets:
   - TanStack Start
   - React Router
+  - vinext App Router and Pages Router
   - SvelteKit
   - Nuxt
+  - Analog
   - Astro
 - static and SPA deploys
 - non-Cloudflare server targets (`node`, `bun`, `deno`)
 
-There is Vinext-specific source in the repo, but it is intentionally on hold and not part of the current public support matrix.
+Direct Cloudflare deployments also support D1, KV, R2, Queues, Hyperdrive, auth, cron jobs, AI, ISR, typed SQLite Durable Objects, and WebSocket rooms. They upload an immutable Worker Version, probe it before activation (using a 0%-traffic version override when Durable Objects disable preview URLs), and retain version metadata for migration-aware rollback.
+
+Self-hosted platform upgrades verify every packaged PostgreSQL migration and require the live Drizzle history to be an exact prefix. Pending SQL is allowed only for an explicitly attested old-version/schema compatibility edge, runs in one transaction, and leaves the old Worker version authoritative until the target runtime passes discovery and health checks.
+
+An upgrade that changes the authenticated usage protocol briefly gates application traffic while it verifies the complete Worker set. An interruption leaves the gate closed for the next resumable upgrade instead of enabling an unsigned compatibility path.
 
 ## Database Model
 
 `void/db` is Drizzle-first.
 
-- D1 is the default managed database target
-- framework apps can opt into PostgreSQL mode
+- D1 is the default managed database target; development and local database commands share the configured binding ID and persistence directory
+- apps can opt into PostgreSQL or MySQL mode
 - route types, DB types, and queue types are generated into `.void/*.d.ts`
 
+Node.js, Bun, and Deno Pages builds include production hydration assets. Deploy `dist/ssr` together with `dist/client`; the server loads its manifest and assets relative to the emitted module.
+
 ## Documentation
 
 Full docs live at [void.cloud/guide](https://void.cloud/guide).

package/dist/{auth-qgMlYp7Z.d.mts → auth-DkcFflXV.d.mts}

@@ -1,7 +1,6 @@
 import { AsyncLocalStorage } from "node:async_hooks";
 import { BetterAuthOptions, Session, User } from "better-auth";
 import { Context, Env } from "hono";
-
 //#region src/runtime/auth.d.ts
 type AuthUser = User;
 type AuthSession = Session;
@@ -12,20 +11,20 @@ type AuthState = {
 type VoidAuthConfigContext = {
   defaults: BetterAuthOptions;
   env: Record<string, unknown>;
-  dialect: "sqlite" | "postgresql";
+  dialect: "sqlite" | "postgresql" | "mysql";
   request: Request;
 };
 type VoidAuthConfig = BetterAuthOptions | ((ctx: VoidAuthConfigContext) => BetterAuthOptions);
 /**
-* Shared AsyncLocalStorage that holds the authenticated Better Auth state for the
-* current request.
-*
-* Stored on `globalThis` under a `Symbol.for` key so duplicate module loads
-* (e.g. once by void's bundled runtime and once by Vite's SSR module runner
-* when user code imports from `void/auth`) share a single ALS instance. Without
-* this, the middleware writes to one instance and `getUser()` reads another,
-* always returning null.
-*/
+ * Shared AsyncLocalStorage that holds the authenticated Better Auth state for the
+ * current request.
+ *
+ * Stored on `globalThis` under a `Symbol.for` key so duplicate module loads
+ * (e.g. once by void's bundled runtime and once by Vite's SSR module runner
+ * when user code imports from `void/auth`) share a single ALS instance. Without
+ * this, the middleware writes to one instance and `getUser()` reads another,
+ * always returning null.
+ */
 type AuthContextStore = {
   user: AuthUser | null;
   state: AuthState | null;