Gate wasp-auth-only codegen behind the provider and expose the active provider identity

[FranjoMindek]

Description

Stack: PR 6, on top of #4719. Capability-gated code generation: the generated app is different code per provider, not different runtime behavior. This is the mechanism RedwoodJS lacked — a library must typecheck every configuration at once; a compiler can simply not emit what cannot work.

Under an external auth provider:

• Not generated, so importing them is a compile error: LoginForm/SignupForm and all of wasp/client/auth/ui, per-method client modules, Wasp's server auth flows (password.ts, jwt.ts, lucia.ts, provider/wasp.ts, hooks.ts, email/username/oauth modules), and their SDK exports entries.
• Not installed: lucia and @lucia-auth/adapter-prisma.
• Not required: JWT_SECRET — gone from the generated env schema and config.auth.
• Still uniform: useAuth, logout(), context.user, authRequired, /auth/me, /auth/logout, and wasp/server/auth's defineUserSignupFields.

And in both directions:

• wasp/auth/provider (new, every auth app): authProviderId and authCapabilities as as const literals — "which provider am I on" answered by the type system.
• Manifest env vars become generated zod validation (server and client): a missing CLERK_SECRET_KEY fails at boot with the manifest's own doc string, not at the first authenticated request.
• JIT provisioning gains userSignupFields: the manifest's ref reaches the SDK as a virtual user module and is fed the provider-verified claims, closing the "non-nullable User.email can never be provisioned" trap flagged in verification. Claims are also persisted as AuthIdentity.providerData.
• A boot assertion checks the manifest's compile-time claims (id, capabilities) against the runtime adapter object — a wrong manifest is a loud startup failure, not a subtly broken app.

Golden proof, not assertion: a new e2e snapshot (auth-provider-external, the Clerk example) pins all of the above verbatim — no auth/forms, no lucia in package.json, no JWT_SECRET, authProviderId = "clerk", Clerk env vars in the env schema. Meanwhile every existing snapshot is byte-identical under .wasp/out/ except the intended additions (the provider-identity module and its export). 1100 e2e tests green.

Consciously not here (each deferred with a reason recorded in the design doc): mounting manifest routes and adapter-package imports (next PR — a src-adapter manifest cannot even declare routes), generated client-adapter glue, provisioning hooks (blocked on the veto-loop tombstone problem), and curated diagnostics beyond TS2307 at the import site.

Type of change

• 🔧 Just code/docs improvement
• 🐞 Bug fix
• 🚀 New/improved feature
• 💥 Breaking change

Checklist

• I tested my change in a Wasp app to verify that it works as intended.

  Verified live at the top of the stack (better-auth example): JIT provisioning with claims → local User row, providerData carrying {email, name}, and context.user.id identical across providers.

• 🧪 Tests and apps:

  • I added unit tests for my change.

    The new e2e snapshot is the test: generated output compared verbatim is strictly stronger than unit-testing generator functions.

  • (if you fixed a bug) I added a regression test for the bug I fixed.

  • (if you added/updated a feature) I added/updated e2e tests in examples/kitchen-sink/e2e-tests.

    Not in kitchen-sink (it must stay a wasp-auth app); the coverage is the new auth-provider-external snapshot suite.

  • (if you added/updated a feature) I updated the starter templates in waspc/data/Cli/templates, as needed.

  • (if you added/updated a feature) I updated the example apps in examples/, as needed.

    • (if you updated examples/tutorials) I updated the tutorial in the docs (and vice versa).

• 📜 Documentation:

  • (if you added/updated a feature) I added/updated the documentation in web/docs/.

    Held with the stack until the API stops moving.

• 🆕 Changelog: (if change is more than just code/docs improvement)

  • I updated waspc/ChangeLog.md with a user-friendly description of the change.
  • (if you did a breaking change) I added a step to the current migration guide in web/docs/migration-guides/.
  • I bumped the version in waspc/waspc.cabal to reflect the changes I introduced.

[cloudflare-workers-and-pages]

Deploying wasp-docs-on-main with    Cloudflare Pages

Latest commit:	a28c9c9
Status:	✅  Deploy successful!
Preview URL:	https://a6d15b1d.wasp-docs-on-main.pages.dev
Branch Preview URL:	https://franjo-auth-capability-codeg.wasp-docs-on-main.pages.dev

View logs

[pkg-pr-new]

Open in StackBlitz

@wasp.sh/spec

npx https://pkg.pr.new/wasp-lang/wasp/@wasp.sh/spec@4720

@wasp.sh/wasp-cli

npx https://pkg.pr.new/wasp-lang/wasp/@wasp.sh/wasp-cli@4720

@wasp.sh/wasp-cli-darwin-arm64-unknown

npx https://pkg.pr.new/wasp-lang/wasp/@wasp.sh/wasp-cli-darwin-arm64-unknown@4720

@wasp.sh/wasp-cli-darwin-x64-unknown

npx https://pkg.pr.new/wasp-lang/wasp/@wasp.sh/wasp-cli-darwin-x64-unknown@4720

@wasp.sh/wasp-cli-linux-arm64-glibc

npx https://pkg.pr.new/wasp-lang/wasp/@wasp.sh/wasp-cli-linux-arm64-glibc@4720

@wasp.sh/wasp-cli-linux-x64-glibc

npx https://pkg.pr.new/wasp-lang/wasp/@wasp.sh/wasp-cli-linux-x64-glibc@4720

@wasp.sh/wasp-cli-linux-x64-musl

npx https://pkg.pr.new/wasp-lang/wasp/@wasp.sh/wasp-cli-linux-x64-musl@4720

commit: a28c9c9

[FranjoMindek]

Superseded by the restacked series (stack of #4724–#4730). This PR survives nearly verbatim as #4728; its external-provider snapshot test moved to #4730 so the golden dir lands exactly once, in final form.