chore(clerk-js, shared): Create experimental PaymentElement #6180
Conversation
🦋 Changeset detectedLatest commit: 02d3552 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 ↗︎
|
@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 introduces a new experimental payment element integration throughout the Clerk ecosystem, centered on Stripe payment flows. It adds an internal asynchronous method Suggested reviewers
📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
⏰ Context from checks skipped due to timeout of 90000ms (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 (
|
📝 WalkthroughWalkthroughThis change set introduces Stripe payment element integration and related infrastructure updates across several packages. It adds a new internal method, 🪧 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 (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 6
🔭 Outside diff range comments (1)
.changeset/twelve-yaks-love.md (1)
1-9: Finalize the changeset details before mergingThe changeset is marked as
wipand lacks a summary of changes/releases. Please update the description, removewip, and provide context for the minor bumps to@clerk/clerk-js,@clerk/shared,@clerk/clerk-react, and@clerk/typesto ensure proper changelog generation.
🧹 Nitpick comments (4)
packages/shared/package.json (1)
153-154: Review dependency categorization and version ranges for Stripe libraries
- Stripe libs are runtime dependencies; consider moving them from
devDependenciestopeerDependencies(ordependencies) so they’re installed by consumers.- Exact pins (
"5.6.0","3.1.1") block minor/patch upgrades—using caret ranges (^5.6.0,^3.1.1) could provide future fixes.packages/shared/src/react/hooks/usePagesOrInfinite.ts (1)
14-16: Add a meaningful description to the JSDoc block.The empty JSDoc comment should include a description of what the
getDifferentKeysfunction does./** - * + * Returns keys from obj1 that don't exist in obj2. */packages/clerk-js/rspack.config.js (1)
84-84: Clarify the TODO comment about externals configuration.The TODO comment questions whether the externals configuration is still needed. Since you're introducing dynamic Stripe library loading, consider whether this external exclusion is still necessary or if it conflicts with the new dynamic loading approach.
packages/shared/src/react/commerce.tsx (1)
92-96: Clarify the commented build flag checkThe commented code suggests uncertainty about environment support. This should be resolved before the experimental feature is used more widely.
Should this check be enabled? If so, what's the proper way to handle unsupported environments? Would you like help implementing proper environment validation?
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (14)
.changeset/twelve-yaks-love.md(1 hunks)packages/clerk-js/bundlewatch.config.json(2 hunks)packages/clerk-js/rspack.config.js(3 hunks)packages/clerk-js/src/core/clerk.ts(1 hunks)packages/clerk-js/src/ui/components/Checkout/CheckoutForm.tsx(1 hunks)packages/clerk-js/src/ui/components/PaymentSources/AddPaymentSource.tsx(5 hunks)packages/clerk-js/src/ui/components/PaymentSources/PaymentSources.tsx(1 hunks)packages/react/src/isomorphicClerk.ts(1 hunks)packages/shared/package.json(1 hunks)packages/shared/src/getEnvVariable.ts(1 hunks)packages/shared/src/react/commerce.tsx(1 hunks)packages/shared/src/react/hooks/usePagesOrInfinite.ts(3 hunks)packages/shared/src/react/index.ts(1 hunks)packages/types/src/clerk.ts(1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms (6)
- GitHub Check: semgrep-cloud-platform/scan
- GitHub Check: semgrep-cloud-platform/scan
- GitHub Check: Formatting | Dedupe | Changeset
- GitHub Check: Build Packages
- GitHub Check: semgrep/ci
- GitHub Check: Analyze (javascript-typescript)
🔇 Additional comments (14)
packages/shared/src/react/index.ts (1)
19-19: Re-export of commerce moduleThis correctly exposes the new experimental Stripe integration hooks and components. Please confirm that all newly exported symbols are covered by unit tests and documented in the public API docs.
packages/clerk-js/bundlewatch.config.json (2)
10-10: Verify new Stripe vendor chunk pattern and size limitEnsure that the
stripe-vendors*.jsoutputted byrspack.config.jsmatches this glob and that the5.54KBthreshold reflects real bundle sizes.
25-25: Adjust checkout bundle size thresholdThe
checkout*.jsmax size was increased from7.25KBto8.30KB. Confirm this change aligns with the measured bundle size post-integration to avoid unintentional size bloat.packages/shared/src/getEnvVariable.ts (1)
11-17: Consistent JSDoc formattingAdded blank line after the summary and punctuation to parameter/return descriptions improves readability.
packages/types/src/clerk.ts (1)
497-504: LGTM! Good addition for experimental Stripe integration.The new
__internal_loadStripeLibsmethod follows established patterns for internal methods and is properly documented. The method signature is appropriate for the experimental PaymentElement feature.Consider improving type safety by replacing
Promise<any>with more specific return types if the Stripe library types are available, thoughanymay be acceptable for experimental features.packages/react/src/isomorphicClerk.ts (1)
1313-1316: LGTM! Implementation follows established patterns.The
__internal_loadStripeLibsmethod implementation correctly follows the same pattern as other async methods in the class, properly waiting for ClerkJS to be ready before delegating to the underlying instance.packages/shared/src/react/hooks/usePagesOrInfinite.ts (1)
67-67: Good documentation improvements.The addition of periods to JSDoc descriptions improves consistency and readability throughout the file.
Also applies to: 71-71, 75-75, 183-183
packages/clerk-js/rspack.config.js (2)
104-108: Good separation of Stripe dependencies into dedicated chunk.The new
stripeVendorcache group properly isolates Stripe libraries (@stripe/stripe-jsand@stripe/react-stripe-js) into a separatestripe-vendorschunk. This aligns well with the dynamic loading strategy and supports optimal code splitting.
117-121: Appropriate removal of legacy paymentSources cache group.Commenting out the
paymentSourcescache group makes sense since Stripe libraries are now handled by the dedicatedstripeVendorcache group. This prevents double-bundling and maintains cleaner chunk separation.packages/clerk-js/src/ui/components/PaymentSources/PaymentSources.tsx (1)
27-29: Clean refactor of the payment source callbackThe simplified callback signature with direct context passing improves code clarity and aligns well with the new Stripe integration approach.
packages/clerk-js/src/ui/components/Checkout/CheckoutForm.tsx (1)
148-159: Good simplification of payment confirmation functionsThe removal of redundant async/await and the consolidated context handling make the code cleaner and more maintainable. The new signature with explicit
gatewayandpaymentTokenproperties is also more type-safe.packages/clerk-js/src/ui/components/PaymentSources/AddPaymentSource.tsx (1)
204-220: ```shell
#!/bin/bashLocate the definition and usages of submitPaymentElement in the codebase
rg "submitPaymentElement" -n -A5 -B5
</details> <details> <summary>packages/shared/src/react/commerce.tsx (2)</summary> `1-335`: **Well-architected Stripe integration layer** This implementation provides a clean abstraction over Stripe's SDKs with good separation of concerns: - Async loading of Stripe libraries - Proper caching with SWR - Clear context boundaries - Reusable hooks Once the identified issues are addressed, this will be a solid foundation for the payment element feature. --- `298-304`: [web_search] ```web Is confirmParams.return_url required for stripe.confirmSetup when using redirect: 'if_required' in Stripe.js v3?
packages/clerk-js/src/ui/components/PaymentSources/AddPaymentSource.tsx
Outdated
Show resolved
Hide resolved
packages/clerk-js/src/ui/components/PaymentSources/AddPaymentSource.tsx
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Actionable comments posted: 5
🧹 Nitpick comments (7)
packages/shared/src/react/hooks/usePagesOrInfinite.ts (1)
14-16: Empty JSDoc block
This JSDoc block abovegetDifferentKeysis empty. Either provide a meaningful description or remove the block to keep the code clean.packages/types/src/clerk.ts (1)
497-504: LGTM! Well-documented internal API declaration.The type declaration is properly documented and structured. The return type with separate
javascript()andreact()functions provides a clean interface for loading different Stripe libraries.Consider using more specific return types instead of
Promise<any>if the loaded library types are known, but the current approach provides flexibility for dynamic imports.packages/clerk-js/src/core/clerk.ts (1)
648-659: Consider improving return types and adding error handling.The implementation looks good overall, but there are a few areas for improvement:
- Return types: Using
unknownmakes it difficult for consumers to understand what they're getting. Consider using more specific return types.- Error handling: The dynamic imports could fail if packages aren't installed. Consider adding error handling or documenting that callers should handle import failures.
public __internal_loadStripeLibs = () => { return { - async javascript(): Promise<unknown> { + async javascript(): Promise<typeof import('@stripe/stripe-js')['loadStripe']> { const { loadStripe } = await import('@stripe/stripe-js'); return loadStripe; }, - async react(): Promise<unknown> { + async react(): Promise<{ + Elements: typeof import('@stripe/react-stripe-js')['Elements']; + PaymentElement: typeof import('@stripe/react-stripe-js')['PaymentElement']; + useElements: typeof import('@stripe/react-stripe-js')['useElements']; + useStripe: typeof import('@stripe/react-stripe-js')['useStripe']; + }> { const { Elements, PaymentElement, useElements, useStripe } = await import('@stripe/react-stripe-js'); return { Elements, PaymentElement, useElements, useStripe }; }, }; };packages/clerk-js/rspack.config.js (1)
117-121: Consider removing commented code if refactoring is complete.The commented-out
paymentSourcescache group suggests this configuration is no longer needed. If the refactoring to use the new Stripe vendor chunk is complete, consider removing this commented code to keep the configuration clean.- // paymentSources: { - // minChunks: 1, - // name: 'paymentSources', - // test: module => !!(module.resource && module.resource.includes('/ui/components/PaymentSources')), - // },packages/shared/src/react/commerce.tsx (1)
91-106: Consider adding retry logic for Stripe SDK loading.The Stripe SDK loading could fail due to network issues. Consider implementing retry logic or fallback behavior.
Consider wrapping the Stripe loading with retry logic to handle transient network failures, especially important for payment functionality.
packages/clerk-js/src/ui/components/PaymentSources/AddPaymentSource.tsx (2)
1-6: Document the experimental nature of these imports.These imports use
__experimental_prefixed exports, indicating they may change or be removed. Consider adding a comment documenting this dependency on experimental APIs.+// Note: These are experimental APIs that may change in future versions import { __experimental_PaymentElementForm as PaymentElementForm, __experimental_PaymentElementRoot as PaymentElementRoot, __experimental_usePaymentElement as usePaymentElement, createContextAndHook, } from '@clerk/shared/react';
23-47: Well-structured Stripe appearance configuration.The
useStipeAppearancehook provides a clean abstraction for translating the internal theme to Stripe's appearance variables. The use ofnormalizeColorStringensures color format compatibility.Note: There's a typo in the hook name - should be
useStripeAppearanceinstead ofuseStipeAppearance.-const useStipeAppearance = () => { +const useStripeAppearance = () => {
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (14)
.changeset/twelve-yaks-love.md(1 hunks)packages/clerk-js/bundlewatch.config.json(2 hunks)packages/clerk-js/rspack.config.js(3 hunks)packages/clerk-js/src/core/clerk.ts(1 hunks)packages/clerk-js/src/ui/components/Checkout/CheckoutForm.tsx(1 hunks)packages/clerk-js/src/ui/components/PaymentSources/AddPaymentSource.tsx(5 hunks)packages/clerk-js/src/ui/components/PaymentSources/PaymentSources.tsx(1 hunks)packages/react/src/isomorphicClerk.ts(1 hunks)packages/shared/package.json(1 hunks)packages/shared/src/getEnvVariable.ts(1 hunks)packages/shared/src/react/commerce.tsx(1 hunks)packages/shared/src/react/hooks/usePagesOrInfinite.ts(3 hunks)packages/shared/src/react/index.ts(1 hunks)packages/types/src/clerk.ts(1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms (23)
- GitHub Check: Integration Tests (nextjs, chrome, 15)
- GitHub Check: Integration Tests (react-router, chrome)
- GitHub Check: Integration Tests (nextjs, chrome, 14)
- GitHub Check: Integration Tests (billing, chrome)
- GitHub Check: Integration Tests (nextjs, chrome, 13)
- GitHub Check: Integration Tests (ap-flows, chrome)
- GitHub Check: Integration Tests (nuxt, chrome)
- GitHub Check: Integration Tests (vue, chrome)
- GitHub Check: Integration Tests (tanstack-react-router, chrome)
- GitHub Check: Integration Tests (localhost, chrome)
- GitHub Check: Integration Tests (tanstack-react-start, chrome)
- GitHub Check: Integration Tests (astro, chrome)
- GitHub Check: Integration Tests (expo-web, chrome)
- GitHub Check: Integration Tests (generic, chrome)
- GitHub Check: Integration Tests (elements, chrome)
- GitHub Check: Integration Tests (sessions, chrome)
- GitHub Check: Integration Tests (quickstart, chrome)
- GitHub Check: Integration Tests (express, chrome)
- GitHub Check: Publish with pkg-pr-new
- GitHub Check: Static analysis
- GitHub Check: semgrep-cloud-platform/scan
- GitHub Check: semgrep-cloud-platform/scan
- GitHub Check: Analyze (javascript-typescript)
🔇 Additional comments (14)
packages/shared/src/react/hooks/usePagesOrInfinite.ts (3)
67-68: JSDoc punctuation update
Added a period at the end of the parameter description. No issues.
71-72: JSDoc punctuation update
Added a period at the end of the function description. Approved.
183-184: JSDoc punctuation update
Adjusted the helper section comment to include a period. Looks good.packages/clerk-js/bundlewatch.config.json (2)
10-10: Approve addition of Stripe vendor chunk
The newstripe-vendors*.jsentry aligns with the updated Rspack cache group for Stripe dependencies.
25-25: Approve checkout bundle size bump
The increasedmaxSizeforcheckout*.jsreflects the added PaymentElement code and is expected.packages/shared/src/getEnvVariable.ts (1)
13-16: JSDoc formatting update
Added trailing periods and an extra blank line for better readability. No functional changes.packages/shared/src/react/index.ts (1)
19-19: LGTM! Clean module export addition.The new export statement properly extends the public API to include commerce functionality and follows the established pattern in this file.
packages/react/src/isomorphicClerk.ts (1)
1313-1316: LGTM! Implementation follows established patterns.The new method correctly follows the async delegation pattern used throughout this class, appropriately waits for ClerkJS to be ready, and maintains consistency with other internal methods.
packages/clerk-js/rspack.config.js (2)
104-108: Good approach to separate Stripe vendor chunking.The new
stripeVendorcache group properly isolates Stripe dependencies into their own chunk, which aligns well with the dynamic loading strategy introduced in the Clerk class.
84-85: ```shell
#!/bin/bashDisplay the remainder of rspack.config.js to see how disableRHC is applied
FILE="packages/clerk-js/rspack.config.js"
echo "Lines 110 to end of $FILE:"
sed -n '110,$p' "$FILE"</details> <details> <summary>packages/clerk-js/src/ui/components/PaymentSources/PaymentSources.tsx (1)</summary> `27-29`: Let’s confirm that `PaymentGateway` includes `"stripe"`: ```shell #!/bin/bash # Locate PaymentGateway definition to verify valid values rg -n "export type PaymentGateway" -A 5 -B 3 packages/types/src/commerce.tspackages/clerk-js/src/ui/components/Checkout/CheckoutForm.tsx (1)
148-159: Consider the error handling implications of removing async/await.The change from async/await to directly returning promises is functionally equivalent, but it subtly changes error propagation. Errors will now be promise rejections rather than thrown exceptions. This is fine as long as all callers properly handle promise rejections.
The simplified parameter format for
addPaymentSourceAndPayaligns well with the new payment token abstraction.packages/shared/src/react/commerce.tsx (1)
269-282: Verify the management URL for Apple Pay recurring payments.The TODO comment questions whether
homeUrlis the correct management URL. This URL is important for Apple Pay users to manage their subscriptions.What is the correct managementURL property for Apple Pay recurring payment requests in Stripe?packages/clerk-js/src/ui/components/PaymentSources/AddPaymentSource.tsx (1)
204-212: ```shell
#!/bin/bashList immediate contents of packages/shared to locate the react module
ls packages/shared
</details> </blockquote></details> </details> <!-- This is an auto-generated comment by CodeRabbit for review status -->
| "@stripe/react-stripe-js": "3.1.1", | ||
| "@stripe/stripe-js": "5.6.0", |
There was a problem hiding this comment.
Move Stripe packages to peerDependencies
Stripe libraries are required at runtime by the exported React commerce hooks/components. They should be declared under peerDependencies (or dependencies) instead of devDependencies.
--- a/packages/shared/package.json
+++ b/packages/shared/package.json
@@ -152,8 +152,6 @@
"devDependencies": {
- "@stripe/react-stripe-js": "3.1.1",
- "@stripe/stripe-js": "5.6.0",
"@types/glob-to-regexp": "0.4.4",
"cross-fetch": "^4.0.0",
"esbuild": "0.25.0"
@@ -179,6 +177,12 @@
"publishConfig": {
"access": "public"
},
+ "peerDependencies": {
+ "@stripe/react-stripe-js": "3.1.1",
+ "@stripe/stripe-js": "5.6.0"
+ }
}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| "@stripe/react-stripe-js": "3.1.1", | |
| "@stripe/stripe-js": "5.6.0", | |
| "devDependencies": { | |
| "@types/glob-to-regexp": "0.4.4", | |
| "cross-fetch": "^4.0.0", | |
| "esbuild": "0.25.0" | |
| }, | |
| "publishConfig": { | |
| "access": "public" | |
| }, | |
| "peerDependencies": { | |
| "@stripe/react-stripe-js": "3.1.1", | |
| "@stripe/stripe-js": "5.6.0" | |
| } |
🤖 Prompt for AI Agents
In packages/shared/package.json around lines 153 to 154, the Stripe packages
"@stripe/react-stripe-js" and "@stripe/stripe-js" are currently listed under
devDependencies but are needed at runtime by exported React commerce
hooks/components. Move these two packages from devDependencies to
peerDependencies to correctly indicate they are required by consumers of the
package at runtime.
There was a problem hiding this comment.
They are used only for their types during dev, does this changes things ?
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Search for all imports of Stripe packages in the shared package to understand usage patterns
echo "=== Searching for Stripe package imports in packages/shared ==="
rg '@stripe/' packages/shared/src/ -A 2 -B 1
echo -e "\n=== Checking for type-only imports ==="
rg 'import\s+type.*@stripe/' packages/shared/src/
echo -e "\n=== Checking for runtime imports ==="
rg 'import.*@stripe/' packages/shared/src/ | grep -v 'import type'
echo -e "\n=== Checking for actual usage of Stripe objects (not just types) ==="
rg 'useStripe|useElements|Elements|PaymentElement|loadStripe' packages/shared/src/ -A 1 -B 1
Length of output: 19610
@panteliselef You're partially correct! Looking at the code, I can see there are indeed type-only imports like:
import type { StripeElement } from '@stripe/stripe-js';
import type { ElementProps, PaymentElementProps } from '@stripe/react-stripe-js';However, the situation is more nuanced. While the packages are imported for types during development, the @clerk/shared package exports experimental React components and hooks (__experimental_PaymentElementRoot, __experimental_PaymentElementForm, __experimental_usePaymentElement) that provide a complete Stripe Elements integration.
These exported components implement their own Elements, useElements, useStripe, and PaymentElement - essentially creating a runtime dependency for consumers who use these experimental features.
Even though Stripe libraries are loaded dynamically via clerk.__internal_loadStripeJs(), consumers of your experimental payment components will still need these Stripe packages available in their environment at runtime.
Recommendation: Keep them as peerDependencies with optional: true in peerDependenciesMeta. This approach:
- Indicates they're needed at runtime for the experimental features
- Doesn't force installation for consumers who don't use the payment features
- Provides clear guidance when consumers do use the experimental payment components
"peerDependencies": {
"@stripe/react-stripe-js": "3.1.1",
"@stripe/stripe-js": "5.6.0"
},
"peerDependenciesMeta": {
"@stripe/react-stripe-js": { "optional": true },
"@stripe/stripe-js": { "optional": true }
}🧠 Learnings used
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/monorepo.mdc:0-0
Timestamp: 2025-06-23T12:25:40.214Z
Learning: Framework packages depend on @clerk/clerk-js for core functionality, while @clerk/shared and @clerk/types provide common utilities and TypeScript definitions used across packages.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/global.mdc:0-0
Timestamp: 2025-06-23T12:25:34.662Z
Learning: Node.js is required for all development and build tasks in the repository.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/monorepo.mdc:0-0
Timestamp: 2025-06-23T12:25:40.214Z
Learning: The monorepo uses pnpm as the package manager and Turbo for build orchestration, which enables efficient dependency management and caching across multiple packages.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/global.mdc:0-0
Timestamp: 2025-06-23T12:25:34.662Z
Learning: The monorepo uses pnpm as the package manager, and all contributors should use pnpm for dependency management and scripts.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/typescript.mdc:0-0
Timestamp: 2025-06-23T12:26:09.855Z
Learning: Avoid barrel files (index.ts re-exports) as they can introduce circular dependencies; instead, import directly from modules.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/typescript.mdc:0-0
Timestamp: 2025-06-23T12:26:09.855Z
Learning: Follow a performance checklist: use type-only imports, ensure exports are tree-shaking friendly, avoid circular dependencies, and keep type computations efficient.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/monorepo.mdc:0-0
Timestamp: 2025-06-23T12:25:40.214Z
Learning: All packages are published under the @clerk namespace on npm, ensuring consistent naming and discoverability.
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: 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: CR
PR: clerk/javascript#0
File: .cursor/rules/global.mdc:0-0
Timestamp: 2025-06-23T12:25:34.662Z
Learning: All packages published from this repository must use the @clerk namespace.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/monorepo.mdc:0-0
Timestamp: 2025-06-23T12:25:40.214Z
Learning: Environment variables prefixed with CLERK_* and NEXT_PUBLIC_CLERK_* are supported for configuration across different environments.
| @@ -21,8 +22,7 @@ | |||
| { "path": "./dist/waitlist*.js", "maxSize": "1.5KB" }, | |||
| { "path": "./dist/keylessPrompt*.js", "maxSize": "6.5KB" }, | |||
| { "path": "./dist/pricingTable*.js", "maxSize": "4.02KB" }, | |||
| { "path": "./dist/checkout*.js", "maxSize": "7.25KB" }, | |||
| { "path": "./dist/paymentSources*.js", "maxSize": "9.17KB" }, | |||
| { "path": "./dist/checkout*.js", "maxSize": "8.30KB" }, | |||
There was a problem hiding this comment.
Removing the chunk for paymentSources, increases the chunk for checkout as some of the code is now in that chunk.
packages/clerk-js/src/ui/components/PaymentSources/AddPaymentSource.tsx
Outdated
Show resolved
Hide resolved
…lities # Conflicts: # packages/clerk-js/bundlewatch.config.json # packages/clerk-js/src/ui/components/PaymentSources/PaymentSources.tsx # packages/shared/src/react/hooks/usePagesOrInfinite.ts
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
package.json (2)
36-36: NarrowingE2E_APP_IDreduces billing-flow coverageChanging
E2E_APP_ID=withBilling.*→E2E_APP_ID=withBilling.next.appRouterconfines thetest:integration:billingscript to a single demo app. Any billing examples for other frameworks (e.g. Remix, Vite, Astro) will now be skipped, so regressions in those flows could slip through CI.If the intent was only to stabilise a flaky target, consider parameterising instead of hard-coding:
-E2E_APP_ID=withBilling.next.appRouter +# Runs Next.js by default; allow override +E2E_APP_ID=${E2E_APP_ID:-withBilling.*}or enumerate multiple IDs with a comma-separated list (
withBilling.next.appRouter,withBilling.remix.*, etc.).
46-48: Inconsistent package-manager invocationScripts
test:integration:nuxt(l 46) andtest:integration:react-router(l 48) still callnpm run …while every other script usespnpm. Mixing runners can bypass PNPM-specific features (e.g. workspace linking) and produce divergent lock-file resolution.- "test:integration:nuxt": "E2E_APP_ID=nuxt.node npm run test:integration:base -- --grep @nuxt", + "test:integration:nuxt": "E2E_APP_ID=nuxt.node pnpm test:integration:base --grep @nuxt",Same adjustment for
react-router.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (3)
packages/react-router/src/__tests__/__snapshots__/exports.test.ts.snapis excluded by!**/*.snappackages/remix/src/__tests__/__snapshots__/exports.test.ts.snapis excluded by!**/*.snappackages/tanstack-react-start/src/__tests__/__snapshots__/exports.test.ts.snapis excluded by!**/*.snap
📒 Files selected for processing (3)
package.json(1 hunks)packages/chrome-extension/src/index.ts(1 hunks)packages/chrome-extension/src/react/re-exports.ts(1 hunks)
✅ Files skipped from review due to trivial changes (1)
- packages/chrome-extension/src/react/re-exports.ts
🧰 Additional context used
📓 Path-based instructions (5)
`**/*.{js,ts,tsx,jsx}`: All code must pass ESLint checks with the project's configuration. Use Prettier for consistent code formatting.
**/*.{js,ts,tsx,jsx}: All code must pass ESLint checks with the project's configuration.
Use Prettier for consistent code formatting.
📄 Source: CodeRabbit Inference Engine (.cursor/rules/development.mdc)
List of files the instruction was applied to:
packages/chrome-extension/src/index.ts
`**/*.{ts,tsx}`: Maintain comprehensive JSDoc comments for public APIs.
**/*.{ts,tsx}: Maintain comprehensive JSDoc comments for public APIs.
📄 Source: CodeRabbit Inference Engine (.cursor/rules/development.mdc)
List of files the instruction was applied to:
packages/chrome-extension/src/index.ts
`packages/**`: All publishable packages under the @clerk namespace must be located in the packages/ directory.
packages/**: All publishable packages under the @clerk namespace must be located in the packages/ directory.
📄 Source: CodeRabbit Inference Engine (.cursor/rules/global.mdc)
List of files the instruction was applied to:
packages/chrome-extension/src/index.ts
`**/index.ts`: Use index.ts files for clean imports but avoid deep barrel exports.
**/index.ts: Use index.ts files for clean imports but avoid deep barrel exports.
📄 Source: CodeRabbit Inference Engine (.cursor/rules/react.mdc)
List of files the instruction was applied to:
packages/chrome-extension/src/index.ts
`**/*.ts`: Always define explicit return types for functions, especially public ...
**/*.ts: Always define explicit return types for functions, especially public APIs.
Use proper type annotations for variables and parameters where inference isn't clear.
Avoidanytype; preferunknownwhen type is uncertain, then narrow with type guards.
Useinterfacefor object shapes that might be extended; usetypefor unions, primitives, and computed types.
Preferreadonlyproperties for immutable data structures.
Useprivatefor internal implementation details,protectedfor inheritance, andpublicexplicitly for clarity in public APIs.
Prefer composition and interfaces over deep inheritance chains; use mixins for shared behavior.
Use ES6 imports/exports consistently; avoid barrel files (index.ts re-exports) to prevent circular dependencies.
Use type-only imports (import type { ... }) where possible.
Useas constfor literal types and thesatisfiesoperator for type checking without widening.
Enable--incrementaland--tsBuildInfoFilefor faster builds.
Use ESLint with @typescript-eslint/recommended rules and Prettier for formatting.
Use lint-staged and Husky for pre-commit checks.
Use type-coverage to measure type safety.
📄 Source: CodeRabbit Inference Engine (.cursor/rules/typescript.mdc)
List of files the instruction was applied to:
packages/chrome-extension/src/index.ts
🧠 Learnings (3)
📓 Common learnings
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-23T12:25:40.214Z
Learning: Each framework integration package (e.g., @clerk/nextjs, @clerk/clerk-react, @clerk/vue) is designed to provide idiomatic support for its respective framework.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/monorepo.mdc:0-0
Timestamp: 2025-06-23T12:25:40.214Z
Learning: Framework packages depend on @clerk/clerk-js for core functionality, while @clerk/shared and @clerk/types provide common utilities and TypeScript definitions used across packages.
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: CR
PR: clerk/javascript#0
File: .cursor/rules/monorepo.mdc:0-0
Timestamp: 2025-06-23T12:25:40.214Z
Learning: Environment variables prefixed with CLERK_* and NEXT_PUBLIC_CLERK_* are supported for configuration across different environments.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/monorepo.mdc:0-0
Timestamp: 2025-06-23T12:25:40.214Z
Learning: All packages are published under the @clerk namespace on npm, ensuring consistent naming and discoverability.
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.
package.json (4)
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/monorepo.mdc:0-0
Timestamp: 2025-06-23T12:25:40.214Z
Learning: Unit tests are run with Jest and Vitest, integration tests with Playwright, and component testing with React Testing Library, demonstrating a layered testing strategy.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/development.mdc:0-0
Timestamp: 2025-06-23T12:25:30.457Z
Learning: Use Jest for unit testing and React Testing Library for component testing; use Playwright for end-to-end integration tests.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/global.mdc:0-0
Timestamp: 2025-06-23T12:25:34.662Z
Learning: The monorepo uses pnpm as the package manager, and all contributors should use pnpm for dependency management and scripts.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/global.mdc:0-0
Timestamp: 2025-06-23T12:25:34.662Z
Learning: Comprehensive testing is enforced, including unit, integration, and E2E tests, to ensure code quality across supported frameworks and platforms.
packages/chrome-extension/src/index.ts (13)
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/typescript.mdc:0-0
Timestamp: 2025-06-23T12:26:09.855Z
Learning: Avoid barrel files (index.ts re-exports) as they can introduce circular dependencies; instead, import directly from modules.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/react.mdc:0-0
Timestamp: 2025-06-23T12:25:57.184Z
Learning: Use index.ts files for clean imports, but avoid deep barrel exports to prevent import cycles and maintain clarity.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/monorepo.mdc:0-0
Timestamp: 2025-06-23T12:25:40.214Z
Learning: Framework packages depend on @clerk/clerk-js for core functionality, while @clerk/shared and @clerk/types provide common utilities and TypeScript definitions used across packages.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/react.mdc:0-0
Timestamp: 2025-06-23T12:25:57.184Z
Learning: Export React components as named exports in .jsx or .tsx files to enable better tree-shaking and optimize bundle size.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/typescript.mdc:0-0
Timestamp: 2025-06-23T12:26:09.855Z
Learning: Use ES6 module syntax (import/export) consistently for maintainability and compatibility.
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/monorepo.mdc:0-0
Timestamp: 2025-06-23T12:25:40.214Z
Learning: All packages are published under the @clerk namespace on npm, ensuring consistent naming and discoverability.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/typescript.mdc:0-0
Timestamp: 2025-06-23T12:26:09.855Z
Learning: Use type-only imports (import type { ... }) to optimize performance and avoid unnecessary code inclusion.
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/global.mdc:0-0
Timestamp: 2025-06-23T12:25:34.662Z
Learning: All packages published from this repository must use the @clerk namespace.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/monorepo.mdc:0-0
Timestamp: 2025-06-23T12:25:40.214Z
Learning: Each framework integration package (e.g., @clerk/nextjs, @clerk/clerk-react, @clerk/vue) is designed to provide idiomatic support for its respective framework.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/typescript.mdc:0-0
Timestamp: 2025-06-23T12:26:09.855Z
Learning: Follow a performance checklist: use type-only imports, ensure exports are tree-shaking friendly, avoid circular dependencies, and keep type computations efficient.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/monorepo.mdc:0-0
Timestamp: 2025-06-23T12:25:40.214Z
Learning: Backend utilities are isolated in @clerk/backend, which is independent and used for server-side operations.
⏰ Context from checks skipped due to timeout of 90000ms (5)
- GitHub Check: semgrep-cloud-platform/scan
- GitHub Check: Formatting | Dedupe | Changeset
- GitHub Check: Build Packages
- GitHub Check: semgrep/ci
- GitHub Check: Analyze (javascript-typescript)
🔇 Additional comments (1)
packages/chrome-extension/src/index.ts (1)
1-1: ```bash
#!/bin/bashVerify the local react/index.ts exports to confirm component overrides
if [ -f "packages/chrome-extension/src/react/index.ts" ]; then
echo "=== packages/chrome-extension/src/react/index.ts ==="
sed -n '1,200p' packages/chrome-extension/src/react/index.ts
else
echo "✗ File not found: packages/chrome-extension/src/react/index.ts"
echo "Searching for index.ts in react directory:"
fd "index.ts" packages/chrome-extension/src/react/
fi</details> </blockquote></details> </details> <!-- This is an auto-generated comment by CodeRabbit for review status -->
There was a problem hiding this comment.
Actionable comments posted: 2
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (5)
.changeset/eleven-days-sniff.md(1 hunks).changeset/great-bees-teach.md(1 hunks).changeset/many-mirrors-vanish.md(1 hunks)integration/tests/pricing-table.test.ts(1 hunks)packages/testing/src/playwright/unstable/page-objects/checkout.ts(1 hunks)
✅ Files skipped from review due to trivial changes (2)
- .changeset/great-bees-teach.md
- .changeset/many-mirrors-vanish.md
🧰 Additional context used
📓 Path-based instructions (6)
`**/*.{js,ts,tsx,jsx}`: All code must pass ESLint checks with the project's configuration. Use Prettier for consistent code formatting.
**/*.{js,ts,tsx,jsx}: All code must pass ESLint checks with the project's configuration.
Use Prettier for consistent code formatting.
📄 Source: CodeRabbit Inference Engine (.cursor/rules/development.mdc)
List of files the instruction was applied to:
packages/testing/src/playwright/unstable/page-objects/checkout.tsintegration/tests/pricing-table.test.ts
`**/*.{ts,tsx}`: Maintain comprehensive JSDoc comments for public APIs.
**/*.{ts,tsx}: Maintain comprehensive JSDoc comments for public APIs.
📄 Source: CodeRabbit Inference Engine (.cursor/rules/development.mdc)
List of files the instruction was applied to:
packages/testing/src/playwright/unstable/page-objects/checkout.tsintegration/tests/pricing-table.test.ts
`packages/**`: All publishable packages under the @clerk namespace must be located in the packages/ directory.
packages/**: All publishable packages under the @clerk namespace must be located in the packages/ directory.
📄 Source: CodeRabbit Inference Engine (.cursor/rules/global.mdc)
List of files the instruction was applied to:
packages/testing/src/playwright/unstable/page-objects/checkout.ts
`**/*.ts`: Always define explicit return types for functions, especially public ...
**/*.ts: Always define explicit return types for functions, especially public APIs.
Use proper type annotations for variables and parameters where inference isn't clear.
Avoidanytype; preferunknownwhen type is uncertain, then narrow with type guards.
Useinterfacefor object shapes that might be extended; usetypefor unions, primitives, and computed types.
Preferreadonlyproperties for immutable data structures.
Useprivatefor internal implementation details,protectedfor inheritance, andpublicexplicitly for clarity in public APIs.
Prefer composition and interfaces over deep inheritance chains; use mixins for shared behavior.
Use ES6 imports/exports consistently; avoid barrel files (index.ts re-exports) to prevent circular dependencies.
Use type-only imports (import type { ... }) where possible.
Useas constfor literal types and thesatisfiesoperator for type checking without widening.
Enable--incrementaland--tsBuildInfoFilefor faster builds.
Use ESLint with @typescript-eslint/recommended rules and Prettier for formatting.
Use lint-staged and Husky for pre-commit checks.
Use type-coverage to measure type safety.
📄 Source: CodeRabbit Inference Engine (.cursor/rules/typescript.mdc)
List of files the instruction was applied to:
packages/testing/src/playwright/unstable/page-objects/checkout.tsintegration/tests/pricing-table.test.ts
`**/*.{test,spec}.{js,ts,tsx,jsx}`: Unit tests are required for all new functionality.
**/*.{test,spec}.{js,ts,tsx,jsx}: Unit tests are required for all new functionality.
📄 Source: CodeRabbit Inference Engine (.cursor/rules/development.mdc)
List of files the instruction was applied to:
integration/tests/pricing-table.test.ts
`integration/**`: Framework integration templates and E2E tests must be placed in the integration/ directory.
integration/**: Framework integration templates and E2E tests must be placed in the integration/ directory.
📄 Source: CodeRabbit Inference Engine (.cursor/rules/global.mdc)
List of files the instruction was applied to:
integration/tests/pricing-table.test.ts
🧠 Learnings (3)
📓 Common learnings
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-23T12:25:40.214Z
Learning: Framework packages depend on @clerk/clerk-js for core functionality, while @clerk/shared and @clerk/types provide common utilities and TypeScript definitions used across packages.
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: CR
PR: clerk/javascript#0
File: .cursor/rules/monorepo.mdc:0-0
Timestamp: 2025-06-23T12:25:40.214Z
Learning: Each framework integration package (e.g., @clerk/nextjs, @clerk/clerk-react, @clerk/vue) is designed to provide idiomatic support for its respective framework.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/monorepo.mdc:0-0
Timestamp: 2025-06-23T12:25:40.214Z
Learning: Environment variables prefixed with CLERK_* and NEXT_PUBLIC_CLERK_* are supported for configuration across different environments.
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/monorepo.mdc:0-0
Timestamp: 2025-06-23T12:25:40.214Z
Learning: All packages are published under the @clerk namespace on npm, ensuring consistent naming and discoverability.
.changeset/eleven-days-sniff.md (2)
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: 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.
integration/tests/pricing-table.test.ts (1)
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/monorepo.mdc:0-0
Timestamp: 2025-06-23T12:25:40.214Z
Learning: Unit tests are run with Jest and Vitest, integration tests with Playwright, and component testing with React Testing Library, demonstrating a layered testing strategy.
⏰ Context from checks skipped due to timeout of 90000ms (24)
- GitHub Check: Integration Tests (nextjs, chrome, 15)
- GitHub Check: Integration Tests (tanstack-react-start, chrome)
- GitHub Check: Integration Tests (vue, chrome)
- GitHub Check: Integration Tests (tanstack-react-router, chrome)
- GitHub Check: Integration Tests (elements, chrome)
- GitHub Check: Integration Tests (nextjs, chrome, 13)
- GitHub Check: Integration Tests (react-router, chrome)
- GitHub Check: Integration Tests (nextjs, chrome, 14)
- GitHub Check: Integration Tests (billing, chrome)
- GitHub Check: Integration Tests (nuxt, chrome)
- GitHub Check: Integration Tests (astro, chrome)
- GitHub Check: Integration Tests (quickstart, chrome)
- GitHub Check: Integration Tests (expo-web, chrome)
- GitHub Check: Integration Tests (sessions, chrome)
- GitHub Check: Integration Tests (localhost, chrome)
- GitHub Check: Integration Tests (ap-flows, chrome)
- GitHub Check: Integration Tests (generic, chrome)
- GitHub Check: Integration Tests (express, chrome)
- GitHub Check: Unit Tests (18, --filter=@clerk/astro --filter=@clerk/backend --filter=@clerk/express --filter=@c...
- GitHub Check: Unit Tests (22, **)
- GitHub Check: Static analysis
- GitHub Check: Publish with pkg-pr-new
- GitHub Check: semgrep-cloud-platform/scan
- GitHub Check: Analyze (javascript-typescript)
🔇 Additional comments (1)
.changeset/eleven-days-sniff.md (1)
5-5: Verify method name consistency in changeset description.The changeset description refers to
waitForStripeElementsbut the actual implementation useswaitForStipeElements(missing 'r'). Ensure the method name in the description matches the actual implementation.#!/bin/bash # Description: Check the actual method name used in the testing package # Expected: Should find either waitForStripeElements or waitForStipeElements consistently echo "Searching for method name in testing package:" rg "waitFor.*Elements" packages/testing/
packages/testing/src/playwright/unstable/page-objects/checkout.ts
Outdated
Show resolved
Hide resolved
…lities # Conflicts: # integration/tests/pricing-table.test.ts # packages/testing/src/playwright/unstable/page-objects/checkout.ts
| ? { | ||
| recurringPaymentRequest: { | ||
| paymentDescription: paymentDescription || '', | ||
| managementURL: environment?.displayConfig.homeUrl || '', // TODO(@COMMERCE): is this the right URL? |
There was a problem hiding this comment.
❓ do we need a ticket to make sure we find the right value here?
There was a problem hiding this comment.
No need, this is already address from an already merged PR, now that i've merged from main, it is fixed.
We are now doing
managementURL:
subscriberType === 'org'
? environment?.displayConfig.organizationProfileUrl || ''
: environment?.displayConfig.userProfileUrl || '',…lities # Conflicts: # packages/clerk-js/bundlewatch.config.json # packages/clerk-js/src/ui/components/PaymentSources/AddPaymentSource.tsx
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (1)
packages/shared/src/react/stripe-react/index.tsx (1)
247-290: Consider using a battle-tested deep equality library.While the custom
isEqualimplementation is correct for simple objects, it doesn't handle edge cases like circular references. For production reliability, consider using a well-tested library.Consider replacing the custom implementation with a proven library:
import isEqual from 'lodash.isequal';Or if you prefer to keep it lightweight, at least add a check for circular references to prevent potential stack overflow errors in edge cases.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (6)
packages/clerk-js/bundlewatch.config.json(2 hunks)packages/clerk-js/package.json(0 hunks)packages/shared/package.json(1 hunks)packages/shared/src/react/commerce.tsx(1 hunks)packages/shared/src/react/stripe-react/index.tsx(1 hunks)packages/shared/src/react/stripe-react/utils.ts(1 hunks)
💤 Files with no reviewable changes (1)
- packages/clerk-js/package.json
🚧 Files skipped from review as they are similar to previous changes (3)
- packages/shared/package.json
- packages/clerk-js/bundlewatch.config.json
- packages/shared/src/react/commerce.tsx
🧰 Additional context used
📓 Path-based instructions (8)
`**/*.{js,jsx,ts,tsx}`: All code must pass ESLint checks with the project's conf...
**/*.{js,jsx,ts,tsx}: All code must pass ESLint checks with the project's configuration
Use Prettier for consistent code formatting
Follow established naming conventions (PascalCase for components, camelCase for variables)
Maintain comprehensive JSDoc comments for public APIs
Use dynamic imports for optional features
All public APIs must be documented with JSDoc
Lazy load components and features when possible
Implement proper caching strategies
Use efficient data structures and algorithms
Validate all inputs and sanitize outputs
Implement proper logging with different levels
📄 Source: CodeRabbit Inference Engine (.cursor/rules/development.mdc)
List of files the instruction was applied to:
packages/shared/src/react/stripe-react/utils.tspackages/shared/src/react/stripe-react/index.tsx
`packages/**/*.ts`: TypeScript is required for all packages
packages/**/*.ts: TypeScript is required for all packages
📄 Source: CodeRabbit Inference Engine (.cursor/rules/development.mdc)
List of files the instruction was applied to:
packages/shared/src/react/stripe-react/utils.ts
`packages/**/*.{ts,tsx,d.ts}`: Packages should export TypeScript types alongside runtime code
packages/**/*.{ts,tsx,d.ts}: Packages should export TypeScript types alongside runtime code
📄 Source: CodeRabbit Inference Engine (.cursor/rules/development.mdc)
List of files the instruction was applied to:
packages/shared/src/react/stripe-react/utils.tspackages/shared/src/react/stripe-react/index.tsx
`**/*.{ts,tsx}`: Use proper TypeScript error types
**/*.{ts,tsx}: Use proper TypeScript error types
📄 Source: CodeRabbit Inference Engine (.cursor/rules/development.mdc)
List of files the instruction was applied to:
packages/shared/src/react/stripe-react/utils.tspackages/shared/src/react/stripe-react/index.tsx
`**/*.{ts,tsx}`: Always define explicit return types for functions, especially p...
**/*.{ts,tsx}: Always define explicit return types for functions, especially public APIs
Use proper type annotations for variables and parameters where inference isn't clear
Avoidanytype - preferunknownwhen type is uncertain, then narrow with type guards
Useinterfacefor object shapes that might be extended
Usetypefor unions, primitives, and computed types
Preferreadonlyproperties for immutable data structures
Useprivatefor internal implementation details
Useprotectedfor inheritance hierarchies
Usepublicexplicitly for clarity in public APIs
Preferreadonlyfor properties that shouldn't change after construction
Use mapped types for transforming object types
Use conditional types for type-level logic
Leverage template literal types for string manipulation
Use ES6 imports/exports consistently
Use default exports sparingly, prefer named exports
Document public functions and APIs with JSDoc-style comments including @param, @returns, @throws, and @example
Define custom error classes for domain-specific errors
Use the Result pattern for error handling instead of throwing exceptions
Use optional chaining and nullish coalescing for safe property access
Let TypeScript infer types when types are obvious
Useconst assertionsfor literal types:as const
Usesatisfiesoperator for type checking without widening
Use readonly arrays and objects for immutability
Use immutable update patterns (spread, etc.) for objects and arrays
Use lazy loading for large types
Preferunknownoveranyfor performance
Use type-only imports:import type { ... }
Use branded types for domain safety
Noanytypes without justification
Proper error handling with typed errors
Consistent use ofreadonlyfor immutable data
Proper generic constraints in TypeScript generics
No unused type parameters in generics
Proper use of utility types instead of manual type construction
Type-only imports where possible for performance
Proper tree-shaking friendly exports
No circular dependencies
Efficient type computations (avoid deep recursion)
📄 Source: CodeRabbit Inference Engine (.cursor/rules/typescript.mdc)
List of files the instruction was applied to:
packages/shared/src/react/stripe-react/utils.tspackages/shared/src/react/stripe-react/index.tsx
`**/*.{tsx,jsx}`: Use error boundaries in React components Minimize re-renders in React components
**/*.{tsx,jsx}: Use error boundaries in React components
Minimize re-renders in React components
📄 Source: CodeRabbit Inference Engine (.cursor/rules/development.mdc)
List of files the instruction was applied to:
packages/shared/src/react/stripe-react/index.tsx
`**/*.{jsx,tsx}`: Always use functional components with hooks instead of class c...
**/*.{jsx,tsx}: Always use functional components with hooks instead of class components
Follow PascalCase naming for components:UserProfile,NavigationMenu
Keep components focused on a single responsibility - split large components
Limit component size to 150-200 lines; extract logic into custom hooks
Use composition over inheritance - prefer smaller, composable components
Export components as named exports for better tree-shaking
One component per file with matching filename and component name
Use useState for simple state management
Use useReducer for complex state logic
Implement proper state initialization
Use proper state updates with callbacks
Implement proper state cleanup
Use Context API for theme/authentication
Implement proper state selectors
Use proper state normalization
Implement proper state persistence
Use React.memo for expensive components
Implement proper useCallback for handlers
Use proper useMemo for expensive computations
Implement proper virtualization for lists
Use proper code splitting with React.lazy
Implement proper cleanup in useEffect
Use proper refs for DOM access
Implement proper event listener cleanup
Use proper abort controllers for fetch
Implement proper subscription cleanup
Use proper HTML elements
Implement proper ARIA attributes
Use proper heading hierarchy
Implement proper form labels
Use proper button types
Implement proper focus management
Use proper keyboard shortcuts
Implement proper tab order
Use proper skip links
Implement proper focus traps
Implement proper error boundaries
Use proper error logging
Implement proper error recovery
Use proper error messages
Implement proper error fallbacks
Use proper form validation
Implement proper error states
Use proper error messages
Implement proper form submission
Use proper form reset
Use proper component naming
Implement proper file naming
Use proper prop naming
Implement proper state naming
Use proper handler naming
Implement proper component structure
Use proper hook structure
📄 Source: CodeRabbit Inference Engine (.cursor/rules/react.mdc)
List of files the instruction was applied to:
packages/shared/src/react/stripe-react/index.tsx
`**/*.tsx`: Use proper type definitions for props and state Leverage TypeScript'...
**/*.tsx: Use proper type definitions for props and state
Leverage TypeScript's type inference where possible
Use proper event types for handlers
Implement proper generic types for reusable components
Use proper type guards for conditional rendering
📄 Source: CodeRabbit Inference Engine (.cursor/rules/react.mdc)
List of files the instruction was applied to:
packages/shared/src/react/stripe-react/index.tsx
🧠 Learnings (3)
📓 Common learnings
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/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: 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: 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.
packages/shared/src/react/stripe-react/utils.ts (15)
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/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 **/*.tsx : Use proper type definitions for props and state
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 useState for simple state management
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: 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 event types for handlers
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: 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 persistence
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 naming
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/development.mdc:0-0
Timestamp: 2025-06-30T10:29:42.997Z
Learning: Applies to **/*.{tsx,jsx} : Minimize re-renders in React 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 **/*.{jsx,tsx} : Use proper refs for DOM access
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 useCallback for handlers
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 cleanup in useEffect
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 event listener 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 useMemo for expensive computations
packages/shared/src/react/stripe-react/index.tsx (12)
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 definitions for props and state
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 HTML elements
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: CR
PR: clerk/javascript#0
File: .cursor/rules/react.mdc:0-0
Timestamp: 2025-06-30T10:32:37.848Z
Learning: Applies to **/*.test.{jsx,tsx} : Test component interactions
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 component structure
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 : Implement proper generic types for reusable 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 **/*.{tsx,jsx} : Use error boundaries in React 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 **/*.{jsx,tsx} : Use composition over inheritance - prefer smaller, composable 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 **/*.{jsx,tsx} : Implement proper state selectors
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/development.mdc:0-0
Timestamp: 2025-06-30T10:29:42.997Z
Learning: Applies to **/*.{tsx,jsx} : Minimize re-renders in React components
🧬 Code Graph Analysis (1)
packages/shared/src/react/stripe-react/index.tsx (2)
packages/shared/src/react/stripe-react/utils.ts (2)
usePrevious(4-12)useAttachEvent(14-45)packages/shared/src/react/commerce.tsx (1)
PaymentElement(319-319)
🪛 Biome (1.9.4)
packages/shared/src/react/stripe-react/index.tsx
[error] 218-218: void is confusing inside a union type.
Unsafe fix: Use undefined instead.
(lint/suspicious/noConfusingVoidType)
[error] 219-219: void is confusing inside a union type.
Unsafe fix: Use undefined instead.
(lint/suspicious/noConfusingVoidType)
⏰ Context from checks skipped due to timeout of 90000ms (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 (4)
packages/shared/src/react/stripe-react/utils.ts (1)
4-12: LGTM! Standard implementation of theusePrevioushook.This is a well-established React pattern for tracking previous values. The implementation correctly uses a ref to persist the value across renders and updates it after each render cycle.
packages/shared/src/react/stripe-react/index.tsx (3)
1-10: Great job on proper attribution and licensing!The file header clearly indicates this is a fork, explains the modifications, and includes the original license information. This is the correct way to handle forked open-source code.
78-148: Excellent implementation of the Elements provider!The component properly handles:
- Both synchronous and asynchronous Stripe initialization
- Race condition prevention with functional setState
- Memory leak prevention with cleanup and isMounted flag
- Developer warnings for unsupported prop changes
- Efficient updates to elements when options change
The implementation follows React best practices and provides a robust foundation for Stripe Elements integration.
327-456: Well-architected factory function for creating Stripe Element components!The implementation excellently handles:
- Server-side rendering with a separate ServerElement component
- Proper lifecycle management with refs and state
- Synchronous DOM updates with useLayoutEffect
- Comprehensive event handling using the custom useAttachEvent hook
- Clean unmounting with proper error handling
The use of refs alongside state ensures elements are immediately available in cleanup hooks, which is crucial for StrictMode compatibility.
panteliselef
deleted the
elef/com-960-dx-guide-introduce-checkout-utilities
branch
Description
Exposing the following Components and hooks as experimental.
PaymentElementProviderPaymentElementusePaymentElementExample usage:
Checklist
pnpm testruns as expected.pnpm buildruns as expected.Type of change
Summary by CodeRabbit
New Features
Refactor
Chores
Documentation