The inferred type of 'authClient' cannot be named without a reference...
I was trying to create a shared auth client package in my monorepo, since I have multiple frontends authenticating with the same server..
But I keep getting an error like this (twice) even before adding any plugins...
Literally.. this is my entire code:
I can't disable declaration in my tsconfig, since it's a shared package in my monorepo, and I need the type safety.
I can't add an explicit return type like ReturnType<typeof createAuthClient> since that ruins type safety for any plugins I might add..
Is this a bug in better-auth? Or did I get something wrong with the configuration
23 Replies
I'm getting this error twice:
The inferred type of 'authClient' cannot be named without a reference to '../node_modules/better-auth/dist/shared/better-auth.ClXlabtY.js'. This is likely not portable. A type annotation is necessary.ts(2742)
The inferred type of 'authClient' cannot be named without a reference to '../node_modules/better-auth/dist/shared/better-auth.ZSfSbnQT.js'. This is likely not portable. A type annotation is necessary.ts(2742)
There seems to be a few issues open about this from March, but they're marked as solved, which is really confusing..
I really want to work with better-auth on this project. But this is like the third typescript-related issue I ran into and it's really giving me a headache. Maybe I'm just doing something wrong.
I had similar issues, worked around this by doing things like this:
You just have to break the config down into smaller parts, only the keys would not be type safe but I found that to be fine
And for the plugins, I did
Spread your configs into your betterAuth function in each app that uses it, and you should have decent enough type safety there
This just seems like terrible developer experience 🥲
I'm not sure if I fully understand yet.. but I did something like:
for example, and the error still appears, just now for defaultConfig instead of authClient
Yeah it's not great when it comes to this. If you spread the entire objects you'll get these issues unfortunately. Instead of 
satisfies Parameters<typeof createAuthClient>[0] you should use as const and type each key if you need to instead e.g.
Something like that...unfortunately that means you lose auto suggestion for config keys but I found that to be manageable. Each key can be copied from the indexed access type i.e. AuthClient["copy-this-here"]I did this, and I still don't get type safety for authClient.admin for example.. Is that what you meant?
Cause then I could just set the return type explicitly to ReturnType<typeof createAuthClient>
Sorry, typing plugins explicitly like that would mean you lose type safety there. Here's an e.g. of my plugins array which is passed to my betterAuth instance.
Above is what you would need to do in each app that uses plugins. I export the default configs from the auth package in my monorepo.
E.g.
man. at this point I might as well just create the client in each app separately and just disable declaration in my tsconfig, since they don't export anything anyway.
@bekacru any chance this will be addressed in a future update? it really sucks to have to either lose my one source of truth, or have to know how to do awesome typescript backflips like @DN_Dev
Yeah that's basically what I had to do, and export as much code as I could to each auth instance in the apps
will be addressed
was there ever any update on this?
yeah we addressed some of the issues. if you're still haivng issues, please share with me your auth client config
i only had an issue with jwt and passkey plugin
i was able to fix it by explicitly typing those to just be a BetterAuthPlugin
this would break the ts inference. can you share with me your auth client config when you can
@bekacru
jwt breaks due to jose, passkey due to some webauthn library
this setup right now works for me because the clients infer from their plugins and not from the server
but would be nice to have it fixed in the future
also i did move this to a seperate package and have it compiled, cause i was getting errors like 'stripeCustomerId' doesnt exist on user due to the type inference depth/complexity.
compiling/composite helped quite a bit
I see. Will look into it. For the time being I recommend casting 
as ReturnType<typeof jwt> instead
were you generating decalation files? if dts is set to false that shouldn't happenyeah i am
just to speed up editor type inference
this gaves the same issue interms of declaration generation
"This is likely not portable. A type annotation is necessary.ts(2742)"
what's in your tsconfig? May I see it?
this is my old tsconfig from when i was having the error
auth.ts was inside the web package
and so this is apps/web/tsconfig.json
and now after i moved better-auth and some other items to a 
trpc package:
and now auth gets "compiled" like this to js+dts+dts.map

i still had the error, likely now due to compiling; but as said above I had to type 2 plugins as generic plugins then it went away (jwt,passkey)
It could be that 
composite, declaration, & declarationMap are being carried over? Since these usually cause type issues with BAactually wait; i think this whole thing started cause i wanted to move to a different package in the first place
so yes, this might be related to composite/declaration/declarationMap in my case
but even with this slight disadvantage, doing this sorta fixed some other issues for me
like the TS server being slow, or not being able to infer at depth which would lead to stuff like 'stripeCustomerId does not exist on type User'
https://ptb.discord.com/channels/1288403910284935179/1407166259652595732/1407166259652595732