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 #1391] monorepo/turborepo: Inferred type of 'authClient' cannot be named without a reference to .pnpm/nanostores. A type annotation is necessary #8726

New Issue
Closed
opened 2026-04-13 03:53:26 -05:00 by GiteaMirror · 38 comments
GiteaMirror commented 2026-04-13 03:53:26 -05:00
Owner
Copy Link

Originally created by @ramadanomar on GitHub (Feb 9, 2025).
Original GitHub issue: https://github.com/better-auth/better-auth/issues/1391

Is this suited for github?

  • Yes, this is suited for github

To Reproduce

Running a turborepo monorepo (NextJS 15)

The inferred type of 'authClient' cannot be named without a reference to '.pnpm/nanostores@0.11.3/node_modules/nanostores'. This is likely not portable. A type annotation is necessary.

If we typecast it with return type

export const authClient: ReturnType<typeof createAuthClient> = createAuthClient(
  {
    baseURL: process.env.NEXT_PUBLIC_APP_URL,
    plugins: [adminClient()],
  }
);

Errors goes away but we dont infer the routes from plugins. Example:

 const response = await authClient.admin.listUsers({
          query: { limit: 10 },
        });

Would error with:

Property 'admin' does not exist on type '{ signIn: { social: <FetchOptions extends { method?: string | undefined; headers?: (HeadersInit & (HeadersInit | CommonHeaders)) | undefined; redirect?: RequestRedirect | undefined; ... 32 more ...; disableValidation?: boolean | undefined; }>(data_0: Prettify<...>, data_1?: FetchOptions | undefined) => Promise<...>;...'.

Setting preserveSymlinks": true would make the error go away but all types would be inferred as any.

using inferAdditionalFields does not work in this case

import { inferAdditionalFields } from "better-auth/client/plugins";
import { createAuthClient } from "better-auth/react";
import type { auth } from "./auth";
 
export const authClient = createAuthClient({
  plugins: [inferAdditionalFields<typeof auth>()],
});

Current vs. Expected behavior

I would want it to work out of the box with inference.

What version of Better Auth are you using?

1.1.16

Provide environment information

- pnpm: v9.15.0
- node: v20.17.0
- "turbo": "^2.3.3",

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

Types, Client

Auth config (if applicable)

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

Additional context

This is my tsconfig.json

{
  "extends": "@resellguru/typescript-config/nextjs.json",
  "compilerOptions": {
    "baseUrl": ".",
    "paths": {
      "@/*": ["./*"],
      "@resellguru/ui/*": ["../../packages/ui/src/*"]
    },
    "plugins": [
      {
        "name": "next"
      }
    ],
  },
  "include": [
    "next-env.d.ts",
    "next.config.mjs",
    "**/*.ts",
    "**/*.tsx",
    ".next/types/**/*.ts"
  ],
  "exclude": ["node_modules"]
}

Issue seems to appear in a lot of other cases: An example
Typescript #42873

Originally created by @ramadanomar on GitHub (Feb 9, 2025). Original GitHub issue: https://github.com/better-auth/better-auth/issues/1391 ### Is this suited for github? - [x] Yes, this is suited for github ### To Reproduce Running a turborepo monorepo (NextJS 15) ``` The inferred type of 'authClient' cannot be named without a reference to '.pnpm/nanostores@0.11.3/node_modules/nanostores'. This is likely not portable. A type annotation is necessary. ``` If we typecast it with return type ```ts export const authClient: ReturnType<typeof createAuthClient> = createAuthClient( { baseURL: process.env.NEXT_PUBLIC_APP_URL, plugins: [adminClient()], } ); ``` Errors goes away but we dont infer the routes from plugins. Example: ```ts const response = await authClient.admin.listUsers({ query: { limit: 10 }, }); ``` Would error with: ``` Property 'admin' does not exist on type '{ signIn: { social: <FetchOptions extends { method?: string | undefined; headers?: (HeadersInit & (HeadersInit | CommonHeaders)) | undefined; redirect?: RequestRedirect | undefined; ... 32 more ...; disableValidation?: boolean | undefined; }>(data_0: Prettify<...>, data_1?: FetchOptions | undefined) => Promise<...>;...'. ``` Setting `preserveSymlinks": true` would make the error go away but all types would be inferred as `any`. using `inferAdditionalFields` does not work in this case ```ts import { inferAdditionalFields } from "better-auth/client/plugins"; import { createAuthClient } from "better-auth/react"; import type { auth } from "./auth"; export const authClient = createAuthClient({ plugins: [inferAdditionalFields<typeof auth>()], }); ``` ### Current vs. Expected behavior I would want it to work out of the box with inference. ### What version of Better Auth are you using? 1.1.16 ### Provide environment information ```bash - pnpm: v9.15.0 - node: v20.17.0 - "turbo": "^2.3.3", ``` ### Which area(s) are affected? (Select all that apply) Types, Client ### Auth config (if applicable) ```typescript import { betterAuth } from "better-auth" export const auth = betterAuth({ emailAndPassword: { enabled: true }, }); ``` ### Additional context This is my tsconfig.json ```json { "extends": "@resellguru/typescript-config/nextjs.json", "compilerOptions": { "baseUrl": ".", "paths": { "@/*": ["./*"], "@resellguru/ui/*": ["../../packages/ui/src/*"] }, "plugins": [ { "name": "next" } ], }, "include": [ "next-env.d.ts", "next.config.mjs", "**/*.ts", "**/*.tsx", ".next/types/**/*.ts" ], "exclude": ["node_modules"] } ``` Issue seems to appear in a lot of other cases: An example [Typescript #42873](https://github.com/microsoft/TypeScript/issues/42873#issuecomment-2066874644)
GiteaMirror added the lockedbug labels 2026-04-13 03:53:26 -05:00
GiteaMirror commented 2026-04-13 03:53:29 -05:00
Author
Owner
Copy Link

@anbehindY commented on GitHub (Feb 9, 2025):

I was setting up a project with turborepo and facing the same issue.

<!-- gh-comment-id:2646133736 --> @anbehindY commented on GitHub (Feb 9, 2025): I was setting up a project with turborepo and facing the same issue.
GiteaMirror commented 2026-04-13 03:53:29 -05:00
Author
Owner
Copy Link

@ryunosuke21 commented on GitHub (Feb 9, 2025):

Same issue here, again with turborepo. Used shadcn's monorepo cli command.

I asked ChatGPT some stuff and even though I know its not 100% reliable thought this could help someone with more knowledge in this than me. 😊

<!-- gh-comment-id:2646450129 --> @ryunosuke21 commented on GitHub (Feb 9, 2025): Same issue here, again with turborepo. Used [shadcn's monorepo](https://ui.shadcn.com/docs/monorepo) cli command. I asked [ChatGPT](https://chatgpt.com/share/e/67a8f00d-05d4-8002-bbe9-b98809b41a6f) some stuff and even though I know its not 100% reliable thought this could help someone with more knowledge in this than me. 😊
GiteaMirror commented 2026-04-13 03:53:30 -05:00
Author
Owner
Copy Link

@ramadanomar commented on GitHub (Feb 9, 2025):

Same issue here, again with turborepo. Used shadcn's monorepo cli command.

I asked ChatGPT some stuff and even though I know its not 100% reliable thought this could help someone with more knowledge in this than me. 😊

Conversation inaccessible or not found. You may need to switch accounts or request access if this conversation exists.

This comment has more context to the problem. I'll try to take a look at it tommorow as i'm quite busy today.

<!-- gh-comment-id:2646457292 --> @ramadanomar commented on GitHub (Feb 9, 2025): > Same issue here, again with turborepo. Used [shadcn's monorepo](https://ui.shadcn.com/docs/monorepo) cli command. > > I asked [ChatGPT](https://chatgpt.com/share/e/67a8f00d-05d4-8002-bbe9-b98809b41a6f) some stuff and even though I know its not 100% reliable thought this could help someone with more knowledge in this than me. 😊 Conversation inaccessible or not found. You may need to switch accounts or request access if this conversation exists. This [comment](https://github.com/microsoft/TypeScript/pull/58176#issuecomment-2052698294) has more context to the problem. I'll try to take a look at it tommorow as i'm quite busy today.
GiteaMirror commented 2026-04-13 03:53:31 -05:00
Author
Owner
Copy Link

@louisab-dev commented on GitHub (Feb 9, 2025):

A temporary workaround is to specify the return type like so:

import { createAuthClient } from "better-auth/react";

export const authClient: ReturnType<typeof createAuthClient> = createAuthClient(
  {
    baseURL: "http://localhost:3000", // the base url of your auth server
  },
);
<!-- gh-comment-id:2646606773 --> @louisab-dev commented on GitHub (Feb 9, 2025): A temporary workaround is to specify the return type like so: ```typescript import { createAuthClient } from "better-auth/react"; export const authClient: ReturnType<typeof createAuthClient> = createAuthClient( { baseURL: "http://localhost:3000", // the base url of your auth server }, ); ```
GiteaMirror commented 2026-04-13 03:53:32 -05:00
Author
Owner
Copy Link

@ramadanomar commented on GitHub (Feb 9, 2025):

A temporary workaround is to specify the return type like so:

import { createAuthClient } from "better-auth/react";

export const authClient: ReturnType = createAuthClient(
{
baseURL: "http://localhost:3000", // the base url of your auth server
},
);

This works if you only use the generic types. It wont infer any properties that are defined from the plugins (atleast for the admin plugin)

EDIT: by generic i mean any non plugin routes

<!-- gh-comment-id:2646607356 --> @ramadanomar commented on GitHub (Feb 9, 2025): > A temporary workaround is to specify the return type like so: > > import { createAuthClient } from "better-auth/react"; > > export const authClient: ReturnType<typeof createAuthClient> = createAuthClient( > { > baseURL: "http://localhost:3000", // the base url of your auth server > }, > ); This works if you only use the generic types. It wont infer any properties that are defined from the plugins (atleast for the admin plugin) EDIT: by generic i mean any non plugin routes
GiteaMirror commented 2026-04-13 03:53:33 -05:00
Author
Owner
Copy Link

@ping-maxwell commented on GitHub (Feb 10, 2025):

Make sure that strict is set to true in your tsconfig.

https://www.better-auth.com/docs/concepts/typescript#typescript-config

<!-- gh-comment-id:2646841986 --> @ping-maxwell commented on GitHub (Feb 10, 2025): Make sure that `strict` is set to `true` in your tsconfig. https://www.better-auth.com/docs/concepts/typescript#typescript-config
GiteaMirror commented 2026-04-13 03:53:34 -05:00
Author
Owner
Copy Link

@ryunosuke21 commented on GitHub (Feb 10, 2025):

Same issue here, again with turborepo. Used shadcn's monorepo cli command.
I asked ChatGPT some stuff and even though I know its not 100% reliable thought this could help someone with more knowledge in this than me. 😊

Conversation inaccessible or not found. You may need to switch accounts or request access if this conversation exists.

This comment has more context to the problem. I'll try to take a look at it tommorow as i'm quite busy today.

I uploaded the logs

<!-- gh-comment-id:2646893291 --> @ryunosuke21 commented on GitHub (Feb 10, 2025): > > Same issue here, again with turborepo. Used [shadcn's monorepo](https://ui.shadcn.com/docs/monorepo) cli command. > > I asked [ChatGPT](https://chatgpt.com/share/e/67a8f00d-05d4-8002-bbe9-b98809b41a6f) some stuff and even though I know its not 100% reliable thought this could help someone with more knowledge in this than me. 😊 > > Conversation inaccessible or not found. You may need to switch accounts or request access if this conversation exists. > > This [comment](https://github.com/microsoft/TypeScript/pull/58176#issuecomment-2052698294) has more context to the problem. I'll try to take a look at it tommorow as i'm quite busy today. I uploaded the [logs](github.com/MarioPon11/chat-log-better-auth/blob/main/README.md)
GiteaMirror commented 2026-04-13 03:53:36 -05:00
Author
Owner
Copy Link

@ramadanomar commented on GitHub (Feb 13, 2025):

Make sure that strict is set to true in your tsconfig.

better-auth.com/docs/concepts/typescript#typescript-config

It is set as strict:

{
  "$schema": "https://json.schemastore.org/tsconfig",
  "display": "Next.js",
  "extends": "./base.json",
  "compilerOptions": {
    "plugins": [{ "name": "next" }],
    "module": "ESNext",
    "moduleResolution": "Bundler",
    "allowJs": true,
    "jsx": "preserve",
    "noEmit": true,
    "strict": true
  }
}

With base.json

{
  "$schema": "https://json.schemastore.org/tsconfig",
  "display": "Default",
  "compilerOptions": {
    "declaration": true,
    "declarationMap": true,
    "esModuleInterop": true,
    "incremental": false,
    "isolatedModules": true,
    "lib": ["es2022", "DOM", "DOM.Iterable"],
    "module": "NodeNext",
    "moduleDetection": "force",
    "moduleResolution": "NodeNext",
    "noUncheckedIndexedAccess": true,
    "resolveJsonModule": true,
    "skipLibCheck": true,
    "strict": true,
    "target": "ES2022"
  }
}
<!-- gh-comment-id:2655235917 --> @ramadanomar commented on GitHub (Feb 13, 2025): > Make sure that `strict` is set to `true` in your tsconfig. > > [better-auth.com/docs/concepts/typescript#typescript-config](https://www.better-auth.com/docs/concepts/typescript#typescript-config) It is set as strict: ```json { "$schema": "https://json.schemastore.org/tsconfig", "display": "Next.js", "extends": "./base.json", "compilerOptions": { "plugins": [{ "name": "next" }], "module": "ESNext", "moduleResolution": "Bundler", "allowJs": true, "jsx": "preserve", "noEmit": true, "strict": true } } ``` With base.json ```json { "$schema": "https://json.schemastore.org/tsconfig", "display": "Default", "compilerOptions": { "declaration": true, "declarationMap": true, "esModuleInterop": true, "incremental": false, "isolatedModules": true, "lib": ["es2022", "DOM", "DOM.Iterable"], "module": "NodeNext", "moduleDetection": "force", "moduleResolution": "NodeNext", "noUncheckedIndexedAccess": true, "resolveJsonModule": true, "skipLibCheck": true, "strict": true, "target": "ES2022" } } ```
GiteaMirror commented 2026-04-13 03:53:36 -05:00
Author
Owner
Copy Link

@BurakGozen commented on GitHub (Feb 13, 2025):

I fixed it by passing the ClientOptions type and overriding the plugins field:

type AuthClientOptions = Omit<ClientOptions, "plugins"> & {
  plugins: [ReturnType<typeof emailOTPClient>];
};

export const authClient = createAuthClient<AuthClientOptions>({
  baseURL: "http://localhost:3000", // the base url of your auth server
  plugins: [emailOTPClient()],
});
<!-- gh-comment-id:2657315583 --> @BurakGozen commented on GitHub (Feb 13, 2025): I fixed it by passing the ClientOptions type and overriding the plugins field: ```tsx type AuthClientOptions = Omit<ClientOptions, "plugins"> & { plugins: [ReturnType<typeof emailOTPClient>]; }; export const authClient = createAuthClient<AuthClientOptions>({ baseURL: "http://localhost:3000", // the base url of your auth server plugins: [emailOTPClient()], }); ```
GiteaMirror commented 2026-04-13 03:53:37 -05:00
Author
Owner
Copy Link

@gabehayes commented on GitHub (Feb 14, 2025):

In my case, using ReturnType<typeof createAuthClient> still leads to issues, because the plugins aren't typed.

Further, using @BurakGozen's example above still didn't work for me, as using a generic still leads to the issue with inference.

The only way that I was able to get the expected typing was by typing the entire object like so:

type AuthClient = ReturnType<
  typeof createAuthClient<{
    plugins: [ReturnType<typeof emailOTPClient>];
  }>
>;

export const authClient: AuthClient = createAuthClient({
  baseURL: process.env.NEXT_PUBLIC_BETTER_AUTH_URL,
  plugins: [emailOTPClient()],
});

I think this is a reasonable workaround, be it rather verbose, for the time being. Hoping it can be addressed in a future release. I didn't see it appear until upgrading pnpm to 10.3, but I don't want to point to that being the culprit as I updated a handful of other dependencies at the same time.

FWIW I did see this issue come up with other libraries as well.

<!-- gh-comment-id:2658018148 --> @gabehayes commented on GitHub (Feb 14, 2025): In my case, using `ReturnType<typeof createAuthClient>` still leads to issues, because the plugins aren't typed. Further, using @BurakGozen's example above still didn't work for me, as using a generic still leads to the issue with inference. The only way that I was able to get the expected typing was by typing the entire object like so: ```ts type AuthClient = ReturnType< typeof createAuthClient<{ plugins: [ReturnType<typeof emailOTPClient>]; }> >; export const authClient: AuthClient = createAuthClient({ baseURL: process.env.NEXT_PUBLIC_BETTER_AUTH_URL, plugins: [emailOTPClient()], }); ``` I think this is a reasonable workaround, be it rather verbose, for the time being. Hoping it can be addressed in a future release. I didn't see it appear until upgrading pnpm to 10.3, but I don't want to point to that being the culprit as I updated a handful of other dependencies at the same time. FWIW I did see this issue come up with other libraries as well.
GiteaMirror commented 2026-04-13 03:53:38 -05:00
Author
Owner
Copy Link

@ibadus commented on GitHub (Feb 15, 2025):

In my case, using ReturnType<typeof createAuthClient> still leads to issues, because the plugins aren't typed.

Further, using @BurakGozen's example above still didn't work for me, as using a generic still leads to the issue with inference.

The only way that I was able to get the expected typing was by typing the entire object like so:

type AuthClient = ReturnType<
typeof createAuthClient<{
plugins: [ReturnType];
}>

;

export const authClient: AuthClient = createAuthClient({
baseURL: process.env.NEXT_PUBLIC_BETTER_AUTH_URL,
plugins: [emailOTPClient()],
});
I think this is a reasonable workaround, be it rather verbose, for the time being. Hoping it can be addressed in a future release. I didn't see it appear until upgrading pnpm to 10.3, but I don't want to point to that being the culprit as I updated a handful of other dependencies at the same time.

FWIW I did see this issue come up with other libraries as well.

This solution is not working for me unfortunately.

Image

<!-- gh-comment-id:2660867414 --> @ibadus commented on GitHub (Feb 15, 2025): > In my case, using `ReturnType<typeof createAuthClient>` still leads to issues, because the plugins aren't typed. > > Further, using [@BurakGozen](https://github.com/BurakGozen)'s example above still didn't work for me, as using a generic still leads to the issue with inference. > > The only way that I was able to get the expected typing was by typing the entire object like so: > > type AuthClient = ReturnType< > typeof createAuthClient<{ > plugins: [ReturnType<typeof emailOTPClient>]; > }> > >; > > export const authClient: AuthClient = createAuthClient({ > baseURL: process.env.NEXT_PUBLIC_BETTER_AUTH_URL, > plugins: [emailOTPClient()], > }); > I think this is a reasonable workaround, be it rather verbose, for the time being. Hoping it can be addressed in a future release. I didn't see it appear until upgrading pnpm to 10.3, but I don't want to point to that being the culprit as I updated a handful of other dependencies at the same time. > > FWIW I did see this issue come up with other libraries as well. This solution is not working for me unfortunately. ![Image](https://github.com/user-attachments/assets/d40f89b5-bdb7-463c-b5b7-4f5ed578a6b6)
GiteaMirror commented 2026-04-13 03:53:38 -05:00
Author
Owner
Copy Link

@benjamindell commented on GitHub (Feb 15, 2025):

FYI - i've just upgraded to the 1.2 beta and it has fixed this issue and more :)

<!-- gh-comment-id:2660870022 --> @benjamindell commented on GitHub (Feb 15, 2025): FYI - i've just upgraded to the 1.2 beta and it has fixed this issue and more :)
GiteaMirror commented 2026-04-13 03:53:39 -05:00
Author
Owner
Copy Link

@ibadus commented on GitHub (Feb 15, 2025):

FYI - i've just upgraded to the 1.2 beta and it has fixed this issue and more :)

Still having the same error with: "better-auth": "1.2.0-beta.8" :(

<!-- gh-comment-id:2660875232 --> @ibadus commented on GitHub (Feb 15, 2025): > FYI - i've just upgraded to the 1.2 beta and it has fixed this issue and more :) Still having the same error with: "better-auth": "1.2.0-beta.8" :(
GiteaMirror commented 2026-04-13 03:53:40 -05:00
Author
Owner
Copy Link

@benjamindell commented on GitHub (Feb 15, 2025):

If you upgrade to 1.2 you shouldn't need to explicitly set the type for the better-auth client initialisation.

<!-- gh-comment-id:2660875631 --> @benjamindell commented on GitHub (Feb 15, 2025): If you upgrade to 1.2 you shouldn't need to explicitly set the type for the better-auth client initialisation.
GiteaMirror commented 2026-04-13 03:53:41 -05:00
Author
Owner
Copy Link

@ibadus commented on GitHub (Feb 15, 2025):

I think I've identified the root cause of this problem. The compiler was throwing the following error:

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

This error occurs when TypeScript tries to infer a type that it cannot handle automatically due to its size.

Adding these options to tsconfig.json resolved the issue:

"compilerOptions": {
    "composite": false,
    "declaration": false,
    "declarationMap": false
}
<!-- gh-comment-id:2660879627 --> @ibadus commented on GitHub (Feb 15, 2025): I think I've identified the root cause of this problem. The compiler was throwing the following error: `The inferred type of this node exceeds the maximum length the compiler will serialize. An explicit type annotation is needed.` This error occurs when TypeScript tries to infer a type that it cannot handle automatically due to its size. Adding these options to `tsconfig.json` resolved the issue: ```json "compilerOptions": { "composite": false, "declaration": false, "declarationMap": false }
GiteaMirror commented 2026-04-13 03:53:42 -05:00
Author
Owner
Copy Link

@ramadanomar commented on GitHub (Feb 19, 2025):

If you upgrade to 1.2 you shouldn't need to explicitly set the type for the better-auth client initialisation.

This does not fix it

<!-- gh-comment-id:2668873605 --> @ramadanomar commented on GitHub (Feb 19, 2025): > If you upgrade to 1.2 you shouldn't need to explicitly set the type for the better-auth client initialisation. This does not fix it
GiteaMirror commented 2026-04-13 03:53:43 -05:00
Author
Owner
Copy Link

@ramadanomar commented on GitHub (Feb 19, 2025):

I have found a fix. I've upgraded to 1.1.14-beta.2 and still faced the same issue. I added nanostores as a dependency and it seems to have fixed it (we dont need to explicitly typecast the authclient anymore as well). as @benjamindell mentioned earlier, i think this fix should work for 1.12 and newer releases but i have not personally tested it

I can close the issue if this fix works for the others.

<!-- gh-comment-id:2668886123 --> @ramadanomar commented on GitHub (Feb 19, 2025): I have found a fix. I've upgraded to `1.1.14-beta.2` and still faced the same issue. I added nanostores as a dependency and it seems to have fixed it (we dont need to explicitly typecast the authclient anymore as well). as @benjamindell mentioned earlier, i think this fix should work for 1.12 and newer releases but i have not personally tested it I can close the issue if this fix works for the others.
GiteaMirror commented 2026-04-13 03:53:43 -05:00
Author
Owner
Copy Link

@samducker commented on GitHub (Feb 23, 2025):

I have the same issue but specifically with the betterAuth on the server

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

On the above solution.

"compilerOptions": {
    "composite": false,
    "declaration": false,
    "declarationMap": false
}

Would love to know how to reliably manually type this as setting my tsconfig like this makes my IDE very slow in a large project.

<!-- gh-comment-id:2677096646 --> @samducker commented on GitHub (Feb 23, 2025): I have the same issue but specifically with the betterAuth on the server ``` The inferred type of 'createAuth' cannot be named without a reference to '../../../../../node_modules/better-auth/dist/helper-DFk-nDjL'. This is likely not portable. A type annotation is necessary.ts(2742) ``` On the above solution. ``` "compilerOptions": { "composite": false, "declaration": false, "declarationMap": false } ``` Would love to know how to reliably manually type this as setting my tsconfig like this makes my IDE very slow in a large project.
GiteaMirror commented 2026-04-13 03:53:44 -05:00
Author
Owner
Copy Link

@nktnet1 commented on GitHub (Feb 23, 2025):

Ran into a similar issue too 😕.

The workaround I ended up going with is to simply export the types together with the auth client, e.g. in my @repo/auth package:

Then instantiating the auth client in my web application with the same types:

The full repository is here for reference. Hope this can be fixed 🙏, but not too bothered by the workaround.

<!-- gh-comment-id:2677136639 --> @nktnet1 commented on GitHub (Feb 23, 2025): Ran into a similar issue too 😕. The workaround I ended up going with is to simply export the types together with the auth client, e.g. in my `@repo/auth` package: - https://github.com/nktnet1/rt-stack/blob/c9e2c654d5014389c82ed07b34b7dc316452f331/packages/auth/src/client.ts#L7 Then instantiating the auth client in my `web` application with the same types: - https://github.com/nktnet1/rt-stack/blob/c9e2c654d5014389c82ed07b34b7dc316452f331/apps/web/src/clients/authClient.ts#L4 The full repository is [here](https://github.com/nktnet1/rt-stack) for reference. Hope this can be fixed 🙏, but not too bothered by the workaround.
GiteaMirror commented 2026-04-13 03:53:45 -05:00
Author
Owner
Copy Link

@pthieu commented on GitHub (Mar 1, 2025):

Ran into a similar issue too 😕.

The workaround I ended up going with is to simply export the types together with the auth client, e.g. in my @repo/auth package:

Then instantiating the auth client in my web application with the same types:

The full repository is here for reference. Hope this can be fixed 🙏, but not too bothered by the workaround.

just tried this with high hopes but looks like it doesn't work when using the admin plugin

Image

<!-- gh-comment-id:2692447416 --> @pthieu commented on GitHub (Mar 1, 2025): > Ran into a similar issue too 😕. > > The workaround I ended up going with is to simply export the types together with the auth client, e.g. in my `@repo/auth` package: > > * https://github.com/nktnet1/rt-stack/blob/c9e2c654d5014389c82ed07b34b7dc316452f331/packages/auth/src/client.ts#L7 > > Then instantiating the auth client in my `web` application with the same types: > > * https://github.com/nktnet1/rt-stack/blob/c9e2c654d5014389c82ed07b34b7dc316452f331/apps/web/src/clients/authClient.ts#L4 > > The full repository is [here](https://github.com/nktnet1/rt-stack) for reference. Hope this can be fixed 🙏, but not too bothered by the workaround. just tried this with high hopes but looks like it doesn't work when using the `admin` plugin ![Image](https://github.com/user-attachments/assets/ab3e0548-05f0-4495-a25b-dd3bdaf01b4d)
GiteaMirror commented 2026-04-13 03:53:47 -05:00
Author
Owner
Copy Link

@nktnet1 commented on GitHub (Mar 1, 2025):

@pthieu if you want to add additional plugins, you need to also infer the client types for them when exporting your AuthClient.

I've updated the code to include the admin plugin on a different branch here:

Specifically, these lines:

export type AuthClient = ReturnType<
  typeof createBetterAuthClient<{ plugins: [ReturnType<typeof adminClient>] }>
>;
<!-- gh-comment-id:2692473372 --> @nktnet1 commented on GitHub (Mar 1, 2025): @pthieu if you want to add additional plugins, you need to also infer the client types for them when exporting your `AuthClient`. I've [updated the code](https://github.com/nktnet1/rt-stack/compare/main...better-auth-admin-plugin) to include the admin plugin on a different branch here: - https://github.com/nktnet1/rt-stack/tree/better-auth-admin-plugin Specifically, [these lines](https://github.com/nktnet1/rt-stack/blob/20c259bbb30455370594b1df006b844c6f5243c9/packages/auth/src/client.ts#L8-L10): ```ts export type AuthClient = ReturnType< typeof createBetterAuthClient<{ plugins: [ReturnType<typeof adminClient>] }> >; ```
GiteaMirror commented 2026-04-13 03:53:48 -05:00
Author
Owner
Copy Link

@RicSala commented on GitHub (Mar 6, 2025):

I think I've identified the root cause of this problem. The compiler was throwing the following error:

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

This error occurs when TypeScript tries to infer a type that it cannot handle automatically due to its size.

Adding these options to tsconfig.json resolved the issue:

"compilerOptions": {
"composite": false,
"declaration": false,
"declarationMap": false
}

it does!!!

<!-- gh-comment-id:2703509091 --> @RicSala commented on GitHub (Mar 6, 2025): > I think I've identified the root cause of this problem. The compiler was throwing the following error: > > `The inferred type of this node exceeds the maximum length the compiler will serialize. An explicit type annotation is needed.` > > This error occurs when TypeScript tries to infer a type that it cannot handle automatically due to its size. > > Adding these options to `tsconfig.json` resolved the issue: > > "compilerOptions": { > "composite": false, > "declaration": false, > "declarationMap": false > } it does!!!
GiteaMirror commented 2026-04-13 03:53:49 -05:00
Author
Owner
Copy Link

@letstri commented on GitHub (Mar 6, 2025):

To fix this, @Bekacru or another maintainer should add an interface for the Better Auth instance. I had the same problem with my lib, and you can check it as a reference to fix it inside the lib.

http://github.com/letstri/permix/blob/main/permix/src/core/create-permix.ts#L280

Better Auth should have an interface for return type and also export.

<!-- gh-comment-id:2704164156 --> @letstri commented on GitHub (Mar 6, 2025): To fix this, @Bekacru or another maintainer should add an interface for the Better Auth instance. I had the same problem with my lib, and you can check it as a reference to fix it inside the lib. http://github.com/letstri/permix/blob/main/permix/src/core/create-permix.ts#L280 Better Auth should have an interface for return type and also export.
GiteaMirror commented 2026-04-13 03:53:50 -05:00
Author
Owner
Copy Link

@Bekacru commented on GitHub (Mar 15, 2025):

Hey everyone, sorry for the late reply here. can you all confirm if you're experiencing issues after upgrading to the PR version?

npm i https://pkg.pr.new/better-auth/better-auth@1827

Please send me the error message along with your tsconfig.

Thanks!

<!-- gh-comment-id:2726425964 --> @Bekacru commented on GitHub (Mar 15, 2025): Hey everyone, sorry for the late reply here. can you all confirm if you're experiencing issues after upgrading to the PR version? ```bash npm i https://pkg.pr.new/better-auth/better-auth@1827 ``` Please send me the error message along with your `tsconfig`. Thanks!
GiteaMirror commented 2026-04-13 03:53:51 -05:00
Author
Owner
Copy Link

@letstri commented on GitHub (Mar 15, 2025):

I've installed the new version, it seems to work, waiting for the release 🫡

<!-- gh-comment-id:2726436352 --> @letstri commented on GitHub (Mar 15, 2025): I've installed the new version, it seems to work, waiting for the release 🫡
GiteaMirror commented 2026-04-13 03:53:52 -05:00
Author
Owner
Copy Link

@nktnet1 commented on GitHub (Mar 15, 2025):

I've also tested it, but same error... weird.
Have tried clearing cache and node_modules, remove pnpm-lock.yaml, then re-install and restart IDE/TS Server.

The changes I made is in this commit - all I did was updated better-auth to https://pkg.pr.new/better-auth/better-auth@1827 and then attempted to remove the explicit AuthClient workaround when using createAuthClient.

Error is still

The inferred type of 'authClient' cannot be named without a reference to '.pnpm/nanostores@0.11.4/node_modules/nanostores'. This is likely not portable. A type annotation is necessary.

Here is the branch for reference. TS Config is in several places:

<!-- gh-comment-id:2726438016 --> @nktnet1 commented on GitHub (Mar 15, 2025): I've also tested it, but same error... weird. Have tried clearing cache and `node_modules`, remove `pnpm-lock.yaml`, then re-install and restart IDE/TS Server. The changes I made is in [this commit](https://github.com/nktnet1/rt-stack/commit/8800e15b4af82cf83dedaf57d21f8dfc7864b8db) - all I did was updated better-auth to `https://pkg.pr.new/better-auth/better-auth@1827` and then attempted to remove the explicit AuthClient workaround when using `createAuthClient`. Error is still > The inferred type of 'authClient' cannot be named without a reference to '.pnpm/nanostores@0.11.4/node_modules/nanostores'. This is likely not portable. A type annotation is necessary. Here is the [branch](https://github.com/nktnet1/rt-stack/tree/better-auth-type-annotation-test) for reference. TS Config is in several places: - [./packages/auth/tsconfig.json](https://github.com/nktnet1/rt-stack/blob/main/packages/auth/tsconfig.json) - [./tools/typescript/internal-package.json](https://github.com/nktnet1/rt-stack/blob/main/tools/typescript/internal-package.json) - [./tools/typescript/base.json](https://github.com/nktnet1/rt-stack/blob/main/tools/typescript/base.json)
GiteaMirror commented 2026-04-13 03:53:53 -05:00
Author
Owner
Copy Link

@Bekacru commented on GitHub (Mar 15, 2025):

@nktnet1 update to https://pkg.pr.new/better-auth/better-auth@dac51d3

<!-- gh-comment-id:2726537688 --> @Bekacru commented on GitHub (Mar 15, 2025): @nktnet1 update to https://pkg.pr.new/better-auth/better-auth@dac51d3
GiteaMirror commented 2026-04-13 03:53:54 -05:00
Author
Owner
Copy Link

@nktnet1 commented on GitHub (Mar 15, 2025):

Thanks @Bekacru, that's better, the error for nanostores is gone.

Now it's undici-types:

The inferred type of 'createAuthClient' cannot be named without a reference to '.pnpm/undici-types@6.20.0/node_modules/undici-types'. This is likely not portable. A type annotation is necessary.

Made the change in this commit. Kept everything else the same.

<!-- gh-comment-id:2726546882 --> @nktnet1 commented on GitHub (Mar 15, 2025): Thanks @Bekacru, that's better, the error for `nanostores` is gone. Now it's `undici-types`: > The inferred type of 'createAuthClient' cannot be named without a reference to '.pnpm/undici-types@6.20.0/node_modules/undici-types'. This is likely not portable. A type annotation is necessary. Made the change in [this commit](https://github.com/nktnet1/rt-stack/commit/55725491f51651b81de3072b02855347f9640539). Kept everything else the same.
GiteaMirror commented 2026-04-13 03:53:54 -05:00
Author
Owner
Copy Link

@Bekacru commented on GitHub (Mar 15, 2025):

@nktnet1 add lib: ["dom"] in your tsconfig

<!-- gh-comment-id:2726568731 --> @Bekacru commented on GitHub (Mar 15, 2025): @nktnet1 add `lib: ["dom"]` in your tsconfig
GiteaMirror commented 2026-04-13 03:53:55 -05:00
Author
Owner
Copy Link

@nktnet1 commented on GitHub (Mar 15, 2025):

That did the trick - thanks @Bekacru! (commit)

<!-- gh-comment-id:2726572684 --> @nktnet1 commented on GitHub (Mar 15, 2025): That did the trick - thanks @Bekacru! ([commit](https://github.com/nktnet1/rt-stack/commit/9c05a98e1a80fbafc2cdbf6b39c2f0b14e98a26a))
GiteaMirror commented 2026-04-13 03:53:55 -05:00
Author
Owner
Copy Link

@grmkris commented on GitHub (Mar 28, 2025):

getting same here still.. on latest versions
turborepo + pnpm

what i do is to have a function that generate auth client this way i can dynamically pass in db object and it can work either with pglite or regular pg

import type { db } from "@/db/db"; // your drizzle instance
import { betterAuth } from "better-auth";
import { drizzleAdapter } from "better-auth/adapters/drizzle";
import {
  admin,
  anonymous,
  apiKey,
  bearer,
  openAPI,
  organization,
  username,
} from "better-auth/plugins";

import { passkey } from "better-auth/plugins/passkey";
import type { Logger } from "logger";
import { SERVICE_URLS } from "shared";
import { env } from "./env";

export const createAuth = (props: {
  db: db;
  logger?: Logger;
}) => {
  return betterAuth({
    baseURL: SERVICE_URLS[env.APP_ENV].auth,
    basePath: "/api/auth",
    trustedOrigins: [
      SERVICE_URLS[env.APP_ENV].frontend,
      SERVICE_URLS[env.APP_ENV].api,
    ],
    database: drizzleAdapter(props.db, {
      provider: "pg", // or "mysql", "sqlite"
    }),
    plugins: [
      openAPI(),
      anonymous(),
      username(),
      passkey(),
      admin(),
      organization(),
      bearer(),
      apiKey(),
    ],
    emailAndPassword: {
      enabled: true,
    },
    logger: {
      level: env.LOG_LEVEL === "trace" ? "debug" : env.LOG_LEVEL,
      log(level, message, ...args) {
        props.logger?.[level](message, ...args);
      },
    },
    advanced: {
      generateId: false,
    },
  });
};


src/auth.ts:19:14 - error TS2742: The inferred type of 'createAuth' cannot be named without a reference to '.pnpm/@simplewebauthn+server@13.1.1/node_modules/@simplewebauthn/server'. This is likely not portable. A type annotation is necessary.

19 export const createAuth = (props: {
                ~~~~~~~~~~

src/auth.ts:19:14 - error TS7056: The inferred type of this node exceeds the maximum length the compiler will serialize. An explicit type annotation is needed.

19 export const createAuth = (props: {
                ~~~~~~~~~~


Found 2 errors in the same file, starting at: src/auth.ts:19

 ELIFECYCLE  Command failed with exit code 1.
                                                                                                                                                                                         

"better-auth": "^1.2.5",
<!-- gh-comment-id:2760814591 --> @grmkris commented on GitHub (Mar 28, 2025): getting same here still.. on latest versions turborepo + pnpm what i do is to have a function that generate auth client this way i can dynamically pass in db object and it can work either with pglite or regular pg ```ts import type { db } from "@/db/db"; // your drizzle instance import { betterAuth } from "better-auth"; import { drizzleAdapter } from "better-auth/adapters/drizzle"; import { admin, anonymous, apiKey, bearer, openAPI, organization, username, } from "better-auth/plugins"; import { passkey } from "better-auth/plugins/passkey"; import type { Logger } from "logger"; import { SERVICE_URLS } from "shared"; import { env } from "./env"; export const createAuth = (props: { db: db; logger?: Logger; }) => { return betterAuth({ baseURL: SERVICE_URLS[env.APP_ENV].auth, basePath: "/api/auth", trustedOrigins: [ SERVICE_URLS[env.APP_ENV].frontend, SERVICE_URLS[env.APP_ENV].api, ], database: drizzleAdapter(props.db, { provider: "pg", // or "mysql", "sqlite" }), plugins: [ openAPI(), anonymous(), username(), passkey(), admin(), organization(), bearer(), apiKey(), ], emailAndPassword: { enabled: true, }, logger: { level: env.LOG_LEVEL === "trace" ? "debug" : env.LOG_LEVEL, log(level, message, ...args) { props.logger?.[level](message, ...args); }, }, advanced: { generateId: false, }, }); }; ``` ```sh src/auth.ts:19:14 - error TS2742: The inferred type of 'createAuth' cannot be named without a reference to '.pnpm/@simplewebauthn+server@13.1.1/node_modules/@simplewebauthn/server'. This is likely not portable. A type annotation is necessary. 19 export const createAuth = (props: { ~~~~~~~~~~ src/auth.ts:19:14 - error TS7056: The inferred type of this node exceeds the maximum length the compiler will serialize. An explicit type annotation is needed. 19 export const createAuth = (props: { ~~~~~~~~~~ Found 2 errors in the same file, starting at: src/auth.ts:19  ELIFECYCLE  Command failed with exit code 1. ``` ``` "better-auth": "^1.2.5", ```
GiteaMirror commented 2026-04-13 03:53:56 -05:00
Author
Owner
Copy Link

@pthieu commented on GitHub (Mar 30, 2025):

Tried to remove the explicit typing mentioned here: https://github.com/better-auth/better-auth/issues/1391#issuecomment-2692473372 to see if 1.2.5 solved it and it did not.

However, looks like if I remove "composite": true while on 1.2.5, the error will go away. Not ideal, but hopefully helps for those who don't need this setting.

<!-- gh-comment-id:2764338498 --> @pthieu commented on GitHub (Mar 30, 2025): Tried to remove the explicit typing mentioned here: https://github.com/better-auth/better-auth/issues/1391#issuecomment-2692473372 to see if `1.2.5` solved it and it did not. However, looks like if I remove `"composite": true` while on `1.2.5`, the error will go away. Not ideal, but hopefully helps for those who don't need this setting.
GiteaMirror commented 2026-04-13 03:53:57 -05:00
Author
Owner
Copy Link

@nktnet1 commented on GitHub (Mar 30, 2025):

@pthieu it works fine for me on 1.2.5 with "composite": "true". Perhaps there is something else you can tweak?

For example, in my auth package's tsconfig, I am importing from this base, which does set composite to true.

<!-- gh-comment-id:2764343781 --> @nktnet1 commented on GitHub (Mar 30, 2025): @pthieu it works fine for me on `1.2.5` with `"composite": "true"`. Perhaps there is something else you can tweak? For example, in my auth package's tsconfig, I am importing from [this base](https://github.com/nktnet1/rt-stack/blob/9114a7fb3b6dcc4555a8f9cd81b67b7c8841bbbb/packages/auth/tsconfig.json#L2), which does [set composite to true](https://github.com/nktnet1/rt-stack/blob/9114a7fb3b6dcc4555a8f9cd81b67b7c8841bbbb/tools/typescript/internal-package.json#L5).
GiteaMirror commented 2026-04-13 03:53:59 -05:00
Author
Owner
Copy Link

@pthieu commented on GitHub (Mar 30, 2025):

@nktnet1

// tsconfig.json
{
  "files": [],
  "references": [
    {
      "path": "./tsconfig.node.json"
    },
    {
      "path": "./tsconfig.vite.json"
    }
  ],
  "compilerOptions": {
    "checkJs": true,
    "verbatimModuleSyntax": true,
    "skipLibCheck": true,
    "strict": true,
    "noEmit": true,
    "baseUrl": ".",
    "paths": {
      "~/*": [
        "./src/*"
      ],
      "@/*": [
        "./src/app/*"
      ]
    },
  }
}

// tsconfig.vite.json
{
  "extends": "./tsconfig.json",
  "include": [
    ".react-router/types/**/*",
    "src/app/**/*",
    "src/**/*",
  ],
  "compilerOptions": {
    "composite": true,
    "strict": true,
    "lib": [
      "DOM",
      "DOM.Iterable",
      "ES2022"
    ],
    "types": [
      "vite/client"
    ],
    "target": "ES2022",
    "module": "ES2022",
    "moduleResolution": "bundler",
    "jsx": "react-jsx",
    "rootDirs": [
      ".",
      "./.react-router/types"
    ],
    "esModuleInterop": true,
    "resolveJsonModule": true
  }
}

Tried a few variables from your links, including declaration and declarationMap, didn't work.

I did notice that assing baseUrl: '.' in my base tsconfig.json solved it for my backend, but still getting it for my frontend.

<!-- gh-comment-id:2764351839 --> @pthieu commented on GitHub (Mar 30, 2025): @nktnet1 ```json // tsconfig.json { "files": [], "references": [ { "path": "./tsconfig.node.json" }, { "path": "./tsconfig.vite.json" } ], "compilerOptions": { "checkJs": true, "verbatimModuleSyntax": true, "skipLibCheck": true, "strict": true, "noEmit": true, "baseUrl": ".", "paths": { "~/*": [ "./src/*" ], "@/*": [ "./src/app/*" ] }, } } ``` ```json // tsconfig.vite.json { "extends": "./tsconfig.json", "include": [ ".react-router/types/**/*", "src/app/**/*", "src/**/*", ], "compilerOptions": { "composite": true, "strict": true, "lib": [ "DOM", "DOM.Iterable", "ES2022" ], "types": [ "vite/client" ], "target": "ES2022", "module": "ES2022", "moduleResolution": "bundler", "jsx": "react-jsx", "rootDirs": [ ".", "./.react-router/types" ], "esModuleInterop": true, "resolveJsonModule": true } } ``` Tried a few variables from your links, including `declaration` and `declarationMap`, didn't work. I did notice that assing `baseUrl: '.'` in my base `tsconfig.json` solved it for my backend, but still getting it for my frontend.
GiteaMirror commented 2026-04-13 03:54:00 -05:00
Author
Owner
Copy Link

@nktnet1 commented on GitHub (Mar 30, 2025):

Hmm well, my repository is publicly available and is confirmed to not have any type issues in v1.2.5 even with "composite": "true", so feel free to play around until you find your desired configuration. I also commented on discord about other potential issues here (e.g. needing to clean node_modules + cache / restart IDE).

Can't really help with much else without a minimal reproducible example, but hope you can get it resolved.

<!-- gh-comment-id:2764374720 --> @nktnet1 commented on GitHub (Mar 30, 2025): Hmm well, my repository is publicly available and is confirmed to not have any type issues in v1.2.5 even with `"composite": "true"`, so feel free to play around until you find your desired configuration. I also commented on discord about other potential issues [here](https://discord.com/channels/1288403910284935179/1344012146194776276/1354293775618281475) (e.g. needing to clean node_modules + cache / restart IDE). Can't really help with much else without a minimal reproducible example, but hope you can get it resolved.
GiteaMirror commented 2026-04-13 03:54:01 -05:00
Author
Owner
Copy Link

@pthieu commented on GitHub (Mar 30, 2025):

@nktnet1 for sure, let me play around about with the links you gave, thanks a bunch!

<!-- gh-comment-id:2764723670 --> @pthieu commented on GitHub (Mar 30, 2025): @nktnet1 for sure, let me play around about with the links you gave, thanks a bunch!
GiteaMirror commented 2026-04-13 03:54:02 -05:00
Author
Owner
Copy Link

@ian commented on GitHub (Apr 2, 2025):

Dealing with the same issues over here on a pnpm monorepo, have tried everything in this thread and still no inferred types on user or session.

Has anyone found a solution here?

<!-- gh-comment-id:2772457338 --> @ian commented on GitHub (Apr 2, 2025): Dealing with the same issues over here on a pnpm monorepo, have tried everything in this thread and still no inferred types on user or session. Has anyone found a solution here?
GiteaMirror commented 2026-04-13 03:54:04 -05:00
Author
Owner
Copy Link

@letstri commented on GitHub (Apr 2, 2025):

You can use my project as reference connnect.app. I hope it can help

<!-- gh-comment-id:2773538135 --> @letstri commented on GitHub (Apr 2, 2025): You can use my project as reference [connnect.app](https://github.com/wannabespace/connnect). I hope it can help
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#8726
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?