Repository navigation
chore(deps): october 2026 dependency refresh - #72
Merged
Merged
Conversation
axelhamil
commented
Oct 29, 2026
axelhamil
commented
Owner
- Node 26.13 LTS (Docker on the latest published 26 image), Bun 1.4.4, pnpm 12.16.1
- better-auth 1.7.14 and @better-auth/utils 0.5.1
- stripe 23 on apiVersion 2026-09-30.endive: the webhook endpoint version must be checked in the Stripe dashboard
- inwire 4, @hookform/resolvers 6, @sentry/vite-plugin 11, tsup 9
- Remaining pins measured and recorded in docs/HISTORY.md: @simplewebauthn/server 13, conventional-changelog-conventionalcommits 9
- RGPD account deletion verifies TOTP with the rotated auth secrets and ignores unconfirmed two-factor enrolments
- Gate green locally: ci:check, turbo build type-check test, jscpd 0.61 %, knip
Node 26.13.0 became the active LTS today, so mise, .nvmrc and the engines floor move to it together. Node 25 dropped corepack from its distribution, so the dev and app images now install pnpm with npm like the api prod image already did. Bun is pinned to 1.4.4 in mise, the images and CI, where it used to float on latest. pnpm 12.16.1 replaces 11.24.0 in mise and packageManager. Its only lockfile change is the packageManagerDependencies document that pins pnpm itself; the dependency graph is untouched. Keycloak moves from 26.0 to 26.8.1 for the opt-in SSO profile. Docs now state the new floors.
Every dependency whose latest release stays inside its current major moves to that release, the better-auth family together to 1.7.14 (exact pins kept). better-auth 1.7.14 depends on exactly @better-auth/utils 0.5.1, so the api's utils pin moves with it: kept at 0.4.2, the lockfile carried two utils copies and two peer variants of @better-auth/core, and the api type-check failed (TS2345, the adapter built from one core variant is not assignable to the other). The other majors (stripe, inwire, @hookform/resolvers, @sentry/vite-plugin, tsup, @simplewebauthn/server, conventional-changelog-conventionalcommits) are left for their own pass. The lockfile is deduplicated: the bump left a stale @types/node 26.6.3 next to 26.6.5, which split stripe into two peer variants and failed the app type-check (it reads the api's auth types) with TS2322 on the Stripe client. One @types/node gives one stripe; older radix-ui primitives, zod 4.6.5 and pg-protocol 1.16.0 duplicates go too. Biome 2.6 formats Markdown and YAML by default; the config opts both out, like it opts json and css in, so the docs and the lockfile keep their current shape instead of a 35 file reformat riding on a bump.
The four images pruned with a hardcoded turbo 2.9.6, which predates the agentGuidance key of turbo.json and failed every build. The pruner now reads the version from the root package.json devDependency, so the next turbo bump moves the images with it instead of drifting again.
The deletion check verifies a TOTP code outside twoFactor, so it must decode the stored secret exactly like the plugin. better-auth 1.7.14's twoFactor treats a secret stored as "base32:<secret>" (imported from another provider) as Base32 bytes, while the repository fed the raw string to createOTP: a user with an imported secret could not confirm their account deletion with a valid code. The repository now applies the same decoding, and tests cover a generated and an imported secret. It lands after the @better-auth/utils 0.5 bump because 0.4.2 types createOTP's secret as a string only, so the byte secret does not type-check before it.
@better-auth/stripe 1.7.14 peers on "^18 || ... || ^23", so the plugin supports the new major. stripe 23 pins API version 2026-09-30.endive; the client now requests it, since the SDK types follow the pinned version. None of the removed surfaces are used here or by the plugin (payment_method_types on Checkout/PaymentIntent params, Stripe.constructEventWithoutVerification, the ErrorType export). The app's client plugin resolves its stripe peer to the same 23.0.1, so the workspace keeps a single stripe copy.
inwire 4 makes a container single use after dispose() and rejects at compile time a local-mode module whose prerequisites the host lacks. Neither applies here: the api never disposes its container, and every module is a global-mode defineModule() that augments AppDeps, so the container still infers a concrete type for every binding (probe: no binding typed any, an unknown key is a type error). inwire 4 also lets a built container be assigned to Record<string, unknown>, so the double cast on the outbox dispatcher's start(di) goes. The api boots, /readyz answers and SIGTERM stops every worker.
The only breaking change of 6.0 is in the effect-ts resolver (Effect v4 required); every form here uses zodResolver, which is unchanged. The ui package's optional peer moves to ^6.0.1 too, otherwise auto-install-peers kept a second copy (5.9.1) for it. 6.0.2 was published hours ago and is held back by pnpm's release-age policy, so the range floor is 6.0.1.
The bundler plugins now release with the SDK, so the version jumps from 5.4.1 to the SDK's 11.9.0 (same as @sentry/react and @sentry/bun here). The options are unchanged. The plugin now drives the `sentry` CLI SDK instead of @sentry/cli, which is no longer installed, so its allowBuilds entry goes. Measured with the plugin active (fake token, mock Sentry server): the build injects debug ids, creates and finalizes the release, attempts the chunk upload, then deletes every dist/**/*.map.
tsup 9 drops Node below 22.18 (the repo runs 26) and moves its debug
logger to obug; the config options used by ddd-kit are unchanged.
As measured, `tsup && tsc -p tsconfig.build.json` still emits
dist/index.{js,cjs,d.ts} with their maps, byte-identical to the tsup 8
output (diff -rq on the whole dist/ is empty).
biome.json disables the Markdown and YAML formatters since Biome 2.6, so lint-staged passing staged .md/.yml/.yaml files to `biome format` only spent a process on files it ignores. The glob now lists the languages Biome formats here.
node:26.13.0-alpine is not on Docker Hub yet (404 on 28/10), so every image failed to build from a clean cache. The four Dockerfiles move to node:26.12.1-alpine, the latest published tag of the same LTS line, while .nvmrc, mise.toml and engines stay on 26.13.0. HISTORY records the pin and when to lift it.
…t deletion The RGPD repository verified the deletion step-up code with its own copy of period 30 and digits 6 while auth.ts relied on the twoFactor defaults. A change on one side would have made account deletion refuse codes that sign-in accepts. TOTP_OPTIONS in shared/auth is now passed to twoFactor and read by the repository; the values are the plugin defaults, so behaviour is unchanged.
better-auth encrypts the two-factor secret with its secret config, built from BETTER_AUTH_SECRETS when rotation is configured, while the account deletion step-up decrypted with BETTER_AUTH_SECRET alone. With rotation on, every deletion confirmed by TOTP failed. env.ts now validates BETTER_AUTH_SECRETS, auth.ts passes it to betterAuth, and authSecretKey in shared/auth builds the same key the repository decrypts with. The new test, a secret enrolled before a rotation, fails on the old code and passes now.
better-auth refuses a two-factor row with verified = false at sign-in, but the account deletion step-up read the row without that filter, so a TOTP enrolled and never confirmed was enough to confirm a deletion. verifyTotp now keeps confirmed rows and legacy NULL ones, as better-auth does. The rule lives in SQL, so check:totp-enrolment proves it on a real database (it fails on the old query) and runs in CI. HISTORY records the three fixes.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.