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

[GH-ISSUE #5574] Version 1.3.31 and v1.4.0-beta.13 type inference error requiring reference to better-call and breaking organization plugin #27612

New Issue
Closed
opened 2026-04-17 18:42:30 -05:00 by GiteaMirror · 18 comments
GiteaMirror commented 2026-04-17 18:42:30 -05:00
Owner
Copy Link

Originally created by @rohovskoi on GitHub (Oct 25, 2025).
Original GitHub issue: https://github.com/better-auth/better-auth/issues/5574

Originally assigned to: @himself65 on GitHub.

Is this suited for github?

  • Yes, this is suited for github

To Reproduce

Upgrade to version 1.3.31 or v1.4.0-beta.13 and you will see type inference errors like this:

The inferred type of this node exceeds the maximum length the compiler will serialize. An explicit type annotation is needed. (ts 7056)

The inferred type of 'IamProvider' cannot be named without a reference to '.pnpm/better-call@1.0.24/node_modules/better-call'. This is likely not portable. A type annotation is necessary. (ts 2742)

By adding organization({}) you will get the following error, which is weird, as its keys are all optional and it still errors out with type incompatibility...

Current vs. Expected behavior

Current:

Type inference error no. 1 that requires a ref to better-call:

The inferred type of this node exceeds the maximum length the compiler will serialize. An explicit type annotation is needed. (ts 7056)
The inferred type of 'IamProvider' cannot be named without a reference to '.pnpm/better-call@1.0.24/node_modules/better-call'. This is likely not portable. A type annotation is necessary. (ts 2742)

Type inference error no. 2 that makes organization plugin totally incompatible:

Type '{ id: "organization"; endpoints: OrganizationEndpoints<{}>; schema: { organization: { modelName: string | undefined; fields: { name: { type: "string"; required: true; sortable: true; fieldName?: string | undefined; }; slug: { ...; }; logo: { ...; }; createdAt: { ...; }; updatedAt: { ...; }; }; }; member: { ...; }; i...' is not assignable to type 'BetterAuthPlugin'.
Types of property 'schema' are incompatible.
Type '{ organization: { modelName: string | undefined; fields: { name: { type: "string"; required: true; sortable: true; fieldName?: string | undefined; }; slug: { type: "string"; required: true; unique: true; sortable: true; fieldName?: string | undefined; }; logo: { ...; }; createdAt: { ...; }; updatedAt: { ...; }; }; }...' is not assignable to type 'BetterAuthPluginDBSchema'.
Property 'organization' is incompatible with index signature.
Type '{ modelName: string | undefined; fields: { name: { type: "string"; required: true; sortable: true; fieldName?: string | undefined; }; slug: { type: "string"; required: true; unique: true; sortable: true; fieldName?: string | undefined; }; logo: { ...; }; createdAt: { ...; }; updatedAt: { ...; }; }; }' is not assignable to type '{ fields: { [x: string]: DBFieldAttribute<DBFieldType>; }; disableMigration?: boolean; modelName?: string; }' with 'exactOptionalPropertyTypes: true'. Consider adding 'undefined' to the types of the target's properties.
Types of property 'fields' are incompatible.
Type '{ name: { type: "string"; required: true; sortable: true; fieldName?: string | undefined; }; slug: { type: "string"; required: true; unique: true; sortable: true; fieldName?: string | undefined; }; logo: { ...; }; createdAt: { ...; }; updatedAt: { ...; }; }' is not assignable to type '{ [x: string]: DBFieldAttribute<DBFieldType>; }'.
Property 'name' is incompatible with index signature.
Type '{ type: "string"; required: true; sortable: true; fieldName?: string | undefined; }' is not assignable to type 'DBFieldAttribute<DBFieldType>' with 'exactOptionalPropertyTypes: true'. Consider adding 'undefined' to the types of the target's properties.
Type '{ type: "string"; required: true; sortable: true; fieldName?: string | undefined; }' is not assignable to type 'DBFieldAttributeConfig' with 'exactOptionalPropertyTypes: true'. Consider adding 'undefined' to the types of the target's properties.
Types of property 'fieldName' are incompatible.
Type 'string | undefined' is not assignable to type 'string'.
Type 'undefined' is not assignable to type 'string'. (ts 2322)

Expected:

None of this shows up and type inference works correctly.

What version of Better Auth are you using?

1.3.31 and v1.4.0-beta.13

System info

.

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

Package, Backend

Auth config (if applicable)

import { betterAuth } from "better-auth"
export const auth = betterAuth({
  emailAndPassword: {  
    enabled: true
  },
  // Other configs...
  plugins: [
     organization({
            
     }),
  ]
});

Additional context

No response

Originally created by @rohovskoi on GitHub (Oct 25, 2025). Original GitHub issue: https://github.com/better-auth/better-auth/issues/5574 Originally assigned to: @himself65 on GitHub. ### Is this suited for github? - [x] Yes, this is suited for github ### To Reproduce Upgrade to version 1.3.31 or v1.4.0-beta.13 and you will see type inference errors like this: ``` The inferred type of this node exceeds the maximum length the compiler will serialize. An explicit type annotation is needed. (ts 7056) The inferred type of 'IamProvider' cannot be named without a reference to '.pnpm/better-call@1.0.24/node_modules/better-call'. This is likely not portable. A type annotation is necessary. (ts 2742) ``` By adding `organization({})` you will get the following error, which is weird, as its keys are all optional and it still errors out with type incompatibility... ### Current vs. Expected behavior ### Current: Type inference error no. 1 that requires a ref to better-call: ``` The inferred type of this node exceeds the maximum length the compiler will serialize. An explicit type annotation is needed. (ts 7056) The inferred type of 'IamProvider' cannot be named without a reference to '.pnpm/better-call@1.0.24/node_modules/better-call'. This is likely not portable. A type annotation is necessary. (ts 2742) ``` Type inference error no. 2 that makes organization plugin totally incompatible: ``` Type '{ id: "organization"; endpoints: OrganizationEndpoints<{}>; schema: { organization: { modelName: string | undefined; fields: { name: { type: "string"; required: true; sortable: true; fieldName?: string | undefined; }; slug: { ...; }; logo: { ...; }; createdAt: { ...; }; updatedAt: { ...; }; }; }; member: { ...; }; i...' is not assignable to type 'BetterAuthPlugin'. Types of property 'schema' are incompatible. Type '{ organization: { modelName: string | undefined; fields: { name: { type: "string"; required: true; sortable: true; fieldName?: string | undefined; }; slug: { type: "string"; required: true; unique: true; sortable: true; fieldName?: string | undefined; }; logo: { ...; }; createdAt: { ...; }; updatedAt: { ...; }; }; }...' is not assignable to type 'BetterAuthPluginDBSchema'. Property 'organization' is incompatible with index signature. Type '{ modelName: string | undefined; fields: { name: { type: "string"; required: true; sortable: true; fieldName?: string | undefined; }; slug: { type: "string"; required: true; unique: true; sortable: true; fieldName?: string | undefined; }; logo: { ...; }; createdAt: { ...; }; updatedAt: { ...; }; }; }' is not assignable to type '{ fields: { [x: string]: DBFieldAttribute<DBFieldType>; }; disableMigration?: boolean; modelName?: string; }' with 'exactOptionalPropertyTypes: true'. Consider adding 'undefined' to the types of the target's properties. Types of property 'fields' are incompatible. Type '{ name: { type: "string"; required: true; sortable: true; fieldName?: string | undefined; }; slug: { type: "string"; required: true; unique: true; sortable: true; fieldName?: string | undefined; }; logo: { ...; }; createdAt: { ...; }; updatedAt: { ...; }; }' is not assignable to type '{ [x: string]: DBFieldAttribute<DBFieldType>; }'. Property 'name' is incompatible with index signature. Type '{ type: "string"; required: true; sortable: true; fieldName?: string | undefined; }' is not assignable to type 'DBFieldAttribute<DBFieldType>' with 'exactOptionalPropertyTypes: true'. Consider adding 'undefined' to the types of the target's properties. Type '{ type: "string"; required: true; sortable: true; fieldName?: string | undefined; }' is not assignable to type 'DBFieldAttributeConfig' with 'exactOptionalPropertyTypes: true'. Consider adding 'undefined' to the types of the target's properties. Types of property 'fieldName' are incompatible. Type 'string | undefined' is not assignable to type 'string'. Type 'undefined' is not assignable to type 'string'. (ts 2322) ``` ### Expected: None of this shows up and type inference works correctly. ### What version of Better Auth are you using? 1.3.31 and v1.4.0-beta.13 ### System info ```bash . ``` ### Which area(s) are affected? (Select all that apply) Package, Backend ### Auth config (if applicable) ```typescript import { betterAuth } from "better-auth" export const auth = betterAuth({ emailAndPassword: { enabled: true }, // Other configs... plugins: [ organization({ }), ] }); ``` ### Additional context _No response_
GiteaMirror added the lockedbug labels 2026-04-17 18:42:30 -05:00
GiteaMirror commented 2026-04-17 18:42:32 -05:00
Author
Owner
Copy Link

@dosubot[bot] commented on GitHub (Oct 25, 2025):

The type inference errors you’re seeing in Better Auth v1.3.31 and v1.4.0-beta.13 are caused by strict TypeScript settings, especially "exactOptionalPropertyTypes": true in your tsconfig. This setting enforces that optional properties can’t be undefined when assigned to certain types, which breaks compatibility with the organization plugin and causes errors like the one referencing better-call types across package boundaries. This is a known issue and has been discussed by maintainers and users in several threads (example, example).

Workarounds:

  • Set "exactOptionalPropertyTypes": false in your tsconfig to restore compatibility. This is the most reliable fix right now, though it does reduce type safety (source).
  • If you need to keep strict settings, you can use an explicit type annotation when exporting your auth instance, like: 
    export const auth = betterAuth(authConfig) as ReturnType<typeof betterAuth<typeof authConfig>>;
    This avoids leaking internal types and resolves the error (source).
  • In monorepos, disabling "declaration" and "declarationMap" in tsconfig can also help, but you’ll lose declaration file generation (source).
  • If you see errors about plugin schemas, make sure your plugin config matches the expected types, and consider updating all related dependencies if you’re using pnpm or turbo (source).

Why this happens:
Recent changes in Better Auth and its plugins made type exports more modular, but stricter TypeScript settings and cross-package type references (like those from better-call) can cause types to leak or become incompatible. The organization plugin’s schema uses optional fields (fieldName?: string | undefined), which TypeScript with strict settings doesn’t accept as assignable to string (source). A deeper type system refactor is needed for full compatibility, and maintainers are aware and planning a fix.

Let me know if you need a concrete example for your config or want to discuss more advanced workarounds!

To reply, just mention @dosu.

How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other  Chat with Dosu Join Discord Share on X

<!-- gh-comment-id:3446724563 --> @dosubot[bot] commented on GitHub (Oct 25, 2025): <!-- Answer --> The type inference errors you’re seeing in Better Auth v1.3.31 and v1.4.0-beta.13 are caused by strict TypeScript settings, especially `"exactOptionalPropertyTypes": true` in your tsconfig. This setting enforces that optional properties can’t be `undefined` when assigned to certain types, which breaks compatibility with the organization plugin and causes errors like the one referencing `better-call` types across package boundaries. This is a known issue and has been discussed by maintainers and users in several threads ([example](https://github.com/better-auth/better-auth/issues/2471), [example](https://github.com/better-auth/better-auth/issues/3493)). **Workarounds:** - Set `"exactOptionalPropertyTypes": false` in your tsconfig to restore compatibility. This is the most reliable fix right now, though it does reduce type safety ([source](https://github.com/better-auth/better-auth/issues/2471)). - If you need to keep strict settings, you can use an explicit type annotation when exporting your auth instance, like: ```typescript export const auth = betterAuth(authConfig) as ReturnType<typeof betterAuth<typeof authConfig>>; ``` This avoids leaking internal types and resolves the error ([source](https://github.com/better-auth/better-auth/issues/4250)). - In monorepos, disabling `"declaration"` and `"declarationMap"` in tsconfig can also help, but you’ll lose declaration file generation ([source](https://github.com/better-auth/better-auth/issues/5122)). - If you see errors about plugin schemas, make sure your plugin config matches the expected types, and consider updating all related dependencies if you’re using pnpm or turbo ([source](https://github.com/better-auth/better-auth/issues/3493)). **Why this happens:** Recent changes in Better Auth and its plugins made type exports more modular, but stricter TypeScript settings and cross-package type references (like those from `better-call`) can cause types to leak or become incompatible. The organization plugin’s schema uses optional fields (`fieldName?: string | undefined`), which TypeScript with strict settings doesn’t accept as assignable to `string` ([source](https://github.com/better-auth/better-auth/issues/4804)). A deeper type system refactor is needed for full compatibility, and maintainers are aware and planning a fix. Let me know if you need a concrete example for your config or want to discuss more advanced workarounds! <!-- Dosu Comment Footer --> *To reply, just mention [@dosu](https://go.dosu.dev/dosubot).* --- <sup>How did I do? [Good](https://app.dosu.dev/response-feedback/e7e6907d-256f-412c-bcce-29911b4ad1ec?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/e7e6907d-256f-412c-bcce-29911b4ad1ec?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/e7e6907d-256f-412c-bcce-29911b4ad1ec?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/e7e6907d-256f-412c-bcce-29911b4ad1ec?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/e7e6907d-256f-412c-bcce-29911b4ad1ec?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/e7e6907d-256f-412c-bcce-29911b4ad1ec?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/e7e6907d-256f-412c-bcce-29911b4ad1ec?feedback_type=other)</sup>&nbsp;&nbsp;[![Chat with Dosu](https://dosu.dev/dosu-chat-badge.svg)](https://app.dosu.dev/cdda13d9-dd27-4d31-b09a-5d8bec92de21/ask?utm_source=github)&nbsp;[![Join Discord](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&label=)](https://go.dosu.dev/discord-bot)&nbsp;[![Share on X](https://img.shields.io/badge/X-share-black)](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/better-auth/better-auth/issues/5574)
GiteaMirror commented 2026-04-17 18:42:34 -05:00
Author
Owner
Copy Link

@rohovskoi commented on GitHub (Oct 25, 2025):

@dosu

I tried using this workaround:

export const auth = betterAuth(authConfig) as ReturnType<typeof betterAuth<typeof authConfig>>;

But got the following error..

The inferred type of 'IamProvider' cannot be named without a reference to '.pnpm/@better-auth+core@1.4.0-beta.11_@better-auth+utils@0.3.0_@better-fetch+fetch@1.1.18_bet_2eea63e86bfa58cd8572a7d3018d4e6e/node_modules/@better-auth/core/db/adapter'. This is likely not portable. A type annotation is necessary. (ts 2742)

<!-- gh-comment-id:3446728806 --> @rohovskoi commented on GitHub (Oct 25, 2025): @dosu I tried using this workaround: `export const auth = betterAuth(authConfig) as ReturnType<typeof betterAuth<typeof authConfig>>;` But got the following error.. The inferred type of 'IamProvider' cannot be named without a reference to '.pnpm/@better-auth+core@1.4.0-beta.11_@better-auth+utils@0.3.0_@better-fetch+fetch@1.1.18_bet_2eea63e86bfa58cd8572a7d3018d4e6e/node_modules/@better-auth/core/db/adapter'. This is likely not portable. A type annotation is necessary. (ts 2742)
GiteaMirror commented 2026-04-17 18:42:36 -05:00
Author
Owner
Copy Link

@dosubot[bot] commented on GitHub (Oct 25, 2025):

The TS2742 error persists even with the explicit type annotation because Better Auth’s plugin and adapter types (like those used by the organization plugin) internally reference types from deep within @better-auth/core/db/adapter. TypeScript tries to serialize these complex, nested types, which aren’t re-exported at the top level, so it requires a direct reference to the internal module—leading to the non-portable type error you’re seeing. This is especially common in monorepos with pnpm, where multiple copies of dependencies make type boundaries even harder for TypeScript to resolve cleanly [source].

Current workarounds:

  • The most reliable fix is to set "declaration": false and "declarationMap": false in your tsconfig for the affected package. This prevents TypeScript from emitting declaration files that would expose these internal types, avoiding TS2742, but you lose declaration file generation [source].
  • If you need declaration files, you can move your auth config to a separate package with declarations disabled, then import it in your main app [source].
  • Using satisfies BetterAuthOptions on your config can help with literal type inference, but it doesn’t fully solve plugin typing issues in monorepos [source].
  • Type assertions like as ReturnType<typeof betterAuth> suppress the error but lose plugin-specific typings, so plugin-added fields won’t be reflected in your type system [source].

Why this happens:
It’s a TypeScript limitation with complex generics and plugin architectures. The only way to fully fix this would be a refactor of Better Auth’s type exports so only public types are exposed in consumer APIs, closing over internal references. For now, all solutions involve trade-offs between type safety and portability [source].

Let me know if you want a concrete tsconfig or code example for your setup!

To reply, just mention @dosu.

How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other  Chat with Dosu Join Discord Share on X

<!-- gh-comment-id:3446733444 --> @dosubot[bot] commented on GitHub (Oct 25, 2025): <!-- Answer --> The TS2742 error persists even with the explicit type annotation because Better Auth’s plugin and adapter types (like those used by the organization plugin) internally reference types from deep within `@better-auth/core/db/adapter`. TypeScript tries to serialize these complex, nested types, which aren’t re-exported at the top level, so it requires a direct reference to the internal module—leading to the non-portable type error you’re seeing. This is especially common in monorepos with pnpm, where multiple copies of dependencies make type boundaries even harder for TypeScript to resolve cleanly [[source](https://github.com/better-auth/better-auth/issues/4250)]. **Current workarounds:** - The most reliable fix is to set `"declaration": false` and `"declarationMap": false` in your tsconfig for the affected package. This prevents TypeScript from emitting declaration files that would expose these internal types, avoiding TS2742, but you lose declaration file generation [[source](https://github.com/better-auth/better-auth/issues/5122)]. - If you need declaration files, you can move your auth config to a separate package with declarations disabled, then import it in your main app [[source](https://github.com/better-auth/better-auth/issues/4654)]. - Using `satisfies BetterAuthOptions` on your config can help with literal type inference, but it doesn’t fully solve plugin typing issues in monorepos [[source](https://github.com/better-auth/better-auth/issues/5122)]. - Type assertions like `as ReturnType<typeof betterAuth>` suppress the error but lose plugin-specific typings, so plugin-added fields won’t be reflected in your type system [[source](https://github.com/better-auth/better-auth/issues/4654)]. **Why this happens:** It’s a TypeScript limitation with complex generics and plugin architectures. The only way to fully fix this would be a refactor of Better Auth’s type exports so only public types are exposed in consumer APIs, closing over internal references. For now, all solutions involve trade-offs between type safety and portability [[source](https://github.com/better-auth/better-auth/issues/4250)]. Let me know if you want a concrete tsconfig or code example for your setup! <!-- Dosu Comment Footer --> *To reply, just mention [@dosu](https://go.dosu.dev/dosubot).* --- <sup>How did I do? [Good](https://app.dosu.dev/response-feedback/7e768c00-a918-44a6-9f25-470f1883b244?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/7e768c00-a918-44a6-9f25-470f1883b244?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/7e768c00-a918-44a6-9f25-470f1883b244?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/7e768c00-a918-44a6-9f25-470f1883b244?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/7e768c00-a918-44a6-9f25-470f1883b244?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/7e768c00-a918-44a6-9f25-470f1883b244?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/7e768c00-a918-44a6-9f25-470f1883b244?feedback_type=other)</sup>&nbsp;&nbsp;[![Chat with Dosu](https://dosu.dev/dosu-chat-badge.svg)](https://app.dosu.dev/cdda13d9-dd27-4d31-b09a-5d8bec92de21/ask?utm_source=github)&nbsp;[![Join Discord](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&label=)](https://go.dosu.dev/discord-bot)&nbsp;[![Share on X](https://img.shields.io/badge/X-share-black)](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/better-auth/better-auth/issues/5574)
GiteaMirror commented 2026-04-17 18:42:37 -05:00
Author
Owner
Copy Link

@ghassenbenghorbal commented on GitHub (Oct 25, 2025):

I have the same problem. Opened an issue #5122 3 weeks ago and still waiting for a fix

<!-- gh-comment-id:3446914466 --> @ghassenbenghorbal commented on GitHub (Oct 25, 2025): I have the same problem. Opened an issue #5122 3 weeks ago and still waiting for a fix
GiteaMirror commented 2026-04-17 18:42:38 -05:00
Author
Owner
Copy Link

@himself65 commented on GitHub (Oct 25, 2025):

Hi, what's your tsconfig setup?

<!-- gh-comment-id:3447801078 --> @himself65 commented on GitHub (Oct 25, 2025): Hi, what's your tsconfig setup?
GiteaMirror commented 2026-04-17 18:42:39 -05:00
Author
Owner
Copy Link

@rohovskoi commented on GitHub (Oct 25, 2025):

@himself65 Hey, thanks for taking your time and checking this issue!

Just to clarify, I cannot set declaration: false, declarationMap: false as its a shared package and my entire repo uses TS project references.
Also I cannot exactOptionalPropertyTypes: false as I need extra strict typing.

Here is my tsconfig.base.json in my repo's root.

{
	"compilerOptions": {
		"strict": true,
		"esModuleInterop": true,
		"allowSyntheticDefaultImports": true,
		"exactOptionalPropertyTypes": true,
		"moduleDetection": "force",
		"composite": true,
		"declaration": true,
		"declarationMap": true,
		"downlevelIteration": true,
		"resolveJsonModule": true,
		"pretty": true,
		"skipLibCheck": true,
		"emitDecoratorMetadata": true,
		"experimentalDecorators": true,
		"types": [],
		"isolatedModules": true,
		"sourceMap": true,
		"noImplicitReturns": false,
		"noUnusedLocals": true,
		"noUnusedParameters": false,
		"noFallthroughCasesInSwitch": true,
		"noEmitOnError": false,
		"noErrorTruncation": false,
		"allowJs": false,
		"checkJs": false,
		"forceConsistentCasingInFileNames": true,
		"noImplicitAny": true,
		"noImplicitThis": true,
		"noUncheckedIndexedAccess": false,
		"strictNullChecks": true,
		"incremental": true,
		"removeComments": false,
		"baseUrl": ".",
		"lib": ["ES2022", "DOM", "DOM.Iterable"],
	  "module": "ESNext",
    "moduleResolution": "bundler",
    "target": "ES2022",
    "verbatimModuleSyntax": true,
    "rewriteRelativeImportExtensions": true,
    "erasableSyntaxOnly": true,
    "noImplicitOverride": true
	}
}

Here is tsconfig.src.json in my auth package which gets built and consumed by another package.

{
  "$schema": "http://json.schemastore.org/tsconfig",
  "extends": "../../../tsconfig.base.json",
  "references": [
   { "path": "../../lib/env" },
   { "path": "../../lib/kernel" }
	],
	"include": ["src"],
	"compilerOptions": {
		"types": ["node"],
		"tsBuildInfoFile": ".tsbuildinfo/src.tsbuildinfo",
		"rootDir": "src",
		"outDir": ".tsbuildinfo/src",
		"baseUrl": ".",
	}
}

here is my tsconfig.test.json from the same auth package

{
  "$schema": "http://json.schemastore.org/tsconfig",
  "extends": "../../../tsconfig.base.json",
	"include": ["test"],
	"references": [{ "path": "tsconfig.src.json" }],
	"compilerOptions": {
		"types": ["node"],
		"tsBuildInfoFile": ".tsbuildinfo/test.tsbuildinfo",
		"rootDir": "test",
		"noEmit": true
	}
}
<!-- gh-comment-id:3447836115 --> @rohovskoi commented on GitHub (Oct 25, 2025): @himself65 Hey, thanks for taking your time and checking this issue! Just to clarify, I cannot set `declaration: false, declarationMap: false` as its a shared package and my entire repo uses TS project references. Also I cannot `exactOptionalPropertyTypes: false` as I need extra strict typing. Here is my `tsconfig.base.json` in my repo's root. ```json { "compilerOptions": { "strict": true, "esModuleInterop": true, "allowSyntheticDefaultImports": true, "exactOptionalPropertyTypes": true, "moduleDetection": "force", "composite": true, "declaration": true, "declarationMap": true, "downlevelIteration": true, "resolveJsonModule": true, "pretty": true, "skipLibCheck": true, "emitDecoratorMetadata": true, "experimentalDecorators": true, "types": [], "isolatedModules": true, "sourceMap": true, "noImplicitReturns": false, "noUnusedLocals": true, "noUnusedParameters": false, "noFallthroughCasesInSwitch": true, "noEmitOnError": false, "noErrorTruncation": false, "allowJs": false, "checkJs": false, "forceConsistentCasingInFileNames": true, "noImplicitAny": true, "noImplicitThis": true, "noUncheckedIndexedAccess": false, "strictNullChecks": true, "incremental": true, "removeComments": false, "baseUrl": ".", "lib": ["ES2022", "DOM", "DOM.Iterable"], "module": "ESNext", "moduleResolution": "bundler", "target": "ES2022", "verbatimModuleSyntax": true, "rewriteRelativeImportExtensions": true, "erasableSyntaxOnly": true, "noImplicitOverride": true } } ``` Here is `tsconfig.src.json` in my `auth` package which gets built and consumed by another package. ```json { "$schema": "http://json.schemastore.org/tsconfig", "extends": "../../../tsconfig.base.json", "references": [ { "path": "../../lib/env" }, { "path": "../../lib/kernel" } ], "include": ["src"], "compilerOptions": { "types": ["node"], "tsBuildInfoFile": ".tsbuildinfo/src.tsbuildinfo", "rootDir": "src", "outDir": ".tsbuildinfo/src", "baseUrl": ".", } } ``` here is my `tsconfig.test.json` from the same `auth` package ```json { "$schema": "http://json.schemastore.org/tsconfig", "extends": "../../../tsconfig.base.json", "include": ["test"], "references": [{ "path": "tsconfig.src.json" }], "compilerOptions": { "types": ["node"], "tsBuildInfoFile": ".tsbuildinfo/test.tsbuildinfo", "rootDir": "test", "noEmit": true } } ```
GiteaMirror commented 2026-04-17 18:42:40 -05:00
Author
Owner
Copy Link

@rohovskoi commented on GitHub (Oct 26, 2025):

@himself65 I used a very "hacky" workaround by adding explicit schema to org plugin. Which kinda fixed org plugin i guess. (Not sure if its a fix)

schema: {
              organizationRole: {
                modelName: 'organization_role',
                fields: {
                  organizationId: 'organizationId',
                  role: 'role',
                  permission: 'permission',
                  createdAt: 'createdAt',
                  updatedAt: 'updatedAt',
                },
              },
            },

BUT now I'm getting:

The inferred type of 'IamProvider' cannot be named without a reference to '.pnpm/zod@4.1.11/node_modules/zod/v4/core'. This is likely not portable. A type annotation is necessary. (ts 2742)
The inferred type of 'IamProvider' cannot be named without a reference to '.pnpm/zod@4.1.11/node_modules/zod'. This is likely not portable. A type annotation is necessary. (ts 2742)
The inferred type of this node exceeds the maximum length the compiler will serialize. An explicit type annotation is needed. (ts 7056)

If I add zod: ^4.1.11 as an explicit dependency to this auth package, i get another error:

The inferred type of 'IamProvider' cannot be named without a reference to '.pnpm/better-call@1.0.24/node_modules/better-call'. This is likely not portable. A type annotation is necessary. (ts 2742)
The inferred type of this node exceeds the maximum length the compiler will serialize. An explicit type annotation is needed. (ts 7056)

This is extremely annoying...

<!-- gh-comment-id:3448354185 --> @rohovskoi commented on GitHub (Oct 26, 2025): @himself65 I used a very "hacky" workaround by adding explicit schema to org plugin. Which kinda fixed org plugin i guess. (Not sure if its a fix) ``` schema: { organizationRole: { modelName: 'organization_role', fields: { organizationId: 'organizationId', role: 'role', permission: 'permission', createdAt: 'createdAt', updatedAt: 'updatedAt', }, }, }, ``` BUT now I'm getting: ``` The inferred type of 'IamProvider' cannot be named without a reference to '.pnpm/zod@4.1.11/node_modules/zod/v4/core'. This is likely not portable. A type annotation is necessary. (ts 2742) The inferred type of 'IamProvider' cannot be named without a reference to '.pnpm/zod@4.1.11/node_modules/zod'. This is likely not portable. A type annotation is necessary. (ts 2742) The inferred type of this node exceeds the maximum length the compiler will serialize. An explicit type annotation is needed. (ts 7056) ``` If I add `zod: ^4.1.11` as an explicit dependency to this `auth` package, i get another error: ``` The inferred type of 'IamProvider' cannot be named without a reference to '.pnpm/better-call@1.0.24/node_modules/better-call'. This is likely not portable. A type annotation is necessary. (ts 2742) The inferred type of this node exceeds the maximum length the compiler will serialize. An explicit type annotation is needed. (ts 7056) ``` This is extremely annoying...
GiteaMirror commented 2026-04-17 18:42:41 -05:00
Author
Owner
Copy Link

@rohovskoi commented on GitHub (Oct 26, 2025):

Without explicitly defined schema inside organization plugin,

schema: {
              organizationRole: {
                modelName: 'organization_role',
                fields: {
                  organizationId: 'organizationId',
                  role: 'role',
                  permission: 'permission',
                  createdAt: 'createdAt',
                  updatedAt: 'updatedAt',
                },
              },
            },

I get:

Type '{ id: "organization"; endpoints: OrganizationEndpoints<{ requireEmailVerificationOnInvitation: true; maximumRolesPerOrganization: number; sendInvitationEmail: ({ email, organization, id }: { id: string; role: string; email: string; organization: { ...; }; invitation: { ...; }; inviter: { ...; } & { ...; }; }) => Pro...' is not assignable to type 'BetterAuthPlugin'.
Types of property 'schema' are incompatible.
Type '{ organizationRole: { modelName: string | undefined; fields: { organizationId: { type: "string"; required: true; references: { model: "organization"; field: "id"; }; fieldName?: string | undefined; }; role: { ...; }; permission: { ...; }; createdAt: { ...; }; updatedAt: { ...; }; }; }; }' is not assignable to type 'BetterAuthPluginDBSchema'.
Property 'organizationRole' is incompatible with index signature.
Type '{ modelName: string | undefined; fields: { organizationId: { type: "string"; required: true; references: { model: "organization"; field: "id"; }; fieldName?: string | undefined; }; role: { type: "string"; required: true; fieldName?: string | undefined; }; permission: { ...; }; createdAt: { ...; }; updatedAt: { ...; ...' is not assignable to type '{ fields: { [x: string]: DBFieldAttribute<DBFieldType>; }; disableMigration?: boolean; modelName?: string; }' with 'exactOptionalPropertyTypes: true'. Consider adding 'undefined' to the types of the target's properties.
Types of property 'fields' are incompatible.
Type '{ organizationId: { type: "string"; required: true; references: { model: "organization"; field: "id"; }; fieldName?: string | undefined; }; role: { type: "string"; required: true; fieldName?: string | undefined; }; permission: { ...; }; createdAt: { ...; }; updatedAt: { ...; }; }' is not assignable to type '{ [x: string]: DBFieldAttribute<DBFieldType>; }'.
Property 'organizationId' is incompatible with index signature.
Type '{ type: "string"; required: true; references: { model: "organization"; field: "id"; }; fieldName?: string | undefined; }' is not assignable to type 'DBFieldAttribute<DBFieldType>' with 'exactOptionalPropertyTypes: true'. Consider adding 'undefined' to the types of the target's properties.
Type '{ type: "string"; required: true; references: { model: "organization"; field: "id"; }; fieldName?: string | undefined; }' is not assignable to type 'DBFieldAttributeConfig' with 'exactOptionalPropertyTypes: true'. Consider adding 'undefined' to the types of the target's properties.
Types of property 'fieldName' are incompatible.
Type 'string | undefined' is not assignable to type 'string'.
Type 'undefined' is not assignable to type 'string'. (ts 2322)
<!-- gh-comment-id:3448502893 --> @rohovskoi commented on GitHub (Oct 26, 2025): Without explicitly defined schema inside organization plugin, ```ts schema: { organizationRole: { modelName: 'organization_role', fields: { organizationId: 'organizationId', role: 'role', permission: 'permission', createdAt: 'createdAt', updatedAt: 'updatedAt', }, }, }, ``` I get: ``` Type '{ id: "organization"; endpoints: OrganizationEndpoints<{ requireEmailVerificationOnInvitation: true; maximumRolesPerOrganization: number; sendInvitationEmail: ({ email, organization, id }: { id: string; role: string; email: string; organization: { ...; }; invitation: { ...; }; inviter: { ...; } & { ...; }; }) => Pro...' is not assignable to type 'BetterAuthPlugin'. Types of property 'schema' are incompatible. Type '{ organizationRole: { modelName: string | undefined; fields: { organizationId: { type: "string"; required: true; references: { model: "organization"; field: "id"; }; fieldName?: string | undefined; }; role: { ...; }; permission: { ...; }; createdAt: { ...; }; updatedAt: { ...; }; }; }; }' is not assignable to type 'BetterAuthPluginDBSchema'. Property 'organizationRole' is incompatible with index signature. Type '{ modelName: string | undefined; fields: { organizationId: { type: "string"; required: true; references: { model: "organization"; field: "id"; }; fieldName?: string | undefined; }; role: { type: "string"; required: true; fieldName?: string | undefined; }; permission: { ...; }; createdAt: { ...; }; updatedAt: { ...; ...' is not assignable to type '{ fields: { [x: string]: DBFieldAttribute<DBFieldType>; }; disableMigration?: boolean; modelName?: string; }' with 'exactOptionalPropertyTypes: true'. Consider adding 'undefined' to the types of the target's properties. Types of property 'fields' are incompatible. Type '{ organizationId: { type: "string"; required: true; references: { model: "organization"; field: "id"; }; fieldName?: string | undefined; }; role: { type: "string"; required: true; fieldName?: string | undefined; }; permission: { ...; }; createdAt: { ...; }; updatedAt: { ...; }; }' is not assignable to type '{ [x: string]: DBFieldAttribute<DBFieldType>; }'. Property 'organizationId' is incompatible with index signature. Type '{ type: "string"; required: true; references: { model: "organization"; field: "id"; }; fieldName?: string | undefined; }' is not assignable to type 'DBFieldAttribute<DBFieldType>' with 'exactOptionalPropertyTypes: true'. Consider adding 'undefined' to the types of the target's properties. Type '{ type: "string"; required: true; references: { model: "organization"; field: "id"; }; fieldName?: string | undefined; }' is not assignable to type 'DBFieldAttributeConfig' with 'exactOptionalPropertyTypes: true'. Consider adding 'undefined' to the types of the target's properties. Types of property 'fieldName' are incompatible. Type 'string | undefined' is not assignable to type 'string'. Type 'undefined' is not assignable to type 'string'. (ts 2322) ```
GiteaMirror commented 2026-04-17 18:42:42 -05:00
Author
Owner
Copy Link

@himself65 commented on GitHub (Oct 27, 2025):

this is the workaround you can check: https://github.com/microsoft/TypeScript/issues/47663#issuecomment-1519138189

<!-- gh-comment-id:3452807041 --> @himself65 commented on GitHub (Oct 27, 2025): this is the workaround you can check: https://github.com/microsoft/TypeScript/issues/47663#issuecomment-1519138189
GiteaMirror commented 2026-04-17 18:42:43 -05:00
Author
Owner
Copy Link

@rohovskoi commented on GitHub (Oct 27, 2025):

@himself65 hey, thanks for your reply!

I was able to fix this by:

adding direct better-call and zod dependencies to my package and adding an explicit organizationRole schema to organization plugin.

This feels like a "hacky" workaround which I don't think should be the best practice from better-auth.

Do you thinks it's fixable on your side ?

<!-- gh-comment-id:3452925209 --> @rohovskoi commented on GitHub (Oct 27, 2025): @himself65 hey, thanks for your reply! I was able to fix this by: adding direct `better-call` and `zod` dependencies to my package and adding an explicit `organizationRole` schema to `organization` plugin. This feels like a "hacky" workaround which I don't think should be the best practice from `better-auth`. Do you thinks it's fixable on your side ?
GiteaMirror commented 2026-04-17 18:42:43 -05:00
Author
Owner
Copy Link

@rohovskoi commented on GitHub (Oct 27, 2025):

@himself65 also do I actually have to explicitly define organizationRole in schema of organizationPlugin? I believe its definitely a bug

<!-- gh-comment-id:3453115431 --> @rohovskoi commented on GitHub (Oct 27, 2025): @himself65 also do I actually have to explicitly define `organizationRole` in schema of organizationPlugin? I believe its definitely a bug
GiteaMirror commented 2026-04-17 18:42:44 -05:00
Author
Owner
Copy Link

@himself65 commented on GitHub (Oct 27, 2025):

organizationRole seems like a type bug, let me check

<!-- gh-comment-id:3453839826 --> @himself65 commented on GitHub (Oct 27, 2025): `organizationRole` seems like a type bug, let me check
GiteaMirror commented 2026-04-17 18:42:45 -05:00
Author
Owner
Copy Link

@himself65 commented on GitHub (Oct 28, 2025):

Oh, I think we already fixed it in the canary now. I just didn't release a version for a long time. Let me do that.

However, for the 1.3.x version, I think we cannot do that easily since there are too many breaking changes, we might only fix this in 1.4

<!-- gh-comment-id:3453892472 --> @himself65 commented on GitHub (Oct 28, 2025): Oh, I think we already fixed it in the canary now. I just didn't release a version for a long time. Let me do that. However, for the 1.3.x version, I think we cannot do that easily since there are too many breaking changes, we might only fix this in 1.4
GiteaMirror commented 2026-04-17 18:42:45 -05:00
Author
Owner
Copy Link

@rohovskoi commented on GitHub (Oct 28, 2025):

Thank you!

1.4xx is fine @himself65

I'm using 1.4 beta 13 anyway :)

<!-- gh-comment-id:3453947191 --> @rohovskoi commented on GitHub (Oct 28, 2025): Thank you! 1.4xx is fine @himself65 I'm using 1.4 beta 13 anyway :)
GiteaMirror commented 2026-04-17 18:42:46 -05:00
Author
Owner
Copy Link

@ghassenbenghorbal commented on GitHub (Oct 28, 2025):

I switched to 1.4.0-beta.14 and still same issue:
src/auth.ts(16,14): error TS2742: The inferred type of 'auth' cannot be named without a reference to '.bun/better-call@1.0.24/node_modules/better-call'. This is likely not port able. A type annotation is necessary.

This happens when you use additionalFields in a monorepo (turning declarations to false doesn't fix the issue).
Here is an issue I opened weeks ago which has all the details #5122

<!-- gh-comment-id:3456341626 --> @ghassenbenghorbal commented on GitHub (Oct 28, 2025): I switched to 1.4.0-beta.14 and still same issue: `src/auth.ts(16,14): error TS2742: The inferred type of 'auth' cannot be named without a reference to '.bun/better-call@1.0.24/node_modules/better-call'. This is likely not port able. A type annotation is necessary.` This happens when you use additionalFields in a monorepo (turning declarations to false doesn't fix the issue). Here is an issue I opened weeks ago which has all the details #5122
GiteaMirror commented 2026-04-17 18:42:46 -05:00
Author
Owner
Copy Link

@rohovskoi commented on GitHub (Oct 28, 2025):

@ghassenbenghorbal add it to direct deps of your package.

<!-- gh-comment-id:3458274445 --> @rohovskoi commented on GitHub (Oct 28, 2025): @ghassenbenghorbal add it to direct deps of your package.
GiteaMirror commented 2026-04-17 18:42:49 -05:00
Author
Owner
Copy Link

@ChristianIvicevic commented on GitHub (Nov 1, 2025):

@ghassenbenghorbal add it to direct deps of your package.

I don't think it's good DX having to declare some arbitrary packages as additional dependencies when they should be supplied by better-auth directly. Doing your recommended workaround is just a bandaid for a bigger issue outlined in #5666

<!-- gh-comment-id:3476963124 --> @ChristianIvicevic commented on GitHub (Nov 1, 2025): > [@ghassenbenghorbal](https://github.com/ghassenbenghorbal) add it to direct deps of your package. I don't think it's good DX having to declare some arbitrary packages as additional dependencies when they should be supplied by better-auth directly. Doing your recommended workaround is just a bandaid for a bigger issue outlined in #5666
GiteaMirror commented 2026-04-17 18:42:50 -05:00
Author
Owner
Copy Link

@better-auth-agent[bot] commented on GitHub (Nov 1, 2025):

It appears that the new versions are exposing an underlying type‐inference issue—specifically, the generated types become too long and include a reference to “better‑call” when using the organization plugin. In the issue discussion, a contributor recommended adding “better‑call” as a direct dependency in your package as a short‑term workaround. That means until a fix is released, you can either:

• Add “better‑call” (version 1.0.24 in this case) to your package’s direct dependencies so that the compiler can resolve the reference correctly, or
• Add explicit type annotations to your auth configuration to limit the inferred type length, which is admittedly less ideal for developer experience.

Both approaches are temporary measures to bypass the TS7056 and TS2742 errors until the core issue (which affects type inference with the organization plugin) is properly resolved in an upcoming Better Auth release. The recommended workaround is not ideal from a DX perspective and should be considered a bandaid, as noted by other users in the discussion [1].

Diagram • Discord • GitHub

Diagram Join Star

<!-- gh-comment-id:3476963305 --> @better-auth-agent[bot] commented on GitHub (Nov 1, 2025): It appears that the new versions are exposing an underlying type‐inference issue—specifically, the generated types become too long and include a reference to “better‑call” when using the organization plugin. In the issue discussion, a contributor recommended adding “better‑call” as a direct dependency in your package as a short‑term workaround. That means until a fix is released, you can either: • Add “better‑call” (version 1.0.24 in this case) to your package’s direct dependencies so that the compiler can resolve the reference correctly, or • Add explicit type annotations to your auth configuration to limit the inferred type length, which is admittedly less ideal for developer experience. Both approaches are temporary measures to bypass the TS7056 and TS2742 errors until the core issue (which affects type inference with the organization plugin) is properly resolved in an upcoming Better Auth release. The recommended workaround is not ideal from a DX perspective and should be considered a bandaid, as noted by other users in the discussion [[1]](https://github.com/better-auth/better-auth/issues/5574). <!-- bot:webhook reply v1 --> [Diagram](https://repodiagrams.s3.eu-north-1.amazonaws.com/better-auth_ultra_detailed_interactive.html) • [Discord](https://discord.gg/better-auth) • [GitHub](https://github.com/better-auth/better-auth) [![Diagram](https://img.shields.io/badge/Diagram-2b3137?style=flat-square)](https://repodiagrams.s3.eu-north-1.amazonaws.com/better-auth_ultra_detailed_interactive.html) [![Join](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&style=flat-square)](https://discord.gg/better-auth) [![Star](https://img.shields.io/badge/star-181717?logo=github&logoColor=white&style=flat-square)](https://github.com/better-auth/better-auth)
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 bug locked
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#27612
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?