@softobotics/storefront-auth
v0.1.1
Published
Headless authentication: session/token state, sign-in/register/verify/password-reset actions, for storefronts built on @softobotics/storefront-vendure-client.
Keywords
Readme
@softobotics/storefront-auth
Headless authentication: session/token state and sign-in/register/verify/password-reset
mutations, built on @softobotics/storefront-vendure-client.
Why this exists
Extracted from vendure-storefront/src/features/authentication, the first of four
interdependent packages (auth, account, cart, checkout) sharing a peer-dependency
cycle inherited from the app they came from — see each package's own notes on which side of
a given cycle it owns.
Usage
import {AuthProvider, useAuth} from '@softobotics/storefront-auth';
export default function RootLayout({children}: {children: React.ReactNode}) {
return <AuthProvider>{children}</AuthProvider>;
}import {loginAction} from '@softobotics/storefront-auth';
const result = await loginAction(username, password, tErrors);
if (result.success) await login(result.token);Every action (loginAction, registerAction, requestPasswordResetAction,
resetPasswordAction, verifyAccountAction) takes a translated message lookup (t) as a
parameter rather than importing a translation library — a plain async function can't call a
translation hook itself, and this keeps the package i18n-library-agnostic.
Scope: headless only
This package (and account/cart/checkout) ships logic only — no UI components. The
route-level forms in vendure-storefront (login-form.tsx etc.) import their app's own
shadcn primitives and i18n routing via path aliases that only exist in that app's own
tsconfig.json, so they can't be compiled into a portable package without also extracting
that whole UI kit — not something this package attempts.
ActiveCustomerFragment / GetActiveCustomerQuery
Owned here, not in @softobotics/storefront-account, even though they're customer data:
AuthProvider is the thing that actually calls this query, to know who is signed in.
storefront-account re-exports both for convenience. This keeps the auth↔account dependency
one-directional (account depends on auth, not the reverse) despite the real circular import
that exists between features/authentication and features/account in the source app.
