please prioritize this instead of anything your prioritizng right now, i thought this was the whole point of this library, to be “Plug & play shadcn/ui auth components for better-auth.” and “Fully customizable!“ as the github readme says but instead i need a whole provider and pass some options that are supported (even if every option was supported). It would be way better if this was actually plug & play/ copy & paste like shadcn components, instead what im doing is looking through the github source code and copying some of the code i like and adopting it into my own codebase.
daveycodez
Team•
May 20, 2025
I can understand your desire for this feature, and it’s fair to want to use it that way. There is a ton of logic that is shared between components using the Provider and I built this package to be as simple to install and use as possible, which is why it is released as an npm package. It gives everything you need for the full Better Auth experience with as little manual labor as possible, and is very easy to update to get the latest features.
It is also already fully customizable. Localization strings and classNames props can be passed to every element to customize all text and design across the board.
That being said, I do plan on this feature, however Organization and Stripe / Polar are both much higher priority for my own projects and have more upvotes & interest as well.
daveycodez
Team•
May 20, 2025
This will also require me to re-plan out the entire structure of the package, so this isn’t exactly easy to tackle. The package will likely use the shadcn registry components as sub-modules, but this also means that the shadcn versions will not be as full featured, and mainly UI only.
keyoc
•
May 27, 2025
yeah i can understand that, goodluck with all that stuff, also if my first message seemed off i was just copy pasting the text chunks to try and explain what i want a bit more.
daveycodez
Team•
May 28, 2025
No worries. The other reason I took this route is because I created this project before shadcn/ui registry even existed. It’s still technically Experimental -
But yea I’ve been brainstorming and planning it out. It will be cool because this will also open up doors for using any UI framework, not just shadcn
Jordan Schoen
•
Dec 16, 2025
I just read the Github 3.3.0 release and I don’t understand why you’d want to deliver this via shadcn registry and not npm. The lack of semantic versioning is going to be a huge pain when you need to update the library. These components aren’t simple UI primitives, they’re extremely complex pieces of the authentication and organization management flows.
After the switch to shadcn registry, the only way to update components will be to overwrite the components in the components/ui folder? What if someone has customized one of the components? Every time you update you’ll have to unravel a git diff to understand what changed and re-apply any changes you made to the components.
How are you going to communicate breaking changes to the components in the registry? Even if I haven’t customized the components, there will be no way for me to know if a breaking change has occurred OR that a change has occurred at all. The only way to determine if a component in the shadcn registry has been updated is by trying to overwrite it and see if something changed.
I may be naive to the workflows for shadcn and if that’s the case I’d love to understand how I can solve the problems above once you convert everything to shadcn registry because this change has me extremely worried.
daveycodez
Team•
Dec 16, 2025
Both shadcn registry and npm package will be supported, you choose your method. I am using nx releases with a custom script for shadcn registry deployment, so every npm release will include notes in GitHub and update the shadcn registry as well. For most people, using npm/pnpm/bun to update will make the most sense, for everyone else, they can update by re-installing components via registry when new updates go live
If anyone else finds themselves here via the same path as me, the “This will be the last major update to this package.” part of the 3.3.0 update is referring to the package @daveyplate/better-auth-ui which is now going to become @better-auth-ui/shadcn and remains installable via npm registry
daveycodez
Team•
Apr 16
Plans changed quite a bit since shadcn released the new theming system, so now in order to support all shadcn themes it is simple shadcn install. I might bring back an npm install option for shadcn that uses a default theme, but for now HeroUI is the way to go if you prefer nom install
Log in to comment and vote
Comments12
keyoc
May 18, 2025
please prioritize this instead of anything your prioritizng right now, i thought this was the whole point of this library, to be “Plug & play shadcn/ui auth components for better-auth.” and “Fully customizable!“ as the github readme says but instead i need a whole provider and pass some options that are supported (even if every option was supported). It would be way better if this was actually plug & play/ copy & paste like shadcn components, instead what im doing is looking through the github source code and copying some of the code i like and adopting it into my own codebase.
daveycodez
May 20, 2025
I can understand your desire for this feature, and it’s fair to want to use it that way. There is a ton of logic that is shared between components using the Provider and I built this package to be as simple to install and use as possible, which is why it is released as an npm package. It gives everything you need for the full Better Auth experience with as little manual labor as possible, and is very easy to update to get the latest features.
It is also already fully customizable. Localization strings and classNames props can be passed to every element to customize all text and design across the board.
That being said, I do plan on this feature, however Organization and Stripe / Polar are both much higher priority for my own projects and have more upvotes & interest as well.
daveycodez
May 20, 2025
This will also require me to re-plan out the entire structure of the package, so this isn’t exactly easy to tackle. The package will likely use the shadcn registry components as sub-modules, but this also means that the shadcn versions will not be as full featured, and mainly UI only.
keyoc
May 27, 2025
yeah i can understand that, goodluck with all that stuff, also if my first message seemed off i was just copy pasting the text chunks to try and explain what i want a bit more.
daveycodez
May 28, 2025
No worries. The other reason I took this route is because I created this project before shadcn/ui registry even existed. It’s still technically Experimental -
https://ui.shadcn.com/docs/registry
But yea I’ve been brainstorming and planning it out. It will be cool because this will also open up doors for using any UI framework, not just shadcn
Jordan Schoen
Dec 16, 2025
I just read the Github 3.3.0 release and I don’t understand why you’d want to deliver this via shadcn registry and not npm. The lack of semantic versioning is going to be a huge pain when you need to update the library. These components aren’t simple UI primitives, they’re extremely complex pieces of the authentication and organization management flows.
After the switch to shadcn registry, the only way to update components will be to overwrite the components in the components/ui folder? What if someone has customized one of the components? Every time you update you’ll have to unravel a git diff to understand what changed and re-apply any changes you made to the components.
How are you going to communicate breaking changes to the components in the registry? Even if I haven’t customized the components, there will be no way for me to know if a breaking change has occurred OR that a change has occurred at all. The only way to determine if a component in the shadcn registry has been updated is by trying to overwrite it and see if something changed.
I may be naive to the workflows for shadcn and if that’s the case I’d love to understand how I can solve the problems above once you convert everything to shadcn registry because this change has me extremely worried.
daveycodez
Dec 16, 2025
Both shadcn registry and npm package will be supported, you choose your method. I am using nx releases with a custom script for shadcn registry deployment, so every npm release will include notes in GitHub and update the shadcn registry as well. For most people, using npm/pnpm/bun to update will make the most sense, for everyone else, they can update by re-installing components via registry when new updates go live
daveycodez
Dec 16, 2025
You can preview the new setup guide here:
https://better-auth-ui.pages.dev/docs/shadcn#install-the-components
Jordan Schoen
Dec 17, 2025
If anyone else finds themselves here via the same path as me, the “This will be the last major update to this package.” part of the 3.3.0 update is referring to the package
@daveyplate/better-auth-uiwhich is now going to become@better-auth-ui/shadcnand remains installable via npm registrydaveycodez
Apr 16
Plans changed quite a bit since shadcn released the new theming system, so now in order to support all shadcn themes it is simple shadcn install. I might bring back an npm install option for shadcn that uses a default theme, but for now HeroUI is the way to go if you prefer nom install