void 0.22.0 → 0.23.0

package/skills/void/docs/guide/auth.md

@@ -5,7 +5,7 @@ outline: deep
 # Authentication
 
 ::: warning ⚠️ Void Apps Only
-Void-managed auth currently works only for Void apps. Meta-framework mode is not supported yet.
+Void-managed auth requires a native Void app on Cloudflare. For meta-frameworks or Node.js, Bun, and Deno, use Better Auth directly.
 :::
 
 Void configures [Better Auth](https://www.better-auth.com/) for your app, including its database connection, API routes, and client. Start with email and password, or add a social login provider.
@@ -14,17 +14,7 @@ Void configures [Better Auth](https://www.better-auth.com/) for your app, includ
 
 ### 1. Enable auth
 
-Add a provider to `void.config.ts`. Email/password is the default, so the simplest config is:
-
-```json
-{
-  "auth": {
-    "providers": ["email"]
-  }
-}
-```
-
-You can also skip this step entirely. Auth activates automatically when you import from `void/auth` or `void/client`.
+Import `auth` from `void/client` to enable email/password auth automatically. Use [configuration](#config) to add social providers.
 
 ### 2. Sign up and sign in
 
@@ -36,14 +26,14 @@ import { auth } from 'void/client';
 // sign up
 await auth.signUp.email({
   email: 'alice@example.com',
-  password: 's3cret',
+  password: 'example-password-123',
   name: 'Alice',
 });
 
 // sign in
 await auth.signIn.email({
   email: 'alice@example.com',
-  password: 's3cret',
+  password: 'example-password-123',
 });
 ```
 
@@ -83,8 +73,6 @@ export const loader = defineHandler(() => {
 await auth.signOut();
 ```
 
-The rest of this page covers configuration, server helpers, and advanced customization in detail.
-
 ## Config
 
 Auth turns on automatically when you:
@@ -94,9 +82,7 @@ Auth turns on automatically when you:
 - add `auth` to `void.config.ts`
 - add a root-level `auth.ts` file
 
-The simplest setup is no config at all. Email/password auth is enabled by default.
-
-Example:
+Email/password is enabled by default. To add social providers:
 
 ```json
 {
@@ -117,38 +103,9 @@ For example, `github` uses:
 
 ## Client Usage
 
-`void/client` exports a preconfigured Better Auth client:
-
-```ts
-import { auth } from 'void/client';
-
-await auth.signUp.email({
-  email: 'alice@example.com',
-  password: 's3cret',
-  name: 'Alice',
-});
-
-await auth.signIn.email({
-  email: 'alice@example.com',
-  password: 's3cret',
-});
-
-await auth.signOut();
-```
-
-The client uses Better Auth's API, configured at `/api/auth`.
-
-See the official [Better Auth client docs](https://www.better-auth.com/docs/concepts/client) for the full client API.
-
-Framework-specific clients are selected automatically:
-
-- React pages apps use `better-auth/react`
-- Vue pages apps use `better-auth/vue`
-- Svelte pages apps use `better-auth/svelte`
-- Solid pages apps use `better-auth/solid`
-- other Void apps use `better-auth/client`
+The `auth` client uses [Better Auth's client API](https://www.better-auth.com/docs/concepts/client) at `/api/auth`. Void selects the client for your framework automatically.
 
-For advanced usage, `void/client` also exports `createAuthClient`.
+For a custom client, import `createAuthClient` from `void/client`.
 
 ## Server Usage
 
@@ -162,67 +119,13 @@ import { getSession, getUser, requireAuth } from 'void/auth';
 - `getSession()` returns `{ user, session } | null`
 - `requireAuth(c)` returns the authenticated user or throws `401`
 
-Example:
-
-```ts
-import { defineHandler } from 'void';
-import { requireAuth } from 'void/auth';
-
-export const GET = defineHandler((c) => {
-  const user = requireAuth(c);
-  return { email: user.email };
-});
-```
-
-### `AuthUser`
-
-`AuthUser` maps to Better Auth's core user type:
-
-```ts
-interface AuthUser {
-  id: string;
-  email: string;
-  emailVerified: boolean;
-  name: string;
-  image?: string | null;
-  createdAt: Date;
-  updatedAt: Date;
-}
-```
-
-### `AuthSession`
-
-`AuthSession` maps to Better Auth's core session type:
-
-```ts
-interface AuthSession {
-  id: string;
-  token: string;
-  userId: string;
-  expiresAt: Date;
-  createdAt: Date;
-  updatedAt: Date;
-  ipAddress?: string | null;
-  userAgent?: string | null;
-}
-```
+Import `AuthUser` and `AuthSession` from `void/auth` for type annotations. See their fields in the [API reference](../reference/api/auth.md#authuser).
 
 ## Behavior
 
-When auth is active, Void configures Better Auth with these conventions:
-
-- mount path: `/api/auth/*`
-- email/password enabled by default unless `auth.providers` is set without `"email"`
-- `auth.providers` can enable any built-in Better Auth social provider
-- deployed apps need an auth secret via `BETTER_AUTH_SECRET`
-- D1/SQLite uses the app `DB` binding
-- PostgreSQL apps (`"database": "pg"`) use the app `HYPERDRIVE` binding
-
-Auth sessions live in the same database system as the rest of the app.
-
-On both deployment targets, Void keeps an existing `BETTER_AUTH_SECRET` or generates one when it's missing. The value is stored as an encrypted Worker secret and reused by later versions.
+Auth sessions use the same database as your app. Void creates `BETTER_AUTH_SECRET` on deploy if it is missing and reuses it on later deploys.
 
-The Vite development server uses a built-in fallback secret automatically. A local preview of a production build needs `BETTER_AUTH_SECRET`; production deployment through Void manages the secret lifecycle for you.
+Local development needs no secret setup. To preview a production build locally, provide `BETTER_AUTH_SECRET`.
 
 ## Customization
 
@@ -245,19 +148,12 @@ For the full set of available options, see the official [Better Auth options ref
 
 Auth tables live alongside your app's tables. During local development, Void creates them automatically.
 
-A Void platform deploy creates the Better Auth tables at runtime after dispatch. A direct Cloudflare deploy requires those tables in your checked-in migrations. Generate them with:
+Void platforms create auth tables automatically. For a direct Cloudflare deploy, include them in your checked-in migrations:
 
 ```sh
 void db generate
 ```
 
-Void adds the production Better Auth schema, including configured model names and plugin tables, to Drizzle's migration input. Review and commit the SQL before deploying. You don't need to duplicate the auth tables in `db/schema.ts` or run a separate Better Auth CLI.
+Review and commit the SQL before deploying. Void includes your auth configuration and plugin tables; you don't need to duplicate them in `db/schema.ts` or run the Better Auth CLI.
 
 MySQL stores OAuth access, refresh, and ID tokens as unbounded text. Existing direct-deploy MySQL apps should run `void db generate` once after upgrading to widen earlier `varchar(255)` token columns. Void platform deployments apply the same safe widening automatically.
-
-## Unsupported Modes
-
-Void-managed Better Auth is supported only for Cloudflare Void apps in v1.
-
-- meta-framework mode should use Better Auth's official framework integrations directly
-- `target: "node" | "bun" | "deno"` should use Better Auth directly

package/skills/void/docs/guide/database/d1.md

@@ -4,26 +4,11 @@ outline: deep
 
 # D1 (SQLite)
 
-[Cloudflare D1](https://developers.cloudflare.com/d1/) is a serverless SQLite database distributed across Cloudflare's network. Void manages it for you, so there is no setup, no connection string, and no separate local database configuration during development.
-
-## When to Use D1
-
-D1 is the default database for Void apps and a great choice when you want zero-config database access:
-
-- **Prototyping:** start building immediately with no external database to provision
-- **Read-heavy apps:** optimized for read workloads at the edge
-- **Small to medium scale:** a good fit for apps that do not need advanced SQL features such as stored procedures or complex joins
-- **Simplicity:** Void creates, migrates, and manages the D1 instance for you
-
-For write-heavy workloads, complex queries, or connecting to existing infrastructure, see [PostgreSQL](./postgresql).
-
-## Configuration
-
-None. D1 is the default dialect, so you can start by defining your schema and querying.
+[Cloudflare D1](https://developers.cloudflare.com/d1/) is Void's default SQLite database. Start with a [schema](../database.md#schema-definition); Void manages the database locally and when you deploy.
 
 ## Read replication
 
-Void enables [D1 read replication](https://developers.cloudflare.com/d1/best-practices/read-replication/) when it provisions a database. For a database that was already configured before this feature, run `void deploy --platform cloudflare --provision` once to enable it. Queries through `db` from `void/db` use a D1 session for each Void request, so reads can run near the request and later queries in that request see at least the same data. Framework handlers without Void's request scope start each database operation on the primary. `createDb` starts a replica-capable session for the binding you pass it.
+Void enables [D1 read replication](https://developers.cloudflare.com/d1/best-practices/read-replication/) when it provisions a database. To enable it on an existing database, run `void deploy --platform cloudflare --provision`. Queries through `db` from `void/db` use a D1 session for each Void request, so reads can run near the request and later queries in that request see at least the same data. Framework handlers without Void's request scope start each database operation on the primary. `createDb` starts a replica-capable session for the binding you pass it.
 
 Replicas can lag between requests. Authentication session checks start on the primary so a revoked session is not accepted because of replica lag. If another read must start with the latest primary data, use `env.DB.withSession('first-primary')` from `cloudflare:workers`. Other query libraries and raw D1 calls need their own `withSession()` to use replicas; a bare D1 binding reads from the primary.
 
@@ -35,45 +20,15 @@ To store local data outside `.void`, set `voidPlugin({ persistTo: 'local-state'
 
 ## Migrations & Prototyping
 
-Void offers two workflows for applying schema changes.
-
-### Prototyping with `push`
-
-During development, use `void db push` to apply your schema directly to the local D1 database. It does not create migration files.
-
-```bash
-void db push
-```
-
-This diffs your Drizzle schema against the local database and applies the changes immediately. It's fast and ideal for iterating on your schema before committing to a migration.
-
-### Production migrations
-
-When you're ready to ship, generate SQL migration files from your schema:
+Use `void db push` to apply schema changes locally without creating migration files. Before deploying, generate and commit migrations:
 
-```bash
+```sh
 void db generate
+void db migrate # apply locally
+void deploy     # apply remotely and deploy
 ```
 
-This creates timestamped SQL files in `db/migrations/` that capture the diff between your schema and the last generated migration.
-
-To apply pending migrations locally:
-
-```bash
-void db migrate
-```
-
-## Deploy Workflow
-
-When you run `void deploy`:
-
-1. The app is built
-2. Migration files are collected from `db/migrations/`
-3. If the schema has drifted ahead of the migrations, you're prompted to generate and commit the new migrations
-4. Pending migrations run against the remote D1 database
-5. The new worker goes live
-
-Deploys always go through migration files. `push` is only for local development.
+See [Database commands](../../reference/cli/database.md#database) for the full workflow.
 
 ## Batch Operations
 
@@ -91,7 +46,7 @@ await db.batch([
 
 ## Alternative Query Layers
 
-While Void's Drizzle integration is the recommended approach, you can use any library that accepts a D1 binding. Import `env.DB` from `cloudflare:workers` and pass it to your library:
+Use `env.DB` from `cloudflare:workers` with another query library or the raw D1 API:
 
 ### Kysely
 
@@ -114,5 +69,5 @@ const { results } = await env.DB.prepare('SELECT * FROM users WHERE id = ?').bin
 Void still handles binding inference and deployment regardless of which query layer you use.
 
 ::: warning ⚠️ Meta framework limitation
-Some frameworks, like Nuxt and SvelteKit, do not run in workerd during dev and therefore do not support directly importing from `cloudflare:workers`.
+Nuxt and SvelteKit do not support `cloudflare:workers` imports during local development. Use `void/db` or your framework's binding access API.
 :::

package/skills/void/docs/guide/database/mysql.md

@@ -4,7 +4,7 @@ outline: deep
 
 # MySQL
 
-Void supports MySQL through [Cloudflare Hyperdrive](https://developers.cloudflare.com/hyperdrive/). You bring a MySQL-compatible database; Void provides the Drizzle runtime, local tooling, migration workflow, and deployment wiring.
+Connect your MySQL database through [Cloudflare Hyperdrive](https://developers.cloudflare.com/hyperdrive/), then define tables and query them with Drizzle. Void configures the connection and applies your migrations when you deploy.
 
 ## Configure
 

package/skills/void/docs/guide/database/postgresql.md

@@ -36,25 +36,17 @@ This connects directly to your Postgres database during local Vite development.
 
 ### 3. Deploy
 
-When deploying to a Void platform, the CLI asks for a connection string if Hyperdrive isn't configured:
+For a Void platform, deploy prompts for the connection string if needed. You can also set it with `void db set-url`. For direct Cloudflare deploys, export the production `DATABASE_URL` in your shell.
 
-```
-Your project uses PostgreSQL. Enter your connection string:
-> postgresql://user:password@host:5432/mydb?sslmode=require
-```
-
-Void provisions Hyperdrive and records its config ID. The connection string isn't written to `void.config.ts`, `void.lock.json`, or generated Worker config.
-Both `postgres://` and `postgresql://` URLs are supported, including provider-supplied query strings such as `?sslmode=require`.
-
-For a linked Void project, you can also configure the connection with `void db set-url`. For a direct Cloudflare deploy, export the production `DATABASE_URL` in your shell.
+Void provisions Hyperdrive without saving the connection string in project config. Both `postgres://` and `postgresql://` URLs are supported, including provider query strings such as `?sslmode=require`.
 
 ## Schema Definition
 
-With the `postgresql` dialect, import schema helpers from `void/schema-pg` (re-exports from `drizzle-orm/pg-core`):
+Import schema helpers from `void/schema-pg`:
 
 ```ts
 // db/schema.ts
-import { pgTable, serial, text, timestamp, boolean, doublePrecision } from 'void/schema-pg';
+import { pgTable, serial, text, timestamp, boolean } from 'void/schema-pg';
 
 export const users = pgTable('users', {
   id: serial('id').primaryKey(),
@@ -86,20 +78,7 @@ void db status
 
 The main difference is that PostgreSQL supports **transactional DDL**. Each migration is wrapped in `BEGIN` and `COMMIT`, so a failure rolls back the whole migration instead of leaving the database half-updated.
 
-## Deploy Workflow
-
-When deploying a PostgreSQL project to a Void platform:
-
-1. The app is built
-2. Migration files are collected from `db/migrations/`
-3. If Hyperdrive hasn't been provisioned yet, you're prompted for the connection string
-4. Pending migrations run inside the deployed worker via Hyperdrive
-5. The new worker goes live
-
-When deploying to your own account with `void deploy --platform cloudflare`, export the production
-connection string as `DATABASE_URL`. Void uses it to provision Hyperdrive and apply the checked-in
-migrations transactionally before it uploads the Worker. The connection string is not written to
-`void.config.ts`, `void.lock.json`, or the generated Worker config.
+`void deploy` applies pending migrations before making the new version live. See [Deployment](../deployment.md).
 
 ## Updating the Connection String
 

package/skills/void/docs/guide/database.md

@@ -39,16 +39,13 @@ Define your tables in TypeScript, then query them with `db` from `void/db`. Void
 
 ## Choosing a Dialect
 
-Void supports three database backends. All use the same Drizzle-based workflow for schema definition, querying, and migrations.
+Choose a database during `void init`, or set `database` in `void.config.ts`:
 
-`void init` can start you with D1, PostgreSQL, MySQL, or no database yet. D1 stays implicit; PostgreSQL writes `"database": "pg"`; MySQL writes `"database": "mysql"`.
-
-|            | [D1 (SQLite)](./database/d1) | [PostgreSQL](./database/postgresql) | [MySQL](./database/mysql)     |
-| ---------- | ---------------------------- | ----------------------------------- | ----------------------------- |
-| Config     | Default                      | `"database": "pg"`                  | `"database": "mysql"`         |
-| Managed by | Void                         | Bring your own database             | Bring your own database       |
-| Best for   | Prototypes, read-heavy apps  | Complex queries, existing Postgres  | Existing MySQL infrastructure |
-| Connection | Automatic D1 binding         | Hyperdrive                          | Hyperdrive                    |
+|            | [D1 (SQLite)](./database/d1) | [PostgreSQL](./database/postgresql) | [MySQL](./database/mysql) |
+| ---------- | ---------------------------- | ----------------------------------- | ------------------------- |
+| Config     | Default                      | `"database": "pg"`                  | `"database": "mysql"`     |
+| Managed by | Void                         | Bring your own database             | Bring your own database   |
+| Connection | Automatic D1 binding         | Hyperdrive                          | Hyperdrive                |
 
 ## Schema Definition
 
@@ -235,25 +232,15 @@ const usersWithPosts = await db.query.users.findMany({
 });
 ```
 
-The user schema is automatically loaded into the `db` instance via a Vite plugin, so relational queries work out of the box.
-
 ::: warning ⚠️ Nuxt and Analog limitations
-Nuxt and Analog use Nitro, which bundles server routes outside of Vite's plugin pipeline. The schema cannot be injected into the `db` instance, so `db.query.*` relational queries are not available in Nuxt and Analog. Use the standard query builder API (`db.select().from(table)`) instead.
+In Nuxt and Analog, use the query builder (`db.select().from(table)`). The `db.query.*` relational API is not available in these frameworks.
 :::
 
 ## Seeding
 
 Use `void db seed` to reset your local database, re-apply migrations, and then run a seed file.
 
-Void resolves default seed files in this order:
-
-1. `db/seed.ts`
-2. `db/seed.mts`
-3. `db/seed.js`
-4. `db/seed.mjs`
-5. `db/seed.sql`
-
-If more than one default seed file exists, pass `--file <path>` explicitly.
+Use `db/seed.ts` for a programmatic seed or `db/seed.sql` for SQL. JavaScript and `.mts` / `.mjs` files also work. If more than one seed file exists, choose one with `--file <path>`.
 
 ### Programmatic seeding
 
@@ -274,7 +261,7 @@ export default defineSeed<typeof import('./schema')>(async ({ db, schema }) => {
 
 The seed context includes:
 
-- `dialect`: `"sqlite"` or `"postgresql"`
+- `dialect`: `"sqlite"`, `"postgresql"`, or `"mysql"`
 - `db`: a Drizzle instance for the local database
 - `schema`: the exports from your `db/schema.ts` or `db/schema/` modules
 
@@ -288,25 +275,14 @@ INSERT INTO messages (text) VALUES ('Hello from SQL');
 
 ## Schema-Derived Validators
 
-You can derive request validators from your Drizzle tables with [`void/drizzle-zod`](../reference/api.md#user-facing-imports), [`void/drizzle-valibot`](../reference/api.md#user-facing-imports), or [`void/drizzle-arktype`](../reference/api.md#user-facing-imports). These adapters use Void's bundled Drizzle version, keeping the validators compatible with your table types.
+Derive request validators from your tables with `void/drizzle-zod`, `void/drizzle-valibot`, or `void/drizzle-arktype`. Add the validator after your table definition:
 
 ::: code-group
 
 ```ts [Zod]
 // db/schema.ts
-import { sqliteTable, text, integer } from 'void/schema-d1';
-import { sql } from 'void/db';
 import { createInsertSchema } from 'void/drizzle-zod';
 
-export const users = sqliteTable('users', {
-  id: integer('id').primaryKey({ autoIncrement: true }),
-  name: text('name').notNull(),
-  email: text('email').notNull(),
-  createdAt: text('created_at')
-    .notNull()
-    .default(sql`(datetime('now'))`),
-});
-
 export const insertUserSchema = createInsertSchema(users, {
   name: (schema) => schema.min(1),
   email: (schema) => schema.email(),
@@ -315,20 +291,9 @@ export const insertUserSchema = createInsertSchema(users, {
 
 ```ts [Valibot]
 // db/schema.ts
-import { sqliteTable, text, integer } from 'void/schema-d1';
-import { sql } from 'void/db';
 import { createInsertSchema } from 'void/drizzle-valibot';
 import { pipe, minLength, email } from 'valibot';
 
-export const users = sqliteTable('users', {
-  id: integer('id').primaryKey({ autoIncrement: true }),
-  name: text('name').notNull(),
-  email: text('email').notNull(),
-  createdAt: text('created_at')
-    .notNull()
-    .default(sql`(datetime('now'))`),
-});
-
 export const insertUserSchema = createInsertSchema(users, {
   name: (schema) => pipe(schema, minLength(1)),
   email: (schema) => pipe(schema, email()),
@@ -337,20 +302,9 @@ export const insertUserSchema = createInsertSchema(users, {
 
 ```ts [ArkType]
 // db/schema.ts
-import { sqliteTable, text, integer } from 'void/schema-d1';
-import { sql } from 'void/db';
 import { createInsertSchema } from 'void/drizzle-arktype';
 import { type } from 'arktype';
 
-export const users = sqliteTable('users', {
-  id: integer('id').primaryKey({ autoIncrement: true }),
-  name: text('name').notNull(),
-  email: text('email').notNull(),
-  createdAt: text('created_at')
-    .notNull()
-    .default(sql`(datetime('now'))`),
-});
-
 export const insertUserSchema = createInsertSchema(users, {
   name: type('string > 0'),
   email: type('string.email'),
@@ -397,35 +351,29 @@ npm install arktype
 
 ## CLI Commands
 
-| Command            | Purpose                                                         |
-| ------------------ | --------------------------------------------------------------- |
-| `void db push`     | Apply schema directly to local database (no migration files)    |
-| `void db connect`  | Connect or provision PostgreSQL/MySQL and save `DATABASE_URL`   |
-| `void db generate` | Generate app and Better Auth SQL migrations for production      |
-| `void db migrate`  | Apply pending migrations locally                                |
-| `void db status`   | Show schema drift and pending migrations                        |
-| `void db reset`    | Drop the local DB and re-apply all migrations                   |
-| `void db seed`     | Reset + run seed file (`--file <path>`)                         |
-| `void db execute`  | Run ad-hoc SQL against local DB (`--file <path>`)               |
-| `void db studio`   | Open Drizzle Studio for the local database                      |
-| `void db export`   | Dump local DB as SQL (`--output`, `--no-data`, `--no-schema`)   |
-| `void db set-url`  | Update the PostgreSQL or MySQL connection string for deployment |
-
-See the [CLI reference](../reference/cli.md#database) for details.
+| Command            | Purpose                                              |
+| ------------------ | ---------------------------------------------------- |
+| `void db push`     | Apply schema changes locally without migration files |
+| `void db generate` | Generate SQL migrations                              |
+| `void db migrate`  | Apply pending migrations locally                     |
+| `void db status`   | Check schema drift and pending migrations            |
+| `void db seed`     | Reset the local database and run a seed file         |
+
+See the [CLI reference](../reference/cli/database.md#database) for connection setup, SQL execution, Studio, exports, and other commands.
 
 ## Scaffolding
 
 The `void gen model` command generates dialect-appropriate `sqliteTable`, `pgTable`, or `mysqlTable` definitions.
 
 ```bash
-void gen model post title:string body:text published:boolean
+void gen model posts title:string body:text published:boolean
 ```
 
 This creates:
 
-1. `db/schema/post.ts`: a Drizzle table definition with `id`, `createdAt`, `updatedAt`, and your columns
-2. Updates `db/schema.ts` with `export * from "./schema/post"`
+1. `db/schema/posts.ts`: a Drizzle table definition with `id`, `createdAt`, `updatedAt`, and your columns
+2. Updates `db/schema.ts` with `export * from "./schema/posts"`
 3. `routes/api/posts/index.ts`: `GET` for list and `POST` for insert with validation
 4. `routes/api/posts/[id].ts`: `GET` by id with `404` handling
 
-See the [CLI reference](../reference/cli.md#code-generation) for the full list of generators.
+See the [CLI reference](../reference/cli/generate.md#code-generation) for the full list of generators.