@opensaas/stack-auth 0.21.0 → 0.23.0

package/.turbo/turbo-build.log

@@ -1,4 +1,4 @@
 
-> @opensaas/stack-auth@0.21.0 build /home/runner/work/stack/stack/packages/auth
+> @opensaas/stack-auth@0.23.0 build /home/runner/work/stack/stack/packages/auth
 > tsc
 

package/CHANGELOG.md

@@ -1,5 +1,97 @@
 # @opensaas/stack-auth
 
+## 0.23.0
+
+## 0.22.0
+
+### Minor Changes
+
+- [#509](https://github.com/OpenSaasAU/stack/pull/509) [`fdc48f8`](https://github.com/OpenSaasAU/stack/commit/fdc48f86a5a7f161bef0b512963e1511a8c8e00e) Thanks [@list({](https://github.com/list({)! - Add `adoptBetterAuthTables()` recipe for adopting an existing better-auth installation
+
+  A migrating project that already runs better-auth (its `AuthUser`/`AuthSession`/`AuthAccount`/`AuthVerification` tables live in a separate `auth` Postgres schema, and its app `User` is a different model) can now adopt those live tables without rebuilding the auth config by hand. The recipe presets the plugin-level `schema` plus each model's `modelName` (and optional column `fields` maps) to the conventions of a standard separate-schema better-auth install, so the derived Auth lists diff clean (Schema parity) against the live database — no destructive auth migration. The app's own domain `User` is left untouched; linking it to the Auth identity is the application's concern.
+
+  ```typescript
+  import { config } from '@opensaas/stack-core'
+  import { authPlugin, adoptBetterAuthTables } from '@opensaas/stack-auth'
+
+  export default config({
+    db: { provider: 'postgresql', url: process.env.DATABASE_URL },
+    plugins: [
+      authPlugin({
+        // Defaults: AuthUser/AuthSession/AuthAccount/AuthVerification in the
+        // `auth` schema, pinned to your live table names (@@map) + schema (@@schema).
+        ...adoptBetterAuthTables(),
+        emailAndPassword: { enabled: true },
+      }),
+    ],
+    lists: {
+      // Your own domain User stays in `public` and is NOT touched by the plugin.
+   fields: { subjectId: text({ validation: { isRequired: true } }) } }),
+    },
+  })
+
+  // Customise when your live tables diverge from the defaults:
+  adoptBetterAuthTables({
+    schema: 'identity', // default: 'auth'
+    modelNamePrefix: 'BA', // default: 'Auth'
+    fields: { user: { name: 'full_name' }, session: { userId: 'user_id' } },
+  })
+  ```
+
+- [#497](https://github.com/OpenSaasAU/stack/pull/497) [`be4181a`](https://github.com/OpenSaasAU/stack/commit/be4181ada3f2d6386052df4d4869ad150d360f89) Thanks [@{](https://github.com/{)! - Derive the auth plugin's Auth lists from the better-auth config
+
+  `authPlugin` now mirrors the better-auth config a developer writes instead of hardcoding the keys `User`/`Session`/`Account`/`Verification`. Per-model `modelName` becomes the OpenSaaS list key (and a table `@@map`), and the `fields` column map becomes per-field `@map`s. The plugin only ever adds/extends its own derived keys, so an app's separate domain `User` is never overwritten. The runtime `getUser`/`getCurrentUser` helpers now resolve the user list key from the configured user model instead of a hardcoded `'user'`.
+
+  Default behaviour (no overrides) is unchanged: the lists are still keyed `User`/`Session`/`Account`/`Verification` with the original field shapes and no `@@map`.
+
+  ```typescript
+  // Adopt existing better-auth tables without a destructive migration
+  authPlugin({
+   modelName: 'AuthUser', fields: { name: 'full_name' } },
+    session: { modelName: 'AuthSession', fields: { userId: 'user_id' } },
+    account: { modelName: 'AuthAccount' },
+    verification: { modelName: 'AuthVerification' },
+  })
+  // -> lists keyed AuthUser/AuthSession/AuthAccount/AuthVerification
+  //    with @@map + column @map matching the live tables
+  ```
+
+  Lists also gain a model-level `db.map` option, which emits a `@@map("...")` on the generated Prisma model so a list key can differ from its physical table name.
+
+- [#502](https://github.com/OpenSaasAU/stack/pull/502) [`593390c`](https://github.com/OpenSaasAU/stack/commit/593390c57d9844ca7ada8f45b340c849f1d8d647) Thanks [@{](https://github.com/{)! - Add `authPlugin` schema placement so Auth lists can adopt an existing non-`public` better-auth layout (clean-diff adoption)
+
+  The auth lists can now be placed in a non-`public` Postgres schema (e.g. `auth`) so they diff CLEAN against a separate-schema better-auth installation. A plugin-level `schema` option applies `@@schema(...)` to all generated Auth lists, with a per-list override.
+
+  ```typescript
+  authPlugin({
+    schema: 'auth', // all Auth lists get @@schema("auth")
+   modelName: 'AuthUser' },
+    session: { modelName: 'AuthSession' },
+    account: { modelName: 'AuthAccount' },
+    // per-model override: relocate one list to a different schema
+    verification: { modelName: 'AuthVerification', schema: 'auth_internal' },
+  })
+  ```
+
+  The plugin's `beforeGenerate` hook wires the datasource `schemas` array (always including `public`) and defaults any list without an explicit `db.schema` to `public`, producing a valid multi-schema Prisma schema. With no `schema` option the output is unchanged (greenfield default stays in `public`, no `@@schema`).
+
+  Core support added for this (mirroring the `db.map` → `@@map` work):
+  - List-level `db.schema` → the Prisma generator emits `@@schema("...")` on the model.
+  - Database-level `db.schemas` → the generator emits the datasource `schemas = [...]` array and enables the `multiSchema` preview feature.
+
+  ```typescript
+  // Core/generator building blocks
+  db: { provider: 'postgresql', schemas: ['public', 'auth'] }
+  AuthUser: list({ fields: { ... }, db: { map: 'AuthUser', schema: 'auth' } })
+  // Generates: model AuthUser { ... @@map("AuthUser") @@schema("auth") }
+  ```
+
+### Patch Changes
+
+- [#501](https://github.com/OpenSaasAU/stack/pull/501) [`e30f6a1`](https://github.com/OpenSaasAU/stack/commit/e30f6a1ef69dc65ae68b37539fa74c3f97823cfd) Thanks [@borisno2](https://github.com/borisno2)! - Keep `createdAt`/`updatedAt` on the auth lists now that auto-timestamps are off by default
+
+  The derived auth lists (User/Session/Account/Verification) now opt into `db: { timestamps: true }`. better-auth's adapter writes those columns and the schema converter returns `null` for them assuming the generator injects them, so the opt-in keeps the generated auth models intact.
+
 ## 0.21.0
 
 ### Minor Changes

package/CLAUDE.md

@@ -62,6 +62,104 @@ config({
 // Result: { lists: { User, Session, Account, Verification, Post } }
 ```
 
+### Deriving Auth lists from better-auth config
+
+The four Auth lists are **derived** from the better-auth model config the
+developer writes — not hardcoded. The pure derivation lives in
+`src/config/derive-auth-lists.ts` (`deriveAuthLists`), which `getAuthLists`
+and the plugin's add-vs-extend logic consume:
+
+- per-model `modelName` → list key + table `@@map`
+- per-model `fields` (better-auth field → column) → field-level `@map`
+- the `userId` column override → the `user` relationship foreign-key `@map`
+- relationship refs between the Auth lists follow the derived keys
+  (e.g. `Session.user → AuthUser.sessions`)
+
+With no `modelName`/`fields` overrides the output is unchanged
+(`User`/`Session`/`Account`/`Verification`, original field shapes, no `@@map`).
+
+```typescript
+// Adopt an existing better-auth installation (Auth lists ≠ app User)
+authPlugin({
+  user: { modelName: 'AuthUser', fields: { name: 'full_name' } },
+  session: { modelName: 'AuthSession', fields: { userId: 'user_id' } },
+})
+// Adds AuthUser/AuthSession/... and leaves an app's own `User` untouched.
+```
+
+Because the plugin only ever adds/extends its **derived** keys, an app's own
+domain `User` (a different model from the better-auth user) is never extended
+or overwritten when the user model is renamed. The runtime `getUser`/
+`getCurrentUser` helpers resolve the user list's `context.db` key from the
+configured user `modelName`.
+
+### Schema placement (relocatable Auth lists)
+
+A plugin-level `schema` option places all generated Auth lists in a non-`public`
+Postgres schema via `@@schema(...)`, so they can adopt a separate-schema
+better-auth layout (e.g. an `auth` schema) and reach **Schema parity** with the
+live tables. Combined with the derived keys/`@@map`/field `@map`s above, the
+generated lists diff CLEAN against an existing `auth`-schema install — they are
+modelled for runtime/types without producing a migration.
+
+```typescript
+authPlugin({
+  schema: 'auth', // all Auth lists get @@schema("auth")
+  user: { modelName: 'AuthUser' },
+  session: { modelName: 'AuthSession' },
+  account: { modelName: 'AuthAccount' },
+  verification: { modelName: 'AuthVerification' },
+  // per-model override: relocate one list to a different schema
+  // verification: { modelName: 'AuthVerification', schema: 'auth_internal' },
+})
+```
+
+How it wires up (Postgres multi-schema):
+
+- Each Auth list gets a list-level `db.schema` → `@@schema(...)` (per-model
+  `schema` override, else the plugin-level `schema`).
+- The plugin's `beforeGenerate` hook adds the auth schema(s) (always plus
+  `public`) to the datasource `db.schemas` array and defaults any list without
+  an explicit `db.schema` to `public`, so the generated multi-schema Prisma
+  schema is valid (the generator emits `previewFeatures = ["multiSchema"]` and
+  `schemas = [...]`).
+- With no `schema` option the Auth lists stay in `public` and no `@@schema` /
+  `schemas` / preview feature is emitted (greenfield default unchanged).
+
+### Adopting an existing better-auth install (`adoptBetterAuthTables`)
+
+`adoptBetterAuthTables()` (`src/config/adopt-better-auth-tables.ts`) is a thin
+recipe that returns the `AuthConfig` adoption knobs — the plugin-level `schema`
+plus a per-model `modelName` (and optional column `fields` maps) — preset to the
+conventions of a standard separate-schema better-auth install. It ties together
+the keys/field derivation and schema placement so a migrator doesn't rebuild the
+config by hand. Spread it into `authPlugin`:
+
+```typescript
+import { authPlugin, adoptBetterAuthTables } from '@opensaas/stack-auth'
+
+authPlugin({
+  ...adoptBetterAuthTables(), // schema: 'auth', AuthUser/AuthSession/AuthAccount/AuthVerification
+  emailAndPassword: { enabled: true },
+})
+// Options: adoptBetterAuthTables({ schema, modelNamePrefix, fields })
+```
+
+It is pure config (no side effects): everything it sets can also be written
+directly on `authPlugin`, and spreading it before your own keys lets you
+override per model. Because the derived user key is `AuthUser` (not `User`), an
+app's own domain `User` is left untouched — the plugin only ever adds/extends
+its derived keys. Combined with the derivation + schema placement above, the
+generated Auth lists reach **Schema parity** (clean `schema:diff`) against a live
+`auth`-schema install — they are modelled for runtime/types, not migrated.
+
+**App User ≠ Auth identity.** The plugin models the **Auth identity** (the
+better-auth user); it does not assume that list is the app's domain `User`.
+Linking an app's `User` to the Auth identity (e.g. a `relationship({ ref:
+'AuthUser' })` the app declares) is the application's concern. See the
+[Authentication guide](../../docs/content/guides/authentication.md) (“Adopting an
+existing better-auth installation”) for the end-to-end migrator walkthrough.
+
 ### Session Provider
 
 Better-auth provides session to context via custom `prismaClientConstructor`:

package/README.md

@@ -203,6 +203,39 @@ authPlugin({
 })
 ```
 
+## Adopting an Existing better-auth Installation
+
+Migrating a project that **already runs better-auth**? The plugin can adopt your
+live tables rather than recreating them, so there's no destructive auth
+migration. Use the `adoptBetterAuthTables()` recipe to preset the model/schema
+knobs that match a standard separate-schema better-auth install:
+
+```typescript
+import { authPlugin, adoptBetterAuthTables } from '@opensaas/stack-auth'
+
+authPlugin({
+  // Defaults: AuthUser/AuthSession/AuthAccount/AuthVerification in the `auth`
+  // Postgres schema — pinned to your live table names + schema (@@map/@@schema).
+  ...adoptBetterAuthTables(),
+  emailAndPassword: { enabled: true },
+})
+
+// Customise when your live tables diverge from the defaults:
+adoptBetterAuthTables({
+  schema: 'identity', // default: 'auth'
+  modelNamePrefix: 'BA', // default: 'Auth' (→ AuthUser/AuthSession/…)
+  fields: { user: { name: 'full_name' }, session: { userId: 'user_id' } },
+})
+```
+
+**App `User` vs the Auth identity.** The plugin models the **Auth identity** (the
+better-auth user, e.g. `AuthUser`). It does not assume that list is your app's
+own domain `User` — when the keys differ, your `User` is never extended or
+overwritten. **Linking your domain `User` to the Auth identity is your app's
+concern** (declare a `relationship({ ref: 'AuthUser' })` on your `User`). See the
+[Authentication guide](https://stack.opensaas.au/docs/guides/authentication) for
+the full migrator walkthrough and a Schema-parity (clean-diff) check.
+
 ## UI Components
 
 ### SignInForm

package/dist/config/adopt-better-auth-tables.d.ts

@@ -0,0 +1,107 @@
+/**
+ * "Adopt existing better-auth tables" recipe.
+ *
+ * A migrating project usually already has a working, hand-wired better-auth
+ * installation: its tables are `AuthUser`/`AuthSession`/`AuthAccount`/
+ * `AuthVerification`, mapped into a separate `auth` Postgres schema, and its
+ * application `User` (`public.User`) is a *different* model. Reconstructing the
+ * matching {@link AuthConfig} by hand — four `modelName`s plus a `schema` on each
+ * model — is repetitive and easy to get wrong.
+ *
+ * {@link adoptBetterAuthTables} produces that {@link AuthConfig} fragment from a
+ * couple of options so the migrator doesn't rebuild it from scratch. It only
+ * sets the *adoption* knobs (per-model `modelName` + the plugin-level `schema`);
+ * the developer composes it with the rest of their auth config (providers,
+ * session fields, `extendUserList`, etc.):
+ *
+ * ```typescript
+ * authPlugin({
+ *   ...adoptBetterAuthTables(),
+ *   emailAndPassword: { enabled: true },
+ *   sessionFields: ['userId', 'email', 'name'],
+ * })
+ * ```
+ *
+ * Combined with the keys/field derivation (`deriveAuthLists`) and schema
+ * placement, the generated Auth lists reach **Schema parity** with the live
+ * tables — they are modelled for runtime/types without producing a destructive
+ * auth migration. The recipe never touches the application's own domain `User`:
+ * its model names are `Auth`-prefixed by default and the plugin only ever
+ * adds/extends its *derived* keys.
+ */
+import type { AuthConfig } from './types.js';
+/**
+ * Options for {@link adoptBetterAuthTables}.
+ *
+ * All options are optional and default to the conventions of a standard
+ * separate-schema better-auth install (an `auth` Postgres schema with
+ * `Auth`-prefixed model names).
+ */
+export type AdoptBetterAuthTablesOptions = {
+    /**
+     * The Postgres schema the live better-auth tables live in.
+     *
+     * Applied as the plugin-level {@link AuthConfig.schema}, placing every Auth
+     * list in this schema via `@@schema(...)`. Pass `'public'` (or any single
+     * schema) for an install that is not on a separate schema; pass an explicit
+     * value to match your layout.
+     *
+     * @default 'auth'
+     */
+    schema?: string;
+    /**
+     * Prefix applied to each better-auth model name to derive the list key /
+     * table name (e.g. prefix `'Auth'` → `AuthUser`/`AuthSession`/...).
+     *
+     * A live better-auth install with `modelName: 'AuthUser'` etc. is the common
+     * case; override this if your tables use a different prefix. Set to `''` to
+     * keep the default better-auth names (`User`/`Session`/...) — but note that an
+     * unprefixed `User` will share the app's `User` key, so prefer a prefix when
+     * your domain `User` is a separate model (see {@link AuthConfig.user}).
+     *
+     * @default 'Auth'
+     */
+    modelNamePrefix?: string;
+    /**
+     * Per-model better-auth field → column maps, keyed by model.
+     *
+     * Only needed when your live tables renamed columns away from the better-auth
+     * defaults (e.g. `name → full_name`). Merged into the matching model config so
+     * the derived field-level `@map`s match your live columns.
+     *
+     * @example
+     * ```typescript
+     * adoptBetterAuthTables({
+     *   fields: {
+     *     user: { name: 'full_name' },
+     *     session: { userId: 'user_id' },
+     *   },
+     * })
+     * ```
+     */
+    fields?: {
+        user?: Record<string, string>;
+        session?: Record<string, string>;
+        account?: Record<string, string>;
+        verification?: Record<string, string>;
+    };
+};
+/**
+ * The adoption-relevant slice of {@link AuthConfig}: the plugin-level `schema`
+ * and the per-model `modelName`/`fields`. Returned (not the full `AuthConfig`)
+ * so it spreads cleanly into the developer's own `authPlugin` config.
+ */
+export type AdoptBetterAuthTablesConfig = Pick<AuthConfig, 'schema' | 'user' | 'session' | 'account' | 'verification'>;
+/**
+ * Build the adoption {@link AuthConfig} fragment for a pre-existing better-auth
+ * installation.
+ *
+ * Returns only the model/schema knobs needed to adopt the live tables; spread it
+ * into {@link authPlugin} alongside your own auth config.
+ *
+ * @param options - Adoption conventions (schema, model-name prefix, column maps)
+ * @returns An {@link AuthConfig} fragment with `schema` + per-model `modelName`
+ *   (and any field column maps) set to match the live tables
+ */
+export declare function adoptBetterAuthTables(options?: AdoptBetterAuthTablesOptions): AdoptBetterAuthTablesConfig;
+//# sourceMappingURL=adopt-better-auth-tables.d.ts.map

package/dist/config/adopt-better-auth-tables.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"adopt-better-auth-tables.d.ts","sourceRoot":"","sources":["../../src/config/adopt-better-auth-tables.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA8BG;AAEH,OAAO,KAAK,EAAE,UAAU,EAAmB,MAAM,YAAY,CAAA;AAE7D;;;;;;GAMG;AACH,MAAM,MAAM,4BAA4B,GAAG;IACzC;;;;;;;;;OASG;IACH,MAAM,CAAC,EAAE,MAAM,CAAA;IAEf;;;;;;;;;;;OAWG;IACH,eAAe,CAAC,EAAE,MAAM,CAAA;IAExB;;;;;;;;;;;;;;;;OAgBG;IACH,MAAM,CAAC,EAAE;QACP,IAAI,CAAC,EAAE,MAAM,CAAC,MAAM,EAAE,MAAM,CAAC,CAAA;QAC7B,OAAO,CAAC,EAAE,MAAM,CAAC,MAAM,EAAE,MAAM,CAAC,CAAA;QAChC,OAAO,CAAC,EAAE,MAAM,CAAC,MAAM,EAAE,MAAM,CAAC,CAAA;QAChC,YAAY,CAAC,EAAE,MAAM,CAAC,MAAM,EAAE,MAAM,CAAC,CAAA;KACtC,CAAA;CACF,CAAA;AAUD;;;;GAIG;AACH,MAAM,MAAM,2BAA2B,GAAG,IAAI,CAC5C,UAAU,EACV,QAAQ,GAAG,MAAM,GAAG,SAAS,GAAG,SAAS,GAAG,cAAc,CAC3D,CAAA;AAED;;;;;;;;;;GAUG;AACH,wBAAgB,qBAAqB,CACnC,OAAO,GAAE,4BAAiC,GACzC,2BAA2B,CAqB7B"}

package/dist/config/adopt-better-auth-tables.js

@@ -0,0 +1,70 @@
+/**
+ * "Adopt existing better-auth tables" recipe.
+ *
+ * A migrating project usually already has a working, hand-wired better-auth
+ * installation: its tables are `AuthUser`/`AuthSession`/`AuthAccount`/
+ * `AuthVerification`, mapped into a separate `auth` Postgres schema, and its
+ * application `User` (`public.User`) is a *different* model. Reconstructing the
+ * matching {@link AuthConfig} by hand — four `modelName`s plus a `schema` on each
+ * model — is repetitive and easy to get wrong.
+ *
+ * {@link adoptBetterAuthTables} produces that {@link AuthConfig} fragment from a
+ * couple of options so the migrator doesn't rebuild it from scratch. It only
+ * sets the *adoption* knobs (per-model `modelName` + the plugin-level `schema`);
+ * the developer composes it with the rest of their auth config (providers,
+ * session fields, `extendUserList`, etc.):
+ *
+ * ```typescript
+ * authPlugin({
+ *   ...adoptBetterAuthTables(),
+ *   emailAndPassword: { enabled: true },
+ *   sessionFields: ['userId', 'email', 'name'],
+ * })
+ * ```
+ *
+ * Combined with the keys/field derivation (`deriveAuthLists`) and schema
+ * placement, the generated Auth lists reach **Schema parity** with the live
+ * tables — they are modelled for runtime/types without producing a destructive
+ * auth migration. The recipe never touches the application's own domain `User`:
+ * its model names are `Auth`-prefixed by default and the plugin only ever
+ * adds/extends its *derived* keys.
+ */
+/** The four better-auth models and their default (unprefixed) model names. */
+const MODEL_DEFAULT_NAMES = {
+    user: 'User',
+    session: 'Session',
+    account: 'Account',
+    verification: 'Verification',
+};
+/**
+ * Build the adoption {@link AuthConfig} fragment for a pre-existing better-auth
+ * installation.
+ *
+ * Returns only the model/schema knobs needed to adopt the live tables; spread it
+ * into {@link authPlugin} alongside your own auth config.
+ *
+ * @param options - Adoption conventions (schema, model-name prefix, column maps)
+ * @returns An {@link AuthConfig} fragment with `schema` + per-model `modelName`
+ *   (and any field column maps) set to match the live tables
+ */
+export function adoptBetterAuthTables(options = {}) {
+    const { schema = 'auth', modelNamePrefix = 'Auth', fields = {} } = options;
+    const buildModel = (model) => {
+        const config = {
+            modelName: `${modelNamePrefix}${MODEL_DEFAULT_NAMES[model]}`,
+        };
+        const fieldMap = fields[model];
+        if (fieldMap && Object.keys(fieldMap).length > 0) {
+            config.fields = fieldMap;
+        }
+        return config;
+    };
+    return {
+        schema,
+        user: buildModel('user'),
+        session: buildModel('session'),
+        account: buildModel('account'),
+        verification: buildModel('verification'),
+    };
+}
+//# sourceMappingURL=adopt-better-auth-tables.js.map

package/dist/config/adopt-better-auth-tables.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"adopt-better-auth-tables.js","sourceRoot":"","sources":["../../src/config/adopt-better-auth-tables.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA8BG;AA+DH,8EAA8E;AAC9E,MAAM,mBAAmB,GAAG;IAC1B,IAAI,EAAE,MAAM;IACZ,OAAO,EAAE,SAAS;IAClB,OAAO,EAAE,SAAS;IAClB,YAAY,EAAE,cAAc;CACpB,CAAA;AAYV;;;;;;;;;;GAUG;AACH,MAAM,UAAU,qBAAqB,CACnC,UAAwC,EAAE;IAE1C,MAAM,EAAE,MAAM,GAAG,MAAM,EAAE,eAAe,GAAG,MAAM,EAAE,MAAM,GAAG,EAAE,EAAE,GAAG,OAAO,CAAA;IAE1E,MAAM,UAAU,GAAG,CAAC,KAAuC,EAAmB,EAAE;QAC9E,MAAM,MAAM,GAAoB;YAC9B,SAAS,EAAE,GAAG,eAAe,GAAG,mBAAmB,CAAC,KAAK,CAAC,EAAE;SAC7D,CAAA;QACD,MAAM,QAAQ,GAAG,MAAM,CAAC,KAAK,CAAC,CAAA;QAC9B,IAAI,QAAQ,IAAI,MAAM,CAAC,IAAI,CAAC,QAAQ,CAAC,CAAC,MAAM,GAAG,CAAC,EAAE,CAAC;YACjD,MAAM,CAAC,MAAM,GAAG,QAAQ,CAAA;QAC1B,CAAC;QACD,OAAO,MAAM,CAAA;IACf,CAAC,CAAA;IAED,OAAO;QACL,MAAM;QACN,IAAI,EAAE,UAAU,CAAC,MAAM,CAAC;QACxB,OAAO,EAAE,UAAU,CAAC,SAAS,CAAC;QAC9B,OAAO,EAAE,UAAU,CAAC,SAAS,CAAC;QAC9B,YAAY,EAAE,UAAU,CAAC,cAAc,CAAC;KACzC,CAAA;AACH,CAAC"}

package/dist/config/derive-auth-lists.d.ts

@@ -0,0 +1,50 @@
+/**
+ * Pure `better-auth config → Auth lists` derivation.
+ *
+ * This module is intentionally free of side effects and plugin/runtime
+ * concerns: given the resolved better-auth model config (per-model `modelName`
+ * and `fields` column maps) plus any custom User fields, it produces the four
+ * OpenSaaS Auth lists (user/session/account/verification) with:
+ *
+ *  - list keys taken from each model's `modelName`
+ *  - a table `@@map` (list-level `db.map`) when the key differs from the
+ *    default better-auth model name
+ *  - field-level `@map` (`db.map`) for any better-auth field → column override
+ *  - relationship refs between the auth lists wired to the *derived* keys
+ *    (e.g. `Session.user → AuthUser.sessions`)
+ *
+ * When the developer supplies no `modelName`/`fields` overrides, the output is
+ * byte-for-byte the historical default set keyed `User`/`Session`/`Account`/
+ * `Verification` with the original field shapes — see the unit tests.
+ *
+ * `getAuthLists`/`convertBetterAuthSchema` (and the runtime user-key
+ * resolution) consume this module so derivation lives in exactly one place.
+ */
+import type { ListConfig } from '@opensaas/stack-core';
+import type { ExtendUserListConfig } from '../lists/index.js';
+import type { NormalizedAuthModels } from './types.js';
+/**
+ * The derived Auth list set together with the keys each list was placed under.
+ * Keys are surfaced separately so callers (plugin add-vs-extend logic, runtime
+ * user-key resolution) don't have to re-derive them.
+ */
+export type DerivedAuthLists = {
+    /** Derived list keys, one per better-auth model. */
+    keys: {
+        user: string;
+        session: string;
+        account: string;
+        verification: string;
+    };
+    /** The derived list configs, keyed by their derived list keys. */
+    lists: Record<string, ListConfig<any>>;
+};
+/**
+ * Derive the OpenSaaS Auth lists from the resolved better-auth model config.
+ *
+ * @param models - Resolved better-auth per-model config (modelName + field column maps)
+ * @param userConfig - Extra User-list fields/access/hooks supplied via `extendUserList`
+ * @returns The derived list keys and the four Auth list configs keyed by those keys
+ */
+export declare function deriveAuthLists(models: NormalizedAuthModels, userConfig?: ExtendUserListConfig): DerivedAuthLists;
+//# sourceMappingURL=derive-auth-lists.d.ts.map

package/dist/config/derive-auth-lists.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"derive-auth-lists.d.ts","sourceRoot":"","sources":["../../src/config/derive-auth-lists.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;GAqBG;AAIH,OAAO,KAAK,EAAE,UAAU,EAAE,MAAM,sBAAsB,CAAA;AACtD,OAAO,KAAK,EAAE,oBAAoB,EAAE,MAAM,mBAAmB,CAAA;AAC7D,OAAO,KAAK,EAA6B,oBAAoB,EAAE,MAAM,YAAY,CAAA;AAajF;;;;GAIG;AACH,MAAM,MAAM,gBAAgB,GAAG;IAC7B,oDAAoD;IACpD,IAAI,EAAE;QACJ,IAAI,EAAE,MAAM,CAAA;QACZ,OAAO,EAAE,MAAM,CAAA;QACf,OAAO,EAAE,MAAM,CAAA;QACf,YAAY,EAAE,MAAM,CAAA;KACrB,CAAA;IACD,kEAAkE;IAElE,KAAK,EAAE,MAAM,CAAC,MAAM,EAAE,UAAU,CAAC,GAAG,CAAC,CAAC,CAAA;CACvC,CAAA;AA+OD;;;;;;GAMG;AACH,wBAAgB,eAAe,CAC7B,MAAM,EAAE,oBAAoB,EAC5B,UAAU,GAAE,oBAAyB,GACpC,gBAAgB,CAiBlB"}