@lunora/auth 1.0.0-alpha.2 → 1.0.0-alpha.20

package/dist/store.d.ts

@@ -43,6 +43,24 @@ interface AuthStore {
   count: (model: string, where: ReadonlyArray<AuthWhereClause>) => Promise<number>;
   /** Insert `data` into `model`; return the stored row (the adapter pre-fills `id`). */
   create: (model: string, data: AuthRow) => Promise<AuthRow>;
+  /**
+  * Atomically apply signed numeric deltas to **at most one** row in `model`
+  * matching `where`, then return the updated row (or `undefined` if the guard
+  * matched none). For each `increment` entry it applies `field = field + delta`
+  * (a negative delta decrements); the optional `set` map assigns absolute
+  * values in the same step. The `where` clause is both selector **and** guard
+  * — comparison operators are honoured, so a guard like
+  * `{ field: "count", operator: "lt", value: max }` only mutates the row while
+  * it still satisfies the predicate.
+  *
+  * Backs better-auth's durable (`storage: "database"`) rate limiter, whose
+  * counter rides these tables. Implementing it natively — one statement that
+  * guards, increments, and returns — gives the **one-winner-across-isolates**
+  * guarantee the read-then-update fallback cannot: on Workers two concurrent
+  * requests would otherwise both read `count=4` and both write `5`, letting a
+  * `max` of 5 pass 6+. Same race-closing rationale as {@link AuthStore.consumeOne}.
+  */
+  incrementOne: (model: string, where: ReadonlyArray<AuthWhereClause>, increment: Record<string, number>, set?: AuthRow) => Promise<AuthRow | undefined>;
   /** Read rows from `model` honouring the filter/sort/window in `query`. */
   read: (model: string, query: AuthQuery) => Promise<AuthRow[]>;
   /** Delete rows in `model` matching `where`; return how many were removed. */

package/dist/store.mjs

@@ -128,6 +128,19 @@ const createMemoryAuthStore = () => {
       tableOf(model).push(row);
       return Promise.resolve({ ...row });
     },
+    incrementOne: (model, where, increment, set) => {
+      const row = tableOf(model).find((candidate) => matchesWhere(candidate, where));
+      if (!row) {
+        return Promise.resolve(void 0);
+      }
+      for (const [field, delta] of Object.entries(increment)) {
+        row[field] = (typeof row[field] === "number" ? row[field] : 0) + delta;
+      }
+      if (set) {
+        Object.assign(row, set);
+      }
+      return Promise.resolve({ ...row });
+    },
     read: (model, query) => {
       let rows = tableOf(model).filter((row) => matchesWhere(row, query.where));
       if (query.sortBy) {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@lunora/auth",
-  "version": "1.0.0-alpha.2",
+  "version": "1.0.0-alpha.20",
   "description": "Auth for Lunora — a thin better-auth wrapper: email/password, OAuth, plugins, D1-backed",
   "keywords": [
     "auth",
@@ -25,7 +25,7 @@
     "directory": "packages/auth"
   },
   "files": [
-    "dist",
+    "./dist",
     "__assets__",
     "README.md",
     "LICENSE.md"
@@ -82,10 +82,11 @@
     "access": "public"
   },
   "dependencies": {
-    "@better-auth/passkey": "^1.6.19",
-    "@lunora/server": "1.0.0-alpha.1",
-    "@lunora/values": "1.0.0-alpha.1",
-    "better-auth": "^1.6.19"
+    "@better-auth/passkey": "^1.6.23",
+    "@lunora/errors": "1.0.0-alpha.1",
+    "@lunora/server": "1.0.0-alpha.16",
+    "@lunora/values": "1.0.0-alpha.4",
+    "better-auth": "^1.6.23"
   },
   "engines": {
     "node": "^22.15.0 || >=24.11.0"

package/dist/packem_shared/create-auth.d-M36jwG_Y.d.mts

@@ -1,58 +0,0 @@
-import { betterAuth, BetterAuthOptions } from 'better-auth';
-/**
-* Lunora's options pass straight through to better-auth — the only thing we add
-* is requiring `secret` up front so a misconfigured deployment fails loudly
-* instead of at the first sign-in.
-*
-* For `database`, prefer `lunoraD1Adapter` (`database: lunoraD1Adapter(env.DB)`)
-* over passing the raw `env.DB`. better-auth *does* accept a D1Database directly,
-* but it then resolves its Kysely adapter via a runtime `await import(...)` inside
-* `auth.$context` — and that import never settles under `@cloudflare/vite-plugin`'s
-* worker runner, hanging every auth request in `pnpm dev`. The explicit adapter
-* skips it, so dev and prod behave the same. (Raw `env.DB` is still correct for
-* the migration-only instance — see `lunoraD1Adapter`'s note.)
-*
-* Session rotation / richer session policies are configured via the `session`
-* field (a `SessionPolicy`); Lunora validates it for obviously-broken
-* durations and forwards it verbatim to better-auth. See `sessionPresets`
-* for ready-made rotation/expiry trade-offs.
-*
-* ## Serverless background tasks (Cloudflare Workers)
-*
-* better-auth runs some work *after* sending the response — most importantly the
-* password-reset email, whose background send is what keeps reset responses
-* constant-time (a timing-attack defence: the response doesn't reveal whether
-* the account exists). On Cloudflare Workers a promise that isn't handed to
-* `ctx.waitUntil` can be cancelled the moment the response returns, dropping
-* that send and weakening the guarantee. Wire your request's `ctx.waitUntil`
-* into better-auth's background handler so the work survives:
-*
-* ```ts
-* // in your worker fetch handler, where `ctx: ExecutionContext` is in scope
-* const auth = createAuth({
-*     secret: env.AUTH_SECRET,
-*     database: lunoraD1Adapter(env.DB),
-*     advanced: {
-*         backgroundTasks: { handler: (promise) => ctx.waitUntil(promise) },
-*     },
-* });
-* ```
-*
-* (Lunora can't set this for you — `ctx.waitUntil` is per-request, but
-* `createAuth` runs once at worker setup.)
-*/
-type LunoraAuthOptions = BetterAuthOptions;
-/**
-* The full better-auth instance: `auth.handler` accepts a `Request` and
-* returns a `Response` (used by `handleAuthRequest`); `auth.api`
-* exposes the typed endpoint surface for server-side calls (e.g.
-* `auth.api.getSession({ headers })` inside a query/mutation).
-*/
-type LunoraAuth = ReturnType<typeof betterAuth>;
-/**
-* Create the auth instance. Thin wrapper around `betterAuth` that enforces
-* the `secret` requirement at construction time so misconfigured deployments
-* fail loudly at the first fetch rather than the first sign-in attempt.
-*/
-declare const createAuth: (options: LunoraAuthOptions) => LunoraAuth;
-export { LunoraAuth as L, LunoraAuthOptions as a, createAuth as c };

package/dist/packem_shared/create-auth.d-M36jwG_Y.d.ts

@@ -1,58 +0,0 @@
-import { betterAuth, BetterAuthOptions } from 'better-auth';
-/**
-* Lunora's options pass straight through to better-auth — the only thing we add
-* is requiring `secret` up front so a misconfigured deployment fails loudly
-* instead of at the first sign-in.
-*
-* For `database`, prefer `lunoraD1Adapter` (`database: lunoraD1Adapter(env.DB)`)
-* over passing the raw `env.DB`. better-auth *does* accept a D1Database directly,
-* but it then resolves its Kysely adapter via a runtime `await import(...)` inside
-* `auth.$context` — and that import never settles under `@cloudflare/vite-plugin`'s
-* worker runner, hanging every auth request in `pnpm dev`. The explicit adapter
-* skips it, so dev and prod behave the same. (Raw `env.DB` is still correct for
-* the migration-only instance — see `lunoraD1Adapter`'s note.)
-*
-* Session rotation / richer session policies are configured via the `session`
-* field (a `SessionPolicy`); Lunora validates it for obviously-broken
-* durations and forwards it verbatim to better-auth. See `sessionPresets`
-* for ready-made rotation/expiry trade-offs.
-*
-* ## Serverless background tasks (Cloudflare Workers)
-*
-* better-auth runs some work *after* sending the response — most importantly the
-* password-reset email, whose background send is what keeps reset responses
-* constant-time (a timing-attack defence: the response doesn't reveal whether
-* the account exists). On Cloudflare Workers a promise that isn't handed to
-* `ctx.waitUntil` can be cancelled the moment the response returns, dropping
-* that send and weakening the guarantee. Wire your request's `ctx.waitUntil`
-* into better-auth's background handler so the work survives:
-*
-* ```ts
-* // in your worker fetch handler, where `ctx: ExecutionContext` is in scope
-* const auth = createAuth({
-*     secret: env.AUTH_SECRET,
-*     database: lunoraD1Adapter(env.DB),
-*     advanced: {
-*         backgroundTasks: { handler: (promise) => ctx.waitUntil(promise) },
-*     },
-* });
-* ```
-*
-* (Lunora can't set this for you — `ctx.waitUntil` is per-request, but
-* `createAuth` runs once at worker setup.)
-*/
-type LunoraAuthOptions = BetterAuthOptions;
-/**
-* The full better-auth instance: `auth.handler` accepts a `Request` and
-* returns a `Response` (used by `handleAuthRequest`); `auth.api`
-* exposes the typed endpoint surface for server-side calls (e.g.
-* `auth.api.getSession({ headers })` inside a query/mutation).
-*/
-type LunoraAuth = ReturnType<typeof betterAuth>;
-/**
-* Create the auth instance. Thin wrapper around `betterAuth` that enforces
-* the `secret` requirement at construction time so misconfigured deployments
-* fail loudly at the first fetch rather than the first sign-in attempt.
-*/
-declare const createAuth: (options: LunoraAuthOptions) => LunoraAuth;
-export { LunoraAuth as L, LunoraAuthOptions as a, createAuth as c };