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 #5666] Systemic type issues across better-* packages ("cannot be named without a reference") (proposed parent issue) #27642

New Issue
Open
opened 2026-04-17 18:45:34 -05:00 by GiteaMirror · 35 comments
GiteaMirror commented 2026-04-17 18:45:34 -05:00
Owner
Copy Link

Originally created by @firxworx on GitHub (Oct 29, 2025).
Original GitHub issue: https://github.com/better-auth/better-auth/issues/5666

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.

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

https://github.com/better-auth/better-auth/issues/2123#issuecomment-3464227691

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

Originally created by @firxworx on GitHub (Oct 29, 2025). Original GitHub issue: https://github.com/better-auth/better-auth/issues/5666 ### Is this suited for github? - [x] 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. - https://github.com/better-auth/better-auth/issues/2123#issuecomment-3457437942 (read the comments this issue is absolutely not closed) - https://github.com/better-auth/better-auth/issues/5637 - https://github.com/better-auth/better-auth/issues/5122 - https://github.com/better-auth/better-auth/issues/4250 - https://github.com/better-auth/better-auth/issues/2036 In issue #2142 I added a comment with a workaround here for those using drizzle adapter: https://github.com/better-auth/better-auth/issues/2123#issuecomment-3464227691 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 ```bash { "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) ```typescript import { betterAuth } from "better-auth" export const auth = betterAuth({ emailAndPassword: { enabled: true }, }); ``` ### Additional context _No response_
GiteaMirror added the trackingcoreneeds: infobug labels 2026-04-17 18:45:34 -05:00
GiteaMirror commented 2026-04-17 18:45:36 -05:00
Author
Owner
Copy Link

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

Based on similar reports, these errors tend to arise when internal types used across the better‑* packages aren’t explicitly exported or properly re‐referenced. This leads to circular or overly “deep” type instantiations that break portability, especially in monorepo setups using strict package managers like pnpm [1][2].

Here are some next steps:

  1. Confirm that every better‑* package (e.g. better‑auth, better‑call, etc.) is updated to the same or at least compatible versions. Version skews can lead to different internal references that are hard for TypeScript to reconcile [1].

  2. In your project (especially on monorepos), consider manually adding explicit type annotations when instantiating auth (or similar constructs). A helper function—similar to a “defineConfig” pattern—could be implemented so that both the input and return types are fixed, ensuring that deeper type references are properly tied to their exported sources. This also encourages earlier validation of any misconfiguration before even compiling [2].

  3. Check your tsconfig settings (like exactOptionalPropertyTypes) and try to keep stricter type options consistent across packages. Some issues have been alleviated by enforcing a consistent TS configuration across the monorepo [3].

  4. Follow or contribute to ongoing discussions on GitHub. As many developers have noted a “web of interdependent types” causing these errors, a collaborative solution (with re-exporting of the necessary types or redesigned internal references) might be available soon [1][3].

While workarounds using type assertions (like casting) may temporarily quiet TypeScript, the goal is to eliminate them entirely by making sure that the better‑* ecosystem provides a single source of truth for its types. Consider opening a consolidated issue (or commenting on the existing parent issue) to advocate for the “defineConfig” helper approach, which has been suggested as a long‑term fix [2].

Let me know if you have any further questions or need additional troubleshooting steps.

Diagram • Discord • GitHub

Diagram Join Star

<!-- gh-comment-id:3464536519 --> @better-auth-agent[bot] commented on GitHub (Oct 29, 2025): Based on similar reports, these errors tend to arise when internal types used across the better‑* packages aren’t explicitly exported or properly re‐referenced. This leads to circular or overly “deep” type instantiations that break portability, especially in monorepo setups using strict package managers like pnpm [[1]](https://github.com/better-auth/better-auth/issues/2123)[[2]](https://github.com/better-auth/better-auth/issues/4250). Here are some next steps: 1. Confirm that every better‑* package (e.g. better‑auth, better‑call, etc.) is updated to the same or at least compatible versions. Version skews can lead to different internal references that are hard for TypeScript to reconcile [[1]](https://github.com/better-auth/better-auth/issues/2123). 2. In your project (especially on monorepos), consider manually adding explicit type annotations when instantiating auth (or similar constructs). A helper function—similar to a “defineConfig” pattern—could be implemented so that both the input and return types are fixed, ensuring that deeper type references are properly tied to their exported sources. This also encourages earlier validation of any misconfiguration before even compiling [[2]](https://github.com/better-auth/better-auth/issues/4250). 3. Check your tsconfig settings (like exactOptionalPropertyTypes) and try to keep stricter type options consistent across packages. Some issues have been alleviated by enforcing a consistent TS configuration across the monorepo [[3]](https://github.com/better-auth/better-auth/issues/1660). 4. Follow or contribute to ongoing discussions on GitHub. As many developers have noted a “web of interdependent types” causing these errors, a collaborative solution (with re-exporting of the necessary types or redesigned internal references) might be available soon [[1]](https://github.com/better-auth/better-auth/issues/2123)[[3]](https://github.com/better-auth/better-auth/issues/1660). While workarounds using type assertions (like casting) may temporarily quiet TypeScript, the goal is to eliminate them entirely by making sure that the better‑* ecosystem provides a single source of truth for its types. Consider opening a consolidated issue (or commenting on the existing parent issue) to advocate for the “defineConfig” helper approach, which has been suggested as a long‑term fix [[2]](https://github.com/better-auth/better-auth/issues/4250). Let me know if you have any further questions or need additional troubleshooting steps. <!-- 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)
GiteaMirror commented 2026-04-17 18:45:36 -05:00
Author
Owner
Copy Link

@firxworx commented on GitHub (Oct 29, 2025):

Regarding some internal types getting out I wonder aloud if currying plays a factor. Its a fine practice but beware of how types can come along for the ride with the signature.

For example when investigating issue with the Drizzle adapter and DBAdapter type I saw:

declare const drizzleAdapter: (db: DB, config: DrizzleAdapterConfig) => (options: BetterAuthOptions) => DBAdapter<BetterAuthOptions>;

And type disagreements just so happen to be related to what DBAdapter and BetterAuthOptions are between packages.

<!-- gh-comment-id:3464557908 --> @firxworx commented on GitHub (Oct 29, 2025): Regarding some internal types getting out I wonder aloud if currying plays a factor. Its a fine practice but beware of how types can come along for the ride with the signature. For example when investigating issue with the Drizzle adapter and `DBAdapter` type I saw: ```ts declare const drizzleAdapter: (db: DB, config: DrizzleAdapterConfig) => (options: BetterAuthOptions) => DBAdapter<BetterAuthOptions>; ``` And type disagreements just so happen to be related to what `DBAdapter` and `BetterAuthOptions` are between packages.
GiteaMirror commented 2026-04-17 18:45:37 -05:00
Author
Owner
Copy Link

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

Based on the summary provided, the following next steps and troubleshooting guidelines are recommended:

  1. Introduce a configuration helper (e.g., a defineConfig function) that explicitly validates the Better Auth options. This helper would ensure that the public export has a fixed, well‐defined type interface even when internal types are curryed or derived from multiple source packages [1].

  2. Audit the internal type dependencies across the better-* packages so that types used in function signatures (such as in the Drizzle adapter’s DBAdapter) are either re-exported from a central, stable source or inlined into the public API. Doing so minimizes the leakage of internal types and prevents mismatches between versions [2].

  3. Consider refactoring curried functions to supply intermediate type annotations. Instead of relying on inferred types from interconnected functions, use explicit type annotations for parameters and returns where these types cross package boundaries. This reduces the “cannot be named without a reference” errors seen in monorepo setups with strict package managers [3].

  4. Verify that the build configuration (e.g., for TypeScript in monorepos using pnpm) is set so that type serialization limits are not exceeded. Adjust compiler options if necessary, but the long‑term fix should be improving the public type stability rather than relying on workarounds with assertions or disabling declarations [4].

In summary, the immediate next steps should be to centralize and simplify the exposure of public types, introduce a helper that validates config objects at compile time, and refactor curried or chained type definitions to avoid carrying internal type details across module boundaries. This will help ensure that Better Auth’s promise of TypeScript safety is maintained, even in monorepos and with varied package manager setups [1], [2], [3].

Diagram • Discord • GitHub

Diagram Join Star

<!-- gh-comment-id:3464561457 --> @better-auth-agent[bot] commented on GitHub (Oct 29, 2025): Based on the summary provided, the following next steps and troubleshooting guidelines are recommended: 1. Introduce a configuration helper (e.g., a defineConfig function) that explicitly validates the Better Auth options. This helper would ensure that the public export has a fixed, well‐defined type interface even when internal types are curryed or derived from multiple source packages [[1]](https://github.com/better-auth/better-auth/issues/2123). 2. Audit the internal type dependencies across the better-* packages so that types used in function signatures (such as in the Drizzle adapter’s DBAdapter<BetterAuthOptions>) are either re-exported from a central, stable source or inlined into the public API. Doing so minimizes the leakage of internal types and prevents mismatches between versions [[2]](https://github.com/better-auth/better-auth/issues/4250). 3. Consider refactoring curried functions to supply intermediate type annotations. Instead of relying on inferred types from interconnected functions, use explicit type annotations for parameters and returns where these types cross package boundaries. This reduces the “cannot be named without a reference” errors seen in monorepo setups with strict package managers [[3]](https://github.com/better-auth/better-auth/issues/1660). 4. Verify that the build configuration (e.g., for TypeScript in monorepos using pnpm) is set so that type serialization limits are not exceeded. Adjust compiler options if necessary, but the long‑term fix should be improving the public type stability rather than relying on workarounds with assertions or disabling declarations [[4]](https://github.com/better-auth/better-auth/issues/1391). In summary, the immediate next steps should be to centralize and simplify the exposure of public types, introduce a helper that validates config objects at compile time, and refactor curried or chained type definitions to avoid carrying internal type details across module boundaries. This will help ensure that Better Auth’s promise of TypeScript safety is maintained, even in monorepos and with varied package manager setups [[1]](https://github.com/better-auth/better-auth/issues/2123), [[2]](https://github.com/better-auth/better-auth/issues/4250), [[3]](https://github.com/better-auth/better-auth/issues/1660). <!-- 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)
GiteaMirror commented 2026-04-17 18:45:38 -05:00
Author
Owner
Copy Link

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

Type generics in the lib are breaking based on various props. I had the same issue with this config:

export const auth = (env: Env, db: DrizzleD1Database) => {
  return betterAuth({
    database: drizzleAdapter(db, {
      provider: 'sqlite',
      usePlural: true,
      schema
    }),
    baseURL: env.BETTER_AUTH_URL,
    secret: env.BETTER_AUTH_SECRET
  });
};

This issue was the presence of drizzleAdapter, luckily, v1.3.34 update fixed the issue.

Now, there is another type of problem when I include mapProfileToUser, e.g.

export const auth = (env: Env, db: DrizzleD1Database) => {
  return betterAuth({
    database: drizzleAdapter(db, {
      provider: 'sqlite',
      usePlural: true,
      schema
    }),
    baseURL: env.BETTER_AUTH_URL,
    secret: env.BETTER_AUTH_SECRET,
    socialProviders: {
      discord: {
        clientId: env.DISCORD_CLIENT_ID,
        clientSecret: env.DISCORD_CLIENT_SECRET,
        disableDefaultScope: true,
        scope: ['identify'],
        mapProfileToUser: async (profile) => {
          return {
            email: profile.id + '@discord-id.com'
          };
        }
      }
    },
  });
};

If I remove mapProfileToUser, the problem is gone which I can't do because I need it. Is there a workaround, perhaps to fake some mapProfileToUser return type to avoid the TS error?

updated

So it seems this type override silences the error (any for the argument):

mapProfileToUser: async (profile: any) => {
  return {
    email: profile.id + '@discord-id.com'
  };
}
<!-- gh-comment-id:3476329530 --> @quirm commented on GitHub (Nov 1, 2025): Type generics in the lib are breaking based on various props. I had the same issue with this config: ```typescript export const auth = (env: Env, db: DrizzleD1Database) => { return betterAuth({ database: drizzleAdapter(db, { provider: 'sqlite', usePlural: true, schema }), baseURL: env.BETTER_AUTH_URL, secret: env.BETTER_AUTH_SECRET }); }; ``` This issue was the presence of `drizzleAdapter`, luckily, [v1.3.34](https://github.com/better-auth/better-auth/releases/tag/v1.3.34) update fixed the issue. Now, there is another type of problem when I include `mapProfileToUser`, e.g. ```typescript export const auth = (env: Env, db: DrizzleD1Database) => { return betterAuth({ database: drizzleAdapter(db, { provider: 'sqlite', usePlural: true, schema }), baseURL: env.BETTER_AUTH_URL, secret: env.BETTER_AUTH_SECRET, socialProviders: { discord: { clientId: env.DISCORD_CLIENT_ID, clientSecret: env.DISCORD_CLIENT_SECRET, disableDefaultScope: true, scope: ['identify'], mapProfileToUser: async (profile) => { return { email: profile.id + '@discord-id.com' }; } } }, }); }; ``` If I remove `mapProfileToUser`, the problem is gone which I can't do because I need it. Is there a workaround, perhaps to fake some `mapProfileToUser` return type to avoid the TS error? **updated** So it seems this type override silences the error (`any` for the argument): ```typescript mapProfileToUser: async (profile: any) => { return { email: profile.id + '@discord-id.com' }; } ```
GiteaMirror commented 2026-04-17 18:45:38 -05:00
Author
Owner
Copy Link

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

The recommended workaround is to help the compiler by explicitly annotating the return type of your mapProfileToUser function. In your case, do something like:

  mapProfileToUser: async (profile: DiscordProfile): Promise<{ email: string }> => {
    return { email: profile.id + '@discord-id.com' };
  }

Doing so provides the compiler with a fixed and exportable type instead of inferring the complex generic type from the context—which is what causes the error. This approach avoids relying on escape hatches like as-casts and maintains stricter type safety [1].

Another next step is to consider wrapping your auth configuration by using a defineConfig() helper function (or similar) that enforces the output type at the boundary. That could help not only for mapProfileToUser but for all parts of your configuration and create a single source of truth for internal types [2].

Both methods can mitigate the issue until a more permanent fix or internal refactoring is applied.

Diagram • Discord • GitHub

Diagram Join Star

<!-- gh-comment-id:3476329720 --> @better-auth-agent[bot] commented on GitHub (Nov 1, 2025): The recommended workaround is to help the compiler by explicitly annotating the return type of your mapProfileToUser function. In your case, do something like:   mapProfileToUser: async (profile: DiscordProfile): Promise<{ email: string }> => {     return { email: profile.id + '@discord-id.com' };   } Doing so provides the compiler with a fixed and exportable type instead of inferring the complex generic type from the context—which is what causes the error. This approach avoids relying on escape hatches like as-casts and maintains stricter type safety [[1]](https://github.com/better-auth/better-auth/issues/5666). Another next step is to consider wrapping your auth configuration by using a defineConfig() helper function (or similar) that enforces the output type at the boundary. That could help not only for mapProfileToUser but for all parts of your configuration and create a single source of truth for internal types [[2]](https://github.com/better-auth/better-auth/issues/1391). Both methods can mitigate the issue until a more permanent fix or internal refactoring is applied. <!-- 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)
GiteaMirror commented 2026-04-17 18:45:40 -05:00
Author
Owner
Copy Link

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

It sounds like the problem lies in how TypeScript infers the return type of your social provider’s profile mapping. One effective workaround is to add an explicit return type annotation to your mapProfileToUser callback. For example, instead of writing:

  mapProfileToUser: async (profile) => {
    return { email: profile.id + '@discord-id.com' };
  }

try explicitly giving it a type like so:

  mapProfileToUser: async (profile): Promise<{ email: string }> => {
    return { email: profile.id + '@discord-id.com' };
  }

This forces the function to conform to a known structure and prevents the compiler from trying to “infer” a type that cannot be named without an internal reference [1]. In addition, if your library supports a helper (or you decide to create one) like defineConfig() (similar to those in other libraries), that could help check the whole configuration and lock in the types, reducing the reliance on inference across interdependent modules [2].

If the issue persists—even after explicitly annotating—the root cause might be deeper in how the types of different better-* packages interact. In that case, you may consider temporarily casting the function with an assertion (only as a stopgap) until a more permanent fix is made in a future release. However, note that using escape hatches like casting is not ideal because it bypasses type safety [1].

Keep your package updated—since the v1.3.34 update already fixed similar issues with the drizzle adapter—and check the release notes for any further improvements for social provider type inference. This should help maintain proper type safety without a significant workaround.

Please let me know if you need further help or have more details.

Diagram • Discord • GitHub

Diagram Join Star

<!-- gh-comment-id:3476330333 --> @better-auth-agent[bot] commented on GitHub (Nov 1, 2025): It sounds like the problem lies in how TypeScript infers the return type of your social provider’s profile mapping. One effective workaround is to add an explicit return type annotation to your mapProfileToUser callback. For example, instead of writing:   mapProfileToUser: async (profile) => {     return { email: profile.id + '@discord-id.com' };   } try explicitly giving it a type like so:   mapProfileToUser: async (profile): Promise<{ email: string }> => {     return { email: profile.id + '@discord-id.com' };   } This forces the function to conform to a known structure and prevents the compiler from trying to “infer” a type that cannot be named without an internal reference [[1]](https://github.com/better-auth/better-auth/issues/5666). In addition, if your library supports a helper (or you decide to create one) like defineConfig() (similar to those in other libraries), that could help check the whole configuration and lock in the types, reducing the reliance on inference across interdependent modules [[2]](https://github.com/better-auth/better-auth/issues/1391). If the issue persists—even after explicitly annotating—the root cause might be deeper in how the types of different better-* packages interact. In that case, you may consider temporarily casting the function with an assertion (only as a stopgap) until a more permanent fix is made in a future release. However, note that using escape hatches like casting is not ideal because it bypasses type safety [[1]](https://github.com/better-auth/better-auth/issues/5666). Keep your package updated—since the v1.3.34 update already fixed similar issues with the drizzle adapter—and check the release notes for any further improvements for social provider type inference. This should help maintain proper type safety without a significant workaround. Please let me know if you need further help or have more details. <!-- 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)
GiteaMirror commented 2026-04-17 18:45:41 -05:00
Author
Owner
Copy Link

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

The underlying issue is that the inferred types for social provider callbacks (like mapProfileToUser) don’t perfectly align with what the library expects. The v1.3.34 update fixed the problems related to drizzleAdapter, but the mapProfileToUser callback still suffers from overly complex inferred generics. One temporary workaround is to provide an explicit type for the callback’s argument so that TypeScript doesn’t try to infer an overly deep type.

For example, if you currently have:

  mapProfileToUser: async (profile) => { … }

you can change it to something like:

  mapProfileToUser: async (profile: any) => {
    return { email: profile.id + '@discord-id.com' };
  },

This bypasses the error by “faking” the type, even though using any is essentially an escape hatch. Another approach is to define (and export) an interface that represents the subset of properties you need from the profile, and then use that type instead of any. This keeps the code more type-safe than a blanket any while still avoiding the deep inference issues.

We recommend that you use an explicit annotation for mapProfileToUser’s parameter (or even annotate its return type if needed) until the library provides a more robust fix. This ensures that your overall configuration retains clearer types without forcing developers to use unsafe casts everywhere [1], [2].

Diagram • Discord • GitHub

Diagram Join Star

<!-- gh-comment-id:3476336655 --> @better-auth-agent[bot] commented on GitHub (Nov 1, 2025): The underlying issue is that the inferred types for social provider callbacks (like mapProfileToUser) don’t perfectly align with what the library expects. The v1.3.34 update fixed the problems related to drizzleAdapter, but the mapProfileToUser callback still suffers from overly complex inferred generics. One temporary workaround is to provide an explicit type for the callback’s argument so that TypeScript doesn’t try to infer an overly deep type. For example, if you currently have:   mapProfileToUser: async (profile) => { … } you can change it to something like:   mapProfileToUser: async (profile: any) => {     return { email: profile.id + '@discord-id.com' };   }, This bypasses the error by “faking” the type, even though using any is essentially an escape hatch. Another approach is to define (and export) an interface that represents the subset of properties you need from the profile, and then use that type instead of any. This keeps the code more type-safe than a blanket any while still avoiding the deep inference issues. We recommend that you use an explicit annotation for mapProfileToUser’s parameter (or even annotate its return type if needed) until the library provides a more robust fix. This ensures that your overall configuration retains clearer types without forcing developers to use unsafe casts everywhere [[1]](https://github.com/better-auth/better-auth/issues/5666), [[2]](https://github.com/better-auth/better-auth/issues/1391). <!-- 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)
GiteaMirror commented 2026-04-17 18:45:41 -05:00
Author
Owner
Copy Link

@firxworx commented on GitHub (Nov 7, 2025):

@quirm its not fixed with better-auth 1.3.34 but I was able to use an inline config very recently when I bumped its dependency better-call to latest 1.0.26 (I declare it as an explicit dependency).

I am not sure if this impacts mapProfileToUser though.

I still suspect the core problem is the constantly in-flux interdependencies amongst better-* packages of different (and ever changing) version numbers that don't appear to have consistent type exports nor consistent sources of truth (wiki) between them.

That's why I think this is a systemic issue that can frustratingly disappear and reappear between different versions of better-auth and/or one or more of its dependencies and it can feel almost random about what feature/plugin of better-auth is impacted.

<!-- gh-comment-id:3499939008 --> @firxworx commented on GitHub (Nov 7, 2025): @quirm its not fixed with better-auth 1.3.34 but I was able to use an inline config very recently when I bumped its dependency better-call to latest 1.0.26 (I declare it as an explicit dependency). I am not sure if this impacts mapProfileToUser though. I still suspect the core problem is the constantly in-flux interdependencies amongst `better-*` packages of different (and ever changing) version numbers that don't appear to have consistent type exports nor consistent [sources of truth](https://en.wikipedia.org/wiki/Single_source_of_truth) (wiki) between them. That's why I think this is a systemic issue that can frustratingly disappear and reappear between different versions of better-auth and/or one or more of its dependencies and it can feel almost random about what feature/plugin of better-auth is impacted.
GiteaMirror commented 2026-04-17 18:45:42 -05:00
Author
Owner
Copy Link

@himself65 commented on GitHub (Nov 14, 2025):

I think we have fixed this in 1.4. So I'm closing. feel free to open a new type issue for 1.4

<!-- gh-comment-id:3531187376 --> @himself65 commented on GitHub (Nov 14, 2025): I think we have fixed this in 1.4. So I'm closing. feel free to open a new type issue for 1.4
GiteaMirror commented 2026-04-17 18:45:43 -05:00
Author
Owner
Copy Link

@chandlj commented on GitHub (Nov 17, 2025):

@himself65 I'm also still getting this on v1.4-beta.21, so I definitely don't think it's fixed

<!-- gh-comment-id:3539835362 --> @chandlj commented on GitHub (Nov 17, 2025): @himself65 I'm also still getting this on v1.4-beta.21, so I definitely don't think it's fixed
GiteaMirror commented 2026-04-17 18:45:44 -05:00
Author
Owner
Copy Link

@sanny-io commented on GitHub (Nov 17, 2025):

I solved this issue by directly installing into my project whatever packages appeared in the error messages. @firxworx also touched on this point.

In the case of this error message:

.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

You would install:

  • @better-auth/core
  • @better-auth/utils
  • @better-fetch/fetch

In his case, all he needed to install was @better-auth/core, so you might just need to install whatever package appears first. Anyways, make sure the versions you are installing match up with whatever version is expected by the package importing it, and remember that you should install whatever packages appear in your own error messages, because it's not going to always be the same between projects.

@chandlj hopefully this helps you until the issue is resolved.

<!-- gh-comment-id:3539937186 --> @sanny-io commented on GitHub (Nov 17, 2025): I solved this issue by directly installing into my project whatever packages appeared in the error messages. @firxworx also touched on this point. In the case of this error message: `.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` You would install: - `@better-auth/core` - `@better-auth/utils` - `@better-fetch/fetch` In his case, all he needed to install was `@better-auth/core`, so you might just need to install whatever package appears first. Anyways, make sure the versions you are installing match up with whatever version is expected by the package importing it, and remember that you should install whatever packages appear in your own error messages, because it's not going to always be the same between projects. @chandlj hopefully this helps you until the issue is resolved.
GiteaMirror commented 2026-04-17 18:45:44 -05:00
Author
Owner
Copy Link

@chandlj commented on GitHub (Nov 17, 2025):

@sanny-io Thanks for the detailed reply! Unfortunately, this did not fix the issue in my case.

For me, I specifically have the following 4 type errors:

  • ../../../node_modules/.pnpm/@better-auth+core@1.4.0-beta.21_@better-auth+utils@0.3.0_@better-fetch+fetch@1.1.18_bet_7022cd786dbb2390cc096c41f7e74fe4/node_modules/@better-auth/core/dist/index-DX7czw7K.mjs.
  • ../../../node_modules/.pnpm/better-call@1.0.26/node_modules/better-call/dist/router-BH6Wndse
  • ../node_modules/better-auth/dist/index-6ni7_s3n.mjs
  • ../node_modules/better-auth/dist/index-DdIAwzpJ.mjs

The only thing that has consistently worked has been turning off declarations in my tsconfig.json. I have tried installing the individuals packages as you mentioned as well as manually typecasting with as ReturnType<typeof betterAuth<typeof config>> which also did not work. If you have other suggestions for how to fix this, that would be great.

Regardless, I do think that this issue should be reopened as 1.4.xx does not fix it.

<!-- gh-comment-id:3542132576 --> @chandlj commented on GitHub (Nov 17, 2025): @sanny-io Thanks for the detailed reply! Unfortunately, this did not fix the issue in my case. For me, I specifically have the following 4 type errors: - `../../../node_modules/.pnpm/@better-auth+core@1.4.0-beta.21_@better-auth+utils@0.3.0_@better-fetch+fetch@1.1.18_bet_7022cd786dbb2390cc096c41f7e74fe4/node_modules/@better-auth/core/dist/index-DX7czw7K.mjs`. - `../../../node_modules/.pnpm/better-call@1.0.26/node_modules/better-call/dist/router-BH6Wndse` - `../node_modules/better-auth/dist/index-6ni7_s3n.mjs` - `../node_modules/better-auth/dist/index-DdIAwzpJ.mjs` The only thing that has consistently worked has been turning off `declarations` in my `tsconfig.json`. I have tried installing the individuals packages as you mentioned as well as manually typecasting with `as ReturnType<typeof betterAuth<typeof config>>` which also did not work. If you have other suggestions for how to fix this, that would be great. Regardless, I do think that this issue should be reopened as 1.4.xx does not fix it.
GiteaMirror commented 2026-04-17 18:45:45 -05:00
Author
Owner
Copy Link

@firxworx commented on GitHub (Nov 18, 2025):

@himself65 as you can see from the commenters its not fixed.

CC @Bekacru (and thank-you for creating better-auth)

When I wrote the issue I worded it as a systemic type issue for a reason: I proposed it to be an issue to "catch all" the stream of extremely related type issues that devs are experiencing.

I was hoping that highlighting that the cluster of related recurring "spot" type issues appear to be symptoms of a greater common issue would help draw your team's attention to it.

Type issues appearing and disappearing even between patch versions is the core issue.

The whack-a-mole "fixes" from version to version are not addressing the underlying causes of this and focusing on what fixes one spot issue appears to lead to other spot issues.

A true fix may involve considering the collective better-* packages and how they relate to each other, who is the source of what truth, and how they get versioned together.

Please re-open this issue.

Only half-joking: I can smell a PM somewhere.

I know its not y'all. Please pull 'em aside or go above em LOL.

  • your internal projects will likely be impacted as you aim to commercialize and scale your paid offerings
  • those hit hardest by this issue are perhaps your target customers for paid offerings: those working on larger and more complex apps in monorepos (devs with budgets)
  • headaches with bumping minor or even patch versions is a concern for a auth/security minded library where its often a good practice to keep up-to-date as security issues get fixed
  • developer pain conflicts with better auth's stated goals and raison d'être

Perhaps a few hours of a next-level consulting TypeScript wizard's efforts could help sort through without impacting team velocity. Congrats on the funding, yay for a use for it!

I truly appreciate the work you put into better-auth and I believe it is destined for great things!

<!-- gh-comment-id:3549816899 --> @firxworx commented on GitHub (Nov 18, 2025): @himself65 as you can see from the commenters its not fixed. CC @Bekacru (and thank-you for creating better-auth) When I wrote the issue I worded it as a _systemic_ type issue for a reason: I proposed it to be an issue to "catch all" the stream of extremely related type issues that devs are experiencing. I was hoping that highlighting that the cluster of related recurring "spot" type issues appear to be _symptoms_ of a greater common issue would help draw your team's attention to it. Type issues appearing and disappearing even between patch versions _is the core issue_. The whack-a-mole "fixes" from version to version are _not_ addressing the underlying causes of this and focusing on what fixes one spot issue appears to lead to other spot issues. A true fix may involve considering the collective `better-*` packages and how they relate to each other, who is the source of what truth, and how they get versioned together. Please re-open this issue. ---- Only half-joking: I can _smell_ a PM somewhere. I know its not y'all. Please pull 'em aside or go above em LOL. - your internal projects will likely be impacted as you aim to commercialize and scale your paid offerings - those hit hardest by this issue are perhaps your target customers for paid offerings: those working on larger and more complex apps in monorepos (devs with budgets) - headaches with bumping minor or even patch versions is a concern for a auth/security minded library where its often a good practice to keep up-to-date as security issues get fixed - developer pain conflicts with better auth's stated goals and _raison d'être_ Perhaps a few hours of a next-level consulting TypeScript wizard's efforts could help sort through without impacting team velocity. Congrats on the funding, yay for a use for it! I truly appreciate the work you put into better-auth and I believe it is destined for great things!
GiteaMirror commented 2026-04-17 18:45:46 -05:00
Author
Owner
Copy Link

@himself65 commented on GitHub (Nov 18, 2025):

Do you have repo so I can reproduce?

<!-- gh-comment-id:3549824957 --> @himself65 commented on GitHub (Nov 18, 2025): Do you have repo so I can reproduce?
GiteaMirror commented 2026-04-17 18:45:47 -05:00
Author
Owner
Copy Link

@chandlj commented on GitHub (Nov 18, 2025):

@himself65 I can't give you mine (proprietary) but I can give you rough instructions to reproduce:

  1. Make a shadcn monorepo with Next.js: https://ui.shadcn.com/docs/monorepo
  2. Add better-auth and drizzle (not sure how important this is but this is just what I have) to the Next.js package
  3. Attempt to create auth.ts and view the error.

Hopefully this is enough to reproduce, if you don't see it let me know

<!-- gh-comment-id:3549856652 --> @chandlj commented on GitHub (Nov 18, 2025): @himself65 I can't give you mine (proprietary) but I can give you rough instructions to reproduce: 1. Make a shadcn monorepo with Next.js: https://ui.shadcn.com/docs/monorepo 2. Add better-auth and drizzle (not sure how important this is but this is just what I have) to the Next.js package 3. Attempt to create `auth.ts` and view the error. Hopefully this is enough to reproduce, if you don't see it let me know
GiteaMirror commented 2026-04-17 18:45:48 -05:00
Author
Owner
Copy Link

@firxworx commented on GitHub (Nov 19, 2025):

@himself65 thank-you for reopening, hugely appreciated :)

I don't have a good repo handy to share though I may have time later this week.

In the meantime, looking at the issues and the recurring "whack a mole" problem that spans across many configurations and plugins, I would propose a purpose-built "type issue detector" monorepo to shine a light on this.

I'd suggest using pnpm because its very anal about dependencies and use ESM. Plus there's nice at-a-glance feedback of the "web" of dependent better-* packages and versions at play in Intellisense for any given issue e.g. see @sanny-io comment above.

Use syncpack

As you play with dependency versions syncpack helps ensure they mutually agree with each other across different apps/packages in your workspace to provide confidence you aren't introducing issues of your own specific to the workspace vs. better-auth.

Test Auth Packages

Add a bunch of discrete auth packages to isolate the dependencies e.g. @workspace/auth-with-drizzle-sqlite under packages/auth-with-drizzle-sqlite.

For each test package define and export a better-auth auth instance (and/or a factory that returns it) plus type definitions that are inferred from the instance and/or its configuration object. Do not use any as casts or other type cheats.

I think you'd want to cover a bunch of cases e.g.

  • auth-with-drizzle-sqlite.ts
  • auth-with-organization-plugin.ts
  • etc.

Plus perhaps a few kitchen sink configurations that replicate popular combinations of features and plugins, inspired from all the different issues and commenters of the past and their affected configurations.

  • Ensure the packages define exports properly
  • Add a typecheck script using tsc

It is pretty much guaranteed at this point that you will find cases where type checks fail.

Remember to ensure your IDE e.g. VSCode is configured to use the workspace "package version" of TypeScript so you can see the issues properly in your editor and so it agrees with tsc results: "typescript.tsdk": "node_modules/typescript/lib".

Test Dependents

To go the full 9 yards, you could add an app/package or two that have an auth package as a dependency and have a module where you import and use the auth instance.

To get good detection you could ensure you make use of or reference the types/properties that would be conditionally impacted by the particular configuration being tested.

The idea is you could see how type checks fail or see first hand how the consuming app/packages can have issues resolving types.

You could use purpose-built type testing packages to confirm expected equivalencies however I don't think they're necessary.

<!-- gh-comment-id:3550482433 --> @firxworx commented on GitHub (Nov 19, 2025): @himself65 thank-you for reopening, hugely appreciated :) I don't have a good repo handy to share though I may have time later this week. In the meantime, looking at the issues and the recurring "whack a mole" problem that spans across many configurations and plugins, I would propose a purpose-built "type issue detector" monorepo to shine a light on this. I'd suggest using pnpm because its very anal about dependencies and use ESM. Plus there's nice at-a-glance feedback of the "web" of dependent `better-*` packages and versions at play in Intellisense for any given issue e.g. see @sanny-io comment above. **Use `syncpack`** As you play with dependency versions `syncpack` helps ensure they mutually agree with each other across different apps/packages in your workspace to provide confidence you aren't introducing issues of your own specific to the workspace vs. better-auth. **Test Auth Packages** Add a bunch of discrete auth packages to isolate the dependencies e.g. `@workspace/auth-with-drizzle-sqlite` under `packages/auth-with-drizzle-sqlite`. For each test package define and export a better-auth `auth` instance (and/or a factory that returns it) plus type definitions that are inferred from the instance and/or its configuration object. Do not use any `as` casts or other type cheats. I think you'd want to cover a bunch of cases e.g. - `auth-with-drizzle-sqlite.ts` - `auth-with-organization-plugin.ts` - etc. Plus perhaps a few kitchen sink configurations that replicate popular combinations of features and plugins, inspired from all the different issues and commenters of the past and their affected configurations. - Ensure the packages define exports properly - Add a typecheck script using `tsc` It is pretty much guaranteed at this point that you will find cases where type checks fail. Remember to ensure your IDE e.g. VSCode is configured to use the workspace "package version" of TypeScript so you can see the issues properly in your editor and so it agrees with `tsc` results: `"typescript.tsdk": "node_modules/typescript/lib"`. **Test Dependents** To go the full 9 yards, you could add an app/package or two that have an auth package as a dependency and have a module where you import and use the auth instance. To get good detection you could ensure you make use of or reference the types/properties that would be conditionally impacted by the particular configuration being tested. The idea is you could see how type checks fail or see first hand how the consuming app/packages can have issues resolving types. You could use purpose-built type testing packages to confirm expected equivalencies however I don't think they're necessary.
GiteaMirror commented 2026-04-17 18:45:48 -05:00
Author
Owner
Copy Link

@mimamuh commented on GitHub (Nov 26, 2025):

I'm getting similar issues with 1.4.2.

@himself65: I've made a repro to reproduce the issue here: bug-exaple-better-auth-1_4_2

This reproduction is based on create-t3-turbo where I did nothing but only upgraded better-auth to 1.4.2 and now get the lint errors:

The inferred type of 'XXX' cannot be named without a reference to 'XXXX.mjs'. This is likely not portable. A type annotation is necessary. ts(2742)

To reproduce:

  1. Clone repro bug-exaple-better-auth-1_4_2 and cd into it
  2. Install dependencies using pnpm install
  3. Run pnpm run lint for seeing the issues
<!-- gh-comment-id:3583169840 --> @mimamuh commented on GitHub (Nov 26, 2025): I'm getting similar issues with `1.4.2`. @himself65: I've made a repro to reproduce the issue here: [bug-exaple-better-auth-1_4_2](https://github.com/mimamuh/bug-exaple-better-auth-1_4_2) This reproduction is based on [create-t3-turbo](https://github.com/t3-oss/create-t3-turbo) where I did nothing but only upgraded better-auth to `1.4.2` and now [get the lint errors](https://github.com/mimamuh/bug-exaple-better-auth-1_4_2/actions/runs/19716892273/job/56491029889#step:5:72): ``` The inferred type of 'XXX' cannot be named without a reference to 'XXXX.mjs'. This is likely not portable. A type annotation is necessary. ts(2742) ``` --- ### To reproduce: 1. Clone repro [bug-exaple-better-auth-1_4_2](https://github.com/mimamuh/bug-exaple-better-auth-1_4_2) and `cd` into it 2. Install dependencies using `pnpm install` 3. Run `pnpm run lint` for seeing the issues
GiteaMirror commented 2026-04-17 18:45:49 -05:00
Author
Owner
Copy Link

@zigcccc commented on GitHub (Nov 27, 2025):

☝️ just tested and it happens with version 1.4.3 too

<!-- gh-comment-id:3584843746 --> @zigcccc commented on GitHub (Nov 27, 2025): ☝️ just tested and it happens with version `1.4.3` too
GiteaMirror commented 2026-04-17 18:45:50 -05:00
Author
Owner
Copy Link

@joeyorlando commented on GitHub (Dec 2, 2025):

@himself65 this is honestly preventing us from upgrading beyond 1.4.1 🙁

<!-- gh-comment-id:3604180329 --> @joeyorlando commented on GitHub (Dec 2, 2025): @himself65 this is honestly preventing us from upgrading beyond `1.4.1` 🙁
GiteaMirror commented 2026-04-17 18:45:50 -05:00
Author
Owner
Copy Link

@jofflin commented on GitHub (Dec 2, 2025):

Same for us. We are stuck with 1.3.33, we tried each version and running into issues

<!-- gh-comment-id:3604288218 --> @jofflin commented on GitHub (Dec 2, 2025): Same for us. We are stuck with 1.3.33, we tried each version and running into issues
GiteaMirror commented 2026-04-17 18:45:51 -05:00
Author
Owner
Copy Link

@himself65 commented on GitHub (Dec 2, 2025):

Thanks, I'm checking rn

<!-- gh-comment-id:3604323681 --> @himself65 commented on GitHub (Dec 2, 2025): Thanks, I'm checking rn
GiteaMirror commented 2026-04-17 18:45:52 -05:00
Author
Owner
Copy Link

@Bekacru commented on GitHub (Dec 2, 2025):

Hey @mimamuh i've been trying to reproduce your issue using the repo you peovider

it only fails if I do pnpm lint globally and other than that, it doesn't break on the editor or when running lint on each package. Can you guys please let me know more aobut your setup and exact issues your facing? @joeyorlando @zigcccc @jofflin

<!-- gh-comment-id:3604345751 --> @Bekacru commented on GitHub (Dec 2, 2025): Hey @mimamuh i've been trying to reproduce your issue using the repo you peovider it only fails if I do pnpm lint globally and other than that, it doesn't break on the editor or when running lint on each package. Can you guys please let me know more aobut your setup and exact issues your facing? @joeyorlando @zigcccc @jofflin
GiteaMirror commented 2026-04-17 18:45:53 -05:00
Author
Owner
Copy Link

@joeyorlando commented on GitHub (Dec 2, 2025):

@himself65 @Bekacru I posted some detailed repro instructions on Discord here for how we use/configure better-auth over in https://github.com/archestra-ai/archestra

<!-- gh-comment-id:3604365303 --> @joeyorlando commented on GitHub (Dec 2, 2025): @himself65 @Bekacru I posted some detailed repro instructions on Discord [here](https://discordapp.com/channels/1288403910284935179/1445542747489698022/1445555787304009930) for how we use/configure better-auth over in https://github.com/archestra-ai/archestra
GiteaMirror commented 2026-04-17 18:45:54 -05:00
Author
Owner
Copy Link

@himself65 commented on GitHub (Dec 2, 2025):

Just

I'm getting similar issues with 1.4.2.

@himself65: I've made a repro to reproduce the issue here: bug-exaple-better-auth-1_4_2

This reproduction is based on create-t3-turbo where I did nothing but only upgraded better-auth to 1.4.2 and now get the lint errors:

The inferred type of 'XXX' cannot be named without a reference to 'XXXX.mjs'. This is likely not portable. A type annotation is necessary. ts(2742)

To reproduce:

  1. Clone repro bug-exaple-better-auth-1_4_2 and cd into it
  2. Install dependencies using pnpm install
  3. Run pnpm run lint for seeing the issues

I fixed this issue. seems like we miss export one type from the code

<!-- gh-comment-id:3604402901 --> @himself65 commented on GitHub (Dec 2, 2025): Just > I'm getting similar issues with `1.4.2`. > > [@himself65](https://github.com/himself65): I've made a repro to reproduce the issue here: [bug-exaple-better-auth-1_4_2](https://github.com/mimamuh/bug-exaple-better-auth-1_4_2) > > This reproduction is based on [create-t3-turbo](https://github.com/t3-oss/create-t3-turbo) where I did nothing but only upgraded better-auth to `1.4.2` and now [get the lint errors](https://github.com/mimamuh/bug-exaple-better-auth-1_4_2/actions/runs/19716892273/job/56491029889#step:5:72): > > ``` > The inferred type of 'XXX' cannot be named without a reference to 'XXXX.mjs'. This is likely not portable. A type annotation is necessary. ts(2742) > ``` > > ### To reproduce: > 1. Clone repro [bug-exaple-better-auth-1_4_2](https://github.com/mimamuh/bug-exaple-better-auth-1_4_2) and `cd` into it > 2. Install dependencies using `pnpm install` > 3. Run `pnpm run lint` for seeing the issues I fixed this issue. seems like we miss export one type from the code
GiteaMirror commented 2026-04-17 18:45:54 -05:00
Author
Owner
Copy Link

@himself65 commented on GitHub (Dec 2, 2025):

@himself65 @Bekacru I posted some detailed repro instructions on Discord here for how we use/configure better-auth over in https://github.com/archestra-ai/archestra

I'm checking this

<!-- gh-comment-id:3604406730 --> @himself65 commented on GitHub (Dec 2, 2025): > [@himself65](https://github.com/himself65) [@Bekacru](https://github.com/Bekacru) I posted some detailed repro instructions on Discord [here](https://discordapp.com/channels/1288403910284935179/1445542747489698022/1445555787304009930) for how we use/configure better-auth over in https://github.com/archestra-ai/archestra I'm checking this
GiteaMirror commented 2026-04-17 18:45:54 -05:00
Author
Owner
Copy Link

@chandlj commented on GitHub (Dec 3, 2025):

@himself65 @Bekacru I created a repo here reproducing the error I'm seeing: https://github.com/chandlj/better-auth-test

The steps I took were:

pnpm dlx shadcn@latest init # Select the monorepo option
cd apps/web
pnpm add better-auth

Please take a look at apps/web/lib/auth.ts and you should see the error. Please let me know if you don't! I just did this with better-auth@1.4.5

<!-- gh-comment-id:3604812839 --> @chandlj commented on GitHub (Dec 3, 2025): @himself65 @Bekacru I created a repo here reproducing the error I'm seeing: https://github.com/chandlj/better-auth-test The steps I took were: ``` pnpm dlx shadcn@latest init # Select the monorepo option cd apps/web pnpm add better-auth ``` Please take a look at `apps/web/lib/auth.ts` and you should see the error. Please let me know if you don't! I just did this with `better-auth@1.4.5`
GiteaMirror commented 2026-04-17 18:45:55 -05:00
Author
Owner
Copy Link

@himself65 commented on GitHub (Dec 4, 2025):

@himself65 @Bekacru I created a repo here reproducing the error I'm seeing: https://github.com/chandlj/better-auth-test

The steps I took were:

pnpm dlx shadcn@latest init # Select the monorepo option
cd apps/web
pnpm add better-auth

Please take a look at apps/web/lib/auth.ts and you should see the error. Please let me know if you don't! I just did this with better-auth@1.4.5

Where is it?

<!-- gh-comment-id:3610121268 --> @himself65 commented on GitHub (Dec 4, 2025): > [@himself65](https://github.com/himself65) [@Bekacru](https://github.com/Bekacru) I created a repo here reproducing the error I'm seeing: https://github.com/chandlj/better-auth-test > > The steps I took were: > > ``` > pnpm dlx shadcn@latest init # Select the monorepo option > cd apps/web > pnpm add better-auth > ``` > > Please take a look at `apps/web/lib/auth.ts` and you should see the error. Please let me know if you don't! I just did this with `better-auth@1.4.5` Where is it?
GiteaMirror commented 2026-04-17 18:45:56 -05:00
Author
Owner
Copy Link

@chandlj commented on GitHub (Dec 7, 2025):

@himself65 sorry thought it was public. Should be fixed now

<!-- gh-comment-id:3623014882 --> @chandlj commented on GitHub (Dec 7, 2025): @himself65 sorry thought it was public. Should be fixed now
GiteaMirror commented 2026-04-17 18:45:56 -05:00
Author
Owner
Copy Link

@joeyorlando commented on GitHub (Dec 17, 2025):

I just tried upgrading to 1.4.6-beta.3 and I still get this.

however one thing I noticed is that in my plugins array if I comment out the apiKey plugin (here), the type errors on auth go away 🤔 (but of course cause type errors elsewhere related to auth.api.verifyApiKey references)

(more context in Discord thread here)

<!-- gh-comment-id:3666027032 --> @joeyorlando commented on GitHub (Dec 17, 2025): I just tried upgrading to `1.4.6-beta.3` and I still get this. however one thing I noticed is that in my plugins array if I comment out the `apiKey` plugin ([here](https://github.com/archestra-ai/archestra/blob/main/platform/backend/src/auth/better-auth.ts#L112)), the type errors on `auth` go away 🤔 (but of course cause type errors elsewhere related to `auth.api.verifyApiKey` references) (more context in Discord thread [here](https://discord.com/channels/1288403910284935179/1445542747489698022/1446947422503698505))
GiteaMirror commented 2026-04-17 18:45:57 -05:00
Author
Owner
Copy Link

@picardplaisimond commented on GitHub (Dec 20, 2025):

I just tried upgrading to 1.4.6-beta.3 and I still get this.

however one thing I noticed is that in my plugins array if I comment out the apiKey plugin (here), the type errors on auth go away 🤔 (but of course cause type errors elsewhere related to auth.api.verifyApiKey references)

(more context in Discord thread here)

Same thing happens to me when I remove the Stripe Plugin... hmmm.

EDIT: Updated from 1.4.5 to 1.4.7, and the error is gone (for now...)

<!-- gh-comment-id:3678060566 --> @picardplaisimond commented on GitHub (Dec 20, 2025): > I just tried upgrading to `1.4.6-beta.3` and I still get this. > > however one thing I noticed is that in my plugins array if I comment out the `apiKey` plugin ([here](https://github.com/archestra-ai/archestra/blob/main/platform/backend/src/auth/better-auth.ts#L112)), the type errors on `auth` go away 🤔 (but of course cause type errors elsewhere related to `auth.api.verifyApiKey` references) > > (more context in Discord thread [here](https://discord.com/channels/1288403910284935179/1445542747489698022/1446947422503698505)) Same thing happens to me when I remove the Stripe Plugin... hmmm. **EDIT: Updated from 1.4.5 to 1.4.7, and the error is gone (for now...)**
GiteaMirror commented 2026-04-17 18:45:58 -05:00
Author
Owner
Copy Link

@marcmaceira commented on GitHub (Dec 21, 2025):

Same thing happens to me when I remove the Stripe Plugin... hmmm.

EDIT: Updated from 1.4.5 to 1.4.7, and the error is gone (for now...)

I still have the error on 1.4.7 😅

<!-- gh-comment-id:3678369919 --> @marcmaceira commented on GitHub (Dec 21, 2025): > Same thing happens to me when I remove the Stripe Plugin... hmmm. > > **EDIT: Updated from 1.4.5 to 1.4.7, and the error is gone (for now...)** I still have the error on 1.4.7 😅
GiteaMirror commented 2026-04-17 18:45:58 -05:00
Author
Owner
Copy Link

@f1shy-dev commented on GitHub (Dec 23, 2025):

i have it on 1.4.9 :(

The inferred type of 'createAuth' cannot be named without a reference to '../../node_modules/better-auth/dist/plugins/anonymous/types.mjs'. This is likely not portable. A type annotation is necessary.

<!-- gh-comment-id:3687495549 --> @f1shy-dev commented on GitHub (Dec 23, 2025): i have it on 1.4.9 :( > The inferred type of 'createAuth' cannot be named without a reference to '../../node_modules/better-auth/dist/plugins/anonymous/types.mjs'. This is likely not portable. A type annotation is necessary.
GiteaMirror commented 2026-04-17 18:45:59 -05:00
Author
Owner
Copy Link

@ktisakib commented on GitHub (Jan 22, 2026):

1.4.17 the error reappeared

<!-- gh-comment-id:3784083879 --> @ktisakib commented on GitHub (Jan 22, 2026): 1.4.17 the error reappeared
GiteaMirror commented 2026-04-17 18:46:00 -05:00
Author
Owner
Copy Link

@joeyorlando commented on GitHub (Feb 25, 2026):

my two-cents - I think this should be prioritized, the dev-ex on this is not great (you end up having to type your betterAuth instance as such 🙁

export const auth: any = betterAuth({
  ...
<!-- gh-comment-id:3959368340 --> @joeyorlando commented on GitHub (Feb 25, 2026): my two-cents - I think this should be prioritized, the dev-ex on this is not great (you end up having to type your `betterAuth` instance as such 🙁 ```ts export const auth: any = betterAuth({ ... ```
GiteaMirror commented 2026-04-17 18:46:00 -05:00
Author
Owner
Copy Link

@fierysolid commented on GitHub (Mar 6, 2026):

I was able to get 1.5.4 working with the following overrides:

  "pnpm": {
    "overrides": {
      "better-auth": "1.5.4",
      "better-call": "1.3.2",
      "@better-auth/core": "1.5.4",
      "@better-auth/sso": "1.5.4",
      "@better-fetch/fetch": "1.1.21",
...
<!-- gh-comment-id:4013927464 --> @fierysolid commented on GitHub (Mar 6, 2026): I was able to get 1.5.4 working with the following overrides: ``` "pnpm": { "overrides": { "better-auth": "1.5.4", "better-call": "1.3.2", "@better-auth/core": "1.5.4", "@better-auth/sso": "1.5.4", "@better-fetch/fetch": "1.1.21", ... ```
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 core needs: info tracking
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#27642
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?