feat(ui): migrate organization billing surface to Mosaic#9164
feat(ui): migrate organization billing surface to Mosaic#9164alexcarpenter wants to merge 10 commits into
Conversation
Add Mosaic controller/view/wrapper trios for the organization billing panel and its Subscriptions, Account Credits, Statements, and Payments sections, plus the Statement and Payment Attempt detail screens. Each is exposed via the OrganizationProfile compound namespace. Additive and backwards-compatible; the legacy billing page is untouched.
Wire swingset stories, MDX docs, registry, and DocsViewer entries for the migrated organization billing panel, its four sections, and the statement and payment detail screens.
🦋 Changeset detectedLatest commit: 2404c8a The changes in this PR will be included in the next version bump. This PR includes changesets to release 3 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
The latest updates on your projects. Learn more about Vercel for GitHub.
1 Skipped Deployment
|
|
Important Review skippedDraft detected. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Repository YAML (base), Repository UI (inherited) Review profile: CHILL Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Comment |
Add a Mosaic payment-methods section that lists saved methods and drives the make-default and remove mutations through dedicated state machines. Self-gates on org:sys_billing:manage and replaces the legacy <PaymentMethods/> in the Mosaic billing panel. The Stripe-backed add flow is not yet migrated. Exposed as OrganizationProfile.BillingPaymentMethodsSection.
The Mosaic payment-methods section lists, removes, and re-defaults methods but does not yet migrate the Stripe PaymentElement add flow. Document why (it cannot be a Clerk-free prop-driven view) in the section and note it in the changeset.
Add an add-payment-method machine, controller wiring, and view entry point to the Mosaic organization billing payment-methods section. The Clerk-side lifecycle (open, submit, revalidate, error) is fully migrated and tested; the gateway's remotely-hosted card element (Stripe) is not rendered here and stays on the legacy surface, with add.onSubmit as the token seam. The add entry point is hidden in no-RHC builds.
@clerk/astro
@clerk/backend
@clerk/chrome-extension
@clerk/clerk-js
@clerk/electron
@clerk/electron-passkeys
@clerk/eslint-plugin
@clerk/expo
@clerk/expo-passkeys
@clerk/express
@clerk/fastify
@clerk/hono
@clerk/localizations
@clerk/nextjs
@clerk/nuxt
@clerk/react
@clerk/react-router
@clerk/shared
@clerk/tanstack-react-start
@clerk/testing
@clerk/ui
@clerk/upgrade
@clerk/vue
commit: |
Description
Migrates the legacy Organization Billing surface into the Mosaic design system, following the
machine → controller → viewsplit. Landed incrementally; this PR accumulates the roadmap items.Each piece ships a Clerk-facing controller (discriminated-union status), a Clerk-free unstyled native-HTML view (all strings/callbacks passed as props), a wrapper that returns null until ready, and controller + view tests. All are exposed via the
OrganizationProfilecompound namespace and wired into swingset (stories, MDX, registry, DocsViewer).Per the migration steer, views are intentionally unstyled native HTML with zero localization (hardcoded English mirroring the en-US strings) — the focus is dialing in the controllers and machines, not the visual layer.
Done
org:sys_billing:read/:manage+ billing-enabled). The whole panel self-gates and renders nothing for members who cannot view billing, matching the legacy route guard.useReverification(step-up auth), matching the legacyRemoveResourceForm. make-default stays unreverified (legacy parity).Parity & test confidence
A parity audit compared each Mosaic controller against the legacy behavior it replaced. Core controller/machine logic is at parity; the remaining differences are the intentional in-scope divergences (localization keys → hardcoded en-US, styled components → native HTML, dropped icons, loader → null). Two spots improve on legacy: a fixed non-transitive subscription sort, and a make-default in-flight disable. Coverage was extended with direct
billing-formatformatter tests and controller characterization tests for previously-uncovered branches (subscription caption lifecycle,subscriberType='user'gate, pending payment intent, empty statement groups, etc.). Suite: 324 mosaic-org tests passing.Remaining
PaymentElementinside aPaymentElementProviderand needs the Stripe appearance-theming bridge, so — unlike every other Mosaic billing view — its element-rendering sub-view cannot be reduced to a Clerk-free, prop-driven component. Until it lands, the Payment Methods section only lists/removes/re-defaults existing methods, matching the legacy RHC-disabled behavior (add button hidden). Documented inorganization-billing-payment-methods-section.tsxand the changeset.Backwards compatibility
Additive only. No existing public API is changed or removed, and the legacy organization billing page is untouched. New surface is exposed via
OrganizationProfile.Billing*namespace entries.Checklist
@clerk/uiminor)