feat(clerk-js,types): Update logic for showing Billing nav within profiles #6315
Conversation
🦋 Changeset detectedLatest commit: d22b94f The changes in this PR will be included in the next version bump. This PR includes changesets to release 22 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 Git ↗︎
|
| @@ -605,7 +605,7 @@ export class Clerk implements ClerkInterface { | |||
|
|
|||
| public __internal_openPlanDetails = (props: __internal_PlanDetailsProps): void => { | |||
| this.assertComponentsReady(this.#componentControls); | |||
| if (disabledBillingFeature(this, this.environment)) { | |||
| if (disabledAllBillingFeatures(this, this.environment)) { | |||
There was a problem hiding this comment.
The thought process on these is that since we don't necessarily know the subscriberType in these functions (right?) we will just check if all billing is disabled.
@clerk/agent-toolkit
@clerk/astro
@clerk/backend
@clerk/chrome-extension
@clerk/clerk-js
@clerk/dev-cli
@clerk/elements
@clerk/clerk-expo
@clerk/expo-passkeys
@clerk/express
@clerk/fastify
@clerk/localizations
@clerk/nextjs
@clerk/nuxt
@clerk/clerk-react
@clerk/react-router
@clerk/remix
@clerk/shared
@clerk/tanstack-react-start
@clerk/testing
@clerk/themes
@clerk/types
@clerk/upgrade
@clerk/vue
commit: |
📝 WalkthroughWalkthroughThis change refactors the billing feature logic throughout the codebase by introducing more granular control over user and organization billing settings. The 📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (1)
✅ Files skipped from review due to trivial changes (1)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (5)
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
There was a problem hiding this comment.
Actionable comments posted: 1
🔭 Outside diff range comments (3)
packages/clerk-js/src/core/clerk.ts (1)
577-1070: Consider adding tests for the new granular billing feature logic.The refactoring from
disabledBillingFeaturetodisabledAllBillingFeaturesintroduces more granular control over billing features. While the changes are straightforward replacements, the new logic should be tested to ensure:
- Billing components are properly disabled when all billing features are disabled
- Components behave correctly when only user or organization billing is disabled
- Error handling works as expected in development mode
#!/bin/bash # Description: Check if tests exist for the updated billing feature guards # Search for existing tests related to billing feature guards rg -A 5 -B 5 "disabledAllBillingFeatures|disabledBillingFeature" --type ts --type js # Look for test files that might cover these billing methods fd -e test.ts -e spec.ts -e test.js -e spec.js | xargs grep -l "openCheckout\|openPlanDetails\|mountPricingTable"packages/clerk-js/src/ui/components/OrganizationProfile/OrganizationProfileRoutes.tsx (2)
86-119: Use optional chaining for nested property access to prevent runtime errors.The conditional check
commerceSettings.billing.organization.enabledaccesses nested properties without optional chaining, which could cause runtime errors if the nested structure is undefined. The component guards incomponentGuards.tsuse optional chaining for similar checks.Apply this diff to use optional chaining:
- {commerceSettings.billing.organization.enabled ? ( + {commerceSettings.billing.organization?.enabled ? (
86-119: Add unit and visual regression tests for OrganizationProfileRoutes billing conditionsNo existing tests reference
OrganizationProfileRoutesor the neworganization-billingroutes. Please add:• Unit tests in
packages/clerk-js/src/ui/components/OrganizationProfile/__tests__/OrganizationProfileRoutes.test.tsx(or similar) that verify:
– WhencommerceSettings.billing.organization.enabledis false, no billing routes render
– When enabled without paid plans, the billing page renders but “plans” route is absent
– When enabled with paid plans, both billing and plans routes render
– The statement (statement/:statementId) and payment-attempt routes render correctly• Use React Testing Library to assert component behavior (not implementation) with proper queries and setup.
• A visual regression test in the
packages/clerk-jssuite (e.g. Storybook + Chromatic/Percy) covering each billing state to catch unintended UI changes.
🧹 Nitpick comments (1)
packages/clerk-js/src/ui/components/Subscriptions/SubscriptionsList.tsx (1)
193-211: Consider refactoring complex conditional logic for better readability.The conditional rendering logic for the ArrowButton is functionally correct but could be more readable with a helper function or extracted variable.
Consider extracting the condition to improve readability:
+ const shouldShowArrowButton = + (subscriberType === 'user' && commerceSettings.billing.user.hasPaidPlans) || + (subscriberType === 'org' && commerceSettings.billing.organization.hasPaidPlans); + - {(commerceSettings.billing.user.hasPaidPlans && subscriberType === 'user') || - (commerceSettings.billing.organization.hasPaidPlans && subscriberType === 'org') ? ( + {shouldShowArrowButton ? ( <ProfileSection.ArrowButton
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (9)
.changeset/public-bags-stay.md(1 hunks)packages/clerk-js/src/core/clerk.ts(4 hunks)packages/clerk-js/src/core/resources/CommerceSettings.ts(3 hunks)packages/clerk-js/src/ui/components/OrganizationProfile/OrganizationProfileRoutes.tsx(3 hunks)packages/clerk-js/src/ui/components/Subscriptions/SubscriptionsList.tsx(3 hunks)packages/clerk-js/src/ui/components/UserProfile/UserProfileRoutes.tsx(2 hunks)packages/clerk-js/src/ui/utils/createCustomPages.tsx(2 hunks)packages/clerk-js/src/utils/componentGuards.ts(1 hunks)packages/types/src/commerceSettings.ts(2 hunks)
🧰 Additional context used
📓 Path-based instructions (9)
**/*.{js,jsx,ts,tsx}
Instructions used from:
Sources:
📄 CodeRabbit Inference Engine
- .cursor/rules/development.mdc
packages/**/*.ts
Instructions used from:
Sources:
📄 CodeRabbit Inference Engine
- .cursor/rules/development.mdc
packages/**/*.{ts,tsx,d.ts}
Instructions used from:
Sources:
📄 CodeRabbit Inference Engine
- .cursor/rules/development.mdc
**/*.{ts,tsx}
Instructions used from:
Sources:
📄 CodeRabbit Inference Engine
- .cursor/rules/development.mdc
- .cursor/rules/typescript.mdc
packages/{clerk-js,elements,themes}/**/*
Instructions used from:
Sources:
📄 CodeRabbit Inference Engine
- .cursor/rules/monorepo.mdc
**/*
Instructions used from:
Sources:
⚙️ CodeRabbit Configuration File
**/*.{tsx,jsx}
Instructions used from:
Sources:
📄 CodeRabbit Inference Engine
- .cursor/rules/development.mdc
**/*.{jsx,tsx}
Instructions used from:
Sources:
📄 CodeRabbit Inference Engine
- .cursor/rules/react.mdc
**/*.tsx
Instructions used from:
Sources:
📄 CodeRabbit Inference Engine
- .cursor/rules/react.mdc
🧠 Learnings (8)
📓 Common learnings
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/monorepo.mdc:0-0
Timestamp: 2025-06-30T10:30:56.197Z
Learning: Applies to packages/{clerk-js,elements,themes}/**/* : Visual regression testing should be performed for UI components.
.changeset/public-bags-stay.md (9)
Learnt from: dstaley
PR: clerk/javascript#6116
File: .changeset/tangy-garlics-say.md:1-2
Timestamp: 2025-06-13T16:09:53.061Z
Learning: In the Clerk JavaScript repository, contributors create intentionally empty changeset files (containing only the YAML delimiters) when a PR touches only non-published parts of the codebase (e.g., sandbox assets). This signals that no package release is required, so such changesets should not be flagged as missing content.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/monorepo.mdc:0-0
Timestamp: 2025-06-30T10:30:56.197Z
Learning: Applies to packages/{clerk-js,elements,themes}/**/* : Visual regression testing should be performed for UI components.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/global.mdc:0-0
Timestamp: 2025-06-30T10:30:13.397Z
Learning: Applies to packages/*/package.json : All packages must be published under the @clerk namespace
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/monorepo.mdc:0-0
Timestamp: 2025-06-30T10:30:56.197Z
Learning: Applies to packages/*/package.json : All packages must be published under the @clerk namespace on npm.
Learnt from: panteliselef
PR: clerk/javascript#6285
File: packages/types/src/commerce.ts:1305-1305
Timestamp: 2025-07-11T18:08:14.697Z
Learning: In the Clerk JavaScript repository, when there's a conflict between naming consistency (camelCase) and avoiding breaking changes, the team prioritizes maintaining backward compatibility over enforcing naming conventions, even for experimental APIs.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/monorepo.mdc:0-0
Timestamp: 2025-06-30T10:30:56.197Z
Learning: Applies to packages/@clerk/*/package.json : Framework packages must depend on '@clerk/clerk-js' for core functionality.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/monorepo.mdc:0-0
Timestamp: 2025-06-30T10:30:56.197Z
Learning: Applies to packages/clerk-react/**/*.{test,spec}.{js,ts,tsx} : Component testing should use React Testing Library.
Learnt from: panteliselef
PR: clerk/javascript#6097
File: packages/clerk-js/src/ui/elements/LineItems.tsx:89-89
Timestamp: 2025-06-10T09:38:56.214Z
Learning: In packages/clerk-js/src/ui/elements/LineItems.tsx, the Title component's React.forwardRef should use HTMLTableCellElement as the generic type parameter, even though it renders a Dt element. This is the correct implementation according to the codebase maintainer.
Learnt from: wobsoriano
PR: clerk/javascript#6163
File: packages/backend/src/api/endpoints/APIKeysApi.ts:60-70
Timestamp: 2025-06-20T17:44:17.570Z
Learning: The Clerk codebase uses POST method for API key update operations instead of the typical PATCH method, as clarified by the maintainer wobsoriano.
packages/clerk-js/src/core/clerk.ts (8)
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/monorepo.mdc:0-0
Timestamp: 2025-06-30T10:30:56.197Z
Learning: Applies to packages/{clerk-js,elements,themes}/**/* : Visual regression testing should be performed for UI components.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/monorepo.mdc:0-0
Timestamp: 2025-06-30T10:30:56.197Z
Learning: Applies to packages/clerk-react/**/*.{test,spec}.{js,ts,tsx} : Component testing should use React Testing Library.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/monorepo.mdc:0-0
Timestamp: 2025-06-30T10:30:56.197Z
Learning: Applies to packages/@clerk/*/package.json : Framework packages must depend on '@clerk/clerk-js' for core functionality.
Learnt from: wobsoriano
PR: clerk/javascript#5858
File: packages/clerk-js/src/core/modules/apiKeys/index.ts:84-97
Timestamp: 2025-06-10T17:35:08.986Z
Learning: In the APIKeys service methods (packages/clerk-js/src/core/modules/apiKeys/index.ts), error handling is intentionally delegated to the component level rather than being implemented within the service methods themselves. This architectural pattern allows calling components to handle errors according to their specific UI needs.
Learnt from: dstaley
PR: clerk/javascript#6100
File: packages/clerk-js/src/ui/components/OAuthConsent/OAuthConsent.tsx:121-124
Timestamp: 2025-06-16T17:08:58.414Z
Learning: The @clerk/clerk-js package only supports browsers released in the last two years (since May 8, 2023), so modern CSS features like color-mix() are fully supported across all target browsers without requiring fallbacks.
Learnt from: LauraBeatris
PR: clerk/javascript#6273
File: packages/testing/src/playwright/unstable/page-objects/sessionTask.ts:22-27
Timestamp: 2025-07-11T17:12:28.495Z
Learning: In Clerk's test utilities, particularly for page objects like sessionTask.ts, when handling task type enums, prefer graceful handling of unknown/unsupported task types rather than throwing errors. This prevents breaking existing tests when new task types are introduced to the SessionTask['key'] union type.
Learnt from: panteliselef
PR: clerk/javascript#6097
File: packages/clerk-js/src/ui/elements/LineItems.tsx:89-89
Timestamp: 2025-06-10T09:38:56.214Z
Learning: In packages/clerk-js/src/ui/elements/LineItems.tsx, the Title component's React.forwardRef should use HTMLTableCellElement as the generic type parameter, even though it renders a Dt element. This is the correct implementation according to the codebase maintainer.
Learnt from: panteliselef
PR: clerk/javascript#6285
File: packages/types/src/commerce.ts:1305-1305
Timestamp: 2025-07-11T18:08:14.697Z
Learning: In the Clerk JavaScript repository, when there's a conflict between naming consistency (camelCase) and avoiding breaking changes, the team prioritizes maintaining backward compatibility over enforcing naming conventions, even for experimental APIs.
packages/clerk-js/src/ui/utils/createCustomPages.tsx (10)
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/monorepo.mdc:0-0
Timestamp: 2025-06-30T10:30:56.197Z
Learning: Applies to packages/clerk-react/**/*.{test,spec}.{js,ts,tsx} : Component testing should use React Testing Library.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/monorepo.mdc:0-0
Timestamp: 2025-06-30T10:30:56.197Z
Learning: Applies to packages/{clerk-js,elements,themes}/**/* : Visual regression testing should be performed for UI components.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/development.mdc:0-0
Timestamp: 2025-06-30T10:29:42.997Z
Learning: Applies to packages/**/index.{js,ts} : Use tree-shaking friendly exports
Learnt from: panteliselef
PR: clerk/javascript#6097
File: packages/clerk-js/src/ui/elements/LineItems.tsx:89-89
Timestamp: 2025-06-10T09:38:56.214Z
Learning: In packages/clerk-js/src/ui/elements/LineItems.tsx, the Title component's React.forwardRef should use HTMLTableCellElement as the generic type parameter, even though it renders a Dt element. This is the correct implementation according to the codebase maintainer.
Learnt from: LauraBeatris
PR: clerk/javascript#6273
File: packages/testing/src/playwright/unstable/page-objects/sessionTask.ts:22-27
Timestamp: 2025-07-11T17:12:28.495Z
Learning: In Clerk's test utilities, particularly for page objects like sessionTask.ts, when handling task type enums, prefer graceful handling of unknown/unsupported task types rather than throwing errors. This prevents breaking existing tests when new task types are introduced to the SessionTask['key'] union type.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/monorepo.mdc:0-0
Timestamp: 2025-06-30T10:30:56.197Z
Learning: Applies to packages/@clerk/*/package.json : Framework packages must depend on '@clerk/clerk-js' for core functionality.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/typescript.mdc:0-0
Timestamp: 2025-06-30T10:33:45.961Z
Learning: Applies to **/*.{ts,tsx} : Proper use of utility types instead of manual type construction
Learnt from: wobsoriano
PR: clerk/javascript#5858
File: packages/clerk-js/src/core/modules/apiKeys/index.ts:84-97
Timestamp: 2025-06-10T17:35:08.986Z
Learning: In the APIKeys service methods (packages/clerk-js/src/core/modules/apiKeys/index.ts), error handling is intentionally delegated to the component level rather than being implemented within the service methods themselves. This architectural pattern allows calling components to handle errors according to their specific UI needs.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/typescript.mdc:0-0
Timestamp: 2025-06-30T10:33:45.961Z
Learning: Applies to **/*.{ts,tsx} : Use `public` explicitly for clarity in public APIs
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/development.mdc:0-0
Timestamp: 2025-06-30T10:29:42.997Z
Learning: Applies to **/*.{js,jsx,ts,tsx} : Use dynamic imports for optional features
packages/clerk-js/src/ui/components/Subscriptions/SubscriptionsList.tsx (11)
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/react.mdc:0-0
Timestamp: 2025-06-30T10:32:37.848Z
Learning: Applies to **/*.{jsx,tsx} : Implement proper subscription cleanup
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/react.mdc:0-0
Timestamp: 2025-06-30T10:32:37.848Z
Learning: Applies to **/*.{jsx,tsx} : Use proper hook structure
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/monorepo.mdc:0-0
Timestamp: 2025-06-30T10:30:56.197Z
Learning: Applies to packages/clerk-react/**/*.{test,spec}.{js,ts,tsx} : Component testing should use React Testing Library.
Learnt from: panteliselef
PR: clerk/javascript#6097
File: packages/clerk-js/src/ui/elements/LineItems.tsx:89-89
Timestamp: 2025-06-10T09:38:56.214Z
Learning: In packages/clerk-js/src/ui/elements/LineItems.tsx, the Title component's React.forwardRef should use HTMLTableCellElement as the generic type parameter, even though it renders a Dt element. This is the correct implementation according to the codebase maintainer.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/react.mdc:0-0
Timestamp: 2025-06-30T10:32:37.848Z
Learning: Applies to **/*.{jsx,tsx} : Use proper state updates with callbacks
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/react.mdc:0-0
Timestamp: 2025-06-30T10:32:37.848Z
Learning: Applies to **/*.{jsx,tsx} : Implement proper virtualization for lists
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/react.mdc:0-0
Timestamp: 2025-06-30T10:32:37.848Z
Learning: Applies to **/*.tsx : Use proper type guards for conditional rendering
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/react.mdc:0-0
Timestamp: 2025-06-30T10:32:37.848Z
Learning: Applies to **/*.{jsx,tsx} : Use proper button types
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/react.mdc:0-0
Timestamp: 2025-06-30T10:32:37.848Z
Learning: Applies to **/*.{jsx,tsx} : Implement proper state selectors
Learnt from: LauraBeatris
PR: clerk/javascript#6117
File: packages/clerk-js/src/ui/components/SessionTasks/index.tsx:64-83
Timestamp: 2025-06-18T16:33:36.764Z
Learning: In SessionTasks component at packages/clerk-js/src/ui/components/SessionTasks/index.tsx, the useEffect that checks for pending tasks should only run on mount (not react to currentTask/status changes) to handle browser back navigation edge cases without interfering with normal task completion flow managed by nextTask().
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/react.mdc:0-0
Timestamp: 2025-06-30T10:32:37.848Z
Learning: Applies to **/*.{jsx,tsx} : Use Context API for theme/authentication
packages/clerk-js/src/ui/components/UserProfile/UserProfileRoutes.tsx (14)
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/react.mdc:0-0
Timestamp: 2025-06-30T10:32:37.848Z
Learning: Applies to **/*.tsx : Use proper type guards for conditional rendering
Learnt from: LauraBeatris
PR: clerk/javascript#6117
File: packages/clerk-js/src/ui/components/SessionTasks/index.tsx:64-83
Timestamp: 2025-06-18T16:33:36.764Z
Learning: In SessionTasks component at packages/clerk-js/src/ui/components/SessionTasks/index.tsx, the useEffect that checks for pending tasks should only run on mount (not react to currentTask/status changes) to handle browser back navigation edge cases without interfering with normal task completion flow managed by nextTask().
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/monorepo.mdc:0-0
Timestamp: 2025-06-30T10:30:56.197Z
Learning: Applies to packages/clerk-react/**/*.{test,spec}.{js,ts,tsx} : Component testing should use React Testing Library.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/nextjs.mdc:0-0
Timestamp: 2025-06-30T10:31:43.578Z
Learning: Applies to app/**/page.tsx : Use page.tsx for route segments that render UI in the App Router
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/nextjs.mdc:0-0
Timestamp: 2025-06-30T10:31:43.578Z
Learning: Applies to app/**/layout.tsx : Use layout.tsx for shared UI that wraps multiple pages in the App Router
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/nextjs.mdc:0-0
Timestamp: 2025-06-30T10:31:43.578Z
Learning: Applies to pages/**/*.{js,ts,jsx,tsx} : Use SWR for client-side data fetching in Pages Router
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/nextjs.mdc:0-0
Timestamp: 2025-06-30T10:31:43.578Z
Learning: Applies to {app/**/*.tsx,pages/**/*.{js,ts,jsx,tsx}} : Use Link component for client-side navigation between pages
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/react.mdc:0-0
Timestamp: 2025-06-30T10:32:37.848Z
Learning: Applies to **/*.{jsx,tsx} : Use Context API for theme/authentication
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/nextjs.mdc:0-0
Timestamp: 2025-06-30T10:31:43.578Z
Learning: Applies to app/**/[[]...*[]]/**/page.tsx : Use double brackets for catch-all routes: [...slug]/page.tsx
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/nextjs.mdc:0-0
Timestamp: 2025-06-30T10:31:43.578Z
Learning: Applies to app/**/*.tsx : Use useRouter hook for programmatic navigation in Client Components
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/nextjs.mdc:0-0
Timestamp: 2025-06-30T10:31:43.578Z
Learning: Applies to app/**/default.tsx : Use default.tsx for parallel routes fallbacks in the App Router
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/nextjs.mdc:0-0
Timestamp: 2025-06-30T10:31:43.578Z
Learning: Applies to app/**/error.tsx : Use error.tsx for error boundaries at the route level in the App Router
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/nextjs.mdc:0-0
Timestamp: 2025-06-30T10:31:43.578Z
Learning: Applies to pages/**/*.{js,ts,jsx,tsx} : Use getStaticPaths with getStaticProps for dynamic static generation in Pages Router
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/nextjs.mdc:0-0
Timestamp: 2025-06-30T10:31:43.578Z
Learning: Applies to app/**/*.tsx : Use redirect function for server-side redirects in Server Components
packages/clerk-js/src/utils/componentGuards.ts (3)
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/monorepo.mdc:0-0
Timestamp: 2025-06-30T10:30:56.197Z
Learning: Applies to packages/{clerk-js,elements,themes}/**/* : Visual regression testing should be performed for UI components.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/react.mdc:0-0
Timestamp: 2025-06-30T10:32:37.848Z
Learning: Applies to **/*.tsx : Use proper type guards for conditional rendering
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/monorepo.mdc:0-0
Timestamp: 2025-06-30T10:30:56.197Z
Learning: Applies to packages/clerk-react/**/*.{test,spec}.{js,ts,tsx} : Component testing should use React Testing Library.
packages/clerk-js/src/ui/components/OrganizationProfile/OrganizationProfileRoutes.tsx (7)
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/react.mdc:0-0
Timestamp: 2025-06-30T10:32:37.848Z
Learning: Applies to **/*.tsx : Use proper type guards for conditional rendering
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/monorepo.mdc:0-0
Timestamp: 2025-06-30T10:30:56.197Z
Learning: Applies to packages/clerk-react/**/*.{test,spec}.{js,ts,tsx} : Component testing should use React Testing Library.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/monorepo.mdc:0-0
Timestamp: 2025-06-30T10:30:56.197Z
Learning: Applies to packages/{clerk-js,elements,themes}/**/* : Visual regression testing should be performed for UI components.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/nextjs.mdc:0-0
Timestamp: 2025-06-30T10:31:43.578Z
Learning: Applies to app/**/page.tsx : Use page.tsx for route segments that render UI in the App Router
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/nextjs.mdc:0-0
Timestamp: 2025-06-30T10:31:43.578Z
Learning: Applies to app/**/layout.tsx : Use layout.tsx for shared UI that wraps multiple pages in the App Router
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/nextjs.mdc:0-0
Timestamp: 2025-06-30T10:31:43.578Z
Learning: Applies to pages/**/*.{js,ts,jsx,tsx} : Use SWR for client-side data fetching in Pages Router
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/react.mdc:0-0
Timestamp: 2025-06-30T10:32:37.848Z
Learning: Applies to **/*.{jsx,tsx} : Use Context API for theme/authentication
🧬 Code Graph Analysis (3)
packages/clerk-js/src/core/clerk.ts (1)
packages/clerk-js/src/utils/componentGuards.ts (1)
disabledAllBillingFeatures(33-35)
packages/clerk-js/src/ui/components/Subscriptions/SubscriptionsList.tsx (1)
packages/clerk-js/src/ui/elements/Section.tsx (1)
ProfileSection(315-323)
packages/clerk-js/src/ui/components/OrganizationProfile/OrganizationProfileRoutes.tsx (1)
packages/clerk-js/src/ui/components/OrganizationProfile/OrganizationPlansPage.tsx (1)
OrganizationPlansPage(54-60)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (5)
- GitHub Check: semgrep-cloud-platform/scan
- GitHub Check: Build Packages
- GitHub Check: Formatting | Dedupe | Changeset
- GitHub Check: semgrep/ci
- GitHub Check: Analyze (javascript-typescript)
🔇 Additional comments (23)
.changeset/public-bags-stay.md (1)
1-7: LGTM - Changeset properly documents the billing feature refactoring.The changeset correctly describes the patch-level changes to support more granular billing feature controls in UserProfile and OrgProfile components.
packages/clerk-js/src/core/clerk.ts (4)
97-97: LGTM - Import updated for granular billing feature guard.The import change correctly updates to use the new combined billing feature guard that checks both user and organization billing states.
577-586: LGTM - Checkout guard updated consistently.The billing feature check in
__internal_openCheckoutis correctly updated to use the new combined guard while maintaining the same error handling behavior.
606-615: LGTM - Plan details guard updated consistently.The billing feature check in
__internal_openPlanDetailsfollows the same pattern as the checkout method, ensuring consistent behavior across billing-related UI components.
1061-1070: LGTM - Pricing table guard updated consistently.The
mountPricingTablemethod correctly adopts the new combined billing feature guard, completing the consistent refactoring across all billing-related UI methods.packages/clerk-js/src/ui/components/Subscriptions/SubscriptionsList.tsx (2)
5-5: LGTM: Proper hook import for accessing environment settings.The addition of
useEnvironmentto access the newly structured commerce settings is correct and follows React hook patterns.
48-48: LGTM: Correct destructuring of commerce settings.The destructuring of
commerceSettingsfromuseEnvironment()is appropriate for accessing the nested billing configuration.packages/clerk-js/src/ui/utils/createCustomPages.tsx (2)
6-7: LGTM: Improved import specificity for billing feature guards.The replacement of generic billing feature guards with specific
disabledOrganizationBillingFeatureanddisabledUserBillingFeatureprovides better granularity and aligns with the overall refactoring goals.
99-101: LGTM: Correct implementation of context-specific billing feature checks.The logic properly uses the appropriate billing feature guard based on the
organizationparameter, providing better separation between user and organization billing features.packages/clerk-js/src/ui/components/UserProfile/UserProfileRoutes.tsx (2)
83-83: LGTM: Correct use of user-specific billing flag.The update to use
commerceSettings.billing.user.enabledinstead of the generic billing flag provides better granularity for user profile billing features.
91-97: LGTM: Proper conditional rendering for plans route.The nested conditional correctly renders the plans route only when
commerceSettings.billing.user.hasPaidPlansis true, ensuring users only see plan options when paid plans are available.packages/clerk-js/src/core/resources/CommerceSettings.ts (3)
14-21: LGTM: Well-structured nested billing properties.The addition of nested
organizationanduserobjects withenabledandhasPaidPlansproperties provides the granular control needed for the billing feature refactoring while maintaining a clean structure.
38-41: LGTM: Proper JSON deserialization with fallbacks.The
fromJSONmethod correctly handles the new nested properties with appropriate fallback values tofalse, ensuring robustness when properties are missing from the input data.
53-60: LGTM: Correct snapshot serialization with proper naming conversion.The
__internal_toSnapshotmethod properly converts the camelCase properties to snake_case format, maintaining consistency with the expected JSON structure.packages/types/src/commerceSettings.ts (3)
12-19: LGTM: Well-defined nested billing structure for JSON interface.The addition of nested
organizationanduserobjects withenabledandhas_paid_plansproperties to the JSON interface properly follows snake_case naming conventions and provides the granular structure needed for the billing refactoring.
29-36: LGTM: Consistent nested billing structure for Resource interface.The Resource interface correctly mirrors the JSON structure using camelCase naming conventions (
hasPaidPlansinstead ofhas_paid_plans), maintaining consistency with TypeScript conventions.
12-36: Ensure Security Review and Enforcement of Billing Access ControlsThese updates to
CommerceSettingsResource.billingmodify how billing features and plans are toggled and accessed. Please engage the Clerk security team to confirm that proper controls are in place and consider implementing the following best practices:
- Principle of Least Privilege
• Grant only the minimum access needed for billing operations (e.g., admin or billing manager roles).- Role-Based Access Control (RBAC)
• Define and enforce clear roles/permissions around viewing invoices, managing payment methods, and changing subscription plans.- Secure Feature Flags
• Store toggles in encrypted, authenticated storage.
• Enforce flags on the backend, not just in the UI.- Audit Logging
• Record every billing-related action with user identity, timestamp, and before/after state.- Protection of API Endpoints
• Require strong authentication and authorization checks (e.g., JWTs, tokens) for all billing APIs.- Data Encryption
• Use TLS for in-transit data and encrypt billing data at rest.- Input Validation
• Sanitize and validate all inputs to billing endpoints to prevent injection attacks.- Regular Security Reviews
• Conduct periodic audits and penetration tests focused on billing flows.- User Notifications
• Alert users/admins on critical events (e.g., plan changes, failed payments) to detect fraud.- Backup & Recovery
• Ensure reliable backups of billing data and tested recovery procedures.- Compliance
• Verify PCI-DSS and other relevant regulatory requirements are met.File:
packages/types/src/commerceSettings.ts
Lines: 12–36packages/clerk-js/src/utils/componentGuards.ts (6)
25-27: LGTM! Well-implemented user billing guard.The new guard correctly checks user billing status with proper optional chaining and follows the established patterns in the file.
29-31: LGTM! Consistent organization billing guard implementation.The guard correctly checks organization billing status and maintains consistency with the user billing guard pattern.
33-35: Excellent composition pattern for combined billing check.The guard correctly uses logical AND to determine if all billing features are disabled, and properly reuses existing guards following DRY principles. The logic ensures billing is only considered fully disabled when both user and organization billing are disabled.
37-39: LGTM! Correctly updated to use nested billing structure.The guard properly accesses the new nested
organization.hasPaidPlansproperty with appropriate optional chaining and fallback handling.
41-43: LGTM! Consistent with organization billing guard pattern.The guard correctly uses the new nested
user.hasPaidPlansproperty and maintains consistency with the organization billing guard implementation.
25-43: No remaining references to the olddisabledBillingFeatureguard found.A full-text search across the repository yielded zero matches for
disabledBillingFeature, confirming that all references have been updated to the new, granular billing guards. No further action is required.
| {commerceSettings.billing.organization.hasPaidPlans ? ( | ||
| <Route path='plans'> | ||
| <Suspense fallback={''}> | ||
| <OrganizationPlansPage /> | ||
| </Suspense> | ||
| </Route> | ||
| ) : null} |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Fix type safety and approve the conditional plans route logic.
The logic to conditionally render the plans route based on available paid plans is excellent and aligns with the PR objectives. However, the same type safety issue exists here with nested property access.
Apply this diff to use optional chaining:
- {commerceSettings.billing.organization.hasPaidPlans ? (
+ {commerceSettings.billing.organization?.hasPaidPlans ? (🤖 Prompt for AI Agents
In
packages/clerk-js/src/ui/components/OrganizationProfile/OrganizationProfileRoutes.tsx
around lines 99 to 105, the conditional rendering of the plans route accesses
nested properties without type safety, risking runtime errors. Fix this by using
optional chaining when accessing
commerceSettings.billing.organization.hasPaidPlans to safely handle cases where
any intermediate property might be undefined or null.
Description
Updates the logic around showing and hiding the Billing nav in the
UserProfileandOrgProfilebased on new environment settings. Also now only shows the "Switch Plans" / "Subscribe to a Plan" button on the Billing page if the respective resource has paid visible plans.Checklist
pnpm testruns as expected.pnpm buildruns as expected.Type of change
Summary by CodeRabbit
New Features
Bug Fixes
Refactor