Is this suited for github?

• Yes, this is suited for github

To Reproduce

better-auth has systemic issues that repeat and reoccur version-after-version regarding the web of types and interdependencies between various better-* packages.

These packages are interdependent on different versions of each other and some types rely on internal types that are not consistently exported or have a consistent source of truth especially between versions.

Type issues are especially common in monorepos and with rigorous package managers like pnpm.

Ultimately type issues make better-auth a time-sink to incorporate into many projects and it can block good development practices at times. Clearly huge numbers of developers are impacted.

The common pattern is: The inferred type of ... cannot be named without a reference to '...' and This is likely not portable. A type annotation is necessary.ts(2742).

These appear to have common causes and they are entirely fixable. Workarounds should not involve telling devs to use TypeScript escape hatches like as casts.

Here are some issues I was able to find. I'm sure there are many more that are closed.

• The inferred type of 'auth' cannot be named without a reference #2123 (comment) (read the comments this issue is absolutely not closed)
• Typescript error in auth export #5637
• AdditionalFields break organization plugin and auth api #5122
• The inferred type of 'auth' cannot be named without a reference #4250
• The inferred type of 'createAuth' cannot be named without a reference to '.pnpm/@simplewebauthn+server@13.1.1/node_modules/@simplewebauthn/server' #2036

In issue #2142 I added a comment with a workaround here for those using drizzle adapter:

#2123 (comment)

I comment on the "web" of interdependent types and give an example:

.pnpm/@better-auth+core@1.3.31_@better-auth+utils@0.3.0_@better-fetch+fetch@1.1.18_better-cal_1c46b965734ebfdf948befe6543bce20/node_modules/@better-auth/core/db/adapter

Suggestions for devs:

config helper

Many libraries (vitest, eslint, hono (defineMiddleware()), etc.) offer a sort of defineConfig() function to help check both the config object argument and guarantee that the return value is a particular exportable type with fixed source(s) of truth.

This can be used as a mechanism to help gloss over some of the deeper internal issues.

Such a helper could even add more value in future: e.g. a layer of validation and perhaps even checks that throw if something really bad or insecure is detected.

Current vs. Expected behavior

better-auth should work the way its supposed to and deliver on the promise of being TypeScript first and delivering type safety; better-auth types should support monorepos and having auth defined in a separate package.

What version of Better Auth are you using?

1.3.34

System info

{
  "system": {
    "platform": "linux",
    "arch": "x64",
    "version": "#1 SMP PREEMPT_DYNAMIC Thu Jun  5 18:30:46 UTC 2025",
    "release": "6.6.87.2-microsoft-standard-WSL2",
    "cpuCount": 0,
    "cpuModel": "XXX",
    "totalMemory": "X GB",
    "freeMemory": "X GB"
  },
  "node": {
    "version": "v22.13.1",
    "env": "development"
  },
  "packageManager": {
    "name": "pnpm",
    "version": "10.20.0"
  },
  "frameworks": null,
  "databases": null,
  "betterAuth": {
    "version": "Unknown",
    "config": null
  }
}

Which area(s) are affected? (Select all that apply)

Types

Auth config (if applicable)

import { betterAuth } from "better-auth"
export const auth = betterAuth({
  emailAndPassword: {  
    enabled: true
  },
});

Additional context

No response