void 0.21.9 → 0.23.0

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

@@ -154,11 +154,9 @@ Configuration for the [email integration](../guide/email.md).
 | ------ | -------- | -------------------------------------------------------------------------------------------------------------- |
 | `from` | `string` | Default sender for `sendEmail()`: one address, optionally with a display name (`Acme <noreply@mail.acme.com>`) |
 
-What `from` does depends on where the app runs:
+During development, `email.from` is the default sender in the local inbox. On a Void platform, use your project's shared sender or registered domain.
 
-- **`void dev`** — becomes the default `from` of every `sendEmail()` call, captured in the dev inbox; no mail leaves the machine.
-- **`void deploy`** (managed platform) — not used: the sender is pinned to your project's own platform address, which Void fills in for you.
-- **`void deploy --platform cloudflare`** (your own Cloudflare account) — the address host (`mail.acme.com`) is the domain Void sets Email Routing and Email Sending up on, and the address becomes the default `from` (written into the worker as the `__VOID_EMAIL_FROM` var). The host must be a zone in the pinned Cloudflare account, or a subdomain of one; a subdomain is the usual choice, and the apex is refused when it already receives mail elsewhere. An app that uses email without `email.from` deploys without it and prints the line to add. Void never picks a zone or writes `void.config.ts` for you. See [Your own Cloudflare account](../guide/email.md#your-own-cloudflare-account).
+For direct Cloudflare deployment, this address selects the mail domain and default sender. Use a zone or subdomain in your account; an existing mail provider's MX records are preserved. See [Email setup](../guide/email/domains.md#your-own-cloudflare-account).
 
 ### `head`
 
@@ -199,7 +197,7 @@ Output mode. Controls the default rendering strategy for pages.
 | `"server"` (default) | `false`           | `export const prerender = true`  | Deploy-time (platform ISR) |
 | `"static"`           | `true`            | `export const prerender = false` | Build or deploy post-build |
 
-When set to `"static"`, all pages are prerendered as static HTML files written to `dist/client/`. A standalone `vite build` renders them in the build; managed `void deploy` renders immediately afterward in the trusted deploy process so build plugins never receive platform credentials. Individual pages can opt out with `export const prerender = false`. Dynamic pages (with route params) without a `getPrerenderPaths()` export are implicitly not prerendered.
+When set to `"static"`, pages are prerendered to HTML in `dist/client/`. Individual pages can opt out with `export const prerender = false`. Dynamic pages need `getPrerenderPaths()` to be prerendered.
 
 When omitted or set to `"server"`, pages are server-rendered on request. Individual pages can opt into deploy-time prerendering with `export const prerender = true`, or opt out of server-rendered component HTML with `export const ssr = false`.
 
@@ -209,7 +207,7 @@ When omitted or set to `"server"`, pages are server-rendered on request. Individ
 
 ### `remote`
 
-Use remote D1/KV/R2 bindings during local development instead of local miniflare. When enabled, the Void plugin replaces local bindings with proxy-backed versions that forward operations to your deployed project's real resources via the Void proxy.
+Use a deployed Void project's D1, KV, and R2 resources during local development. Writes affect real data. See [Remote Development](../guide/remote-dev.md).
 
 ```json
 { "remote": true }
@@ -229,31 +227,31 @@ VOID_REMOTE=1 pnpm dev
 
 ### `sandbox`
 
-Enable and configure Cloudflare Sandboxes for Void apps. Importing from `void/sandbox` enables this automatically; set `sandbox` when you need custom container settings.
+Enable and configure Cloudflare Sandboxes. Importing from `void/sandbox` enables this automatically.
 
 ```json
 {
   "sandbox": {
     "image": "./Dockerfile.sandbox",
-    "platformImage": "registry.example.com/acme/sandbox:latest",
-    "instanceType": "lite",
-    "maxInstances": 2
+    "platformImage": "registry.cloudflare.com/<account-id>/sandbox@sha256:<digest>",
+    "instanceType": "standard-1"
   }
 }
 ```
 
-| Field               | Type     | Default                              |
-| ------------------- | -------- | ------------------------------------ |
-| `binding`           | `string` | `SANDBOX`                            |
-| `className`         | `string` | `Sandbox`                            |
-| `containerName`     | `string` | `void-sandbox`                       |
-| `image`             | `string` | Matching published sandbox SDK image |
-| `imageBuildContext` | `string` | Directory of `image`                 |
-| `platformImage`     | `string` | Matching sandbox SDK registry image  |
-| `instanceType`      | `string` | `lite` on Void deploy                |
-| `maxInstances`      | `number` | `20` on Void deploy                  |
+| Field               | Type     | Default                     |
+| ------------------- | -------- | --------------------------- |
+| `binding`           | `string` | `SANDBOX`                   |
+| `className`         | `string` | `SandboxV1`                 |
+| `containerName`     | `string` | `void-sandbox-v1`           |
+| `image`             | `string` | Packaged Node.js Dockerfile |
+| `imageBuildContext` | `string` | Directory of `image`        |
+| `platformImage`     | `string` | `cloudflare/debian-trixie`  |
+| `instanceType`      | `string` | `lite`                      |
 
-Sandbox is available to Void apps on the Cloudflare target and requires [Workers Paid](https://dash.cloudflare.com/?to=/:account/workers/plans) and Containers access. Void checks access before provisioning or building. For a managed platform, its runtime token needs Account / Containers: Edit and Account / Cloudchamber: Edit. Apps without Sandbox use neither Containers nor an entitlement check. The default image matches the installed `@cloudflare/sandbox` version. If `sandbox.image` points to a local Dockerfile, set `sandbox.platformImage` to the pushed image for the platform.
+Supported sizes are `lite` and `standard-1` through `standard-4`. Native deploys build Dockerfiles with Docker; registry images must be digest-pinned references from the Cloudflare managed registry. Custom images must include the matching Sandbox SDK helper. For a local Dockerfile, supply `platformImage` when deploying to a managed platform. See [Sandboxes](../guide/sandboxes.md) for image setup and runtime examples.
+
+Sandbox requires [Workers Paid](https://dash.cloudflare.com/?to=/:account/workers/plans) and Containers access. Managed runtime tokens need Account / Containers: Edit and Account / Cloudchamber: Edit. See [Sandbox deployment](../guide/sandboxes.md#deployment).
 
 ### `target`
 
@@ -345,7 +343,7 @@ Routing and edge configuration for headers, redirects, rewrites, and caching.
 
 #### `routing.headers`
 
-Custom response headers for dispatch-worker responses. Keys are URL patterns, values are arrays of `"Name: value"` strings. See [Custom Headers](../guide/edge/headers) for details.
+Custom response headers. Keys are URL patterns, values are arrays of `"Name: value"` strings. See [Custom Headers](../guide/edge/headers) for details.
 
 ```json
 {
@@ -388,7 +386,7 @@ URL rewrites. Keys are source URL patterns, values are destination paths. Serves
 }
 ```
 
-Destinations use the `RewriteDestination` shape — typed route patterns plus `string`, so known routes autocomplete while dynamic paths remain accepted. See [Programmatic rewrites in middleware](../guide/edge/rewrites#programmatic-rewrites-in-middleware) for the trade-off and performance notes.
+Destinations use the `RewriteDestination` shape — typed route patterns plus `string`, so known routes autocomplete while dynamic paths remain accepted. See [Programmatic rewrites](../guide/edge/rewrites#programmatic-rewrites-in-middleware).
 
 #### `routing.fallbacks`
 
@@ -416,7 +414,7 @@ Boolean switch for Void's ISR caching. When omitted or `true`, Void infers cachi
 }
 ```
 
-This does not disable `output: "static"` build-time HTML generation or delete existing KV resources. Set it to `true` to enable your configured cache policies again. Existing-Worker migration saves this choice before provisioning, so it remains consistent on retries and later deployments.
+Build-time HTML generation with `output: "static"` is unaffected. Set `isr` to `true` to enable your configured cache policies again.
 
 #### `routing.revalidate`
 
@@ -464,7 +462,7 @@ Paths to prerender as static HTML at deploy time. Each path must start with `/`.
 
 #### `routing.notFound`
 
-Override how the asset layer answers a request that matched no asset and no worker route. One of `"single-page-application"`, `"404-page"`, or `"none"`. If omitted, Void infers it — see [Static Assets](../guide/edge/static-assets.md#unmatched-requests).
+Override how the asset layer answers a request that matched no asset and no worker route. One of `"single-page-application"`, `"404-page"`, or `"none"`. If omitted, Void infers it — see [Static Assets](../guide/edge/static-assets.md#navigation-and-middleware).
 
 ```json
 {
@@ -474,13 +472,9 @@ Override how the asset layer answers a request that matched no asset and no work
 }
 ```
 
-Set `"404-page"` when your assets come from a static site generator (VitePress, Docusaurus, …) and you want unknown URLs to serve the generator's own `404.html` with a real HTTP 404. Without it, an app whose only backend is API routes keeps the inferred SPA fallback, so every unknown URL returns `index.html` with a `200` — correct for a single-page app, wrong for a generated site, and bad for crawlers.
-
-`run_worker_first` is untouched, so API routes, auth, and `/__void/*` still reach the worker first. When the worker owns HTML routing it also serves the resolved behavior itself, since `run_worker_first: ["/**"]` means the platform switch never runs — see [Unmatched requests](../guide/edge/static-assets.md#unmatched-requests).
-
-This does **not** apply to SvelteKit, Nuxt, Analog, or Astro deploys: those pin `not_found_handling` to `"none"` because the framework's own worker owns unmatched HTML, and `void deploy` warns if you set `routing.notFound` anyway.
+Use `"404-page"` for a generated static site with a `404.html`, `"single-page-application"` for a client router, or `"none"` to keep the Worker's own 404. API and middleware routing remain unchanged.
 
-TanStack Start, React Router, and vinext honor it on a managed `void deploy`, which resolves the asset config itself. Void writes no `assets` policy into their generated Worker config (`dist/server` for TanStack Start and vinext App, `build/server` for React Router, `dist/ssr` for vinext Pages). A custom config must declare a complete `assets` policy — `binding`, `directory`, `not_found_handling`, and `run_worker_first`. Void leaves those fields untouched, so your own policy is honored; with none, Cloudflare's default applies. `vite build` warns when it is set. See [Static Assets](../guide/edge/static-assets.md#unmatched-requests) for the per-framework paths.
+SvelteKit, Nuxt, Analog, and Astro use their own error pages and ignore this setting. For direct Cloudflare deployment with TanStack Start, React Router, or vinext, set a complete asset policy in your framework's Cloudflare config. See [Static Assets](../guide/edge/static-assets.md#navigation-and-middleware).
 
 ### `inference`
 
@@ -488,7 +482,7 @@ Configuration for build-time inference, including how Void detects your app type
 
 #### `inference.bindings`
 
-Explicitly control inferred Cloudflare bindings. If omitted, bindings are [automatically inferred](./resource-inference.md) by scanning your source files for binding usage. If provided, explicit values take precedence and inference is skipped entirely.
+Explicitly control inferred Cloudflare bindings. If omitted, bindings are [automatically inferred](./resource-inference.md) by scanning your source files for binding usage. Explicit values override the named bindings; omitted bindings are still inferred. Auth and checked-in migrations still require a database even when `db` is `false`.
 
 Each binding accepts `true` (use default name), `false` (disable), or a string (custom binding name):
 

package/skills/void/docs/reference/resource-inference.md

@@ -6,16 +6,6 @@ outline: deep
 
 Void automatically detects which Cloudflare resources your project uses by scanning source files at startup. In most cases, there is no manual configuration. Use a resource in code, and Void provisions the matching binding for local development.
 
-## How It Works
-
-When `voidPlugin()` initializes, it synchronously scans your source files using a three-tier approach optimized for speed:
-
-1. **Import detection:** uses `es-module-lexer` to check for `void/*` imports. This is the fastest pass and does not require AST parsing.
-2. **Regex pre-check:** tests for patterns such as `env.DB` and `env.KV` so files without bindings can be skipped early.
-3. **AST confirmation:** when the regex matches, parses the full AST to confirm `c.env.DB` or `env.DB` member expressions.
-
-This runs once before plugins initialize, so the results are available to configure the Cloudflare Vite plugin.
-
 ## Detected Bindings
 
 | Binding          | Type                       | Detected by import                                                                                                                                               | Detected by env access                                                         |
@@ -31,7 +21,7 @@ This runs once before plugins initialize, so the results are available to config
 
 Auth detection also triggers when importing the `auth` specifier from `void/client` or a framework-specific client subpath such as `void/client/react` (but not when importing only `fetch`).
 
-Durable state is inferred from files in `durable-objects/`. For example, `durable-objects/shopping-cart.ts` creates the `SHOPPING_CART` binding, exports `ShoppingCartDurableObject`, and adds a `new_sqlite_classes` migration. See [Durable State](../guide/durable-state.md).
+Durable state is inferred from files in `durable-objects/`. For example, `durable-objects/shopping-cart.ts` creates the `SHOPPING_CART` binding, exports `ShoppingCartDurableObject`, and records its migration. See [Durable State](../guide/durable-state.md).
 
 ## Scanned Directories
 
@@ -86,7 +76,7 @@ Paths are relative to the project root. When `inference.scanDirs` is set, it rep
 
 ## Explicit Binding Overrides
 
-If inference doesn't match your setup, you can skip it entirely and declare bindings explicitly:
+Override individual bindings when inference does not match your setup:
 
 ```json
 {
@@ -101,53 +91,8 @@ If inference doesn't match your setup, you can skip it entirely and declare bind
 }
 ```
 
-When `inference.bindings` is set, explicit values take full precedence and inference is skipped entirely.
+Explicit values override only their named bindings. Omitted bindings continue to be inferred, so setting `kv` does not disable storage, auth, or other features. Auth and checked-in migrations still require a database even when `db` is `false`.
 
 ## File Types
 
 Inference scans files matching `**/*.{ts,tsx,mts,js,jsx,mjs}` within each directory. Non-JS files (CSS, HTML, images) are ignored.
-
-## Common Patterns
-
-### Pages mode with D1
-
-A page companion file in `pages/` triggers D1 inference:
-
-```ts
-// pages/users.server.ts
-import { db } from 'void/db';
-
-export function loader() {
-  return db.select().from(users);
-}
-```
-
-### Cron job with KV
-
-A scheduled handler in `crons/` triggers KV inference:
-
-```ts
-// crons/cleanup.ts
-import { defineScheduled } from 'void';
-import { kv } from 'void/kv';
-
-export default defineScheduled(async () => {
-  await kv.delete('temp-cache');
-});
-```
-
-### Route handler with R2
-
-A route handler in `routes/` triggers R2 inference:
-
-```ts
-// routes/api/upload.ts
-import { defineHandler } from 'void';
-import { storage } from 'void/storage';
-
-export const POST = defineHandler(async (c) => {
-  const file = await c.req.blob();
-  await storage.put('uploads/file.bin', file);
-  return c.json({ ok: true });
-});
-```

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

@@ -10,12 +10,15 @@ const items = [
   { name: "db/", description: "Drizzle schema and SQL migrations", link: "#db" },
   { name: "crons/", description: "Scheduled cron jobs", link: "#crons" },
   { name: "queues/", description: "Async queue consumers", link: "#queues" },
+  { name: "email/", description: "Inbound email handlers", link: "#email" },
+  { name: "durable-objects/", description: "Durable State modules", link: "#durable-objects" },
   { name: "src/", description: "Shared app code", link: "#src" },
   { name: "public/", description: "Static assets (served as-is)", link: "#public" },
   { name: ".void/", description: "Auto-generated (gitignored)", link: "#void" },
   { name: "vite.config.ts", description: "Vite config with voidPlugin()", link: "#config-files" },
   { name: "void.config.ts", description: "Void project config (optional)", link: "#config-files" },
-  { name: ".env", description: "Environment variables", link: "#config-files" },
+  { name: ".env", description: "Local environment values", link: "#config-files" },
+  { name: "env.ts", description: "Environment schema", link: "#config-files" },
   { name: "package.json" },
   { name: "tsconfig.json" },
 ];
@@ -47,18 +50,6 @@ const dbItems = [
   },
 ];
 
-const voidItems = [
-  {
-    name: ".void/",
-    children: [
-      { name: "db.d.ts", description: "Drizzle DB instance types" },
-      { name: "routes.d.ts", description: "Typed fetch client types" },
-      { name: "queues.d.ts", description: "Queue consumer types" },
-      { name: "tsconfig.json", description: "TypeScript config fragment" },
-      { name: "v3/", description: "Local dev state (D1, KV, R2)" },
-    ],
-  },
-];
 </script>
 
 # Project Structure
@@ -102,11 +93,11 @@ Global middleware that runs on every request. Numeric prefixes control execution
 
 <FileTree :items="middlewareItems" default-expanded />
 
-Each file exports a `defineMiddleware()` handler. Use middleware to set shared context (auth, logging, rate limiting) available to all routes.
+Each file default-exports a `defineMiddleware()` handler. Use middleware to set shared context (auth, logging, rate limiting) available to all routes.
 
 ## `db/`
 
-[Drizzle schema](/guide/database#schema-definition) and SQL migration files for the [D1 database](/guide/database).
+[Drizzle schemas](/guide/database#schema-definition) and SQL migrations for D1, PostgreSQL, or MySQL.
 
 <FileTree :items="dbItems" default-expanded />
 
@@ -118,33 +109,19 @@ Generate schema with `void gen model` or write it by hand. Generate migrations w
 
 ## `crons/`
 
-[Scheduled jobs](/guide/jobs) that run on a cron schedule.
+[Scheduled jobs](/guide/jobs). Each file exports a `cron` expression and a default `defineScheduled()` handler.
 
-```ts
-// crons/heartbeat.ts
-import { defineScheduled } from 'void';
-
-export const cron = '*/5 * * * *';
+## `queues/`
 
-export default defineScheduled(async (controller, env) => {
-  // runs every 5 minutes
-});
-```
+[Queue consumers](/guide/queues). Each file default-exports a `defineQueue()` handler.
 
-## `queues/`
+## `email/`
 
-[Async queue consumers](/guide/queues) for background job processing.
+[Inbound email handlers](../guide/email/receiving.md#inbound). A file's name selects the recipient; `_default.ts` handles other addresses.
 
-```ts
-// queues/email.ts
-import { defineQueue } from 'void';
+## `durable-objects/`
 
-export default defineQueue(async (batch, env) => {
-  for (const msg of batch.messages) {
-    // process message
-  }
-});
-```
+[Durable State](/guide/durable-state) modules. Each file default-exports a `defineDurableState()` definition.
 
 ## `src/`
 
@@ -156,11 +133,7 @@ Static assets served as-is at the root path. Files here are not processed by Vit
 
 ## `.void/`
 
-Auto-generated directory (gitignored). Contains:
-
-Generate or refresh it with `void prepare`, or let `vite dev` / `vite build` populate it during normal app workflows.
-
-<FileTree :items="voidItems" default-expanded />
+Generated types and local development state (gitignored). Run `void prepare` to create the types, or let `vite dev` and `vite build` update them.
 
 ## Config Files
 

package/dist/canonical-json-DuDiiUsQ.mjs

@@ -1,13 +0,0 @@
-//#region src/migrations/canonical-json.ts
-function canonicalJson(value) {
-	if (value === null) return "null";
-	if (typeof value === "string" || typeof value === "number" || typeof value === "boolean") return JSON.stringify(value);
-	if (Array.isArray(value)) return `[${value.map((entry) => canonicalJson(entry)).join(",")}]`;
-	if (typeof value === "object") {
-		const object = value;
-		return `{${Object.keys(object).sort().filter((key) => object[key] !== void 0).map((key) => `${JSON.stringify(key)}:${canonicalJson(object[key])}`).join(",")}}`;
-	}
-	throw new TypeError(`Unsupported canonical JSON value: ${typeof value}`);
-}
-//#endregion
-export { canonicalJson as t };