github-starred/better-auth
2
0
Fork 0
mirror of https://github.com/better-auth/better-auth.git synced 2026-05-23 07:18:56 -05:00
Code Issues 2.5k Packages Projects Releases 112 Wiki Activity

[GH-ISSUE #8986] [Types] use const generic on betterAuth() to preserve plugin tuple types #28573

New Issue
Open
opened 2026-04-17 20:01:10 -05:00 by GiteaMirror · 0 comments
GiteaMirror commented 2026-04-17 20:01:10 -05:00
Owner
Copy Link

Originally created by @cursor[bot] on GitHub (Apr 6, 2026).
Original GitHub issue: https://github.com/better-auth/better-auth/issues/8986

Problem

plugins in BetterAuthOptions is typed as BetterAuthPlugin[] (init-options.ts#L773), so when an untyped (any) plugin is present alongside typed plugins:

const auth = betterAuth({
  plugins: [organization(), untypedPlugin], // untypedPlugin: any
});

TypeScript collapses the inferred array element type: Organization | any → any, producing any[]. This means Options["plugins"] loses all individual plugin type information before the type-level tuple walk (InferPluginFieldFromTuple) gets a chance to process each element separately.

Current mitigations (PR #8981)

PR #8981 added IsAny guards to ExtractPluginField and related utilities, which prevents the result from collapsing to any. However, because the tuple information is already lost at the BetterAuthPlugin[] level, all typed plugin contributions are also lost — the result is {} rather than the org plugin's inferred types.

Proposed solution

Add a const modifier to the generic type parameter of betterAuth():

export const betterAuth = <const Options extends BetterAuthOptions>(
  options: Options & {},
): Auth<Options> => { ... };

With const (TypeScript 5.0+, TS#51865):

  1. Tuple structure is preserved: [organization(), {} as any] infers as readonly [OrgPlugin, any] instead of any[]
  2. Tuple walk path activates: O["plugins"] extends readonly [unknown, ...unknown[]] matches, routing to InferPluginFieldFromTuple
  3. Per-element any isolation works: InferPluginFieldFromTuple processes each element via ExtractPluginField, which has the IsAny guard — any elements return {}, typed elements preserve their contributions

Expected outcome

const auth = betterAuth({
  plugins: [organization(), {} as any],
});

// Before (current): auth.$Infer = {} (all contributions lost)
// After (const generic): auth.$Infer = { Session: { ... activeOrganizationId ... } }

Considerations

  • The const modifier affects the entire Options type, not just plugins. This may over-narrow other properties (e.g., string config values becoming literal types like "postgres" instead of string). Need to verify this does not break downstream type consumers.
  • Arrays inferred with const become readonly. The existing tuple check readonly [unknown, ...unknown[]] already handles this, but other places that consume Options["plugins"] may need to accept readonly arrays.
  • The same const treatment may be needed for createBetterAuth in packages/better-auth/src/auth/base.ts and the minimal variant in packages/better-auth/src/auth/minimal.ts.
  • Need to ensure getTestInstance (test utility) also preserves tuple types for tests to validate this behavior.
  • InferDBFieldsFromPlugins / InferDBFieldsFromPluginsInput in packages/core/src/db/type.ts also use tuple walks and would benefit from this change.

References

Originally created by @cursor[bot] on GitHub (Apr 6, 2026). Original GitHub issue: https://github.com/better-auth/better-auth/issues/8986 ## Problem `plugins` in `BetterAuthOptions` is typed as `BetterAuthPlugin[]` ([init-options.ts#L773](https://github.com/better-auth/better-auth/blob/main/packages/core/src/types/init-options.ts#L773)), so when an untyped (`any`) plugin is present alongside typed plugins: ```ts const auth = betterAuth({ plugins: [organization(), untypedPlugin], // untypedPlugin: any }); ``` TypeScript collapses the inferred array element type: `Organization | any` → `any`, producing `any[]`. This means `Options["plugins"]` loses all individual plugin type information **before** the type-level tuple walk (`InferPluginFieldFromTuple`) gets a chance to process each element separately. ### Current mitigations (PR #8981) PR #8981 added `IsAny` guards to `ExtractPluginField` and related utilities, which prevents the result from collapsing to `any`. However, because the tuple information is already lost at the `BetterAuthPlugin[]` level, **all typed plugin contributions are also lost** — the result is `{}` rather than the org plugin's inferred types. ## Proposed solution Add a `const` modifier to the generic type parameter of `betterAuth()`: ```ts export const betterAuth = <const Options extends BetterAuthOptions>( options: Options & {}, ): Auth<Options> => { ... }; ``` With `const` (TypeScript 5.0+, [TS#51865](https://github.com/microsoft/TypeScript/pull/51865)): 1. **Tuple structure is preserved**: `[organization(), {} as any]` infers as `readonly [OrgPlugin, any]` instead of `any[]` 2. **Tuple walk path activates**: `O["plugins"] extends readonly [unknown, ...unknown[]]` matches, routing to `InferPluginFieldFromTuple` 3. **Per-element `any` isolation works**: `InferPluginFieldFromTuple` processes each element via `ExtractPluginField`, which has the `IsAny` guard — `any` elements return `{}`, typed elements preserve their contributions ### Expected outcome ```ts const auth = betterAuth({ plugins: [organization(), {} as any], }); // Before (current): auth.$Infer = {} (all contributions lost) // After (const generic): auth.$Infer = { Session: { ... activeOrganizationId ... } } ``` ## Considerations - The `const` modifier affects the **entire** `Options` type, not just `plugins`. This may over-narrow other properties (e.g., string config values becoming literal types like `"postgres"` instead of `string`). Need to verify this does not break downstream type consumers. - Arrays inferred with `const` become `readonly`. The existing tuple check `readonly [unknown, ...unknown[]]` already handles this, but other places that consume `Options["plugins"]` may need to accept `readonly` arrays. - The same `const` treatment may be needed for `createBetterAuth` in `packages/better-auth/src/auth/base.ts` and the minimal variant in `packages/better-auth/src/auth/minimal.ts`. - Need to ensure `getTestInstance` (test utility) also preserves tuple types for tests to validate this behavior. - `InferDBFieldsFromPlugins` / `InferDBFieldsFromPluginsInput` in `packages/core/src/db/type.ts` also use tuple walks and would benefit from this change. ## References - PR #8981: current `IsAny` guard approach - [TypeScript PR #51865](https://github.com/microsoft/TypeScript/pull/51865): `const` type parameters - [TypeScript PR #45711](https://github.com/microsoft/TypeScript/pull/45711): stricter conditional checks for `any` - [`BetterAuthOptions.plugins` definition](https://github.com/better-auth/better-auth/blob/main/packages/core/src/types/init-options.ts#L773)
GiteaMirror added the enhancement label 2026-04-17 20:01:10 -05:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
adapter
astro
awaiting external contributor
blocked
breaking
breaking change
bug
c-devops
core
credentials
database
dependencies
devops
devtools
docs
documentation
duplicate
elysia
enhancement
enterprise
expo
express
fastify
good first issue
help wanted
hono
identity
infra
integration
invalid
javascript
locked
maintenance
need-more-information
needs: info
needs: repro
nextjs
nuxt
oauth
organization
P0
payments
perf
platform
plugin
pull-request
Mirrored from GitHub Pull Request
 question
ready
regression
remix
security
social-provider
solid
stale
svelte
tanstack-start
tracking
version-bump
vue
wontfix
No Label enhancement
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/better-auth#28573
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?