Version Packages

[github-actions]

This PR was opened by the Changesets release GitHub action. When you're ready to do a release, you can merge this and the packages will be published to npm automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to main, this PR will be updated.

Releases

@seamless-auth/react@0.11.0

Minor Changes

• 74f17d2: Let the bundled screens choose where a magic link lands.

  requestMagicLink(redirectUri) arrived in 0.10.0, but only the headless client
  path could reach it. An application using AuthRoutes had no way to set one, so
  the deployment-wide destination was the only option for the audience least likely
  to be wiring up its own client.

  AuthProvider now takes magicLinkRedirectUri, and useAuthClient() hands it to
  the client as the default for every send. SeamlessAuthClientOptions carries the
  same field, so a directly constructed client can do this too.

  The destination lives on the client rather than at each call site on purpose. The
  sign-in screen and the resend on the "check your email" screen both send with no
  argument, so they cannot disagree about where the link goes. A resend that landed
  somewhere other than the link it repeats would be a confusing failure and an easy
  one to miss in review.

  Nothing changes if you omit it: the same empty body is sent and the deployment's
  own destination still applies. An explicit requestMagicLink(uri) still wins over
  the configured default.

• eb10397: Stop painting the disabled submit button as a filled grey primary.

  On the sign-in and MFA screens the submit button was disabled until its field
  validated, and while disabled it was filled with --seamless-disabled while the
  label kept --seamless-accent-contrast. Those two colours were chosen in
  different places, so no value a themed app could supply worked in both a light
  and a dark theme: lighten the fill and the label washed out, darken it and the
  label went near-black on dark. The result read as a primary button that had
  broken rather than a control waiting on input.

  The disabled state is now the enabled button at reduced opacity. Label and
  background stay on the accent pair the app already tuned, so their contrast
  cannot invert with the theme, and the control reads as inactive instead of
  broken. This matches how the magic-link and passkey screens already draw their
  disabled buttons.

  --seamless-disabled is no longer read anywhere and has been dropped from the
  token table. If you set it, remove it; every other token behaves as before.

  The sign-in screen now also says why the button is refusing, in a live region
  below it that reports whether the field is empty, incomplete, or ready. A
  disabled button is not focusable and is passed over by screen readers, so the
  refusal was previously silent for the people least able to guess the reason.

  Fixing that surfaced a related bug: a valid email typed in registration left the
  Login button enabled after switching to sign-in, even with the identifier field
  empty, because the submit check fell through to the registration field. Each
  mode now checks only its own field.