convex() fails to bundle on better-auth 1.7 (oidc-provider removed) #433

Activity

1. PeterHewat commented on Aug 28, 2026

   

   PeterHewat

   on Aug 28, 2026

   Author

   More actions

   Just noticed sshkeda has worked on this here: #430
   But since he is a first contributor, tests haven't run and his PR is blocked.
2. tiagonrodrigues commented on Sep 6, 2026

   

   tiagonrodrigues

   on Sep 6, 2026

   More actions

   Hit this across six production apps today, and I want to flag how sharp the edge is, because I don't think the thread conveys it yet.

   This lands in production, not in CI. The specifier appears in three places in @convex-dev/better-auth@0.12.5, and the third is what makes it dangerous:

   dist/auth-options.js:7               import { oidcProvider } from "better-auth/plugins/oidc-provider";
   dist/plugins/convex/index.js:4       import { oidcProvider as oidcProviderPlugin } from "better-auth/plugins/oidc-provider";
   dist/plugins/convex/index.d.ts:261   import("better-auth/plugins/oidc-provider").OIDCMetadata
   

   Because it also sits in a .d.ts inside node_modules, tsc --noEmit passes under the default skipLibCheck. Typecheck is green, tests are green, and the build then dies at bundle time:

   Module not found: Can't resolve 'better-auth/plugins/oidc-provider'
   

   Anyone on Renovate, Dependabot or a homegrown updater gets a clean-looking PR that breaks their deploy. The declared peerDependencies range (>=1.6.11 <1.7.0) is the only pre-build signal, and neither bun install nor npm install treats a peer violation as an error by default. That combination is why six of our apps broke at once.

   Why this is urgent rather than merely annoying. better-auth@1.7 has been the latest tag since 18 August. Every new install of this adapter that doesn't pin resolves to a broken pair on day one, and there is no published version of the adapter that works with it, including prerelease tags: latest is 0.12.5, and both next (0.7.0-alpha.3) and alpha (0.9.7-alpha.1) are older than latest, so there's no channel to test against either. The only escape is pinning better-auth below 1.7 and staying there.

   #430 appears to do the work. From the outside it looks blocked on process rather than code: the test workflow is sitting in action_required because it's a first-time contribution, so CI has never run on it, and there's no maintainer comment on it or on this issue.

   Two things would help a lot, in order:

   1. Any signal on whether Migrate Convex adapter to Better Auth 1.7 #430 is the intended path, or whether you plan your own migration. Right now nobody downstream can tell whether to wait a week or vendor a workaround.
   2. Failing that, a 0.12.6 that only tightens the peer range to a hard <1.7.0 with a clear message, so installs fail loudly at install time instead of silently at deploy time.

   One correction for the thread: the claim above that types break from 1.6.18 doesn't reproduce here. Six apps run better-auth@1.6.30 with @convex-dev/better-auth@0.12.5, and all six typecheck, build and deploy cleanly. If it breaks at 1.6.18 for someone, it may be specific to a client setup we don't have. ~1.6.30 is holding fine for us.

   For the record, confirmed on the registry: ./plugins/oidc-provider is present in better-auth@1.6.30's exports and gone in 1.7.0, along with ./plugins/mcp/client. Upstream documents the removal as intentional with @better-auth/oauth-provider as the replacement, so this is squarely an adapter migration, not an upstream regression.

   Happy to test a prerelease against six real apps the day one exists.

   👍React with 👍2Reacted by Jack Landon and Kristofher Muñoz Rojas

   👀React with 👀1Reacted by Kristofher Muñoz Rojas
3. tiagonrodrigues commented on Oct 15, 2026

   

   tiagonrodrigues

   on Oct 15, 2026

   More actions

   Bump on this!