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

[GH-ISSUE #7219] SSO plugin type inference issue #19393

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

Originally created by @anzev on GitHub (Jan 9, 2026).
Original GitHub issue: https://github.com/better-auth/better-auth/issues/7219

Originally assigned to: @bytaesu on GitHub.

Is this suited for github?

  • Yes, this is suited for github

To Reproduce

Frontend

const authClient = createAuthClient({
  plugins: [ssoClient()],
});

Backend

const auth = betterAuth({
  plugins: [sso()],
});

Current vs. Expected behavior

There's an issue with type inference when including the sso plugin in the configuration for backend and frontend.

For example, authClient is resolved as type any.
Image

However, if I remove the plugin from the list, the type gets resolved correctly:
Image

Similar thing happens on the backend, where the api object gets infered as any:

const auth = betterAuth({
  plugins: [sso()],
});

type AuthType = typeof auth;

In this case AuthType is inferred as (note the incorrect api: any type):
Image

and if you remove sso() from the plugins, you get the expected inference of the api object:
Image

If it helps, it seems that this broke in the version 1.4.4, because in 1.4.3 the types are correctly inferred.

What version of Better Auth are you using?

1.4.10

System info

{
  "system": {
    "platform": "darwin",
    "arch": "arm64",
    "version": "Darwin Kernel Version 25.2.0: Tue Nov 18 21:09:40 PST 2025; root:xnu-12377.61.12~1/RELEASE_ARM64_T6000",
    "release": "25.2.0",
    "cpuCount": 10,
    "cpuModel": "Apple M1 Pro",
    "totalMemory": "32.00 GB",
    "freeMemory": "0.20 GB"
  },
  "node": {
    "version": "v20.19.1",
    "env": "development"
  },
  "packageManager": {
    "name": "npm",
    "version": "10.8.2"
  },
  "frameworks": [
    {
      "name": "next",
      "version": "16.0.10"
    },
    {
      "name": "react",
      "version": "19.2.3"
    },
    {
      "name": "vue",
      "version": "^2.6.12"
    }
  ],
  "databases": [
    {
      "name": "pg",
      "version": "^8.16.3"
    },
    {
      "name": "drizzle",
      "version": "^0.44.7"
    }
  ],
  "betterAuth": {
    "version": "1.4.10",
    "config": null
  }
}

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

Types

Auth config (if applicable)

Additional context

No response

Originally created by @anzev on GitHub (Jan 9, 2026). Original GitHub issue: https://github.com/better-auth/better-auth/issues/7219 Originally assigned to: @bytaesu on GitHub. ### Is this suited for github? - [x] Yes, this is suited for github ### To Reproduce Frontend ``` const authClient = createAuthClient({ plugins: [ssoClient()], }); ``` Backend ``` const auth = betterAuth({ plugins: [sso()], }); ``` ### Current vs. Expected behavior There's an issue with type inference when including the sso plugin in the configuration for backend and frontend. For example, `authClient` is resolved as type `any`. <img width="356" height="126" alt="Image" src="https://github.com/user-attachments/assets/c05163de-0ec2-460d-a560-2662bb0da8b6" /> However, if I remove the plugin from the list, the type gets resolved correctly: <img width="903" height="301" alt="Image" src="https://github.com/user-attachments/assets/a61ec97e-d98b-462b-b1f9-cad0e3f195f0" /> Similar thing happens on the backend, where the `api` object gets infered as `any`: ``` const auth = betterAuth({ plugins: [sso()], }); type AuthType = typeof auth; ``` In this case `AuthType` is inferred as (note the incorrect `api: any` type): <img width="583" height="304" alt="Image" src="https://github.com/user-attachments/assets/07fdfc0d-d7f4-4e03-b4b5-2a8fa51f0485" /> and if you remove `sso()` from the plugins, you get the expected inference of the `api` object: <img width="786" height="303" alt="Image" src="https://github.com/user-attachments/assets/df80c2de-89d9-4394-902f-3bef5dc97174" /> If it helps, it seems that this broke in the version **1.4.4**, because in **1.4.3** the types are correctly inferred. ### What version of Better Auth are you using? 1.4.10 ### System info ```bash { "system": { "platform": "darwin", "arch": "arm64", "version": "Darwin Kernel Version 25.2.0: Tue Nov 18 21:09:40 PST 2025; root:xnu-12377.61.12~1/RELEASE_ARM64_T6000", "release": "25.2.0", "cpuCount": 10, "cpuModel": "Apple M1 Pro", "totalMemory": "32.00 GB", "freeMemory": "0.20 GB" }, "node": { "version": "v20.19.1", "env": "development" }, "packageManager": { "name": "npm", "version": "10.8.2" }, "frameworks": [ { "name": "next", "version": "16.0.10" }, { "name": "react", "version": "19.2.3" }, { "name": "vue", "version": "^2.6.12" } ], "databases": [ { "name": "pg", "version": "^8.16.3" }, { "name": "drizzle", "version": "^0.44.7" } ], "betterAuth": { "version": "1.4.10", "config": null } } ``` ### Which area(s) are affected? (Select all that apply) Types ### Auth config (if applicable) ```typescript ``` ### Additional context _No response_
GiteaMirror added the locked label 2026-04-15 18:26:37 -05:00
GiteaMirror commented 2026-04-15 18:26:40 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (Jan 9, 2026):

Hi @anzev! I'm Dosu and I’m helping the better-auth team.

This type inference issue is caused by the SSO plugin's implementation: its return type is declared as any, which causes TypeScript to infer any for the entire plugin and all downstream types in both backend and frontend. This regression started after v1.4.3, when the internal SSO plugin was removed and replaced by the external @better-auth/sso package. The external package's sso function still returns any in its implementation, even though it has rich overloads—so including it in your plugins array collapses type inference to any for your client and API objects (source).

How to fix or work around:

  • The recommended path is to use the external @better-auth/sso package and update your imports:

    • For backend: import sso from @better-auth/sso
    • For frontend: import ssoClient from @better-auth/sso/client
      Make sure you have removed all references to the old internal plugin (migration details).

  • If you still see type inference issues, it's because the sso function's implementation signature needs to be fixed upstream to return the correct type, not any. Until that's released, you can:

    • Use explicit type assertions (e.g., as ReturnType) to silence errors, but this will lose plugin-specific type safety.
    • If you need full type safety, you would need to locally patch the sso function's return type or wait for an upstream fix.

  • This pattern has already been fixed in other plugins (like admin, jwt, two-factor) by using a NoInfer utility type for their options, but not yet in sso (example PR).

Example migration:

// Backend
import { sso } from "@better-auth/sso";
const auth = betterAuth({
  plugins: [sso()],
});

// Frontend
import { ssoClient } from "@better-auth/sso/client";
const authClient = createAuthClient({
  plugins: [ssoClient()],
});

If you need a temporary workaround, you can use:

const authClient = createAuthClient({ plugins: [ssoClient()] }) as ReturnType<typeof createAuthClient>;

…but this will not restore full type safety for SSO plugin methods.

Keep an eye on the @better-auth/sso package for updates that fix the return type of the sso function to restore proper type inference.

To reply, just mention @dosu.

How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other

Chat with Dosu Open in Cursor Join Discord Share on X

<!-- gh-comment-id:3728789321 --> @dosubot[bot] commented on GitHub (Jan 9, 2026): <!-- Greeting --> Hi @anzev! I'm [Dosu](https://go.dosu.dev/dosubot) and I’m helping the better-auth team. <!-- Answer --> This type inference issue is caused by the SSO plugin's implementation: its return type is declared as any, which causes TypeScript to infer any for the entire plugin and all downstream types in both backend and frontend. This regression started after v1.4.3, when the internal SSO plugin was removed and replaced by the external @better-auth/sso package. The external package's sso function still returns any in its implementation, even though it has rich overloads—so including it in your plugins array collapses type inference to any for your client and API objects [(source)](https://github.com/better-auth/better-auth/blob/c31c92f3d24f3ccfb6776d4634e0681c6dee2db5/packages/sso/src/index.ts#L80-L222). **How to fix or work around:** - The recommended path is to use the external @better-auth/sso package and update your imports: - For backend: import sso from `@better-auth/sso` - For frontend: import ssoClient from `@better-auth/sso/client` Make sure you have removed all references to the old internal plugin [(migration details)](https://github.com/better-auth/better-auth/pull/5332). - If you still see type inference issues, it's because the sso function's implementation signature needs to be fixed upstream to return the correct type, not any. Until that's released, you can: - Use explicit type assertions (e.g., as ReturnType<typeof createAuthClient>) to silence errors, but this will lose plugin-specific type safety. - If you need full type safety, you would need to locally patch the sso function's return type or wait for an upstream fix. - This pattern has already been fixed in other plugins (like admin, jwt, two-factor) by using a NoInfer utility type for their options, but not yet in sso [(example PR)](https://github.com/better-auth/better-auth/pull/6689). **Example migration:** ```ts // Backend import { sso } from "@better-auth/sso"; const auth = betterAuth({ plugins: [sso()], }); // Frontend import { ssoClient } from "@better-auth/sso/client"; const authClient = createAuthClient({ plugins: [ssoClient()], }); ``` If you need a temporary workaround, you can use: ```ts const authClient = createAuthClient({ plugins: [ssoClient()] }) as ReturnType<typeof createAuthClient>; ``` …but this will not restore full type safety for SSO plugin methods. Keep an eye on the @better-auth/sso package for updates that fix the return type of the sso function to restore proper type inference. <!-- Dosu Comment Footer --> *To reply, just mention [@dosu](https://go.dosu.dev/dosubot).* --- <sup>How did I do? [Good](https://app.dosu.dev/response-feedback/c0f4a2d8-f873-4400-9980-c40793dbed75?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/c0f4a2d8-f873-4400-9980-c40793dbed75?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/c0f4a2d8-f873-4400-9980-c40793dbed75?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/c0f4a2d8-f873-4400-9980-c40793dbed75?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/c0f4a2d8-f873-4400-9980-c40793dbed75?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/c0f4a2d8-f873-4400-9980-c40793dbed75?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/c0f4a2d8-f873-4400-9980-c40793dbed75?feedback_type=other)</sup> [![Chat with Dosu](https://dosu.dev/dosu-chat-badge.svg)](https://app.dosu.dev/cdda13d9-dd27-4d31-b09a-5d8bec92de21/ask?utm_source=github)&nbsp;[![Open in Cursor](https://dosu.dev/dosu-in-cursor.svg)](https://cursor.com/link/prompt?text=This%20type%20inference%20issue%20is%20caused%20by%20the%20SSO%20plugin%27s%20implementation%3A%20its%20return%20type%20is%20declared%20as%20any%2C%20which%20causes%20TypeScript%20to%20infer%20any%20for%20the%20entire%20plugin%20and%20all%20downstream%20types%20in%20both%20backend%20and%20frontend.%20This%20regression%20started%20after%20v1.4.3%2C%20when%20the%20internal%20SSO%20plugin%20was%20removed%20and%20replaced%20by%20the%20external%20%40better-auth/sso%20package.%20The%20external%20package%27s%20sso%20function%20still%20returns%20any%20in%20its%20implementation%2C%20even%20though%20it%20has%20rich%20overloads%E2%80%94so%20including%20it%20in%20your%20plugins%20array%20collapses%20type%20inference%20to%20any%20for%20your%20client%20and%20API%20objects%20%5B%28source%29%5D%28https%3A//github.com/better-auth/better-auth/blob/c31c92f3d24f3ccfb6776d4634e0681c6dee2db5/packages/sso/src/index.ts%23L80-L222%29.%0A%0A%2A%2AHow%20to%20fix%20or%20work%20around%3A%2A%2A%0A%0A-%20The%20recommended%20path%20is%20to%20use%20the%20external%20%40better-auth/sso%20package%20and%20update%20your%20imports%3A%20%20%0A%20%20-%20For%20backend%3A%20import%20sso%20from%20%60%40better-auth/sso%60%0A%20%20-%20For%20frontend%3A%20import%20ssoClient%20from%20%60%40better-auth/sso/client%60%20%20%0A%20%20Make%20sure%20you%20have%20removed%20all%20references%20to%20the%20old%20internal%20plugin%20%5B%28migration%20details%29%5D%28https%3A//github.com/better-auth/better-auth/pull/5332%29.%0A%0A-%20If%20you%20still%20see%20type%20inference%20issues%2C%20it%27s%20because%20the%20sso%20function%27s%20implementation%20signature%20needs%20to%20be%20fixed%20upstream%20to%20return%20the%20correct%20type%2C%20not%20any.%20Until%20that%27s%20released%2C%20you%20can%3A%0A%20%20-%20Use%20explicit%20type%20assertions%20%28e.g.%2C%20as%20ReturnType%3Ctypeof%20createAuthClient%3E%29%20to%20silence%20errors%2C%20but%20this%20will%20lose%20plugin-specific%20type%20safety.%0A%20%20-%20If%20you%20need%20full%20type%20safety%2C%20you%20would%20need%20to%20locally%20patch%20the%20sso%20function%27s%20return%20type%20or%20wait%20for%20an%20upstream%20fix.%0A%0A-%20This%20pattern%20has%20already%20been%20fixed%20in%20other%20plugins%20%28like%20admin%2C%20jwt%2C%20two-factor%29%20by%20using%20a%20NoInfer%20utility%20type%20for%20their%20options%2C%20but%20not%20yet%20in%20sso%20%5B%28example%20PR%29%5D%28https%3A//github.com/better-auth/better-auth/pull/6689%29.%0A%0A%2A%2AExample%20migration%3A%2A%2A%0A%60%60%60ts%0A//%20Backend%0Aimport%20%7B%20sso%20%7D%20from%20%22%40better-auth/sso%22%3B%0Aconst%20auth%20%3D%20betterAuth%28%7B%0A%20%20plugins%3A%20%5Bsso%28%29%5D%2C%0A%7D%29%3B%0A%0A//%20Frontend%0Aimport%20%7B%20ssoClient%20%7D%20from%20%22%40better-auth/sso/client%22%3B%0Aconst%20authClient%20%3D%20createAuthClient%28%7B%0A%20%20plugins%3A%20%5BssoClient%28%29%5D%2C%0A%7D%29%3B%0A%60%60%60%0A%0AIf%20you%20need%20a%20temporary%20workaround%2C%20you%20can%20use%3A%0A%60%60%60ts%0Aconst%20authClient%20%3D%20createAuthClient%28%7B%20plugins%3A%20%5BssoClient%28%29%5D%20%7D%29%20as%20ReturnType%3Ctypeof%20createAuthClient%3E%3B%0A%60%60%60%0A%E2%80%A6but%20this%20will%20not%20restore%20full%20type%20safety%20for%20SSO%20plugin%20methods.%0A%0AKeep%20an%20eye%20on%20the%20%40better-auth/sso%20package%20for%20updates%20that%20fix%20the%20return%20type%20of%20the%20sso%20function%20to%20restore%20proper%20type%20inference.)&nbsp;[![Join Discord](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&label=)](https://go.dosu.dev/discord-bot)&nbsp;[![Share on X](https://img.shields.io/badge/X-share-black)](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/better-auth/better-auth/issues/7219)
GiteaMirror commented 2026-04-15 18:26:41 -05:00
Author
Owner
Copy Link
Copy Source

@bytaesu commented on GitHub (Jan 9, 2026):

Hi @anzev, I'll check this

<!-- gh-comment-id:3728945195 --> @bytaesu commented on GitHub (Jan 9, 2026): Hi @anzev, I'll check this
GiteaMirror commented 2026-04-15 18:26:42 -05:00
Author
Owner
Copy Link
Copy Source

@bytaesu commented on GitHub (Jan 9, 2026):

Hi @anzev,

I tested with v1.4.10 and couldn't reproduce the issue. It might be a temporary problem that can be fixed by restarting the TypeScript server or reinstalling node_modules... or similar steps

If it still happens, feel free to share a reproducible repo with me so I can take a look 👀

Image
<!-- gh-comment-id:3729411626 --> @bytaesu commented on GitHub (Jan 9, 2026): Hi @anzev, I tested with `v1.4.10` and couldn't reproduce the issue. It might be a temporary problem that can be fixed by restarting the TypeScript server or reinstalling node_modules... or similar steps If it still happens, feel free to share a reproducible repo with me so I can take a look 👀 --- <img width="981" height="633" alt="Image" src="https://github.com/user-attachments/assets/55ab7eac-87bc-4636-91f6-da1121eef536" />
GiteaMirror commented 2026-04-15 18:26:43 -05:00
Author
Owner
Copy Link
Copy Source

@himself65 commented on GitHub (Jan 10, 2026):

This could be a tsconfig setup issue or a node_module-related issue.

I would doubt you have a dual version of the better-auth package in the node_modules at first glance.

Closing this until we have reproducible repo

<!-- gh-comment-id:3732947396 --> @himself65 commented on GitHub (Jan 10, 2026): This could be a tsconfig setup issue or a node_module-related issue. I would doubt you have a dual version of the better-auth package in the node_modules at first glance. Closing this until we have reproducible repo
GiteaMirror commented 2026-04-15 18:26:44 -05:00
Author
Owner
Copy Link
Copy Source

@anzev commented on GitHub (Jan 12, 2026):

Thanks for looking into this.

I've already tried the typical node_modules removal, ts server restart etc. Now trying to see if it is somehow monorepo-related (our project is part of an NX monorepo)... Will get back to you if I discover anything.

<!-- gh-comment-id:3737745281 --> @anzev commented on GitHub (Jan 12, 2026): Thanks for looking into this. I've already tried the typical node_modules removal, ts server restart etc. Now trying to see if it is somehow monorepo-related (our project is part of an NX monorepo)... Will get back to you if I discover anything.
GiteaMirror commented 2026-04-15 18:26:45 -05:00
Author
Owner
Copy Link
Copy Source

@lexer21 commented on GitHub (Jan 15, 2026):

@himself65 im also experiancing this type inference issue. Im playing around with this example repo to test out tanstack start + better auth: https://github.com/MrHertal/router/tree/examples/start-basic-better-auth . In the example app examples/react/start-basic-better-auth if i use the ssoClient plugin i get any as the infered type:

Image

My better auth version and sso version is v1.4.13

<!-- gh-comment-id:3755979990 --> @lexer21 commented on GitHub (Jan 15, 2026): @himself65 im also experiancing this type inference issue. Im playing around with this example repo to test out tanstack start + better auth: https://github.com/MrHertal/router/tree/examples/start-basic-better-auth . In the example app `examples/react/start-basic-better-auth` if i use the `ssoClient` plugin i get any as the infered type: <img width="2130" height="608" alt="Image" src="https://github.com/user-attachments/assets/ec16c809-8a17-45fc-9ab0-a529769280b9" /> My better auth version and sso version is v1.4.13
GiteaMirror commented 2026-04-15 18:26:46 -05:00
Author
Owner
Copy Link
Copy Source

@anzev commented on GitHub (Jan 20, 2026):

@bytaesu hmm looks like this wasn't a fluke on our end. can you check out @lexer21's example repo?

<!-- gh-comment-id:3771568253 --> @anzev commented on GitHub (Jan 20, 2026): @bytaesu hmm looks like this wasn't a fluke on our end. can you check out @lexer21's example repo?
GiteaMirror commented 2026-04-15 18:26:48 -05:00
Author
Owner
Copy Link
Copy Source

@bojanbass commented on GitHub (Jan 26, 2026):

Any update on this issue?

<!-- gh-comment-id:3799504972 --> @bojanbass commented on GitHub (Jan 26, 2026): Any update on this issue?
GiteaMirror commented 2026-04-15 18:26:50 -05:00
Author
Owner
Copy Link
Copy Source

@bytaesu commented on GitHub (Jan 28, 2026):

I can't reproduce this. Also, the example above isn’t a reproducible example repo, so I can't verify it..

Image
<!-- gh-comment-id:3808330032 --> @bytaesu commented on GitHub (Jan 28, 2026): I can't reproduce this. Also, [the example above](https://github.com/MrHertal/router/tree/examples/start-basic-better-auth) isn’t a reproducible example repo, so I can't verify it.. <img width="647" height="458" alt="Image" src="https://github.com/user-attachments/assets/f5c15245-3157-4c2e-b24e-0cdad1ce686d" />
GiteaMirror commented 2026-04-15 18:26:50 -05:00
Author
Owner
Copy Link
Copy Source

@lexer21 commented on GitHub (Jan 28, 2026):

Hello @bytaesu could you please try this repo i prepared: https://github.com/lexer21/better-auth-sso? Just npm install and go to src/utils/auth-client.ts and you will see that authClient has type any, if you comment the sso plugin you will get the correct type.

Image

<!-- gh-comment-id:3810473256 --> @lexer21 commented on GitHub (Jan 28, 2026): Hello @bytaesu could you please try this repo i prepared: https://github.com/lexer21/better-auth-sso? Just npm install and go to `src/utils/auth-client.ts` and you will see that `authClient` has type `any`, if you comment the sso plugin you will get the correct type. ![Image](https://github.com/user-attachments/assets/a13c8ec9-841b-48c5-a801-fad26942797f)
GiteaMirror commented 2026-04-15 18:26:51 -05:00
Author
Owner
Copy Link
Copy Source

@bytaesu commented on GitHub (Jan 28, 2026):

I noticed something, will fix this.

Using bun or pnpm creates symlinks, but the issue shows up when using npm.

<!-- gh-comment-id:3811358138 --> @bytaesu commented on GitHub (Jan 28, 2026): I noticed something, will fix this. Using bun or pnpm creates symlinks, but the issue shows up when using npm.
GiteaMirror commented 2026-04-15 18:26:51 -05:00
Author
Owner
Copy Link
Copy Source

@NathanVeeva commented on GitHub (Mar 18, 2026):

@bytaesu I am still experiencing this issue as @lexer21 had with v1.5.5. All other plugins seem to work fine. I have to cast the sso plugin to BetterAuthPlugin to have the api typed properly. Unfortunately I lose any SSO typing.

Image

<!-- gh-comment-id:4082083635 --> @NathanVeeva commented on GitHub (Mar 18, 2026): @bytaesu I am still experiencing this issue as @lexer21 had with v1.5.5. All other plugins seem to work fine. I have to cast the `sso` plugin to `BetterAuthPlugin` to have the api typed properly. Unfortunately I lose any SSO typing. ![Image](https://github.com/user-attachments/assets/2206d1d0-3611-4a41-bd6b-0bdbeafd3572)
GiteaMirror commented 2026-04-15 18:26:52 -05:00
Author
Owner
Copy Link
Copy Source

@github-actions[bot] commented on GitHub (Mar 31, 2026):

This issue has been locked as it was closed more than 7 days ago. If you're experiencing a similar problem or you have additional context, please open a new issue and reference this one.

<!-- gh-comment-id:4165914824 --> @github-actions[bot] commented on GitHub (Mar 31, 2026): This issue has been locked as it was closed more than 7 days ago. If you're experiencing a similar problem or you have additional context, please open a new issue and reference this one.
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 labels locked
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
GiteaMirror ninjasurge (Kaehlen Rog)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/better-auth#19393