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

[GH-ISSUE #2123] The inferred type of 'auth' cannot be named without a reference #9060

New Issue
Closed
opened 2026-04-13 04:21:04 -05:00 by GiteaMirror · 37 comments
GiteaMirror commented 2026-04-13 04:21:04 -05:00
Owner
Copy Link

Originally created by @guptaashwanee on GitHub (Apr 4, 2025).
Original GitHub issue: https://github.com/better-auth/better-auth/issues/2123

Is this suited for github?

  • Yes, this is suited for github

To Reproduce

setup better-auth in express node application.

Current vs. Expected behavior

The inferred type of 'auth' cannot be named without a reference to '../../node_modules/better-auth/dist/shared/better-auth.BAfIsot3.js'. This is likely not portable. A type annotation is necessary.ts(2742)

const auth = betterAuth({

});

What version of Better Auth are you using?

^1.2.5

Provide environment information

- OS: Mac os

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

Backend

Auth config (if applicable)

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

Additional context

No response

Originally created by @guptaashwanee on GitHub (Apr 4, 2025). Original GitHub issue: https://github.com/better-auth/better-auth/issues/2123 ### Is this suited for github? - [x] Yes, this is suited for github ### To Reproduce setup better-auth in express node application. ### Current vs. Expected behavior The inferred type of 'auth' cannot be named without a reference to '../../node_modules/better-auth/dist/shared/better-auth.BAfIsot3.js'. This is likely not portable. A type annotation is necessary.ts(2742) const auth = betterAuth({ }); ### What version of Better Auth are you using? ^1.2.5 ### Provide environment information ```bash - OS: Mac os ``` ### Which area(s) are affected? (Select all that apply) Backend ### Auth config (if applicable) ```typescript import { betterAuth } from "better-auth" export const auth = betterAuth({ emailAndPassword: { enabled: true }, }); ``` ### Additional context _No response_
GiteaMirror added the lockedbug labels 2026-04-13 04:21:04 -05:00
GiteaMirror commented 2026-04-13 04:21:05 -05:00
Author
Owner
Copy Link

@Kinfe123 commented on GitHub (Apr 4, 2025):

if you using ts , can you please share your tsconfig file just to check some flags ?

<!-- gh-comment-id:2779726491 --> @Kinfe123 commented on GitHub (Apr 4, 2025): if you using ts , can you please share your tsconfig file just to check some flags ?
GiteaMirror commented 2026-04-13 04:21:06 -05:00
Author
Owner
Copy Link

@SohelIslamImran commented on GitHub (Apr 5, 2025):

Same issue...

<!-- gh-comment-id:2780707635 --> @SohelIslamImran commented on GitHub (Apr 5, 2025): Same issue...
GiteaMirror commented 2026-04-13 04:21:06 -05:00
Author
Owner
Copy Link

@vctrodrigues commented on GitHub (Apr 5, 2025):

Same issue :(

I changed my tsconfig.json file adding declaration: false and declarationMap: false to suppress the error. But I would prefer to use declarations in my tsconfig.

<!-- gh-comment-id:2780741511 --> @vctrodrigues commented on GitHub (Apr 5, 2025): Same issue :( I changed my `tsconfig.json` file adding `declaration: false` and `declarationMap: false` to suppress the error. But I would prefer to use declarations in my tsconfig.
GiteaMirror commented 2026-04-13 04:21:06 -05:00
Author
Owner
Copy Link

@AlfieJones commented on GitHub (Apr 5, 2025):

Seems to be a regression with 1.2.5, 1.2.4 works okay

<!-- gh-comment-id:2780787534 --> @AlfieJones commented on GitHub (Apr 5, 2025): Seems to be a regression with 1.2.5, 1.2.4 works okay
GiteaMirror commented 2026-04-13 04:21:07 -05:00
Author
Owner
Copy Link

@Lukem121 commented on GitHub (Apr 8, 2025):

Can confirm fixed in "better-auth": "^1.2.6-beta.6",

<!-- gh-comment-id:2785568728 --> @Lukem121 commented on GitHub (Apr 8, 2025): Can confirm fixed in `"better-auth": "^1.2.6-beta.6",`
GiteaMirror commented 2026-04-13 04:21:07 -05:00
Author
Owner
Copy Link

@multiplehats commented on GitHub (Apr 8, 2025):

"^1.2.6-beta.6"

This comment saved me, holy cow, this was driving me crazy. Thank you so much

<!-- gh-comment-id:2785729152 --> @multiplehats commented on GitHub (Apr 8, 2025): > "^1.2.6-beta.6" This comment saved me, holy cow, this was driving me crazy. Thank you so much
GiteaMirror commented 2026-04-13 04:21:07 -05:00
Author
Owner
Copy Link

@taylor-lindores-reeves commented on GitHub (Apr 9, 2025):

Confirmed, upgrading from 1.2.5 to 1.2.6-beta.6 fix it for me

<!-- gh-comment-id:2790377752 --> @taylor-lindores-reeves commented on GitHub (Apr 9, 2025): Confirmed, upgrading from 1.2.5 to 1.2.6-beta.6 fix it for me
GiteaMirror commented 2026-04-13 04:21:08 -05:00
Author
Owner
Copy Link

@hexcowboy commented on GitHub (Apr 25, 2025):

I'm seeing this in version 1.2.7 when using the haveIBeenPwned plugin

<!-- gh-comment-id:2830721199 --> @hexcowboy commented on GitHub (Apr 25, 2025): I'm seeing this in version 1.2.7 when using the `haveIBeenPwned` plugin
GiteaMirror commented 2026-04-13 04:21:08 -05:00
Author
Owner
Copy Link

@waltershewmake commented on GitHub (May 1, 2025):

I was getting this on v1.2.7 when attempting to define the mapProfileToUser function within the microsoft social provider. I'm assuming this will also apply to other social providers. Here is what I had, which didn't work:

mapProfileToUser: async (profile) => {
	...
}

To fix it, I just had to strongly define the profile type. I was able to hover over profile in the above snippet to determine its type, and then simply import it and use it.

mapProfileToUser: async (profile: MicrosoftEntraIDProfile) => {
	...
}
<!-- gh-comment-id:2845966375 --> @waltershewmake commented on GitHub (May 1, 2025): I was getting this on **v1.2.7** when attempting to define the `mapProfileToUser` function within the `microsoft` social provider. I'm assuming this will also apply to other social providers. Here is what I had, which didn't work: ``` mapProfileToUser: async (profile) => { ... } ``` To fix it, I just had to strongly define the profile type. I was able to hover over `profile` in the above snippet to determine its type, and then simply import it and use it. ``` mapProfileToUser: async (profile: MicrosoftEntraIDProfile) => { ... } ```
GiteaMirror commented 2026-04-13 04:21:08 -05:00
Author
Owner
Copy Link

@firxworx commented on GitHub (May 3, 2025):

This happens in a monorepo (pnpm workspace) for me when trying to centralize a common auth configuration for multiple apps.

An approach I used within individual apps did not translate to being in a package.

Key difference is that in the library the database and a couple other options such as trustedOrigins had to be passed into a factory so were variable

I think better-auth is missing some type exports and generic type utilities or helper functions to help make strong-typed libraries (or at least I couldn't find it in the docs).

<!-- gh-comment-id:2848343540 --> @firxworx commented on GitHub (May 3, 2025): This happens in a monorepo (pnpm workspace) for me when trying to centralize a common auth configuration for multiple apps. An approach I used within individual apps did not translate to being in a package. Key difference is that in the library the database and a couple other options such as `trustedOrigins` had to be passed into a factory so were variable I think better-auth is missing some type exports and generic type utilities or helper functions to help make strong-typed libraries (or at least I couldn't find it in the docs).
GiteaMirror commented 2026-04-13 04:21:09 -05:00
Author
Owner
Copy Link

@webdevelukas commented on GitHub (May 6, 2025):

This happens in a monorepo (pnpm workspace) for me when trying to centralize a common auth configuration for multiple apps.

An approach I used within individual apps did not translate to being in a package.

Key difference is that in the library the database and a couple other options such as trustedOrigins had to be passed into a factory so were variable

I think better-auth is missing some type exports and generic type utilities or helper functions to help make strong-typed libraries (or at least I couldn't find it in the docs).

I try to do the same thing in a monorepo (turborepo/pnpm). If I export betterAuth like this I got the error:

export const auth = betterAuth(betterAuthConfig)

If I add ReturnType<typeof betterAuth> it is gone:

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

But it still doesn't work for me because it is then missing the types that are added through the emailOTP plugin.

<!-- gh-comment-id:2854468610 --> @webdevelukas commented on GitHub (May 6, 2025): > This happens in a monorepo (pnpm workspace) for me when trying to centralize a common auth configuration for multiple apps. > > An approach I used within individual apps did not translate to being in a package. > > Key difference is that in the library the database and a couple other options such as `trustedOrigins` had to be passed into a factory so were variable > > I think better-auth is missing some type exports and generic type utilities or helper functions to help make strong-typed libraries (or at least I couldn't find it in the docs). I try to do the same thing in a monorepo (turborepo/pnpm). If I export betterAuth like this I got the error: ``` export const auth = betterAuth(betterAuthConfig) ``` If I add `ReturnType<typeof betterAuth>` it is gone: ``` export const auth = betterAuth(betterAuthConfig) as ReturnType<typeof betterAuth> ``` But it still doesn't work for me because it is then missing the types that are added through the `emailOTP` plugin.
GiteaMirror commented 2026-04-13 04:21:09 -05:00
Author
Owner
Copy Link

@eth0izzle commented on GitHub (May 9, 2025):

I was getting this on v1.2.7 when attempting to define the mapProfileToUser function within the microsoft social provider. I'm assuming this will also apply to other social providers. Here is what I had, which didn't work:

mapProfileToUser: async (profile) => {
	...
}

To fix it, I just had to strongly define the profile type. I was able to hover over profile in the above snippet to determine its type, and then simply import it and use it.

mapProfileToUser: async (profile: MicrosoftEntraIDProfile) => {
	...
}

Same here when using mapProfileToUser on v1.2.7. This fix works but you can also explicitly type the entire auth config as ReturnType<typeof betterAuth>

<!-- gh-comment-id:2867063000 --> @eth0izzle commented on GitHub (May 9, 2025): > I was getting this on **v1.2.7** when attempting to define the `mapProfileToUser` function within the `microsoft` social provider. I'm assuming this will also apply to other social providers. Here is what I had, which didn't work: > > ``` > mapProfileToUser: async (profile) => { > ... > } > ``` > > To fix it, I just had to strongly define the profile type. I was able to hover over `profile` in the above snippet to determine its type, and then simply import it and use it. > > ``` > mapProfileToUser: async (profile: MicrosoftEntraIDProfile) => { > ... > } > ``` Same here when using `mapProfileToUser` on v1.2.7. This fix works but you can also explicitly type the entire auth config ` as ReturnType<typeof betterAuth>`
GiteaMirror commented 2026-04-13 04:21:09 -05:00
Author
Owner
Copy Link

@cjroebuck commented on GitHub (Jul 24, 2025):

Started getting this after updating zod to 4.0.8.

Fixed it by making sure my version of zod (in all packages in my monorepo) was the same as better-auth's currently 4.0.5.

<!-- gh-comment-id:3113270382 --> @cjroebuck commented on GitHub (Jul 24, 2025): Started getting this after updating zod to 4.0.8. Fixed it by making sure my version of zod (in all packages in my monorepo) was the same as better-auth's currently 4.0.5.
GiteaMirror commented 2026-04-13 04:21:10 -05:00
Author
Owner
Copy Link

@viktorbonino commented on GitHub (Jul 26, 2025):

i solved this by creating a package "better-auth" (im using a monorepo) where i have my config (with declaration and declarationMap set to false)

import { BetterAuthOptions } from 'better-auth'
import { admin } from 'better-auth/plugins'
import { organization } from 'better-auth/plugins'

export const authConfig = {
  emailAndPassword: {
    enabled: true,
  },
  plugins: [admin(), organization()],

  trustedOrigins: ['http://localhost:3000'],
} satisfies BetterAuthOptions

Then i imported the package in my app (with composite: true):

import { betterAuth, BetterAuthOptions } from 'better-auth'
import { drizzleAdapter, DB } from 'better-auth/adapters/drizzle'

import { createDb } from '@/db/db'
import * as schema from '@/db/auth-schema'
import { authConfig } from '@repo/better-auth/server'

const createConfig = (db: DB) => {
  return {
    ...authConfig,
    database: drizzleAdapter(db, {
      provider: 'pg',
      schema: schema,
    }),
  } satisfies BetterAuthOptions
}

export const createAuth = () => {
  const db = createDb()
  return betterAuth(createConfig(db)) as ReturnType<typeof betterAuth<typeof authConfig>>
}

(i'm using honojs with cloudflare workers, so i need to create a db connection everytime, but you can avoid to do it if using something else)

<!-- gh-comment-id:3122197553 --> @viktorbonino commented on GitHub (Jul 26, 2025): i solved this by creating a package "better-auth" (im using a monorepo) where i have my config (with declaration and declarationMap set to false) ```ts import { BetterAuthOptions } from 'better-auth' import { admin } from 'better-auth/plugins' import { organization } from 'better-auth/plugins' export const authConfig = { emailAndPassword: { enabled: true, }, plugins: [admin(), organization()], trustedOrigins: ['http://localhost:3000'], } satisfies BetterAuthOptions ``` Then i imported the package in my app (with composite: true): ```ts import { betterAuth, BetterAuthOptions } from 'better-auth' import { drizzleAdapter, DB } from 'better-auth/adapters/drizzle' import { createDb } from '@/db/db' import * as schema from '@/db/auth-schema' import { authConfig } from '@repo/better-auth/server' const createConfig = (db: DB) => { return { ...authConfig, database: drizzleAdapter(db, { provider: 'pg', schema: schema, }), } satisfies BetterAuthOptions } export const createAuth = () => { const db = createDb() return betterAuth(createConfig(db)) as ReturnType<typeof betterAuth<typeof authConfig>> } ``` (i'm using honojs with cloudflare workers, so i need to create a db connection everytime, but you can avoid to do it if using something else)
GiteaMirror commented 2026-04-13 04:21:10 -05:00
Author
Owner
Copy Link

@hadrysmateusz commented on GitHub (Aug 19, 2025):

I have the exact same issue (on version 1.3.7) both with betterAuth() and createAuthClient. Manually adding a type annotation worked fine before I added plugins, but with the admin plugin, I haven't found a way to annotate it in a way that would actually work.

However for createAuthClient() I found that simply adding any import from 'better-auth' in the same file fixes the issue for me.

For example:

import type {} from 'better-auth';
<!-- gh-comment-id:3202924366 --> @hadrysmateusz commented on GitHub (Aug 19, 2025): I have the exact same issue (on version 1.3.7) both with `betterAuth()` and `createAuthClient`. Manually adding a type annotation worked fine before I added plugins, but with the admin plugin, I haven't found a way to annotate it in a way that would actually work. However for `createAuthClient()` I found that simply adding any import from 'better-auth' in the same file fixes the issue for me. For example: ```ts import type {} from 'better-auth'; ```
GiteaMirror commented 2026-04-13 04:21:10 -05:00
Author
Owner
Copy Link

@rinarakaki commented on GitHub (Aug 26, 2025):

This reproduces with version 1.3.7.

<!-- gh-comment-id:3222359989 --> @rinarakaki commented on GitHub (Aug 26, 2025): This reproduces with version 1.3.7.
GiteaMirror commented 2026-04-13 04:21:10 -05:00
Author
Owner
Copy Link

@Jordan-Hall commented on GitHub (Sep 8, 2025):

Im having the same thing with the authplugin

<!-- gh-comment-id:3265886430 --> @Jordan-Hall commented on GitHub (Sep 8, 2025): Im having the same thing with the authplugin
GiteaMirror commented 2026-04-13 04:21:11 -05:00
Author
Owner
Copy Link

@VesperQuartz commented on GitHub (Sep 16, 2025):

WHy is this closed?

<!-- gh-comment-id:3300578161 --> @VesperQuartz commented on GitHub (Sep 16, 2025): WHy is this closed?
GiteaMirror commented 2026-04-13 04:21:11 -05:00
Author
Owner
Copy Link

@demirtasdurmus commented on GitHub (Sep 22, 2025):

Same here.

<!-- gh-comment-id:3318938600 --> @demirtasdurmus commented on GitHub (Sep 22, 2025): Same here.
GiteaMirror commented 2026-04-13 04:21:12 -05:00
Author
Owner
Copy Link

@MarkLee425 commented on GitHub (Oct 2, 2025):

Still has the same issue with OpenAPI plugin.

<!-- gh-comment-id:3360675095 --> @MarkLee425 commented on GitHub (Oct 2, 2025): Still has the same issue with OpenAPI plugin.
GiteaMirror commented 2026-04-13 04:21:13 -05:00
Author
Owner
Copy Link

@ricardofrancoli commented on GitHub (Oct 3, 2025):

Same here, having this issue using v1.3.25 with the jwt plugin. It's the same with the authClient.

<!-- gh-comment-id:3366128944 --> @ricardofrancoli commented on GitHub (Oct 3, 2025): Same here, having this issue using `v1.3.25` with the `jwt` plugin. It's the same with the `authClient`.
GiteaMirror commented 2026-04-13 04:21:13 -05:00
Author
Owner
Copy Link

@nikitasheremet commented on GitHub (Oct 4, 2025):

I was getting the same typescript issue when using createAuthClient, and I was able to resolve the issue by adding as ReturnType<typeof createAuthClient>

createAuthClient({
  ...<some configs here>
}) as ReturnType<typeof createAuthClient>
<!-- gh-comment-id:3368306286 --> @nikitasheremet commented on GitHub (Oct 4, 2025): I was getting the same typescript issue when using `createAuthClient`, and I was able to resolve the issue by adding `as ReturnType<typeof createAuthClient>` ``` createAuthClient({ ...<some configs here> }) as ReturnType<typeof createAuthClient> ```
GiteaMirror commented 2026-04-13 04:21:13 -05:00
Author
Owner
Copy Link

@Pyakz commented on GitHub (Oct 11, 2025):

updates? this is very blocking me right now.
using "better-auth": "^1.3.25",

i am using bhvr

<!-- gh-comment-id:3393321700 --> @Pyakz commented on GitHub (Oct 11, 2025): updates? this is very blocking me right now. using "better-auth": "^1.3.25", i am using [bhvr](https://bhvr.dev/)
GiteaMirror commented 2026-04-13 04:21:14 -05:00
Author
Owner
Copy Link

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

Really better-auth should follow standard schema -- https://standardschema.dev/

Zod has a doc for library/package authors building with zod - https://zod.dev/library-authors

I don't think these type issues or tight coupling to very particular versions of zod (or even to zod itself) should even be a thing. A ton of popular schema libraries are now compatible with standard schema.

If better-auth were compatible, devs could theoretically choose what they wanted to use, and multiple versions or different types of schema libraries wouldn't even need to end up in the bundle.

<!-- gh-comment-id:3398759274 --> @firxworx commented on GitHub (Oct 13, 2025): Really better-auth should follow standard schema -- https://standardschema.dev/ Zod has a doc for library/package authors building with zod - https://zod.dev/library-authors I don't think these type issues or tight coupling to very particular versions of zod (or even to zod itself) should even be a thing. A ton of popular schema libraries are now compatible with standard schema. If better-auth were compatible, devs could theoretically choose what they wanted to use, and multiple versions or different types of schema libraries wouldn't even need to end up in the bundle.
GiteaMirror commented 2026-04-13 04:21:15 -05:00
Author
Owner
Copy Link

@zigcccc commented on GitHub (Oct 22, 2025):

Seeing this on ^1.3.28 as well.

<!-- gh-comment-id:3433410037 --> @zigcccc commented on GitHub (Oct 22, 2025): Seeing this on `^1.3.28` as well.
GiteaMirror commented 2026-04-13 04:21:15 -05:00
Author
Owner
Copy Link

@Jordan-Hall commented on GitHub (Oct 22, 2025):

Ive been stuck with this issue and then added Jose as a dependencies and the better auth split package and it solved the issue

<!-- gh-comment-id:3433417355 --> @Jordan-Hall commented on GitHub (Oct 22, 2025): Ive been stuck with this issue and then added Jose as a dependencies and the better auth split package and it solved the issue
GiteaMirror commented 2026-04-13 04:21:15 -05:00
Author
Owner
Copy Link

@zigcccc commented on GitHub (Oct 22, 2025):

Ive been stuck with this issue and then added Jose as a dependencies and the better auth split package and it solved the issue

That didn't solve it for me :/

<!-- gh-comment-id:3433425781 --> @zigcccc commented on GitHub (Oct 22, 2025): > Ive been stuck with this issue and then added Jose as a dependencies and the better auth split package and it solved the issue That didn't solve it for me :/
GiteaMirror commented 2026-04-13 04:21:16 -05:00
Author
Owner
Copy Link

@Jordan-Hall commented on GitHub (Oct 22, 2025):

It could be any number of packages I only really got the errors I needed because of bun install informed me others didnt

<!-- gh-comment-id:3433436931 --> @Jordan-Hall commented on GitHub (Oct 22, 2025): It could be any number of packages I only really got the errors I needed because of bun install informed me others didnt
GiteaMirror commented 2026-04-13 04:21:17 -05:00
Author
Owner
Copy Link

@zigcccc commented on GitHub (Oct 22, 2025):

So, for me, it boils down to the usage of drizzleAdapter imported from better-auth/adapters/drizzle (I believe it's similar to what @viktorbonino is observing here). If I remove the adapter from the config, I don't get any errors. Following his suggestion now to see if it solves it for me.

<!-- gh-comment-id:3433495917 --> @zigcccc commented on GitHub (Oct 22, 2025): So, for me, it boils down to the usage of `drizzleAdapter` imported from `better-auth/adapters/drizzle` (I believe it's similar to what @viktorbonino is observing [here](https://github.com/better-auth/better-auth/issues/2123#issuecomment-3122197553)). If I remove the adapter from the config, I don't get any errors. Following his suggestion now to see if it solves it for me.
GiteaMirror commented 2026-04-13 04:21:18 -05:00
Author
Owner
Copy Link

@Jordan-Hall commented on GitHub (Oct 22, 2025):

So, for me, it boils down to the usage of drizzleAdapter imported from better-auth/adapters/drizzle (I believe it's similar to what @viktorbonino is observing here). If I remove the adapter from the config, I don't get any errors. Following his suggestion now to see if it solves it for me.

Im using bun mono repo without having to turn that. Are you able to create a small repo for example

<!-- gh-comment-id:3433506892 --> @Jordan-Hall commented on GitHub (Oct 22, 2025): > So, for me, it boils down to the usage of `drizzleAdapter` imported from `better-auth/adapters/drizzle` (I believe it's similar to what @viktorbonino is observing [here](https://github.com/better-auth/better-auth/issues/2123#issuecomment-3122197553)). If I remove the adapter from the config, I don't get any errors. Following his suggestion now to see if it solves it for me. Im using bun mono repo without having to turn that. Are you able to create a small repo for example
GiteaMirror commented 2026-04-13 04:21:19 -05:00
Author
Owner
Copy Link

@zigcccc commented on GitHub (Oct 22, 2025):

So, for me, it boils down to the usage of drizzleAdapter imported from better-auth/adapters/drizzle (I believe it's similar to what @viktorbonino is observing here). If I remove the adapter from the config, I don't get any errors. Following his suggestion now to see if it solves it for me.

Im using bun mono repo without having to turn that. Are you able to create a small repo for example

Not sure - I'm using pnpm workspaces + turbo combo, and I have only faced this in a fairly complex setup. I'll see if I can figure it out otherwise I'll spend some time trying to come up with a minimal repro example.

<!-- gh-comment-id:3433542149 --> @zigcccc commented on GitHub (Oct 22, 2025): > > So, for me, it boils down to the usage of `drizzleAdapter` imported from `better-auth/adapters/drizzle` (I believe it's similar to what [@viktorbonino](https://github.com/viktorbonino) is observing [here](https://github.com/better-auth/better-auth/issues/2123#issuecomment-3122197553)). If I remove the adapter from the config, I don't get any errors. Following his suggestion now to see if it solves it for me. > > Im using bun mono repo without having to turn that. Are you able to create a small repo for example Not sure - I'm using pnpm workspaces + turbo combo, and I have only faced this in a fairly complex setup. I'll see if I can figure it out otherwise I'll spend some time trying to come up with a minimal repro example.
GiteaMirror commented 2026-04-13 04:21:19 -05:00
Author
Owner
Copy Link

@Jordan-Hall commented on GitHub (Oct 22, 2025):

That's fine. im using turbo too i swapped to bun to solve the issue lol

<!-- gh-comment-id:3433609099 --> @Jordan-Hall commented on GitHub (Oct 22, 2025): That's fine. im using turbo too i swapped to bun to solve the issue lol
GiteaMirror commented 2026-04-13 04:21:20 -05:00
Author
Owner
Copy Link

@pedronauck commented on GitHub (Oct 22, 2025):

as @viktorbonino said, by creating a separated package on my monorepo and doing this, solved for me:

import { authConfig } from "@pkgs/better-auth/server";
import { betterAuth, type BetterAuthOptions } from "better-auth";
import { drizzleAdapter } from "better-auth/adapters/drizzle";
import { db } from "../db";

const createConfig = () => {
  return {
    ...authConfig,
    database: drizzleAdapter(db, { provider: "pg", usePlural: true }),
  } satisfies BetterAuthOptions;
};

export function createAuth() {
  return betterAuth(createConfig()) as ReturnType<typeof betterAuth<typeof authConfig>>;
}

export const auth = createAuth();
type InferredSession = typeof auth.$Infer.Session;

export type AuthSession = InferredSession["session"] & {
  activeOrganizationId?: string | null;
};
export type AuthUser = InferredSession["user"];
<!-- gh-comment-id:3433718478 --> @pedronauck commented on GitHub (Oct 22, 2025): as @viktorbonino said, by creating a separated package on my monorepo and doing this, solved for me: ```ts import { authConfig } from "@pkgs/better-auth/server"; import { betterAuth, type BetterAuthOptions } from "better-auth"; import { drizzleAdapter } from "better-auth/adapters/drizzle"; import { db } from "../db"; const createConfig = () => { return { ...authConfig, database: drizzleAdapter(db, { provider: "pg", usePlural: true }), } satisfies BetterAuthOptions; }; export function createAuth() { return betterAuth(createConfig()) as ReturnType<typeof betterAuth<typeof authConfig>>; } export const auth = createAuth(); type InferredSession = typeof auth.$Infer.Session; export type AuthSession = InferredSession["session"] & { activeOrganizationId?: string | null; }; export type AuthUser = InferredSession["user"]; ```
GiteaMirror commented 2026-04-13 04:21:20 -05:00
Author
Owner
Copy Link

@zigcccc commented on GitHub (Oct 22, 2025):

Well, updating to 1.4.0-beta.12 solved it for me, without doing any weird gymnastics with extra packages and whatnot. Not great, not terrible.

<!-- gh-comment-id:3433751307 --> @zigcccc commented on GitHub (Oct 22, 2025): Well, updating to `1.4.0-beta.12` solved it for me, without doing any weird gymnastics with extra packages and whatnot. Not great, not terrible.
GiteaMirror commented 2026-04-13 04:21:21 -05:00
Author
Owner
Copy Link

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

I reverted to 1.3.27. The problem seems to come from the drizzle adapter. But originally, the error was not there when I removed the drizzle adapter from the schema.
and yes. it's fixed in 1.4.0-beta.

<!-- gh-comment-id:3448897717 --> @picardplaisimond commented on GitHub (Oct 26, 2025): I reverted to `1.3.27`. The problem seems to come from the drizzle adapter. But originally, the error was not there when I removed the drizzle adapter from the schema. and yes. it's fixed in `1.4.0-beta`.
GiteaMirror commented 2026-04-13 04:21:21 -05:00
Author
Owner
Copy Link

@4anklee commented on GitHub (Oct 28, 2025):

for anyone who is using mapProfileToUser, adding an explicit type to the argument resolves the issue:

mapProfileToUser: (profile: { picture?: string }) => {
    return {
        image: profile.picture,
    };
},
<!-- gh-comment-id:3457437942 --> @4anklee commented on GitHub (Oct 28, 2025): for anyone who is using `mapProfileToUser`, adding an explicit type to the argument resolves the issue: ``` mapProfileToUser: (profile: { picture?: string }) => { return { image: profile.picture, }; }, ```
GiteaMirror commented 2026-04-13 04:21:22 -05:00
Author
Owner
Copy Link

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

This appears to be a systemic issue and I think it will continue to reappear because "better X" packages may not be using fully consistent sources of truth for certain types and are they are interdependent on each other.

When these packages re-export types here and there may seem to address surface issues, but it could compound the problem depending on what package and which version of that package a given type originally came from.

For example, here's a current issue regarding database adapter types:

'.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'

It appears various config options for better-auth are "landmines" with types that manifest especially hard in monorepos.

More rigorous package managers like pnpm perhaps uncover these issues more often but that's actually a good thing in the big picture in terms of producing consistent reproducible builds.

To those experiencing the issue with the DrizzleAdapterConfig I have a workaround you can try that is less elaborate and restrictive vs. some of what is proposed above.

UPDATE 2025-11-06:

The following was no longer viable nor required when I bumped to now-current better-call version 1.0.26 (with better-auth still at 1.3.34). The types worked such that I was able to define database: drizzleAdapter(db, drizzleAdapterConfig) inline my betterAuthOptions.

Unless there have been significant changes in better-auth's practices I expect issues to come back in future versions as the web of dependencies in the better-* ecosystem continues to flux.

I bumped my packages to confirm the issue persists in latest better-auth 1.3.34 and confirm that this fix continues to work.

Especially if you are using pnpm you will want @better-auth/core as an explicit dependency alongside better-auth with matching version numbers in package.json, e.g.

  "@better-auth/core": "^1.3.34",
  "better-auth": "^1.3.34",

On to the code...

Your situation may vary. In my case this is in a dedicated @workspace/auth package in a monorepo with multiple related apps that share a common database, auth configuration, ui components, etc.

Use these imports:

import { betterAuth, type BetterAuthOptions } from 'better-auth'
import { drizzleAdapter, type DrizzleAdapterConfig } from 'better-auth/adapters/drizzle'
import type { DBAdapter } from '@better-auth/core/db/adapter'

Define your DrizzleAdapterConfig separately with satisfies to ensure correctness:

// the details of this block depend on your project so adjust accordingly
export const drizzleAdapterConfig = {
  provider: 'sqlite',
  schema: {
    user: schema.userEntity,
    session: schema.sessionEntity,
    account: schema.accountEntity,
    verification: schema.verificationEntity,
    rateLimit: schema.rateLimitEntity,
  },
  transaction: false, // cloudflare D1 does not support transactions
} satisfies DrizzleAdapterConfig

Here's the part where we use a TypeScript escape hatch out of necessity. We assure TypeScript that the return value of drizzleAdapter() is compatible with what is required by the BetterAuthOptions type:

// unsafe `as unknown as DBAdapter<...>` cast is confirmed workaround re type issue in better-auth packages
export const databaseAdapter = drizzleAdapter(db, drizzleAdapterConfig) as unknown as DBAdapter<BetterAuthOptions>

You will no longer have a type issue when you add the databaseAdapter to your better-auth options because it is the version of DBAdapter<BetterAuthOptions> that better-auth requires. The following passes the satisfies check:

export const betterAuthOptions = {
  // ...
  database: databaseAdapter,
  // ...
} satisfies BetterAuthOptions

Now you can finally export your auth:

export const auth = betterAuth(betterAuthOptions)

And whatever types or other goodies you want to export as well:

export type AuthOptions = typeof betterAuthOptions
export type AuthInstance = ReturnType<typeof betterAuth<AuthOptions>>
<!-- gh-comment-id:3464227691 --> @firxworx commented on GitHub (Oct 29, 2025): This appears to be a systemic issue and I think it will continue to reappear because "better X" packages may not be using fully consistent sources of truth for certain types and are they are interdependent on each other. When these packages re-export types here and there may seem to address surface issues, but it could compound the problem depending on what package and which version of that package a given type originally came from. For example, here's a current issue regarding database adapter types: `'.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'` It appears various config options for better-auth are "landmines" with types that manifest especially hard in monorepos. More rigorous package managers like pnpm perhaps uncover these issues more often but that's actually a good thing in the big picture in terms of producing consistent reproducible builds. ---- To those experiencing the issue with the `DrizzleAdapterConfig` I have a workaround you can try that is less elaborate and restrictive vs. some of what is proposed above. **UPDATE 2025-11-06:** > The following was no longer viable nor required when I bumped to now-current `better-call` version `1.0.26` (with `better-auth` still at `1.3.34`). The types worked such that I was able to define `database: drizzleAdapter(db, drizzleAdapterConfig)` inline my `betterAuthOptions`. > Unless there have been significant changes in better-auth's practices I expect issues to come back in future versions as the web of dependencies in the `better-*` ecosystem continues to flux. I bumped my packages to confirm the issue persists in latest better-auth `1.3.34` and confirm that this fix continues to work. Especially if you are using pnpm you will want `@better-auth/core` as an explicit dependency alongside `better-auth` with matching version numbers in `package.json`, e.g. ```json "@better-auth/core": "^1.3.34", "better-auth": "^1.3.34", ``` On to the code... Your situation may vary. In my case this is in a dedicated `@workspace/auth` package in a monorepo with multiple related apps that share a common database, auth configuration, ui components, etc. Use these imports: ```ts import { betterAuth, type BetterAuthOptions } from 'better-auth' import { drizzleAdapter, type DrizzleAdapterConfig } from 'better-auth/adapters/drizzle' import type { DBAdapter } from '@better-auth/core/db/adapter' ``` Define your `DrizzleAdapterConfig` separately with `satisfies` to ensure correctness: ```ts // the details of this block depend on your project so adjust accordingly export const drizzleAdapterConfig = { provider: 'sqlite', schema: { user: schema.userEntity, session: schema.sessionEntity, account: schema.accountEntity, verification: schema.verificationEntity, rateLimit: schema.rateLimitEntity, }, transaction: false, // cloudflare D1 does not support transactions } satisfies DrizzleAdapterConfig ``` Here's the part where we use a TypeScript escape hatch out of necessity. We assure TypeScript that the return value of `drizzleAdapter()` is compatible with what is required by the `BetterAuthOptions` type: ```ts // unsafe `as unknown as DBAdapter<...>` cast is confirmed workaround re type issue in better-auth packages export const databaseAdapter = drizzleAdapter(db, drizzleAdapterConfig) as unknown as DBAdapter<BetterAuthOptions> ``` You will no longer have a type issue when you add the `databaseAdapter` to your better-auth options because it is the version of `DBAdapter<BetterAuthOptions>` that `better-auth` requires. The following passes the `satisfies` check: ```ts export const betterAuthOptions = { // ... database: databaseAdapter, // ... } satisfies BetterAuthOptions ``` Now you can finally export your auth: ```ts export const auth = betterAuth(betterAuthOptions) ``` And whatever types or other goodies you want to export as well: ```ts export type AuthOptions = typeof betterAuthOptions export type AuthInstance = ReturnType<typeof betterAuth<AuthOptions>> ```
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#9060
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?