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

Split @better-auth/expo into server and client packages to avoid forcing React Native into Node backends #2761

New Issue
Closed
opened 2026-03-13 10:18:44 -05:00 by GiteaMirror · 2 comments
GiteaMirror commented 2026-03-13 10:18:44 -05:00
Owner
Copy Link

Originally created by @meabhisingh on GitHub (Jan 25, 2026).

Is this suited for github?

  • Yes, this is suited for github

Is your feature request related to a problem? Please describe.

Currently @better-auth/expo bundles both server-side helpers and Expo/React-Native client logic into a single package. Because of this, installing @better-auth/expo on a Node.js backend (as recommended in the docs for Expo integrations) forces mobile-only dependencies like:

  • expo
  • react-native
  • @types/react@19

into the backend project via transitive peer dependencies (expo-network → expo → react-native).

This creates unnecessary platform coupling where a pure Node.js server ends up depending on React Native and Expo, even though it only needs server-side helpers (OAuth redirects, token exchange, etc).

This also leads to practical issues like:

  • React Native polluting backend dependency trees
  • React 19 type requirements on non-React backends
  • Confusing peer dependency resolution for monorepos

Describe the solution you'd like

Split the Expo integration into separate server and client packages, for example:

@better-auth/expo-server   // Node.js only helpers
@better-auth/expo-client   // Expo / React Native integration

So that:

  • Backends can use Expo-related server helpers without pulling mobile runtime dependencies.
  • Expo apps can use the full client integration.
  • Dependency graphs stay clean and platform-correct.

Describe alternatives you've considered

The only current workaround is:

  • Accepting that React Native and Expo are installed in the backend project, even though they are never used.

This works functionally, but is not ideal because it:

  • Pollutes the backend dependency tree
  • Introduces unnecessary peer dependency conflicts
  • Makes installations heavier and more confusing

Another workaround is to bypass peer dependencies using --legacy-peer-deps, but that hides real structural issues and is not a clean solution.

Additional context

No response

Originally created by @meabhisingh on GitHub (Jan 25, 2026). ### Is this suited for github? - [x] Yes, this is suited for github ### Is your feature request related to a problem? Please describe. Currently `@better-auth/expo` bundles both server-side helpers and Expo/React-Native client logic into a single package. Because of this, installing `@better-auth/expo` on a Node.js backend (as recommended in the docs for Expo integrations) forces mobile-only dependencies like: - expo - react-native - @types/react@19 into the backend project via transitive peer dependencies (`expo-network → expo → react-native`). This creates unnecessary platform coupling where a pure Node.js server ends up depending on React Native and Expo, even though it only needs server-side helpers (OAuth redirects, token exchange, etc). This also leads to practical issues like: - React Native polluting backend dependency trees - React 19 type requirements on non-React backends - Confusing peer dependency resolution for monorepos ### Describe the solution you'd like Split the Expo integration into separate server and client packages, for example: ``` @better-auth/expo-server // Node.js only helpers @better-auth/expo-client // Expo / React Native integration ``` So that: - Backends can use Expo-related server helpers without pulling mobile runtime dependencies. - Expo apps can use the full client integration. - Dependency graphs stay clean and platform-correct. ### Describe alternatives you've considered The only current workaround is: - Accepting that React Native and Expo are installed in the backend project, even though they are never used. This works functionally, but is not ideal because it: - Pollutes the backend dependency tree - Introduces unnecessary peer dependency conflicts - Makes installations heavier and more confusing Another workaround is to bypass peer dependencies using `--legacy-peer-deps`, but that hides real structural issues and is not a clean solution. ### Additional context _No response_
GiteaMirror added the expo label 2026-03-13 10:18:44 -05:00
GiteaMirror commented 2026-03-13 10:18:47 -05:00
Author
Owner
Copy Link

@better-auth-agent[bot] commented on GitHub (Jan 25, 2026):

Thank you for your detailed feature request regarding splitting the @better-auth/expo package into separate server and client packages. This idea aims to reduce unnecessary dependencies on mobile frameworks for backend projects, which makes perfect sense, especially for cleaner dependency management.

While there isn't a finalized solution yet, there are ongoing discussions and some movement towards improving how Better Auth integrates with Expo, including potentially decoupling dependencies. This can clarify usage scenarios without coupling mobile packages unnecessarily to server-side applications.

If you have thoughts on how you see this splitting improving your workflow or specific use cases you have in mind, feel free to share! Also, please remember to tag @better-auth-agent if you would like an answer from the Agent.

If you need more help, tag @better-auth-agent in a comment so I can respond.

Diagram • Discord • GitHub

Diagram Join Star

@better-auth-agent[bot] commented on GitHub (Jan 25, 2026): Thank you for your detailed feature request regarding splitting the `@better-auth/expo` package into separate server and client packages. This idea aims to reduce unnecessary dependencies on mobile frameworks for backend projects, which makes perfect sense, especially for cleaner dependency management. While there isn't a finalized solution yet, there are ongoing discussions and some movement towards improving how Better Auth integrates with Expo, including potentially decoupling dependencies. This can clarify usage scenarios without coupling mobile packages unnecessarily to server-side applications. If you have thoughts on how you see this splitting improving your workflow or specific use cases you have in mind, feel free to share! Also, please remember to tag @better-auth-agent if you would like an answer from the Agent. _If you need more help, tag @better-auth-agent in a comment so I can respond._ <!-- bot:webhook reply v1 --> [Diagram](https://repodiagrams.s3.eu-north-1.amazonaws.com/better-auth_ultra_detailed_interactive.html) • [Discord](https://discord.gg/better-auth) • [GitHub](https://github.com/better-auth/better-auth) [![Diagram](https://img.shields.io/badge/Diagram-2b3137?style=flat-square)](https://repodiagrams.s3.eu-north-1.amazonaws.com/better-auth_ultra_detailed_interactive.html) [![Join](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&style=flat-square)](https://discord.gg/better-auth) [![Star](https://img.shields.io/badge/star-181717?logo=github&logoColor=white&style=flat-square)](https://github.com/better-auth/better-auth)
GiteaMirror commented 2026-03-13 10:18:48 -05:00
Author
Owner
Copy Link

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

Hi @meabhisingh,

I think we don’t need to separate it into its own package for now. I'll just revert the part I removed by mistake last time 🙂

@bytaesu commented on GitHub (Jan 28, 2026): Hi @meabhisingh, I think we don’t need to separate it into its own package for now. I'll just revert the part I removed by mistake last time 🙂
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 expo
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#2761
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?