RC3 codegen cannot load a real Next.js stack config

[olliethedev]

Summary

@btst/codegen@0.2.0-rc.3 cannot generate the Drizzle schema from the RC3 validation app's normal Next.js stack config. The wrapper delegates to an isolated npx @btst/cli@2.2.3 process that does not reproduce the application's module resolution.

Reproduction

CI=true corepack pnpm@10.17.1 dlx @btst/codegen@0.2.0-rc.3 generate -- \
  --config lib/stack.ts \
  --output db/btst-schema.ts \
  --orm drizzle \
  --yes

The stack uses the RC3 server authorization split and imports its server module through lib/stack.ts.

Failures observed

1. With the normal Next.js server marker:

Cannot find module 'server-only'

Adding the marker package explicitly changes this to its intentional outside-RSC error:

This module cannot be imported from a Client Component module. It should only be used from a Server Component.

2. Temporarily removing the marker reaches the next loader incompatibility:

Cannot find module '@/lib/auth'
Require stack: lib/stack-authorization.server.ts

The CLI does not resolve the app's TypeScript path aliases.

3. Changing that import to a relative path and supplying the full environment reaches the isolated delegated install, then fails even though the app directly installs drizzle-orm@0.45.2:

ERR_MODULE_NOT_FOUND: Cannot find package 'drizzle-orm' imported from
~/.npm/_npx/.../node_modules/@better-auth/drizzle-adapter/dist/index.mjs

The wrapper prints:

Delegating to: npx --yes @btst/cli@2.2.3 generate ...

Expected

RC3 codegen should load the same config that Next.js and TypeScript load, including standard server-only markers and tsconfig path aliases, and its delegated CLI should resolve ORM peers from the application. Schema generation should not require temporarily weakening server boundaries, rewriting imports, or adding duplicate packages to an isolated npx environment.

Impact

The RC3 media schema added updatedAt fields for both mediaAsset and mediaFolder, but codegen could not produce the update. The validation app had to inspect the published RC3 schema and add those fields manually before generating the Drizzle migration.

[olliethedev]

Bio Mogging confirms the RC3 codegen loader defect on the Prisma path as well.

Final reproduction from the retained Next.js + Prisma application:

CI=true corepack pnpm@10.17.1 dlx @btst/codegen@0.2.0-rc.3 generate -- \
  --config lib/stack.ts \
  --output /tmp/bio-mogging-btst-v3-rc3-schema.prisma \
  --orm prisma \
  --yes

The wrapper delegates to npx --yes @btst/cli@2.2.3, then fails loading the normal application graph:

Failed to load schema: Cannot find module `@/lib/contact`
Require stack:
- /home/deck/Projects/bio-mogging/lib/email-client.ts

This reproduction does not import the server-only marker, so the unresolved tsconfig alias alone is sufficient to block Prisma generation. Next.js production build, tsx Prisma seeds, Prisma Client generation, and TypeScript all load the same application graph successfully. The application therefore had to inspect the published RC3 schema and check in the Better Auth issuer plus Media updatedAt migration manually.

[olliethedev]

Completed by Better Auth PR #48, release hardening PR #49 and PR #50, plus Better Stack PR #250.

Release and acceptance evidence:

• @btst/cli@2.2.4 is public on latest from tag btst-cli-v2.2.4 at 9ab86f2fe4ddf69e2c8749620e16fb4dd355d53b.
• Trusted-publishing run 33449661032 passed.
• npm integrity: sha512-YcuHD1dJs3Wfl1gfJQfc3iS4MPRlPz9WtWBRDgtLdNXzk5TWqW0T57uM3Jqw+BEf9LWz7TvZMJMUk1qJI8OzNQ==; shasum: b39b1358f5df7aea0546239fc870c17d94fa95d0.
• The CLI now loads normal consumer aliases, environment variables, server-only configs, and consumer ORM peers while preserving the Better Auth 1.6.16 database cohort.
• Better Stack delegates to the exact 2.2.4 CLI without adding it to the consumer dependency graph.
• Next.js, React Router, and TanStack codegen E2E passed, and the rerun init smoke passed against the public CLI.

All acceptance criteria are satisfied.