void 1.4.0 → 1.6.0

package/docs/reference/cli/database.md

@@ -20,7 +20,7 @@ For SQLite, Void checks that the migration history applies to a fresh database.
 
 ## `void db status` {#void-db-status}
 
-Show migration status. Displays which migrations are applied or pending locally, then uses the saved deployment target for remote status: the hosted API for Void projects, the pinned D1 database and its configured migration table for direct Cloudflare SQLite projects, or the shell `DATABASE_URL` for direct Cloudflare PostgreSQL/MySQL projects. If the remote credential or service is unavailable, local status is still shown. If the local PostgreSQL or MySQL database cannot be read, local status shows `unknown`; the command fails when remote status is not available either.
+Show applied and pending migrations locally and on the saved deployment target. Direct Cloudflare PostgreSQL and MySQL projects use `DATABASE_URL` from the current shell for remote status.
 
 ## `void db reset` {#void-db-reset}
 
@@ -28,7 +28,7 @@ Show migration status. Displays which migrations are applied or pending locally,
 void db reset [--yes]
 ```
 
-Drop the development database and re-apply all migrations. D1 resets the local database. PostgreSQL drops the tables, views, sequences, and custom types in the `public` schema of the `DATABASE_URL` database from `.env` and keeps installed extensions. If a table, view, or function in another schema uses one of those views, sequences, or types, reset stops before it drops anything and lists those objects. MySQL drops every table and view in that database.
+Reset the development database and re-apply all migrations. D1 resets local data. PostgreSQL clears tables, views, sequences, and custom types from the `public` schema while preserving extensions; dependencies from other schemas must be resolved first. MySQL drops all tables and views. PostgreSQL and MySQL use `DATABASE_URL` from `.env`.
 
 When that `DATABASE_URL` points to a host other than `localhost`, Void names the database and asks before dropping its tables. Pass `--yes` to skip the prompt in scripts and CI; without a terminal, the command stops unless `--yes` is set. If `.env` uses the same URL as your deployment (for example after `void db connect`), reset drops the deployed tables.
 
@@ -87,7 +87,7 @@ By default, targets the local database. Pass `--remote` to open Studio against t
 
 - **Hosted PostgreSQL and MySQL projects**: fetch the stored connection string from the platform and open Studio against it. If the URL isn't stored yet, run `void db set-url` first.
 - **Direct Cloudflare PostgreSQL and MySQL projects**: use `DATABASE_URL` from the current shell.
-- **D1 projects**: remote Studio is not available. Use `void db execute --remote` to query your deployed D1 database.
+- **D1 projects**: use `void db execute --remote` to query the deployed database.
 
 ## `void db restore` {#void-db-restore}
 
@@ -96,19 +96,25 @@ void db restore --bookmark <bookmark> [--platform cloudflare] [--yes]
 void db restore --timestamp <iso-time> [--platform cloudflare] [--yes]
 ```
 
-Restore the deployed D1 database of a direct Cloudflare deploy with D1 [Time Travel](https://developers.cloudflare.com/d1/reference/time-travel/). Before `void deploy --platform cloudflare` applies migrations, it prints the `--bookmark` that undoes them. `--timestamp` restores the state at an ISO 8601 time with `Z` or an offset instead, such as `2026-10-16T09:30:00Z`, with at most millisecond precision. Time Travel keeps 7 days of history on Workers Free and 30 days on Workers Paid. An older bookmark or time can no longer be restored: Cloudflare rejects it and the database stays unchanged. To undo an older migration, write a new migration that reverses it.
+Restore a directly deployed Cloudflare D1 database using [Time Travel](https://developers.cloudflare.com/d1/reference/time-travel/). Use the bookmark printed before deployment migrations, or an ISO 8601 timestamp with a timezone, such as `2026-10-16T09:30:00Z`.
 
-If the project's saved destination is not Cloudflare and you deployed once with `void deploy --platform cloudflare`, pass `--platform cloudflare`; deploy prints the command with it.
+Time Travel keeps 7 days of history on Workers Free and 30 days on Workers Paid. Reverse older migrations with a new migration.
 
-Restoring replaces the whole database and discards every write made after that point. Void names the database and asks before it restores. Pass `--yes` to skip the prompt in scripts and CI; without a terminal, the command stops unless `--yes` is set. Afterwards Void prints the `void db restore` command that undoes the restore.
+Restoring discards every write made after the selected point. Void asks for confirmation and prints a command to undo the restore afterward. Pass `--yes` for scripts and CI.
 
-A restore also rewinds the record of applied migrations. Void lists the migration files the database no longer has applied; the next deploy applies them, so fix or remove the one that caused the problem first. Restoring does not change the deployed code: use [`void project rollback`](./project.md#void-project-rollback-deployid) if the live version needs the newer schema. After a one-off Cloudflare deploy, pass `--platform cloudflare` to `void project rollback` and `void deploy` as well.
+To recover from a bad migration:
+
+1. Roll back the code with [`void project rollback`](./project.md#void-project-rollback-deployid) if the live version needs the newer schema.
+2. Restore the database using the printed bookmark.
+3. Fix or remove the failed migration before deploying again. The restore also rewinds migration history, so the next deploy reapplies pending files.
+
+For a one-off Cloudflare deployment, add `--platform cloudflare` to restore, rollback, and deploy commands.
 
 ## `void db rename-migrations` {#void-db-rename-migrations}
 
-Rename existing migrations from the old numeric prefix format (`0001_name.sql`) to timestamp-based format (`20260410161500_name.sql`). Updates local tracking table and remote records if logged in with a linked project. A project that deploys to Void must be linked first with `void project link`; otherwise the command stops without changes.
+For linked Void platform projects, rename migrations from numeric prefixes (`0001_name.sql`) to timestamps (`20260410161500_name.sql`) and update local and remote migration records. Sign in and run `void project link` first.
 
-Direct Cloudflare deploys are not supported: Void cannot rename the records in the deployed database, so the command stops without changes. Keep the existing names; new migrations use timestamps and run after them.
+For direct Cloudflare deployments, keep existing filenames. New migrations use timestamps and run after them.
 
 ## `void db connect` {#void-db-connect}
 

package/docs/reference/cli/email.md

@@ -59,9 +59,11 @@ void email alias <name> [--yes] [--project <name>]
 
 With no name, show the project's address on the platform's shared mail domain and whether inbound mail reaches it.
 
-With a name, give that address a shorter name: `void email alias acme` makes `acme@<mail domain>` and `acme+<tag>@<mail domain>` reach the project and lets it send from them. Only the project owner can set it. The name follows the same rules as a project slug, must not be used by any other project's slug or alias, and names of five characters or fewer need a plan that allows short names.
+As the project owner, run `void email alias acme` to send and receive at `acme@<mail domain>` and `acme+<tag>@<mail domain>`. Choose an available name that follows the project slug rules. Names of five characters or fewer require a plan that allows short names.
 
-The alias is permanent: it cannot be changed or removed, and it is freed only when the project is deleted. The slug address keeps working for sending and receiving, so nothing that already uses it breaks. The CLI asks for confirmation; pass `--yes` to skip the prompt, which is required outside an interactive terminal. Inbound mail at the alias starts once the project has `email/` handlers deployed and its recipient rule is ready; run `void email alias` to check. Redeploy with the current `void` before you share the alias: an app built with an older version sees `message.to` with the alias still in front (`acme+support@…` instead of `support@…`).
+An alias is permanent and reserved until the project is deleted. The original slug address keeps working. The CLI asks for confirmation; use `--yes` in scripts and CI.
+
+Before sharing the alias, redeploy with the current Void version so handlers receive the expected `message.to` address. Inbound mail starts when the project's `email/` handlers and recipient rule are ready; run `void email alias` to check.
 
 ## `void email domain` {#void-email-domain}
 

package/docs/reference/cli/platform-installation.md

@@ -25,6 +25,7 @@ void platform install [options] [--yes]
 | `--dedicated-zone`                        | Add zone-wide catch-all routes; valid only when the app domain is the whole zone     |
 | `--no-dedicated-zone`                     | Skip zone-wide application catch-all routes                                          |
 | `--custom-domains`                        | Let projects add their own domains; needs a dedicated zone                           |
+| `--runtime-logs <full\|minimal>`          | `minimal` keeps request URLs and log and exception messages out of runtime logs      |
 | `--control-plane-domain <domain>`         | Optional API custom hostname; defaults to `workers.dev`                              |
 | `--no-control-plane-domain`               | Use the default `workers.dev` API hostname                                           |
 | `--dashboard-url <origin>`                | HTTPS origin of an optional dashboard deployed separately                            |
@@ -41,7 +42,7 @@ The installed platform needs a separate runtime token to provision resources for
 
 To enable email during install or upgrade, set both `VOID_EMAIL_SENDER_DOMAIN` and `VOID_EMAIL_SHARED_ZONE_ID`. Void records the pair for later upgrades; supplying only one is an error.
 
-Use `--dashboard-url `[`https://dash.example.com`](https://dash.example.com) when deploying the optional user
+Use `--dashboard-url https://dash.example.com` when deploying the optional user
 dashboard separately. The URL must be an HTTPS origin without credentials, a
 path, query, or fragment. Void permits that origin's login callbacks and saves
 it for later maintenance; it does not deploy a dashboard Worker. Omission keeps
@@ -101,7 +102,7 @@ Use these commands to recover, update, pause, or remove an installation:
 
 ```sh
 void platform discover [--account <id>] [--installation <id-or-name>]
-void platform upgrade [id] [--runtime <path>] [--dashboard-url <origin>] [--custom-domains] [--plan] [--yes]
+void platform upgrade [id] [--runtime <path>] [--dashboard-url <origin>] [--custom-domains] [--runtime-logs <full|minimal>] [--plan] [--yes]
 void platform rollback [id] --runtime <earlier-path> [--from-runtime <current-path>] [--plan] [--yes]
 void platform repair [id] [--runtime <path>] [--dashboard-url <origin>] [--custom-domains] [--auth-config <path>] [--plan] [--yes]
 void platform disable [id] [--plan] [--yes]
@@ -113,6 +114,8 @@ void platform uninstall [id] [--plan] [--purge-data | --purge-resources] [--yes]
 
 Use the installation slug shown beside its name in `void platform list`. Installation IDs and saved connection IDs also work. Lifecycle commands require local installation records; use `discover` to restore them on another machine. Omit `id` when only one installation is configured, or choose from the interactive picker. Non-interactive commands need a slug or ID when several installations exist. Commands that make changes also require `--yes`; `--plan` only previews changes.
 
+`upgrade --runtime-logs <full|minimal>` changes what runtime logs record; without it, upgrades keep the current setting. See [Choose what runtime logs record](../../guide/platform/installation/setup.md#runtime-logs).
+
 To add or explicitly change a separately deployed dashboard after installation,
 use `repair --dashboard-url <origin>` or `upgrade --dashboard-url <origin>`.
 Preview with `--plan` first. Existing Access protection must cover the configured
@@ -138,7 +141,7 @@ After discovery on another machine, set `VOID_PLATFORM_DATABASE_URL`. See [Manag
 
 Repair and upgrade preserve disabled state. New, resumed, and previously disabled installations block user traffic until all target Workers pass verification; the installer's health probes can still run. Routes and custom domains remain attached.
 
-If a platform Worker was changed outside Void, or has an active version without a Void deployment record, a command that deploys the platform Workers stops before it changes a platform Worker or pauses traffic, unless you agree in a terminal to replace the changes. See [Platform Workers changed outside Void](../../guide/platform/installation/maintenance.md#workers-changed-outside-void).
+Replacing platform Worker configuration changed outside Void requires interactive approval. Follow [Platform Workers changed outside Void](../../guide/platform/installation/maintenance.md#workers-changed-outside-void) if maintenance asks for it.
 
 `--runtime` selects a custom platform build. Relative paths resolve from your current directory. Void verifies the build before making changes; see [Platform Development](../../guide/platform/development/runtime.md#deploying-your-runtime) for creating one.
 

package/docs/reference/cli/project.md

@@ -179,9 +179,9 @@ Roll back to a previous deployment or Worker Version.
 
 On a Void platform, you can select a retained deployment. On Cloudflare, use a complete Worker Version ID or an unambiguous prefix. Void activates that version at 100%. When both versions have complete trigger snapshots, it also restores the selected version's schedules, queues, workflows, routes, and custom domains. Otherwise, rollback keeps the current triggers and restores the code, including versions originally deployed outside Void.
 
-If the project's saved destination is not Cloudflare and you deployed once with `void deploy --platform cloudflare`, pass `--platform cloudflare` to roll back that Worker.
+Pass `--platform cloudflare` to roll back a one-off Cloudflare deployment.
 
-Rollback doesn't reverse database migrations. If older code may run against a newer schema, or migration metadata is missing, Void explains the risk and asks for confirmation. On Cloudflare, undo D1 migrations with [`void db restore`](./database.md#void-db-restore) and the restore point that deploy printed before it applied them, within 7 days on Workers Free or 30 days on Workers Paid.
+Database recovery is separate from code rollback. Void asks for confirmation when the earlier code may be incompatible with the current schema. For D1 on Cloudflare, use [`void db restore`](./database.md#void-db-restore) with the restore point printed during deployment.
 
 ## `void project cancel [deployId]` {#void-project-cancel-deployid}
 

package/docs/reference/cli/secrets.md

@@ -30,7 +30,7 @@ On a direct Cloudflare target, the value is stored as an encrypted Worker secret
 ## `void secret sync` {#void-secret-sync}
 
 ```
-void secret sync <file> [--project <name>]
+void secret sync <file> [--project <name>] [--yes]
 ```
 
 Upload production server values from a dotenv file stored outside your project. Include only keys declared in `env.ts`; leave out local development credentials and public `VITE_*` values.
@@ -39,6 +39,8 @@ Upload production server values from a dotenv file stored outside your project.
 void secret sync /secure/path/production.env
 ```
 
+Pass `--yes` to skip confirmation in scripts and CI.
+
 Existing remote secrets absent from the file are kept. Every entry must be a server key declared in `env.ts`, and its value must pass validation.
 
 ## `void secret delete` {#void-secret-delete}

package/docs/reference/cli/setup.md

@@ -23,7 +23,7 @@ Resources recorded in `void.lock.json` without a matching definition appear sepa
 
 `void migrate` converts legacy `void.json` and root `wrangler.jsonc` or `wrangler.json` files into `void.config.ts`. It also accepts one root `wrangler*.json(c)` file referenced by a supported framework adapter. Void saves backups in `.void/config-migration/`, records resource IDs in `void.lock.json`, and updates supported adapters to use its generated Cloudflare config.
 
-`.void-wrangler.jsonc` is generated for Cloudflare tooling and belongs in `.gitignore`; migration adds the entry. Review and commit `void.config.ts`, `void.lock.json`, and `.gitignore`. `void init` and `void deploy` migrate legacy files automatically. If the project has conflicting or multiple Cloudflare configs, resolve them first. The project's installed `void` package must match the CLI version before Cloudflare deployment.
+The command adds generated `.cloudflare/` and `.void-wrangler.jsonc` files to `.gitignore` as needed. Review and commit `void.config.ts`, `void.lock.json`, and `.gitignore`. `void init` and `void deploy` migrate legacy files automatically. Resolve conflicting Cloudflare configs first, and keep the project's `void` package and CLI on the same version.
 
 ## `void init` {#void-init}
 
@@ -32,9 +32,9 @@ void init [--tsconfig] [--github] [--git | --no-git]
           [--toolchain <name>] [--framework <name>] [--starter <name>] [--deploy <target>]
 ```
 
-Set up a new or existing Void project. In an empty directory, choose Vite+ or Vite, a framework, and a D1, PostgreSQL, MySQL, or Static Pages starter.
+Set up a new or existing Void project. In an empty directory, choose Vite+ or Vite, a framework, and a D1, PostgreSQL, MySQL, or Static Pages starter. The new app's `void.config.ts` turns on [`routing.typedRoutes`](../config.md#routing-typedroutes).
 
-To scaffold without prompts, for example from a script or a coding agent, pass the choices as flags. Without an interactive terminal, init stops and names the flag it needs instead of prompting.
+Pass your choices as flags to scaffold from a script or coding agent:
 
 | Flag          | Values                                    |
 | ------------- | ----------------------------------------- |
@@ -48,7 +48,7 @@ void init --toolchain vite-plus --framework react --starter sqlite --deploy none
 npm create void@latest my-app -- --toolchain vite-plus --framework react --starter sqlite --deploy none
 ```
 
-Cloudflare and Void platform setup still sign in interactively. Without a terminal, choose `--deploy none` and run `void connect` later.
+For non-interactive scaffolding, choose `--deploy none` and run `void connect` later to sign in.
 
 Vite+ projects install dependencies through `vp install`; no global Vite+ installation is required. Void preserves existing package-manager versions and lockfiles. New Vite+ projects without a package-manager configuration use pnpm without pinning a version.
 

package/docs/reference/cli.md

@@ -76,7 +76,7 @@ Use this page as a command reference. If you are setting up a project for the fi
 | `void email alias [name]`         | Show the shared mail address, or give it a shorter permanent name             |
 | `void email domain`               | Send and receive at your own domain on a Cloudflare zone                      |
 | `void init`                       | Set up a new or existing project, including coding agents                     |
-| `void migrate`                    | Convert legacy `void.json` and root Wrangler JSON/JSONC into `void.config.ts` |
+| `void migrate`                    | Update project configuration                                                  |
 
 ## Binary Invocation {#binary-invocation}
 

package/docs/reference/config.md

@@ -63,7 +63,7 @@ With that config, Void reads `src/pages`, `src/routes`, `src/db/schema.ts`, `src
 
 ### `ai`
 
-`ai.gateway` names the Cloudflare AI Gateway that `ai.provider().fetch()` uses when your app runs on your own Cloudflare account. `ai.run()`, `ai.stream()`, and `ai.image()` use the Workers AI binding and do not need a gateway. On a Void platform, the platform selects the gateway and ignores this setting.
+Set `ai.gateway` to the Cloudflare AI Gateway used by `ai.provider().fetch()` on your own Cloudflare account. `ai.run()`, `ai.stream()`, and `ai.image()` use the Workers AI binding. On a Void platform, the platform selects the gateway.
 
 ```json
 { "ai": { "gateway": "my-gateway" } }
@@ -297,7 +297,7 @@ Void-managed WebSocket route files (`*.ws.ts`) are Cloudflare-only because they
 
 ### `worker`
 
-Curated Cloudflare Workers configuration. `void init` pins `compatibility_date` here. If a project has no config file and no date, the first dev server or build creates `void.config.ts` with only this date and adds `.void-wrangler.jsonc` to `.gitignore`. Astro, SvelteKit, Nuxt, and Analog apps get the date in a root `wrangler.jsonc` instead, which their adapter reads by default. A project with a `wrangler.toml` gets it in `void.json`. Binding arrays such as `d1_databases`, `kv_namespaces`, and `r2_buckets` go in [`cloudflare`](#cloudflare), where Void preserves custom settings and resolved IDs during deployment.
+Cloudflare Workers settings, including the `compatibility_date` pinned by `void init`. Put binding arrays such as `d1_databases`, `kv_namespaces`, and `r2_buckets` in [`cloudflare`](#cloudflare).
 
 | Field                 | Type       | Description                            |
 | --------------------- | ---------- | -------------------------------------- |
@@ -376,6 +376,16 @@ routing: {
 }
 ```
 
+#### `routing.typedRoutes`
+
+Type-check URL strings against your app's routes in `Link`'s `href`, `router.visit()`, `router.prefetch()`, `router.flush()`, and `c.rewrite()`. Omitted or `false` means off; `void init` turns it on for new apps. It changes types only, not navigation at runtime. Strings may also be same-page queries or hashes, or `http://`, `https://`, `mailto:`, and `tel:` URLs. See [Checked URL strings](../guide/type-safety#checked-url-strings).
+
+```ts
+routing: {
+  typedRoutes: true,
+}
+```
+
 #### `routing.headers`
 
 Custom response headers. Keys are URL patterns, values are arrays of `"Name: value"` strings. See [Custom Headers](../guide/edge/headers) for details.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "void",
-  "version": "1.4.0",
+  "version": "1.6.0",
   "description": "Full-stack framework and deployment CLI for Cloudflare Workers, powered by Vite.",
   "homepage": "https://void.cloud",
   "bugs": {
@@ -90,7 +90,9 @@
       "require": "./dist/runtime/validator.mjs"
     },
     "./routes": {
-      "types": "./dist/routes-stub.d.mts"
+      "types": "./dist/routes-stub.d.mts",
+      "import": "./dist/routes-stub.mjs",
+      "require": "./dist/routes-stub.mjs"
     },
     "./nitro": {
       "types": "./dist/nitro.d.mts",
@@ -341,56 +343,58 @@
     }
   },
   "dependencies": {
-    "@cloudflare/build-output-utils": "^0.9.3",
-    "@cloudflare/codemods": "^0.5.1",
-    "@cloudflare/config": "^0.27.0",
-    "@cloudflare/sandbox": "^1.0.2",
-    "@cloudflare/vite-plugin": "^1.64.0",
-    "@cloudflare/workers-auth": "^0.14.1",
-    "@cloudflare/workers-types": "^5.20261019.1",
-    "@cloudflare/workers-utils": "^0.47.3",
+    "@cloudflare/build-output-utils": "^0.9.7",
+    "@cloudflare/codemods": "^0.7.1",
+    "@cloudflare/config": "^0.29.1",
+    "@cloudflare/sandbox": "^1.0.3",
+    "@cloudflare/vite-plugin": "^2.0.0-beta.v.9",
+    "@cloudflare/workers-auth": "^0.15.4",
+    "@cloudflare/workers-types": "^5.20261102.1",
+    "@cloudflare/workers-utils": "^0.50.2",
     "@napi-rs/keyring": "^2.1.2",
-    "@void/deploy-cloudflare": "1.4.0",
-    "@void/deploy-core": "1.4.0",
-    "@void/edge": "1.4.0",
-    "@void/isr": "1.4.0",
-    "@void/platform": "1.4.0",
-    "better-auth": "^1.7.11",
+    "@void/deploy-cloudflare": "1.6.0",
+    "@void/deploy-core": "1.6.0",
+    "@void/edge": "1.6.0",
+    "@void/isr": "1.6.0",
+    "@void/platform": "1.6.0",
+    "better-auth": "^1.7.14",
     "better-sqlite3": "^13.0.3",
     "blake3-jit": "^1.1.0",
-    "cf": ">=1.0.0-beta.18 <1.0.0-beta.19",
+    "cf": "^1.0.0-beta.26",
     "drizzle-arktype": "^0.1.3",
     "drizzle-kit": "^0.31.11",
     "drizzle-orm": "^0.45.4",
     "drizzle-valibot": "^0.4.2",
     "drizzle-zod": "^0.8.3",
     "email-validator": "^2.0.4",
-    "hono": "^4.13.13",
-    "ignore": "^7.0.12",
+    "gray-matter": "^4.0.3",
+    "hono": "^4.13.16",
+    "ignore": "^7.0.14",
     "jiti": "^2.7.0",
     "jsonc-parser": "^3.3.1",
-    "mime": "^4.1.1",
-    "miniflare": "^5.20261012.1-beta",
-    "minimatch": "^10.2.6",
+    "mime": "^4.1.2",
+    "miniflare": "^5.20261101.0-beta",
+    "minimatch": "^11.0.3",
     "mysql2": "^3.24.6",
     "pg": "^8.23.1",
-    "postal-mime": "^4.0.11",
+    "postal-mime": "^4.2.0",
     "proper-lockfile": "^4.1.2",
+    "smol-toml": "^1.9.1",
     "terminal-link": "^5.0.0",
     "yaml": "^2.9.1"
   },
   "devDependencies": {
-    "@electric-sql/pglite": "0.5.10",
+    "@electric-sql/pglite": "0.5.14",
     "@types/better-sqlite3": "^9.6.0",
-    "@types/node": "^26.6.5",
+    "@types/node": "^26.6.6",
     "@types/pg": "^8.23.1",
     "@types/proper-lockfile": "^4.1.4",
-    "@voidzero-dev/vite-plus-prompts": "1.3.0",
-    "arktype": "^2.2.8",
+    "@voidzero-dev/vite-plus-prompts": "1.4.0",
+    "arktype": "^2.2.9",
     "ci-info": "^4.4.0",
     "estree-walker": "^3.0.3",
     "fast-wrap-ansi": "^0.2.2",
-    "magic-string": "^1.4.3",
+    "magic-string": "^1.4.5",
     "ofetch": "2.0.0-alpha.3",
     "pathslash": "^0.1.0",
     "pglite-server": "0.1.5",
@@ -398,12 +402,12 @@
     "tinyglobby": "^0.2.17",
     "typescript": "7.0.2",
     "valibot": "^1.5.0",
-    "vite": "npm:@voidzero-dev/vite-plus-core@1.3.0",
-    "vite-plus": "1.3.0",
+    "vite": "npm:@voidzero-dev/vite-plus-core@1.4.0",
+    "vite-plus": "1.4.0",
     "zod": "^4.6.7"
   },
   "peerDependencies": {
-    "@void/md": "1.4.0",
+    "@void/md": "1.6.0",
     "arktype": ">=2.0.0",
     "valibot": ">=1.0.0-beta.7",
     "vite": "^8.0.0",
@@ -424,7 +428,7 @@
     }
   },
   "engines": {
-    "node": ">=24.21.0"
+    "node": "^24.22.0 || >=26.12.0"
   },
   "scripts": {
     "build": "node scripts/sync-docs.mjs && vp pack",

package/sandbox.Dockerfile

@@ -1,4 +1,4 @@
 FROM node:26.12.1-trixie-slim
-COPY --from=docker.io/cloudflare/sandbox:1.0.2 /usr/local/bin/sandbox-shim /usr/local/bin/sandbox-shim
+COPY --from=docker.io/cloudflare/sandbox:1.0.3 /usr/local/bin/sandbox-shim /usr/local/bin/sandbox-shim
 WORKDIR /workspace
 CMD ["sleep", "infinity"]

package/schema.json

@@ -152,6 +152,10 @@
           "type": "boolean",
           "description": "Enable inferred ISR caching. Set false to disable ISR and edge prerendering, including per-page prerender and revalidate policies. Does not disable output: static build-time prerendering."
         },
+        "typedRoutes": {
+          "type": "boolean",
+          "description": "Type-check URL strings in Link href, router navigation, and c.rewrite() against the app's routes. Omitted or false means off."
+        },
         "notFound": {
           "type": "string",
           "enum": ["single-page-application", "404-page", "none"],

package/skills/void/SKILL.md

@@ -84,6 +84,11 @@ the app's existing saved destination, including when the target project is new.
   guides and use `void info` to preserve resource names and instance keys.
 - Declare application environment keys in `env.ts` and access them through
   `void/env`; follow `docs/guide/env-vars.md` for local and production values.
+- In Pages navigation, style the current link with `Link`'s `aria-current` and `data-void-active`
+  attributes (`activeMatch="prefix"` for sections) instead of comparing `useRouter().path`; see
+  `docs/guide/pages-routing/overview.md#active-links`. Show a loading state on
+  the clicked link with `data-void-pending` instead of matching `useNavigation().location`
+  yourself; see `docs/guide/pages-routing/overview.md#pending-links`.
 - For platform setup, follow the pages linked from
   `docs/guide/self-hosted-platform.md`. Use `void platform list` to find the
   installation slug for maintenance. For recovery, use its documented resume

package/dist/cf-build-output-bd8Uwv1P.mjs

@@ -1 +0,0 @@
-export { t as prepareCfBuildOutput } from "./cf-build-output-XpNR9zoh.mjs";

package/dist/client-BZb9j66F.mjs

@@ -1 +0,0 @@
-export { r as PlatformClient } from "./client-B3LnB_bE.mjs";

package/dist/collect-BWhkgtAn.mjs

@@ -1 +0,0 @@
-export { t as collectMigrations } from "./collect-Dew86qce.mjs";

package/dist/deploy-CX94CmKa.mjs

@@ -1,2 +0,0 @@
-import "./deploy-transport-DIq_gFTP.mjs";
-export { i as checkWranglerMigrationApplySet, t as parseRootWranglerConfig, r as runDeploy } from "./deploy-CdM-LAxX.mjs";

package/dist/discover-D4TPKo57.mjs

@@ -1 +0,0 @@
-export { t as discoverSchema } from "./discover-LaV0tbIu.mjs";

package/dist/gen-BhWBT4iu.mjs

@@ -1 +0,0 @@
-export { r as runGenCommand } from "./gen-CFmsUsW1.mjs";