fusion-auth

Core email/password authentication for the Fusion stack — a thin Better Auth wrapper over the fusion-db schema, plus API-token auth and session helpers. Source-published (Model A): consumers bundle the TypeScript directly.

The one rule: core depends only on fusion-db

The features auth used to hard-import — a distributed rate-limit store, password-reset email, LDAP/OIDC sign-in — are injected by the consuming app instead, so they stay out of the core dependency graph. Your app owns the auth singleton and passes those capabilities in; core auth never imports a cache, a mailer, or an enterprise SSO plugin.

Solid arrows are real dependencies; dotted arrows are capabilities the app injects through createAuth options. Omit them and you still get a working email/password setup — reset links are generated but not delivered, rate-limit counters live in per-process memory, and there is no SSO.

Three entry points

The server and session entries resolve to throwing stubs in browser bundles, so the Node-only code (DB, crypto, Better Auth's server runtime) never ships to the client. See Client.

Install

Published to GitHub Packages under the @tikab-interactive scope, so an .npmrc with a read:packages token is required:

@tikab-interactive:registry=https://npm.pkg.github.com
//npm.pkg.github.com/:_authToken=${NPM_TOKEN}

bun add @tikab-interactive/fusion-auth @tikab-interactive/fusion-db \
  better-auth drizzle-orm react react-dom @tanstack/react-start

better-auth, drizzle-orm, react, react-dom and @tanstack/react-start are peer dependencies — the app owns their versions.

Next steps

• Server: createAuth — build the auth singleton and inject optional capabilities.
• Sessions — getSession / requireSession, and the single choke point where cookies and tokens converge.
• API tokens — sk_live_… personal access tokens for scripts, CI, and integrations.
• Client — the browser authClient and the server-only stubs.