Upgrading Beignet

Beignet packages version together. Upgrade every installed @beignet/* package, @beignet/cli, and create-beignet to the same release instead of mixing versions across the framework.

Upgrade workflow

Read the target release notes and the migration section on this page.
Update all Beignet packages to the same version and reinstall dependencies.
Run bun beignet doctor --strict and bun beignet lint.
Run the app's typecheck, test, and production build scripts.
Exercise app-owned worker, cron, webhook, outbox, and task entrypoints that are not covered by the web build.

Generated files belong to the app after creation. Do not rerun create-beignet over an existing app or copy a fresh starter wholesale. Apply migration steps to the app's current structure and use doctor fixers only for findings explicitly marked safe.

Unreleased 1.0 stabilization changes

The current stabilization pass removes redundant pre-adoption APIs before the compatibility promise hardens.

Provider registration uses factories

Provider packages no longer export shared xProvider instances. Import and call the matching factory in server/providers.ts:

typescript

import { createRedisCacheProvider } from "@beignet/provider-cache-redis";

export const providers = [createRedisCacheProvider()] as const;

The same mechanical change applies across first-party providers, for example pinoLoggerProvider becomes createPinoLoggerProvider() and stripePaymentsProvider becomes createStripePaymentsProvider().

Framework-neutral server imports come from core

Route declarations, route registries, hooks, and framework-neutral server types come from @beignet/core/server. Runtime adapter packages expose only their platform-specific APIs:

typescript

import {
  contractsFromRoutes,
  defineRouteGroup,
  defineRoutes,
} from "@beignet/core/server";
import { createNextServer, createNextServerLoader } from "@beignet/next";

Use @beignet/web for Web Fetch conversion and server adapters. In particular, replace toNextResponse(...) with toWebResponse(...) imported from @beignet/web.

Test helpers use one subpath

Move imports from @beignet/core/ports/testing to @beignet/core/testing. Fixtures, recording adapters, actors, policy helpers, assertions, factories, seeds, and provider test installation now share that single public boundary.

Removed aliases

Removed	Replacement
`contract.pathTemplate`	`contract.path`
`defineFlagRegistry(...)`	`defineFlags(...)`
`ctx.ports.db.db`	`ctx.ports.db.drizzle`
`defineRouteGroup<AppContext>({ ... })`	`defineRouteGroup<AppContext>()({ ... })`
`toNextResponse(...)`	`toWebResponse(...)` from `@beignet/web`
`createInMemoryEventBus(...)`	`createMemoryEventBus(...)`
`createInMemoryEventBusProvider(...)`	`createMemoryEventBusProvider(...)`
`InMemoryEventBus*` types	`MemoryEventBus*` types

Getting help from the compiler

Most Beignet migrations are import or option-shape changes. TypeScript should identify every affected call site. When a removed symbol appears only in a generated registry or configuration string, beignet doctor --strict and beignet providers audit cover the registration and provider metadata that the compiler cannot inspect.

See Stability and releases for the compatibility policy.