feat(clerk-js,clerk-react,shared,types): Add sign in with Solana feature support #7293
Conversation
🦋 Changeset detectedLatest commit: dabe8be 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 GitHub.
|
WalkthroughAdds Solana wallet authentication: runtime deps and Wallet Standard integration, Solana-aware web3 utilities and provider detection, new authenticateWithSolana APIs in Clerk/SignIn/SignUp, wallet-selection UI components/routes for sign-in/sign-up, and shared type/localization updates to carry Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant UI as Clerk UI
participant Detector as Wallet Detector
participant Core as Clerk Core
participant Wallet as Solana Wallet
participant Backend as Clerk Backend
User->>UI: open choose-wallet (sign-in/sign-up)
UI->>Detector: listInstalledSolanaWallets()
Detector-->>UI: available wallets
User->>UI: select wallet (walletName)
UI->>Core: getSolanaIdentifier(walletName)
Core->>Wallet: connect() / request public key
Wallet-->>Core: public key (identifier)
Core->>Wallet: signMessage(nonce)
Wallet-->>Core: signature
Core->>Backend: authenticateWithWeb3(identifier, signature, strategy=web3_solana_signature)
Backend-->>Core: auth result / session
Core-->>UI: finalize (redirect / session established)
Estimated code review effort🎯 4 (Complex) | ⏱️ ~60 minutes
Possibly related PRs
Suggested reviewers
Poem
Pre-merge checks and finishing touches❌ Failed checks (1 warning, 1 inconclusive)
✅ Passed checks (3 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
Warning Review ran into problems🔥 ProblemsErrors were encountered while retrieving linked issues. Errors (1)
Comment |
@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: |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 5
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
packages/shared/src/types/signInFuture.ts (1)
243-256: Consider using a discriminated union for stronger type safety.The JSDoc states that
walletNameis required whenprovideris'solana', but TypeScript doesn't enforce this constraint. This could lead to runtime errors if developers forget to providewalletNamefor Solana authentication.Consider refactoring to a discriminated union type to enforce this at compile time:
export type SignInFutureWeb3Params = | { strategy: Web3Strategy; provider: Exclude<Web3Provider, 'solana'>; walletName?: never; } | { strategy: Extract<Web3Strategy, 'web3_solana_signature'>; provider: 'solana'; walletName: string; };This approach ensures type safety and prevents runtime issues.
🧹 Nitpick comments (7)
packages/clerk-js/src/ui/components/SignIn/SignInSocialButtons.tsx (1)
61-63: LGTM! Solana flow correctly routes to wallet selection.The early return for the Solana strategy correctly navigates to the wallet selection route before authentication, which aligns with the PR's objectives for Solana wallet detection and selection.
Optional: Extract magic strings to constants.
Consider defining constants for the strategy and route strings to improve maintainability:
const WEB3_SOLANA_STRATEGY = 'web3_solana_signature'; const CHOOSE_WALLET_ROUTE = 'choose-wallet';Then use them:
-if (strategy === 'web3_solana_signature') { - return navigate(`choose-wallet?strategy=${strategy}`); +if (strategy === WEB3_SOLANA_STRATEGY) { + return navigate(`${CHOOSE_WALLET_ROUTE}?strategy=${strategy}`);packages/shared/src/types/clerk.ts (1)
872-875: Consider enhancing the JSDoc comment.The JSDoc for
authenticateWithSolanacould be more descriptive. Consider documenting:
- The optional
walletNameparameter and when it should be provided- Return type details (e.g., what the promise resolves to)
- Example usage
Compare to other authentication methods for consistency in documentation style.
packages/clerk-js/src/core/resources/SignUp.ts (2)
271-320: Add a Solana-specific walletName guard inauthenticateWithWeb3For sign-up,
walletNameis effectively required whenstrategyisweb3_solana_signature(the Solana utils cannot resolve a provider without it), butauthenticateWithWeb3does not enforce this. If a caller bypassesauthenticateWithSolanaand invokes this method directly with a Solana strategy and nowalletName, you’ll end up with empty identifiers/signatures and a less obvious backend error.Consider failing fast for Solana here, similar to the SignIn flow:
): Promise<SignUpResource> => { const { generateSignature, identifier, unsafeMetadata, strategy = 'web3_metamask_signature', legalAccepted, walletName, } = params || {}; - const provider = strategy.replace('web3_', '').replace('_signature', '') as Web3Provider; + const provider = strategy.replace('web3_', '').replace('_signature', '') as Web3Provider; + + if (provider === 'solana' && !walletName) { + clerkMissingOptionError('walletName'); + }
382-397: Fail fast on missingwalletNameinauthenticateWithSolana
getSolanaIdentifierandgenerateSignatureWithSolanaboth expect a concrete wallet selection; calling this method withoutwalletNamewill currently hit those utilities withundefined, produce console warnings, and then fail later in the flow.To make the API clearer and consistent with the SignIn/Future Solana paths, validate
walletNameat the entry point:public authenticateWithSolana = async ( params?: SignUpAuthenticateWithWeb3Params & { walletName?: string; legalAccepted?: boolean; }, ): Promise<SignUpResource> => { - const identifier = await getSolanaIdentifier({ walletName: params?.walletName }); + if (!params?.walletName) { + clerkMissingOptionError('walletName'); + } + + const identifier = await getSolanaIdentifier({ walletName: params.walletName }); return this.authenticateWithWeb3({ identifier, generateSignature: generateSignatureWithSolana, unsafeMetadata: params?.unsafeMetadata, strategy: 'web3_solana_signature', legalAccepted: params?.legalAccepted, walletName: params?.walletName, }); };packages/clerk-js/src/core/resources/SignIn.ts (1)
471-479: Avoid unnecessary Solana identifier lookup whenwalletNameis missing
authenticateWithSolanacurrently callsgetSolanaIdentifier({ walletName: params?.walletName })even whenwalletNameis absent, and only later willauthenticateWithWeb3throw due to the Solana walletName guard. To keep errors cleaner and avoid extra provider lookups, you can fail early here:public authenticateWithSolana = async (params?: AuthenticateWithSolanaParams): Promise<SignInResource> => { - const identifier = await getSolanaIdentifier({ walletName: params?.walletName }); + if (!params?.walletName) { + clerkMissingOptionError('walletName'); + } + + const identifier = await getSolanaIdentifier({ walletName: params.walletName }); return this.authenticateWithWeb3({ identifier, generateSignature: generateSignatureWithSolana, strategy: 'web3_solana_signature', walletName: params?.walletName, }); };packages/clerk-js/src/core/clerk.ts (1)
2267-2382: Add SolanawalletNameguard inauthenticateWithWeb3to mirror SignIn behavior
authenticateWithWeb3now:
- Derives
providerfromstrategy.- Calls
getWeb3Identifier({ provider, walletName }).- Chooses
generateSignatureWithSolanawhenprovider === 'solana'.- Forwards
walletNameinto bothsignIn.authenticateWithWeb3andsignUp.authenticateWithWeb3.That wiring is good, but when
strategyisweb3_solana_signatureandwalletNameis missing,getWeb3Identifierwill already be invoked with an undefined wallet name, causing a console warning and an empty identifier before SignIn/SignUp eventually throw.To provide a clearer error and avoid the extra Solana provider lookup, add a guard similar to the one in
SignIn.authenticateWithWeb3:public authenticateWithWeb3 = async ({ redirectUrl, signUpContinueUrl, customNavigate, unsafeMetadata, strategy, legalAccepted, secondFactorUrl, walletName, }: ClerkAuthenticateWithWeb3Params): Promise<void> => { @@ - const provider = strategy.replace('web3_', '').replace('_signature', '') as Web3Provider; - const identifier = await getWeb3Identifier({ provider, walletName }); + const provider = strategy.replace('web3_', '').replace('_signature', '') as Web3Provider; + + if (provider === 'solana' && !walletName) { + throw new ClerkRuntimeError('walletName is required for solana web3 authentication', { + code: 'missing_wallet_name', + }); + } + + const identifier = await getWeb3Identifier({ provider, walletName });This keeps the contract “walletName is required for Solana” enforced at the highest entry point and avoids surprising warnings downstream.
packages/shared/src/types/web3Wallet.ts (1)
28-49: Solana typings look sound; consider tightening the discriminated unionThe changes here (adding
walletName?: stringtoAuthenticateWithWeb3Params/GenerateSignatureParams, and introducingGenerateSolanaSignatureParamswithprovider: 'solana'and requiredwalletName) are structurally backward compatible and give Solana a more precise payload shape.If you want stronger compile-time guarantees, you could simplify
GenerateSignatureto a proper discriminated union keyed byproviderinstead ofGenerateSignatureParams | GenerateSolanaSignatureParams(which is effectively just the base type since the Solana variant extends it). This is purely a type-level nicety; the current form is fine functionally.
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Disabled knowledge base sources:
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (28)
packages/clerk-js/package.json(2 hunks)packages/clerk-js/src/core/clerk.ts(8 hunks)packages/clerk-js/src/core/resources/SignIn.ts(10 hunks)packages/clerk-js/src/core/resources/SignUp.ts(4 hunks)packages/clerk-js/src/ui/components/SignIn/SignInFactorOneSolanaWalletsCard.tsx(1 hunks)packages/clerk-js/src/ui/components/SignIn/SignInSocialButtons.tsx(1 hunks)packages/clerk-js/src/ui/components/SignIn/index.tsx(2 hunks)packages/clerk-js/src/ui/components/SignUp/SignUpSocialButtons.tsx(1 hunks)packages/clerk-js/src/ui/components/SignUp/SignUpStartSolanaWalletsCard.tsx(1 hunks)packages/clerk-js/src/ui/components/SignUp/index.tsx(2 hunks)packages/clerk-js/src/ui/elements/Web3WalletButtons.tsx(1 hunks)packages/clerk-js/src/ui/elements/contexts/index.tsx(1 hunks)packages/clerk-js/src/utils/injectedWeb3EthProviders.ts(3 hunks)packages/clerk-js/src/utils/injectedWeb3SolanaProviders.ts(1 hunks)packages/clerk-js/src/utils/web3.ts(4 hunks)packages/elements/src/internals/machines/sign-in/start.machine.ts(1 hunks)packages/elements/src/internals/machines/sign-up/start.machine.ts(1 hunks)packages/elements/src/react/hooks/use-third-party-provider.hook.ts(1 hunks)packages/react/src/isomorphicClerk.ts(2 hunks)packages/shared/src/types/clerk.ts(3 hunks)packages/shared/src/types/factors.ts(1 hunks)packages/shared/src/types/signIn.ts(2 hunks)packages/shared/src/types/signInFuture.ts(2 hunks)packages/shared/src/types/signUp.ts(2 hunks)packages/shared/src/types/signUpCommon.ts(1 hunks)packages/shared/src/types/web3.ts(1 hunks)packages/shared/src/types/web3Wallet.ts(1 hunks)packages/shared/src/web3.ts(1 hunks)
🧰 Additional context used
🧬 Code graph analysis (11)
packages/shared/src/types/signIn.ts (1)
packages/shared/src/types/clerk.ts (1)
AuthenticateWithSolanaParams(2302-2309)
packages/shared/src/types/signUp.ts (1)
packages/shared/src/types/signUpCommon.ts (1)
SignUpAuthenticateWithSolanaParams(120-122)
packages/shared/src/types/web3Wallet.ts (2)
packages/shared/src/types/strategies.ts (1)
Web3Strategy(20-20)packages/shared/src/types/web3.ts (1)
Web3Provider(15-20)
packages/clerk-js/src/ui/components/SignIn/SignInFactorOneSolanaWalletsCard.tsx (7)
packages/clerk-js/src/ui/elements/contexts/index.tsx (2)
useCardState(42-70)withCardStateProvider(72-81)packages/clerk-js/src/ui/contexts/components/SignIn.ts (1)
useSignInContext(38-169)packages/clerk-js/src/ui/utils/errorHandler.ts (1)
handleError(64-86)packages/clerk-js/src/ui/customizables/Flow.tsx (1)
Flow(41-44)packages/clerk-js/src/ui/elements/Header.tsx (1)
Header(103-108)packages/clerk-js/src/ui/elements/Web3WalletButtons.tsx (1)
Web3WalletButtons(106-123)packages/clerk-js/src/ui/common/withRedirect.tsx (2)
withRedirectToSignInTask(93-113)withRedirectToAfterSignIn(55-72)
packages/clerk-js/src/ui/components/SignUp/index.tsx (1)
packages/clerk-js/src/ui/components/SignUp/SignUpStartSolanaWalletsCard.tsx (1)
SignUpStartSolanaWalletsCard(75-77)
packages/clerk-js/src/core/clerk.ts (2)
packages/shared/src/types/clerk.ts (1)
AuthenticateWithSolanaParams(2302-2309)packages/clerk-js/src/utils/web3.ts (2)
getWeb3Identifier(19-39)generateSignatureWithSolana(130-132)
packages/clerk-js/src/ui/components/SignIn/index.tsx (1)
packages/clerk-js/src/ui/components/SignIn/SignInFactorOneSolanaWalletsCard.tsx (1)
SignInFactorOneSolanaWalletsCard(70-72)
packages/clerk-js/src/ui/components/SignUp/SignUpStartSolanaWalletsCard.tsx (3)
packages/clerk-js/src/ui/elements/contexts/index.tsx (2)
useCardState(42-70)withCardStateProvider(72-81)packages/clerk-js/src/ui/contexts/components/SignUp.ts (1)
useSignUpContext(37-158)packages/clerk-js/src/ui/common/withRedirect.tsx (2)
withRedirectToSignUpTask(115-135)withRedirectToAfterSignUp(74-91)
packages/shared/src/types/signInFuture.ts (1)
packages/shared/src/types/web3.ts (1)
Web3Provider(15-20)
packages/clerk-js/src/utils/injectedWeb3EthProviders.ts (1)
packages/shared/src/types/web3.ts (2)
MetamaskWeb3Provider(9-9)OKXWalletWeb3Provider(11-11)
packages/clerk-js/src/ui/elements/Web3WalletButtons.tsx (2)
packages/clerk-js/src/ui/elements/contexts/index.tsx (1)
useCardState(42-70)packages/clerk-js/src/ui/customizables/index.ts (3)
Grid(18-18)Flex(16-16)Image(30-30)
⏰ 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). (4)
- GitHub Check: Build Packages
- GitHub Check: semgrep-cloud-platform/scan
- GitHub Check: semgrep-cloud-platform/scan
- GitHub Check: Analyze (javascript-typescript)
🔇 Additional comments (29)
packages/clerk-js/src/utils/injectedWeb3EthProviders.ts (4)
30-38: LGTM: Consistent renaming to disambiguate Ethereum providers.The type alias and class renaming from
InjectedWeb3ProvidertoInjectedWeb3EthProviderandInjectedWeb3ProviderstoInjectedWeb3EthProvidersis clear and consistent, properly disambiguating Ethereum providers from the new Solana providers being added in this PR.
48-53: LGTM: getInstance method correctly updated.All references to the renamed class are consistent throughout the singleton getInstance implementation.
55-55: LGTM: Method signature updated consistently.The
getmethod parameter type is correctly updated to useInjectedWeb3EthProvider.
75-75: All call sites have been correctly updated to use the new export name.Verification confirms zero remaining references to the old naming patterns (
getInjectedWeb3Providers,InjectedWeb3Providers, or incompatibleInjectedWeb3Providerreferences). The sole import site inpackages/clerk-js/src/utils/web3.tscorrectly uses the new name and the export is properly defined.packages/shared/src/types/factors.ts (1)
42-47: LGTM! Clean type extension for wallet name tracking.The addition of the optional
walletNameproperty toWeb3SignatureFactoris a non-breaking change that enables tracking which specific wallet was used for Web3 authentication, aligning well with the Solana wallet selection feature.packages/elements/src/react/hooks/use-third-party-provider.hook.ts (1)
100-102: LGTM! Consistent Web3 provider integration.The Solana provider handling follows the established pattern for other Web3 providers (Metamask, Base, Coinbase, OKX), sending the appropriate
AUTHENTICATE.WEB3event with theweb3_solana_signaturestrategy.packages/shared/src/types/web3.ts (1)
13-26: LGTM! Correct type modeling for Solana as a non-Ethereum Web3 provider.The type definitions correctly distinguish between
Web3Provider(which includes Solana) andEthereumWeb3Provider(which excludes Solana), properly reflecting that Solana is a separate blockchain platform rather than an Ethereum-compatible network.packages/clerk-js/src/ui/components/SignUp/index.tsx (1)
90-92: LGTM! Route addition for Solana wallet selection.The new
choose-walletroute integrates cleanly into the SignUp flow. The generic route name allows for potential future expansion to support other blockchain wallet selections beyond Solana.packages/clerk-js/src/ui/components/SignIn/index.tsx (1)
81-83: LGTM! Symmetric route addition maintaining flow consistency.The
choose-walletroute for SignIn mirrors the identical route in SignUp, maintaining consistency across authentication flows. The route placement between account switching and verification steps is logical.packages/clerk-js/src/ui/elements/contexts/index.tsx (1)
128-129: LGTM! FlowMetadata extension for wallet selection tracking.The addition of
'choose-wallet'to theFlowMetadata.partunion enables proper flow metadata tracking for the new Solana wallet selection UI, maintaining consistency with the route names defined in the SignIn and SignUp components.packages/elements/src/internals/machines/sign-up/start.machine.ts (1)
50-52: LGTM!The Solana authentication handling follows the established pattern for other Web3 strategies. Verification confirms that
signUp.authenticateWithSolana()is properly implemented on the SignUpResource and returnsPromise<SignUpResource>.packages/elements/src/internals/machines/sign-in/start.machine.ts (1)
45-47: LGTM! Verification complete.The
authenticateWithSolana()method is properly defined on SignInResource and returnsPromise<SignInResource>as expected. The implementation is consistent with other Web3 authentication strategies in the SignIn flow.packages/shared/src/types/clerk.ts (1)
2258-2258: LGTM: walletName addition to web3 params.Adding the optional
walletNamefield toClerkAuthenticateWithWeb3Paramsis appropriate since it's Solana-specific and other Web3 providers don't require it.packages/shared/src/web3.ts (1)
24-28: LGTM: Solana provider addition.The Solana provider entry follows the established pattern and is correctly structured with the appropriate strategy and display name.
packages/shared/src/types/signUpCommon.ts (1)
120-122: LGTM: Correct type definition for Solana sign-up params.The
SignUpAuthenticateWithSolanaParamstype correctly extends the base Web3 params and makeswalletNamerequired, which aligns with Solana authentication requirements.Note: This highlights the inconsistency with
AuthenticateWithSolanaParamsinpackages/shared/src/types/clerk.tswherewalletNameis optional (already flagged in a separate comment).packages/shared/src/types/signIn.ts (1)
1-1: LGTM: Solana authentication method added to SignIn resource.The
authenticateWithSolanamethod follows the established pattern of other Web3 authentication methods and maintains API consistency.Note: This method relies on
AuthenticateWithSolanaParamsfromclerk.ts, which has a potential type inconsistency withwalletNameoptionality (already flagged in a separate comment).Also applies to: 80-80
packages/shared/src/types/signUp.ts (1)
9-9: LGTM: Solana authentication method added to SignUp resource.The
authenticateWithSolanamethod correctly follows the established pattern of other Web3 authentication methods in SignUp (e.g.,authenticateWithMetamask,authenticateWithBase).The params being optional at the method level while
SignUpAuthenticateWithSolanaParamsrequireswalletNameis consistent with the existing pattern where params are optional, but required fields must be provided when calling the method.Also applies to: 111-111
packages/clerk-js/package.json (1)
72-73: Solana packages verified as latest stable with no security vulnerabilities.Verification confirms @solana/wallet-adapter-react (^0.15.39) and @solana/wallet-standard (^1.1.4) are the latest stable versions. GitHub's security advisory database shows no known vulnerabilities for these packages or their dependencies.
packages/react/src/isomorphicClerk.ts (1)
18-18: Solana auth wiring matches existing web3 patternsThe
AuthenticateWithSolanaParamsimport andauthenticateWithSolanamethod are consistent with the existingauthenticateWithMetamask/authenticateWithCoinbaseWallet/authenticateWithBase/authenticateWithOKXWalletimplementations, including premount queuing behavior. No issues from this file’s side, assumingBrowserClerkexposesauthenticateWithSolanaas well.Also applies to: 1412-1419
packages/clerk-js/src/ui/components/SignIn/SignInFactorOneSolanaWalletsCard.tsx (1)
21-36: Solana sign-in factor flow is consistent with existing web3 patternsThe factor-one Solana card correctly:
- Sets loading with the selected
walletName,- Calls
clerk.authenticateWithWeb3usingweb3_solana_signature,customNavigate,redirectUrl,signUpContinueUrl, andsecondFactorUrl,- Handles errors via the shared
handleErrorhelper and resets card state.Overall structure and redirect HOCs around the card match the existing sign-in flow conventions.
Also applies to: 42-67
packages/clerk-js/src/ui/elements/Web3WalletButtons.tsx (1)
18-34: ****The original review is incorrect. The codebase correctly uses Wallet-Standard auto-detection, which does not require explicit wallet adapters.
The file imports
MAINNET_ENDPOINTfrom@solana/wallet-standard, and the Wallet-Standard wallets are auto-detected by @solana/wallet-adapter-base, so you do not need to create adapters for them—passing an empty wallets array to WalletProvider is the correct pattern for Wallet-Standard-only support. TheuseWallet()hook will correctly expose installed wallets (Phantom, Backpack, etc.) via auto-detection, not from thewalletsprop. The code is working as designed and no changes are required.Likely an incorrect or invalid review comment.
packages/clerk-js/src/core/resources/SignIn.ts (3)
191-221: Solana web3 strategy correctly wired into first-factor prepThe addition of
case 'web3_solana_signature'intoprepareFirstFactorwith aWeb3SignatureConfigusingweb3WalletIdkeeps the Web3 factor treatment consistent across providers and ensures Solana factors are prepared through the same path.
385-424: Web3 Solana path andwalletNamevalidation inauthenticateWithWeb3look correctDeriving
providerfromstrategy, requiringwalletNamewhenprovider === 'solana', and passingwalletNameinto both the initial and Coinbase-retry signature calls aligns with the Solana utils’ expectations and avoids ambiguous failures when no wallet is selected.
983-1068: Futureweb3Solana branch is consistent with core flowThe new
case 'solana'inSignInFuture.web3correctly:
- Enforces
walletNameat runtime with a specificClerkRuntimeError.- Resolves the identifier via
getSolanaIdentifier({ walletName }).- Uses
generateSignatureWithSolanaand passeswalletNamefor signing and for the Coinbase retry branch.This keeps the experimental Future API in sync with the main SignIn Web3/Solana semantics.
packages/clerk-js/src/core/clerk.ts (1)
2260-2265: Solana helper on Clerk is wired correctly to the generic Web3 flow
authenticateWithSolanasimply forwards props intoauthenticateWithWeb3withstrategy: 'web3_solana_signature', which keeps the public API small and reuses the core Web3 handling. This is consistent with the existing Metamask/Coinbase/Base/OKX helpers.packages/clerk-js/src/utils/web3.ts (4)
19-39: Solana/EVM split ingetWeb3Identifieris clear and matches provider abstractionsUsing a shared
getWeb3WalletProviderand branching onprovider === 'solana'to callwalletProvider.features[standard:connect].connect()(vseth_requestAccountsfor EVM wallets) is a good fit for the wallet-standard model and keeps identifier resolution consistent across all providers.
46-79: Solana signing flow ingenerateWeb3Signatureis well-structuredThe Solana branch:
- Resolves the wallet via
getWeb3WalletProvider(provider, walletName).- Finds the account matching
identifier.- Calls the
solana:signMessagefeature.- Encodes the resulting signature with
bs58.Returning
''with a console warning when the provider, account, or signature is missing keeps behavior aligned with the existing EVM paths that fall back to an empty identifier/signature on missing providers.
97-132:getSolanaIdentifier/generateSignatureWithSolanahelpers correctly encapsulate Solana detailsThe new helpers nicely wrap the generic primitives:
getSolanaIdentifierdelegates togetWeb3Identifier({ provider: 'solana', walletName }).generateSignatureWithSolanaforwards togenerateWeb3Signaturewithprovider: 'solana'and propagateswalletName.This keeps call sites (SignIn, SignUp, Clerk) simple while centralizing Solana-specific behavior.
134-180: Provider discovery helper cleanly separates Solana vs EVM resolution
getWeb3WalletProvidernow:
- Uses SDKs for
coinbase_walletandbase(with environment checks).- For
solana, requireswalletNameand looks up the provider viagetInjectedWeb3SolanaProviders().get(walletName), warning and returningnullif none is provided.- For other EVM wallets, relies on
getInjectedWeb3EthProviders().get(provider).This nicely centralizes provider discovery and lets higher-level flows stay provider-agnostic.
| if (strategy === 'web3_solana_signature') { | ||
| // TODO: Add support to pass legalAccepted status | ||
| return navigate(`choose-wallet?strategy=${strategy}`); | ||
| } |
There was a problem hiding this comment.
Address the TODO: Pass legalAccepted status to wallet chooser.
The TODO comment indicates that legalAccepted status should be passed to the wallet chooser route, but it's currently not included. This could result in users needing to re-accept legal terms or the legal acceptance status being lost.
Consider passing legalAccepted via query parameters or route state to maintain consistency with the OAuth and other web3 flows (lines 58, 71, 89).
Would you like me to suggest an implementation that propagates legalAccepted through the navigation?
🤖 Prompt for AI Agents
In packages/clerk-js/src/ui/components/SignUp/SignUpSocialButtons.tsx around
lines 77-80, the wallet chooser navigation for strategy 'web3_solana_signature'
currently omits the legalAccepted state; update the navigate call to include
legalAccepted like the other flows (lines 58, 71, 89) by adding it as a query
parameter or route state (e.g., include &legalAccepted=${String(legalAccepted)}
or pass { state: { legalAccepted } }), ensuring the strategy param is preserved
and the boolean is stringified/encoded if using query params.
packages/clerk-js/src/ui/components/SignUp/SignUpStartSolanaWalletsCard.tsx
Outdated
Show resolved
Hide resolved
kduprey
changed the title
packages/clerk-js/package.json
Outdated
| "@solana/wallet-adapter-react": "^0.15.39", | ||
| "@solana/wallet-standard": "^1.1.4", |
There was a problem hiding this comment.
| "@solana/wallet-adapter-react": "^0.15.39", | |
| "@solana/wallet-standard": "^1.1.4", | |
| "@solana/wallet-adapter-react": "0.15.39", | |
| "@solana/wallet-standard": "1.1.4", |
There was a problem hiding this comment.
I see we're using these in the AIO like so:
import { WalletReadyState } from '@solana/wallet-adapter-base';
import { ConnectionProvider, useWallet, WalletProvider } from '@solana/wallet-adapter-react';
Are we sure that we need both packages? Is there any chance WalletReadyState is re-experted from wallet-adapter-react instead?
There was a problem hiding this comment.
Unfortunately, I checked in the midst of development before installing the additional lib, and WalletReadyState is not exported from @solana/wallet-adapter-react, so I would have just used the one lib here. I am all in favour of us declaring it with a link to the lib, but that means we need to maintain the value as up to date.
| }); | ||
| }; | ||
|
|
||
| public authenticateWithSolana = async (params?: AuthenticateWithSolanaParams): Promise<SignInResource> => { |
There was a problem hiding this comment.
i guess the params should be required here right? We need the walletName always
| public authenticateWithSolana = async (params?: AuthenticateWithSolanaParams): Promise<SignInResource> => { | |
| public authenticateWithSolana = async (params: AuthenticateWithSolanaParams): Promise<SignInResource> => { |
| signature = await generateSignature({ | ||
| identifier, | ||
| nonce: message, | ||
| walletName: params.walletName, |
There was a problem hiding this comment.
why do we need to pass the wallet name here, as we are in the case of the coinbase wallet
|
|
||
| public authenticateWithSolana = async ( | ||
| params?: SignUpAuthenticateWithWeb3Params & { | ||
| walletName?: string; |
There was a problem hiding this comment.
in case of Solana this should be a required parameter right?
| }} | ||
| web3Callback={strategy => { | ||
| if (strategy === 'web3_solana_signature') { | ||
| return navigate(`choose-wallet?strategy=${strategy}`); |
There was a problem hiding this comment.
is this the proper way to navigate to the next screen? In general, why we need to pass along the strategy? Doesn't than mean that the rest of the query parameters will be lost after the navigate. For example, if somebody navigates to example.com/sign-up?redirect_url=/checkout, we need to make sure that after clicking the solana wallet button, the extra query parameters will persist
There was a problem hiding this comment.
After speaking with @dstaley regarding this implementation strategy, we agreed that this would pave the way for the future of supporting Web3 chains, rather than specific wallets, which would result in the user needing to select their wallet of choice, and inturn require the persistance of the strategy to listen in the browser window for the proper wallet extension providers that support the chosen strategy.
@panteliselef - Please do let me know if the query param will cause issues in this flow and if it should be reworked.
nikosdouvlis
left a comment
nikosdouvlis
left a comment
There was a problem hiding this comment.
I see that bundlewatch checks fail, this is because we now use 5 new libs and bundle them in the core clerk-js bundle directly. We need to update rspack.config.ts so that the modules are bundled as a 3p vendor instead
packages/clerk-js/package.json
Outdated
| "@solana/wallet-adapter-react": "^0.15.39", | ||
| "@solana/wallet-standard": "^1.1.4", |
There was a problem hiding this comment.
I see we're using these in the AIO like so:
import { WalletReadyState } from '@solana/wallet-adapter-base';
import { ConnectionProvider, useWallet, WalletProvider } from '@solana/wallet-adapter-react';
Are we sure that we need both packages? Is there any chance WalletReadyState is re-experted from wallet-adapter-react instead?
packages/clerk-js/package.json
Outdated
| "@wallet-standard/core": "^1.1.1", | ||
| "@wallet-standard/react": "^1.0.1", |
There was a problem hiding this comment.
| "@wallet-standard/core": "^1.1.1", | |
| "@wallet-standard/react": "^1.0.1", | |
| "@wallet-standard/core": "1.1.1", | |
| "@wallet-standard/react": "1.0.1", |
Do we absolutely need both @wallet-standard/core and @wallet-standard/core and @solana/wallet-standard?
There was a problem hiding this comment.
We could type check against WalletWithSolanaFeatures but we risk it being too strict of a type and providers not matching all required features in this wallet standard (I realise that is the point of a standard, but this is still a relatively new standard at that.), resulting in omitting providers that provide standard:connect and solana:signMessage but not the rest of the methods required in this type.
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
packages/clerk-js/src/core/resources/SignUp.ts (1)
271-320: Consider adding walletName validation for Solana in authenticateWithWeb3.The
authenticateWithWeb3method acceptswalletNameas optional (line 283), but whenprovideris 'solana',walletNameis required. Consider adding validation similar to what's done in SignIn.ts (lines 394-396) to fail fast with a clear error message:public authenticateWithWeb3 = async ( params: AuthenticateWithWeb3Params & { unsafeMetadata?: SignUpUnsafeMetadata; legalAccepted?: boolean; }, ): Promise<SignUpResource> => { const { generateSignature, identifier, unsafeMetadata, strategy = 'web3_metamask_signature', legalAccepted, walletName, } = params || {}; const provider = strategy.replace('web3_', '').replace('_signature', '') as Web3Provider; if (!(typeof generateSignature === 'function')) { clerkMissingOptionError('generateSignature'); } + if (provider === 'solana' && !walletName) { + clerkMissingOptionError('walletName'); + }This provides consistency with SignIn and clearer error messaging.
packages/clerk-js/src/core/resources/SignIn.ts (1)
984-1018: Use ClerkRuntimeError for consistency and remove commented code.
Line 987: Remove the commented
// as Web3Provider;- it's unclear why it was commented out and adds noise.Lines 1010-1012: Use
ClerkRuntimeErrorinstead of genericErrorfor consistency with the rest of the codebase:case 'solana': if (!params.walletName) { - throw new Error('walletName is required for solana web3 authentication'); + throw new ClerkRuntimeError('walletName is required for solana web3 authentication', { + code: 'missing_wallet_name', + }); }This provides consistent error handling and structured error codes throughout the application.
♻️ Duplicate comments (2)
packages/clerk-js/src/utils/web3.ts (2)
1-2: CRITICAL: Remove non-existent type import.The type
SolanaWalletAdapterWalletdoes not exist in@solana/wallet-standard. According to the Wallet Standard specification, wallets implement theWalletinterface from@wallet-standard/base, which includes:
accounts: readonly WalletAccount[]features: Record<string, unknown>Remove this import and use the standard types instead.
Apply this diff:
-import type { GenerateSignature, GenerateSolanaSignatureParams, Web3Provider } from '@clerk/shared/types'; -import type { SolanaWalletAdapterWallet } from '@solana/wallet-standard'; +import type { GenerateSignature, GenerateSolanaSignatureParams, Web3Provider } from '@clerk/shared/types'; +import type { Wallet } from '@wallet-standard/base';
53-69: CRITICAL: Fix invalid type cast and improve error handling.Multiple issues in the Solana signing logic:
Invalid cast (lines 55, 60): The cast to
SolanaWalletAdapterWalletis invalid since this type doesn't exist. Use theWallettype from@wallet-standard/baseinstead.Silent failures (lines 57-59, 65-67): Using
console.warnand returning empty strings hides errors from users. These should throw proper errors.Type safety: The wallet accounts and features should be accessed with proper type guards.
Apply this diff:
if (provider === 'solana') { const bs58 = await import('bs58').then(mod => mod.default); - const walletAccount = (wallet as SolanaWalletAdapterWallet).accounts.find(a => a.address === identifier); + const walletAccount = wallet.accounts.find(a => a.address === identifier); if (!walletAccount) { - console.warn(`Wallet account with address ${identifier} not found`); - return ''; + throw new ClerkRuntimeError(`Wallet account with address ${identifier} not found`, { + code: 'wallet_account_not_found', + }); } - const signedMessages = await (wallet as SolanaWalletAdapterWallet).features[SolanaSignMessage]?.signMessage({ + const signMessageFeature = wallet.features[SolanaSignMessage]; + if (!signMessageFeature || typeof signMessageFeature.signMessage !== 'function') { + throw new ClerkRuntimeError('Wallet does not support message signing', { + code: 'wallet_feature_not_supported', + }); + } + const signedMessages = await signMessageFeature.signMessage({ account: walletAccount, message: new TextEncoder().encode(nonce), }); if (!signedMessages || signedMessages.length === 0) { - console.warn('No signed messages returned from wallet'); - return ''; + throw new ClerkRuntimeError('No signed messages returned from wallet', { + code: 'wallet_signing_failed', + }); } return bs58.encode(signedMessages[0].signature); }Additionally, import
ClerkRuntimeError:+import { ClerkRuntimeError } from '@clerk/shared/error';
🧹 Nitpick comments (3)
packages/clerk-js/src/core/resources/SignIn.ts (1)
1041-1061: Address inconsistent walletName handling in retry logic.The Coinbase wallet retry logic (lines 1053-1057) doesn't pass
walletNamein the retry attempt, while the initial attempt does (line 1041-1045). This inconsistency could cause issues if a Solana-specific parameter is needed during retry.However, looking at the logic more carefully: this retry is specifically for
coinbase_wallet(line 1053), not Solana. ThewalletNamewould beundefinedfor Coinbase wallet anyway, so this is actually safe.For clarity and to prevent confusion, consider adding a comment explaining why
walletNameis omitted in the retry:if (provider === 'coinbase_wallet' && err.code === 4001) { + // Retry without walletName as Coinbase wallet doesn't require it signature = await generateSignature({ identifier, nonce: message, });packages/clerk-js/src/utils/web3.ts (2)
20-40: Improve error handling - avoid silent failures with empty string returns.Lines 25-29: When a provider is not found, the function returns an empty string with just a TODO comment. This silently fails and makes debugging difficult. Consider throwing a proper error or returning a Result type.
Apply this diff:
const walletProvider = await getWeb3Wallet(provider, walletName); // TODO - core-3: Improve error handling for the case when the provider is not found if (!walletProvider) { - // If a plugin for the requested provider is not found, - // the flow will fail as it has been the expected behavior so far. - return ''; + throw new ClerkRuntimeError(`Web3 provider "${provider}" not found`, { + code: 'web3_provider_not_found', + }); }The same issue exists in
generateWeb3Signatureat lines 47-51.
93-95: Refactor: Make walletName parameter direct instead of object.For internal utility functions, passing
walletNamedirectly as a string parameter rather than wrapping it in an object improves clarity and reduces boilerplate:-export async function getSolanaIdentifier(walletName: string): Promise<string> { - return await getWeb3Identifier({ provider: 'solana', walletName }); -} +export async function getSolanaIdentifier(walletName: string): Promise<string> { + if (!walletName) { + throw new ClerkRuntimeError('Wallet name is required for Solana', { + code: 'wallet_name_required', + }); + } + return await getWeb3Identifier({ provider: 'solana', walletName }); +}Also consider adding the validation here to fail fast.
Based on coding guidelines: "As per coding guidelines, internal utilities can accept direct parameters instead of objects for simplicity."
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Disabled knowledge base sources:
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (12)
packages/clerk-js/package.json(1 hunks)packages/clerk-js/src/core/clerk.ts(9 hunks)packages/clerk-js/src/core/resources/SignIn.ts(12 hunks)packages/clerk-js/src/core/resources/SignUp.ts(4 hunks)packages/clerk-js/src/utils/injectedWeb3SolanaProviders.ts(1 hunks)packages/clerk-js/src/utils/web3.ts(4 hunks)packages/react/src/isomorphicClerk.ts(2 hunks)packages/shared/src/types/clerk.ts(3 hunks)packages/shared/src/types/signIn.ts(2 hunks)packages/shared/src/types/signUp.ts(2 hunks)packages/shared/src/types/web3.ts(1 hunks)packages/shared/src/types/web3Wallet.ts(2 hunks)
🚧 Files skipped from review as they are similar to previous changes (6)
- packages/clerk-js/package.json
- packages/shared/src/types/signUp.ts
- packages/clerk-js/src/utils/injectedWeb3SolanaProviders.ts
- packages/react/src/isomorphicClerk.ts
- packages/shared/src/types/clerk.ts
- packages/shared/src/types/signIn.ts
🧰 Additional context used
📓 Path-based instructions (7)
**/*.{js,jsx,ts,tsx}
📄 CodeRabbit inference engine (.cursor/rules/development.mdc)
All code must pass ESLint checks with the project's configuration
Files:
packages/shared/src/types/web3.tspackages/clerk-js/src/core/clerk.tspackages/shared/src/types/web3Wallet.tspackages/clerk-js/src/utils/web3.tspackages/clerk-js/src/core/resources/SignIn.tspackages/clerk-js/src/core/resources/SignUp.ts
**/*.{js,jsx,ts,tsx,json,md,yml,yaml}
📄 CodeRabbit inference engine (.cursor/rules/development.mdc)
Use Prettier for consistent code formatting
Files:
packages/shared/src/types/web3.tspackages/clerk-js/src/core/clerk.tspackages/shared/src/types/web3Wallet.tspackages/clerk-js/src/utils/web3.tspackages/clerk-js/src/core/resources/SignIn.tspackages/clerk-js/src/core/resources/SignUp.ts
packages/**/src/**/*.{ts,tsx}
📄 CodeRabbit inference engine (.cursor/rules/development.mdc)
TypeScript is required for all packages
Files:
packages/shared/src/types/web3.tspackages/clerk-js/src/core/clerk.tspackages/shared/src/types/web3Wallet.tspackages/clerk-js/src/utils/web3.tspackages/clerk-js/src/core/resources/SignIn.tspackages/clerk-js/src/core/resources/SignUp.ts
**/*.{ts,tsx,js,jsx}
📄 CodeRabbit inference engine (.cursor/rules/development.mdc)
Follow established naming conventions (PascalCase for components, camelCase for variables)
Prefer importing types from
@clerk/shared/typesinstead of the deprecated@clerk/typesalias
Files:
packages/shared/src/types/web3.tspackages/clerk-js/src/core/clerk.tspackages/shared/src/types/web3Wallet.tspackages/clerk-js/src/utils/web3.tspackages/clerk-js/src/core/resources/SignIn.tspackages/clerk-js/src/core/resources/SignUp.ts
packages/**/src/**/*.{ts,tsx,js,jsx}
📄 CodeRabbit inference engine (.cursor/rules/development.mdc)
packages/**/src/**/*.{ts,tsx,js,jsx}: Maintain comprehensive JSDoc comments for public APIs
Use tree-shaking friendly exports
Validate all inputs and sanitize outputs
All public APIs must be documented with JSDoc
Use dynamic imports for optional features
Provide meaningful error messages to developers
Include error recovery suggestions where applicable
Log errors appropriately for debugging
Lazy load components and features when possible
Implement proper caching strategies
Use efficient data structures and algorithms
Implement proper logging with different levels
Files:
packages/shared/src/types/web3.tspackages/clerk-js/src/core/clerk.tspackages/shared/src/types/web3Wallet.tspackages/clerk-js/src/utils/web3.tspackages/clerk-js/src/core/resources/SignIn.tspackages/clerk-js/src/core/resources/SignUp.ts
**/*.ts?(x)
📄 CodeRabbit inference engine (.cursor/rules/development.mdc)
Use proper TypeScript error types
Files:
packages/shared/src/types/web3.tspackages/clerk-js/src/core/clerk.tspackages/shared/src/types/web3Wallet.tspackages/clerk-js/src/utils/web3.tspackages/clerk-js/src/core/resources/SignIn.tspackages/clerk-js/src/core/resources/SignUp.ts
**/*.{ts,tsx}
📄 CodeRabbit inference engine (.cursor/rules/typescript.mdc)
**/*.{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
Implement type guards forunknowntypes using the patternfunction isType(value: unknown): value is Type
Useinterfacefor object shapes that might be extended
Usetypefor unions, primitives, and computed types
Preferreadonlyproperties for immutable data structures
Useprivatefor internal implementation details in classes
Useprotectedfor inheritance hierarchies
Usepublicexplicitly for clarity in public APIs
Use mixins for shared behavior across unrelated classes in TypeScript
Use generic constraints with bounded type parameters like<T extends { id: string }>
Use utility types likeOmit,Partial, andPickfor data transformation instead of manual type construction
Use discriminated unions instead of boolean flags for state management and API responses
Use mapped types for transforming object types
Use conditional types for type-level logic
Leverage template literal types for string manipulation at the type level
Use ES6 imports/exports consistently
Use default exports sparingly, prefer named exports
Document functions with JSDoc comments including @param, @returns, @throws, and @example tags
Create custom error classes that extend Error for specific error types
Use the Result pattern for error handling instead of throwing exceptions
Use optional chaining (?.) and nullish coalescing (??) operators for safe property access
Let TypeScript infer obvious types to reduce verbosity
Useconst assertionswithas constfor literal types
Usesatisfiesoperator for type checking without widening types
Declare readonly arrays and objects for immutable data structures
Use spread operator and array spread for immutable updates instead of mutations
Use lazy loading for large types...
Files:
packages/shared/src/types/web3.tspackages/clerk-js/src/core/clerk.tspackages/shared/src/types/web3Wallet.tspackages/clerk-js/src/utils/web3.tspackages/clerk-js/src/core/resources/SignIn.tspackages/clerk-js/src/core/resources/SignUp.ts
🧬 Code graph analysis (3)
packages/clerk-js/src/core/clerk.ts (3)
packages/shared/src/types/clerk.ts (1)
AuthenticateWithSolanaParams(2302-2309)packages/clerk-js/src/utils/web3.ts (2)
getWeb3Identifier(20-40)generateSignatureWithSolana(118-120)packages/shared/src/types/web3Wallet.ts (1)
GenerateSignature(28-30)
packages/shared/src/types/web3Wallet.ts (2)
packages/shared/src/types/strategies.ts (1)
Web3Strategy(20-20)packages/shared/src/types/web3.ts (2)
EthereumWeb3Provider(17-21)SolanaWeb3Provider(13-13)
packages/clerk-js/src/core/resources/SignUp.ts (2)
packages/shared/src/types/signUp.ts (1)
SignUpResource(41-123)packages/clerk-js/src/utils/web3.ts (2)
getSolanaIdentifier(93-95)generateSignatureWithSolana(118-120)
⏰ 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: Build Packages
- GitHub Check: Formatting | Dedupe | Changeset
- GitHub Check: semgrep-cloud-platform/scan
- GitHub Check: semgrep-cloud-platform/scan
- GitHub Check: Analyze (javascript-typescript)
🔇 Additional comments (7)
packages/shared/src/types/web3.ts (1)
13-21: LGTM! Clean type organization.The addition of
SolanaWeb3Providerand the refactoring to introduceEthereumWeb3Providerimproves type clarity and maintains backward compatibility while supporting the new Solana integration.packages/clerk-js/src/core/resources/SignUp.ts (1)
382-397: Verify AuthenticateWithSolanaParams type includes walletName as required.The method signature requires
walletName: stringin the params (line 384), which is correct for Solana. Ensure that theAuthenticateWithSolanaParamstype in the shared types package includeswalletNameas a required field, not optional.Based on the relevant code snippet from packages/shared/src/types/clerk.ts showing
AuthenticateWithSolanaParamsincludeswalletName: string(required), this is correctly aligned.packages/shared/src/types/web3Wallet.ts (1)
28-51: LGTM! Type definitions correctly distinguish Ethereum and Solana requirements.The separation into
GenerateEthereumSignatureParamsandGenerateSolanaSignatureParamswith differentwalletNamerequirements (optional vs required) correctly models the domain:
- Ethereum wallets can be auto-detected, so
walletNameis optional- Solana requires explicit wallet selection, so
walletNameis requiredThe union type for
GenerateSignatureenables proper type narrowing based on the provider.packages/clerk-js/src/core/clerk.ts (2)
2260-2265: LGTM! Solana authentication properly delegates to Web3 flow.The
authenticateWithSolanamethod correctly:
- Accepts
AuthenticateWithSolanaParamswith requiredwalletName- Delegates to
authenticateWithWeb3with the appropriate strategy- Follows the established pattern of other wallet-specific methods (Metamask, Coinbase, etc.)
2267-2302: Based on my verification, I have confirmed the review comment through examining:
Type definitions:
AuthenticateWithWeb3ParamsandClerkAuthenticateWithWeb3Paramsboth definewalletNameas optional (walletName?: string)Propagation flow:
- ✅
walletNameis destructured inClerk.authenticateWithWeb3(line 2275)- ✅ Passed to
getWeb3Identifier(line 2284)- ✅ Forwarded to
SignIn.authenticateWithWeb3(line 2317)- ✅ Forwarded to
SignUp.authenticateWithWeb3(line 2327)Optional handling:
- ✅
SignIn.authenticateWithWeb3validateswalletNameis required only for Solana (line 394-395)- ✅
SignUpprovides separateauthenticateWithSolana()method that enforceswalletNamerequirement- ✅ Non-Solana providers (Metamask, Coinbase, Base, OKX) do not pass
walletName- ✅
getWeb3Identifiercorrectly handles optionalwalletNameparameter✅ walletName is correctly propagated through the entire authentication flow with proper handling of its optional nature for non-Solana providers.
packages/clerk-js/src/core/resources/SignIn.ts (2)
394-396: LGTM! Proper validation for Solana-specific requirements.The validation ensures that
walletNameis provided when using Solana, which is essential since Solana wallets cannot be auto-detected like Ethereum wallets. This prevents runtime errors downstream in the signature generation flow.
472-480: LGTM! Solana authentication method follows established patterns.The
authenticateWithSolanamethod correctly:
- Requires
walletNamein the params- Fetches the Solana identifier using the provided wallet name
- Delegates to
authenticateWithWeb3with the appropriate strategy and parameters
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (1)
packages/clerk-js/src/utils/web3.ts (1)
1-3: RevisitSolanaWalletAdapterWalletimport and cast – likely unnecessary and brittleThe import and cast here are fragile:
import type { SolanaWalletAdapterWallet } from '@solana/wallet-standard';(wallet as SolanaWalletAdapterWallet).accountsand(wallet as SolanaWalletAdapterWallet).features[SolanaSignMessage]...Unless your version of
@solana/wallet-standardexplicitly exportsSolanaWalletAdapterWallet, this will fail type‑checking. Even if it does,getInjectedWeb3SolanaProviders().get(walletName)is conceptually returning a Wallet‑StandardWallet, so a narrower adapter‑specific type is not really needed here.A more robust approach would be:
- Use the canonical Wallet Standard types (e.g.
Wallet/WalletAccountfrom@wallet-standard/baseor your existing Solana wallet helper types), and- Drop the explicit
SolanaWalletAdapterWalletcast, accessingwallet.accountsandwallet.features[SolanaSignMessage]through those types or a local structural type.This avoids tight coupling to a specific adapter type and reduces the risk of type mismatch when upgrading Solana dependencies.
Does the `@solana/wallet-standard` package (at the version used in this repo) export a `SolanaWalletAdapterWallet` type, or should we instead type injected Solana wallets using the standard `Wallet` / `WalletAccount` interfaces plus the `solana:signMessage` feature types?Also applies to: 53-61
🧹 Nitpick comments (3)
packages/clerk-js/src/core/resources/SignIn.ts (2)
215-221: Solana Web3 auth wiring looks consistent; small type/style nitsThe Solana additions here line up well with existing Web3 providers:
- Adding
'web3_solana_signature'toprepareFirstFactorand reusingWeb3SignatureConfigis consistent.authenticateWithWeb3’sproviderderivation and thewalletNameguard forprovider === 'solana'match the requirement that Solana flows always know the wallet name.authenticateWithSolanacorrectly resolves the identifier viagetSolanaIdentifierand delegates toauthenticateWithWeb3usinggenerateSignatureWithSolana.Minor cleanups you may want to consider:
authenticateWithSolanadeclaresparams: AuthenticateWithSolanaParams(non‑optional), soparams?.walletNamecan just beparams.walletNamein both thegetSolanaIdentifiercall and the object passed toauthenticateWithWeb3.- The Solana‑specific
walletNamecheck inauthenticateWithWeb3overlaps with the guard ingetWeb3Wallet(viaerrorThrower) on the utils side; if you want a single source of truth, you could rely on the utils guard and keep only the friendlierclerkMissingOptionErrorhere (or vice‑versa). Not critical, but worth aligning to avoid future drift.Also applies to: 386-397, 413-425, 472-480
984-1014: SignInFuture.web3 Solana branch is correct; consider stronger typing & error consistencyThe
web3future API’s Solana branch is wired correctly:
providerderivation fromstrategymatches the main SignIn path.- The Solana case enforces
params.walletName, obtains the identifier viagetSolanaIdentifier, and usesgenerateSignatureWithSolana.- The shared
generateSignature: GenerateSignatureabstraction keeps Solana and EVM paths consistent.A couple of refinements you might want to make:
- Replace
throw new Error('walletName is required for solana web3 authentication');with a typed error (e.g.ClerkRuntimeErrorwith a specificcode) to match other error paths in this class and make downstream handling easier.params?.walletNameis unnecessary sinceparamsis non‑nullable;params.walletNameis sufficient and slightly clearer.These are cosmetic; behavior-wise this looks good.
Also applies to: 1038-1058
packages/clerk-js/src/utils/web3.ts (1)
20-37: getWeb3Identifier / getWeb3Wallet Solana path behavior looks good; minor polishBehavior-wise, the Solana additions are consistent:
getWeb3Identifiernow threadswalletNameintogetWeb3Walletand uses the Wallet Standardstandard:connectfeature to derive the address.getWeb3WalletenforceswalletNamefor Solana viaerrorThrower, then delegates togetInjectedWeb3SolanaProviders().get(walletName).- Non‑Solana providers still go through the existing Coinbase/Base SDK or injected Ethereum providers, preserving previous behavior.
Minor nits you might consider:
- After
errorThrower.throw(...)in the Solana branch, thereturn;is effectively unreachable (the throw isnever), so it can be dropped for clarity.- Since
getWeb3Walletalready enforceswalletNamefor Solana, you may not need additional guards at higher levels unless you specifically want different error shapes/messages there.Nothing blocking here; just possible cleanups.
Also applies to: 93-95, 122-168
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Disabled knowledge base sources:
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (3)
packages/clerk-js/src/core/resources/SignIn.ts(12 hunks)packages/clerk-js/src/utils/web3.ts(4 hunks)packages/shared/src/types/web3Wallet.ts(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- packages/shared/src/types/web3Wallet.ts
🧰 Additional context used
📓 Path-based instructions (7)
**/*.{js,jsx,ts,tsx}
📄 CodeRabbit inference engine (.cursor/rules/development.mdc)
All code must pass ESLint checks with the project's configuration
Files:
packages/clerk-js/src/utils/web3.tspackages/clerk-js/src/core/resources/SignIn.ts
**/*.{js,jsx,ts,tsx,json,md,yml,yaml}
📄 CodeRabbit inference engine (.cursor/rules/development.mdc)
Use Prettier for consistent code formatting
Files:
packages/clerk-js/src/utils/web3.tspackages/clerk-js/src/core/resources/SignIn.ts
packages/**/src/**/*.{ts,tsx}
📄 CodeRabbit inference engine (.cursor/rules/development.mdc)
TypeScript is required for all packages
Files:
packages/clerk-js/src/utils/web3.tspackages/clerk-js/src/core/resources/SignIn.ts
**/*.{ts,tsx,js,jsx}
📄 CodeRabbit inference engine (.cursor/rules/development.mdc)
Follow established naming conventions (PascalCase for components, camelCase for variables)
Prefer importing types from
@clerk/shared/typesinstead of the deprecated@clerk/typesalias
Files:
packages/clerk-js/src/utils/web3.tspackages/clerk-js/src/core/resources/SignIn.ts
packages/**/src/**/*.{ts,tsx,js,jsx}
📄 CodeRabbit inference engine (.cursor/rules/development.mdc)
packages/**/src/**/*.{ts,tsx,js,jsx}: Maintain comprehensive JSDoc comments for public APIs
Use tree-shaking friendly exports
Validate all inputs and sanitize outputs
All public APIs must be documented with JSDoc
Use dynamic imports for optional features
Provide meaningful error messages to developers
Include error recovery suggestions where applicable
Log errors appropriately for debugging
Lazy load components and features when possible
Implement proper caching strategies
Use efficient data structures and algorithms
Implement proper logging with different levels
Files:
packages/clerk-js/src/utils/web3.tspackages/clerk-js/src/core/resources/SignIn.ts
**/*.ts?(x)
📄 CodeRabbit inference engine (.cursor/rules/development.mdc)
Use proper TypeScript error types
Files:
packages/clerk-js/src/utils/web3.tspackages/clerk-js/src/core/resources/SignIn.ts
**/*.{ts,tsx}
📄 CodeRabbit inference engine (.cursor/rules/typescript.mdc)
**/*.{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
Implement type guards forunknowntypes using the patternfunction isType(value: unknown): value is Type
Useinterfacefor object shapes that might be extended
Usetypefor unions, primitives, and computed types
Preferreadonlyproperties for immutable data structures
Useprivatefor internal implementation details in classes
Useprotectedfor inheritance hierarchies
Usepublicexplicitly for clarity in public APIs
Use mixins for shared behavior across unrelated classes in TypeScript
Use generic constraints with bounded type parameters like<T extends { id: string }>
Use utility types likeOmit,Partial, andPickfor data transformation instead of manual type construction
Use discriminated unions instead of boolean flags for state management and API responses
Use mapped types for transforming object types
Use conditional types for type-level logic
Leverage template literal types for string manipulation at the type level
Use ES6 imports/exports consistently
Use default exports sparingly, prefer named exports
Document functions with JSDoc comments including @param, @returns, @throws, and @example tags
Create custom error classes that extend Error for specific error types
Use the Result pattern for error handling instead of throwing exceptions
Use optional chaining (?.) and nullish coalescing (??) operators for safe property access
Let TypeScript infer obvious types to reduce verbosity
Useconst assertionswithas constfor literal types
Usesatisfiesoperator for type checking without widening types
Declare readonly arrays and objects for immutable data structures
Use spread operator and array spread for immutable updates instead of mutations
Use lazy loading for large types...
Files:
packages/clerk-js/src/utils/web3.tspackages/clerk-js/src/core/resources/SignIn.ts
🧬 Code graph analysis (1)
packages/clerk-js/src/utils/web3.ts (4)
packages/shared/src/types/web3.ts (1)
Web3Provider(15-15)packages/shared/src/types/web3Wallet.ts (2)
GenerateSignature(28-28)GenerateSignatureParams(37-42)packages/clerk-js/src/utils/injectedWeb3SolanaProviders.ts (3)
wallet(24-26)wallet(28-30)getInjectedWeb3SolanaProviders(66-66)packages/clerk-js/src/utils/injectedWeb3EthProviders.ts (1)
getInjectedWeb3EthProviders(75-75)
⏰ 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: Build Packages
- GitHub Check: Formatting | Dedupe | Changeset
- GitHub Check: Analyze (javascript-typescript)
- GitHub Check: semgrep-cloud-platform/scan
- GitHub Check: semgrep-cloud-platform/scan
kduprey
force-pushed
the
kenton/user-3770-add-functionality-to-clerk-js-to-be-able-to-detect-all
branch
from
ba0adbf to
b2d0f22
Compare
There was a problem hiding this comment.
Actionable comments posted: 2
♻️ Duplicate comments (5)
packages/clerk-js/src/utils/web3.ts (4)
2-2: Remove non-existentSolanaWalletAdapterWalletimport.The type
SolanaWalletAdapterWalletdoes not exist in@solana/wallet-standard. Past reviews with web search confirmed this package does not export this type. The correct approach is to use theWallettype from@wallet-standard/base, which hasaccounts: readonly WalletAccount[]andfeatureswithsolana:signMessage.Remove this import:
-import type { SolanaWalletAdapterWallet } from '@solana/wallet-standard';And if explicit typing is needed in the code, import and use:
import type { Wallet } from '@wallet-standard/base';Based on learnings, this was flagged in previous reviews and confirmed via web search.
56-65: Fix type cast and verify signature encoding format.Two issues here:
Critical: Lines 56 and 61 cast to
SolanaWalletAdapterWallet, which doesn't exist in@solana/wallet-standard(see comment on Line 2).Major: Line 65 uses
Array.from(signedMessages[0].signature).toString(), which creates a comma-separated string like"1,2,3,4,...". Past reviews discussed encoding and decided not to use bs58. Please verify this format is what the backend expects—if the backend needs a continuous string of digits, use.join('')instead of.toString().Apply this diff to fix the cast issue (after fixing the import):
+import type { Wallet } from '@wallet-standard/base'; + if (provider === 'solana') { try { - const walletAccount = (wallet as SolanaWalletAdapterWallet).accounts.find(a => a.address === identifier); + const walletAccount = wallet.accounts.find(a => a.address === identifier); if (!walletAccount) { console.warn(`Wallet account with address ${identifier} not found`); return ''; } - const signedMessages = await (wallet as SolanaWalletAdapterWallet).features[SolanaSignMessage]?.signMessage({ + const signedMessages = await wallet.features[SolanaSignMessage]?.signMessage({ account: walletAccount, message: new TextEncoder().encode(nonce), });For the signature format, verify with the backend team whether comma-separated format is correct or if it should be:
return signedMessages?.[0]?.signature ? Array.from(signedMessages[0].signature).join('') : '';Based on learnings, the cast issue was flagged in previous reviews.
101-106: MakewalletNameparameter required instead of optional.The
walletNameparameter is typed as optional (walletName?: string) but immediately validated as required with an error throw. This creates unnecessary runtime validation for something that can be enforced at compile time.Apply this diff:
-export async function getSolanaIdentifier(walletName?: string): Promise<string> { - if (!walletName) { - throw new Error('walletName is required for solana web3 authentication'); - } +export async function getSolanaIdentifier(walletName: string): Promise<string> { return await getWeb3Identifier({ provider: 'solana', walletName }); }This enforces the requirement at the type level, preventing invalid calls at compile time.
Based on learnings, past reviews also suggested walletName should be required.
129-131: AddwalletNameto Solana signature params for type safety.The
generateSignatureWithSolanafunction usesGenerateSignatureParams(Lines 108-111), which only includesidentifierandnonce. However, Solana authentication requireswalletName(as enforced ingetWeb3Walletat Lines 171-172). This means callers can compile code that callsgenerateSignatureWithSolana({ identifier, nonce })withoutwalletName, only to encounter a runtime error.Apply this diff to enforce
walletNameat the type level:type GenerateSignatureParams = { identifier: string; nonce: string; }; +type GenerateSolanaSignatureParams = GenerateSignatureParams & { + walletName: string; +}; -export async function generateSignatureWithSolana(params: GenerateSignatureParams): Promise<string> { - return await generateWeb3Signature({ ...params, provider: 'solana' }); +export async function generateSignatureWithSolana(params: GenerateSolanaSignatureParams): Promise<string> { + return await generateWeb3Signature({ ...params, provider: 'solana' }); }Based on learnings, a past review by coderabbitai flagged this exact issue and suggested this fix.
packages/clerk-js/src/core/resources/SignIn.ts (1)
472-480: Makeparamsrequired inauthenticateWithSolana.The
paramsparameter is marked optional (params?: AuthenticateWithSolanaParams), but the method body immediately accessesparams.walletNamewithout a null check on Line 473. SinceAuthenticateWithSolanaParamsrequireswalletName(per the type definition in the relevant code snippets), and the method cannot function without it,paramsshould be required.Apply this diff:
- public authenticateWithSolana = async (params?: AuthenticateWithSolanaParams): Promise<SignInResource> => { + public authenticateWithSolana = async (params: AuthenticateWithSolanaParams): Promise<SignInResource> => {Based on learnings, past reviews also flagged this issue.
🧹 Nitpick comments (6)
packages/clerk-js/src/ui/components/SignUp/SignUpStartSolanaWalletsCard.tsx (3)
38-52: Add card loading/idle handling around the Solana auth callThe
web3AuthCallbackkicks off an async auth flow but never updates the card loading state. For consistency with other flows and the guidelines about callingcard.setLoading()/card.setError()on submissions, consider wrapping this in loading/idle transitions so the UI is disabled and shows progress while auth is in flight.For example:
- <Web3WalletButtons - web3AuthCallback={({ walletName }) => { - return clerk - .authenticateWithWeb3({ + <Web3WalletButtons + web3AuthCallback={({ walletName }) => { + card.setLoading(); + return clerk + .authenticateWithWeb3({ customNavigate: router.navigate, redirectUrl: ctx.afterSignUpUrl || '/', signUpContinueUrl: '../continue', strategy: 'web3_solana_signature', unsafeMetadata: ctx.unsafeMetadata, // TODO: Add support to pass legalAccepted status // legalAccepted: , walletName, }) - .catch(err => web3CallbackErrorHandler(err, card.setError)); + .catch(err => web3CallbackErrorHandler(err, card.setError)) + .finally(() => card.setIdle()); }} />
40-50: Confirm whetherauthenticateWithWeb3is the intended API vsauthenticateWithSolanaThe PR description mentions adding an
authenticateWithSolanasurface toClerk, but this card is still usingclerk.authenticateWithWeb3withstrategy: 'web3_solana_signature'. If the new Solana‑specific helper is meant to be the canonical path for these flows, it might be preferable to call that here for clearer intent and stronger typing.Please double‑check the intended public API and update this call if
authenticateWithSolanais the preferred entrypoint, or document whyauthenticateWithWeb3remains correct here (e.g. for backward compatibility or shared implementation).
67-69: Add JSDoc for the exportedSignUpStartSolanaWalletsCardcomponentSince this card is exported from the UI package, it effectively becomes part of the public surface. To align with the guidelines about documenting public APIs, consider adding a brief JSDoc describing its purpose and usage.
For example:
-export const SignUpStartSolanaWalletsCard = withRedirectToSignUpTask( +/** + * Sign-up flow card that lets users choose a Solana-capable wallet in the `choose-wallet` step. + * Wrapped with redirect HOCs to respect existing SignUp redirect/task behavior. + */ +export const SignUpStartSolanaWalletsCard = withRedirectToSignUpTask( withRedirectToAfterSignUp(withCardStateProvider(SignUpStartSolanaWalletsCardInner)), );Optionally, you can also add an explicit return type to
SignUpStartSolanaWalletsCardInnerif you want stricter typing for components.packages/clerk-js/src/core/resources/SignIn.ts (1)
1008-1011: Consider validatingwalletNamefor Solana in SignInFuture.web3.The
solanacase callsgetSolanaIdentifier(params.walletName), which will throw an error ifwalletNameis missing (per the implementation in web3.ts). While this is functionally correct, it would be more user-friendly to validatewalletNameupfront in thesolanacase, similar to howauthenticateWithWeb3validates it at Line 394-396.Consider adding early validation:
case 'solana': + if (!params.walletName) { + throw new ClerkRuntimeError('Wallet name is required for Solana authentication', { + code: 'wallet_name_required', + }); + } identifier = await getSolanaIdentifier(params.walletName); generateSignature = generateSignatureWithSolana; break;packages/clerk-js/src/utils/web3.ts (2)
57-60: Throw error instead of returning empty string when wallet account not found.When the wallet account matching the identifier is not found (Lines 57-60), the code logs a warning and returns an empty string. This is inconsistent with the error handling below (Lines 67-75) which throws
ClerkRuntimeError.For consistency and better error propagation:
const walletAccount = wallet.accounts.find(a => a.address === identifier); if (!walletAccount) { - console.warn(`Wallet account with address ${identifier} not found`); - return ''; + throw new ClerkRuntimeError(`Wallet account with address ${identifier} not found`, { + code: 'web3_wallet_account_not_found', + }); }
170-176: Remove unreachable return statement.Line 173 has a
return;statement aftererrorThrower.throw(), which is unreachable becauseerrorThrower.throw()has a return type ofneverand will halt execution. While harmless, removing it improves code clarity.Apply this diff:
if (!walletName || walletName.length === 0) { errorThrower.throw('Wallet name must be provided to get Solana wallet provider'); - return; }Based on learnings, past reviews confirmed that
errorThrower.throw()does indeed throw and halt execution.
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Disabled knowledge base sources:
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (7)
packages/clerk-js/package.json(1 hunks)packages/clerk-js/src/core/resources/SignIn.ts(12 hunks)packages/clerk-js/src/ui/components/SignIn/SignInFactorOneSolanaWalletsCard.tsx(1 hunks)packages/clerk-js/src/ui/components/SignUp/SignUpStartSolanaWalletsCard.tsx(1 hunks)packages/clerk-js/src/ui/elements/Web3WalletButtons.tsx(1 hunks)packages/clerk-js/src/ui/utils/web3CallbackErrorHandler.ts(1 hunks)packages/clerk-js/src/utils/web3.ts(4 hunks)
🚧 Files skipped from review as they are similar to previous changes (3)
- packages/clerk-js/src/ui/utils/web3CallbackErrorHandler.ts
- packages/clerk-js/src/ui/elements/Web3WalletButtons.tsx
- packages/clerk-js/src/ui/components/SignIn/SignInFactorOneSolanaWalletsCard.tsx
🧰 Additional context used
📓 Path-based instructions (13)
**/*.{js,jsx,ts,tsx,json,md,yml,yaml}
📄 CodeRabbit inference engine (.cursor/rules/development.mdc)
Use Prettier for consistent code formatting
Files:
packages/clerk-js/package.jsonpackages/clerk-js/src/ui/components/SignUp/SignUpStartSolanaWalletsCard.tsxpackages/clerk-js/src/core/resources/SignIn.tspackages/clerk-js/src/utils/web3.ts
packages/*/package.json
📄 CodeRabbit inference engine (.cursor/rules/development.mdc)
packages/*/package.json: Packages should export TypeScript types alongside runtime code
Follow semantic versioning for all packagesAll packages must be published under @clerk namespace
Files:
packages/clerk-js/package.json
**/package.json
📄 CodeRabbit inference engine (.cursor/rules/global.mdc)
Use pnpm as the package manager for this monorepo
Files:
packages/clerk-js/package.json
packages/clerk-js/src/ui/**/*.{ts,tsx}
📄 CodeRabbit inference engine (.cursor/rules/clerk-js-ui.mdc)
packages/clerk-js/src/ui/**/*.{ts,tsx}: Element descriptors should be written in camelCase
Use useCardState for card-level state management
Use useFormState for form-level state management
Use useLoadingStatus for managing loading states
Use useFormControl hook for form field state management with validation and localization support
All rendered values must be localized using useLocalizations hook - hard coded values are not allowed
Use localizationKeys for translating UI text with support for parameters and error messages
Use handleError utility for API error handling and provide field states for proper error mapping
Use the styled system sx prop with theme tokens for custom styling instead of inline styles
Use the Card component pattern with Card.Root, Card.Header, Card.Title, Card.Content, and Card.Footer for consistent card layouts
Use FormContainer with headerTitle and headerSubtitle localization keys combined with Form.Root and FormButtons for consistent form layouts
When form submission occurs, manage loading and error states by calling status.setLoading(), card.setLoading(), and card.setError() appropriately
Files:
packages/clerk-js/src/ui/components/SignUp/SignUpStartSolanaWalletsCard.tsx
**/*.{js,jsx,ts,tsx}
📄 CodeRabbit inference engine (.cursor/rules/development.mdc)
All code must pass ESLint checks with the project's configuration
Files:
packages/clerk-js/src/ui/components/SignUp/SignUpStartSolanaWalletsCard.tsxpackages/clerk-js/src/core/resources/SignIn.tspackages/clerk-js/src/utils/web3.ts
packages/**/src/**/*.{ts,tsx}
📄 CodeRabbit inference engine (.cursor/rules/development.mdc)
TypeScript is required for all packages
Files:
packages/clerk-js/src/ui/components/SignUp/SignUpStartSolanaWalletsCard.tsxpackages/clerk-js/src/core/resources/SignIn.tspackages/clerk-js/src/utils/web3.ts
**/*.{ts,tsx,js,jsx}
📄 CodeRabbit inference engine (.cursor/rules/development.mdc)
Follow established naming conventions (PascalCase for components, camelCase for variables)
Prefer importing types from
@clerk/shared/typesinstead of the deprecated@clerk/typesalias
Files:
packages/clerk-js/src/ui/components/SignUp/SignUpStartSolanaWalletsCard.tsxpackages/clerk-js/src/core/resources/SignIn.tspackages/clerk-js/src/utils/web3.ts
packages/**/src/**/*.{ts,tsx,js,jsx}
📄 CodeRabbit inference engine (.cursor/rules/development.mdc)
packages/**/src/**/*.{ts,tsx,js,jsx}: Maintain comprehensive JSDoc comments for public APIs
Use tree-shaking friendly exports
Validate all inputs and sanitize outputs
All public APIs must be documented with JSDoc
Use dynamic imports for optional features
Provide meaningful error messages to developers
Include error recovery suggestions where applicable
Log errors appropriately for debugging
Lazy load components and features when possible
Implement proper caching strategies
Use efficient data structures and algorithms
Implement proper logging with different levels
Files:
packages/clerk-js/src/ui/components/SignUp/SignUpStartSolanaWalletsCard.tsxpackages/clerk-js/src/core/resources/SignIn.tspackages/clerk-js/src/utils/web3.ts
**/*.ts?(x)
📄 CodeRabbit inference engine (.cursor/rules/development.mdc)
Use proper TypeScript error types
Files:
packages/clerk-js/src/ui/components/SignUp/SignUpStartSolanaWalletsCard.tsxpackages/clerk-js/src/core/resources/SignIn.tspackages/clerk-js/src/utils/web3.ts
**/*.tsx
📄 CodeRabbit inference engine (.cursor/rules/development.mdc)
**/*.tsx: Use error boundaries in React components
Minimize re-renders in React components
**/*.tsx: Use proper type definitions for props and state in React components
Leverage TypeScript's type inference where possible in React components
Use proper event types for handlers in React components
Implement proper generic types for reusable React components
Use proper type guards for conditional rendering in React components
Files:
packages/clerk-js/src/ui/components/SignUp/SignUpStartSolanaWalletsCard.tsx
**/*.{md,tsx}
📄 CodeRabbit inference engine (.cursor/rules/development.mdc)
Update documentation for API changes
Files:
packages/clerk-js/src/ui/components/SignUp/SignUpStartSolanaWalletsCard.tsx
**/*.{jsx,tsx}
📄 CodeRabbit inference engine (.cursor/rules/react.mdc)
**/*.{jsx,tsx}: Always use functional components with hooks instead of class components
Follow PascalCase naming for components (e.g.,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
Separate UI components from business logic components
Use useState for simple state management in React components
Use useReducer for complex state logic in React components
Implement proper state initialization in React components
Use proper state updates with callbacks in React components
Implement proper state cleanup in React components
Use Context API for theme/authentication state management
Implement proper state persistence in React applications
Use React.memo for expensive components
Implement proper useCallback for handlers in React components
Use proper useMemo for expensive computations in React components
Implement proper virtualization for lists in React components
Use proper code splitting with React.lazy in React applications
Implement proper cleanup in useEffect hooks
Use proper refs for DOM access in React components
Implement proper event listener cleanup in React components
Use proper abort controllers for fetch in React components
Implement proper subscription cleanup in React components
Use proper HTML elements for semantic HTML in React components
Implement proper ARIA attributes for accessibility in React components
Use proper heading hierarchy in React components
Implement proper form labels in React components
Use proper button types in React components
Implement proper focus management for keyboard navigation in React components
Use proper keyboard shortcuts in React components
Implement proper tab order in React components
Use proper ...
Files:
packages/clerk-js/src/ui/components/SignUp/SignUpStartSolanaWalletsCard.tsx
**/*.{ts,tsx}
📄 CodeRabbit inference engine (.cursor/rules/typescript.mdc)
**/*.{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
Implement type guards forunknowntypes using the patternfunction isType(value: unknown): value is Type
Useinterfacefor object shapes that might be extended
Usetypefor unions, primitives, and computed types
Preferreadonlyproperties for immutable data structures
Useprivatefor internal implementation details in classes
Useprotectedfor inheritance hierarchies
Usepublicexplicitly for clarity in public APIs
Use mixins for shared behavior across unrelated classes in TypeScript
Use generic constraints with bounded type parameters like<T extends { id: string }>
Use utility types likeOmit,Partial, andPickfor data transformation instead of manual type construction
Use discriminated unions instead of boolean flags for state management and API responses
Use mapped types for transforming object types
Use conditional types for type-level logic
Leverage template literal types for string manipulation at the type level
Use ES6 imports/exports consistently
Use default exports sparingly, prefer named exports
Document functions with JSDoc comments including @param, @returns, @throws, and @example tags
Create custom error classes that extend Error for specific error types
Use the Result pattern for error handling instead of throwing exceptions
Use optional chaining (?.) and nullish coalescing (??) operators for safe property access
Let TypeScript infer obvious types to reduce verbosity
Useconst assertionswithas constfor literal types
Usesatisfiesoperator for type checking without widening types
Declare readonly arrays and objects for immutable data structures
Use spread operator and array spread for immutable updates instead of mutations
Use lazy loading for large types...
Files:
packages/clerk-js/src/ui/components/SignUp/SignUpStartSolanaWalletsCard.tsxpackages/clerk-js/src/core/resources/SignIn.tspackages/clerk-js/src/utils/web3.ts
🧬 Code graph analysis (3)
packages/clerk-js/src/ui/components/SignUp/SignUpStartSolanaWalletsCard.tsx (4)
packages/clerk-js/src/ui/contexts/components/SignUp.ts (1)
useSignUpContext(37-158)packages/clerk-js/src/ui/elements/Web3WalletButtons.tsx (1)
Web3WalletButtons(256-271)packages/clerk-js/src/ui/utils/web3CallbackErrorHandler.ts (1)
web3CallbackErrorHandler(10-23)packages/clerk-js/src/ui/common/withRedirect.tsx (2)
withRedirectToSignUpTask(115-135)withRedirectToAfterSignUp(74-91)
packages/clerk-js/src/core/resources/SignIn.ts (6)
packages/shared/src/types/web3.ts (1)
Web3Provider(15-15)packages/clerk-js/src/core/errors.ts (1)
clerkMissingOptionError(75-77)packages/shared/src/types/clerk.ts (1)
AuthenticateWithSolanaParams(2302-2309)packages/shared/src/types/signIn.ts (1)
SignInResource(36-96)packages/clerk-js/src/utils/web3.ts (2)
getSolanaIdentifier(101-106)generateSignatureWithSolana(129-131)packages/shared/src/types/web3Wallet.ts (1)
GenerateSignature(28-28)
packages/clerk-js/src/utils/web3.ts (3)
packages/shared/src/types/web3.ts (1)
Web3Provider(15-15)packages/clerk-js/src/utils/injectedWeb3SolanaProviders.ts (3)
wallet(24-26)wallet(28-30)getInjectedWeb3SolanaProviders(66-66)packages/clerk-js/src/utils/injectedWeb3EthProviders.ts (1)
getInjectedWeb3EthProviders(75-75)
⏰ 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). (4)
- GitHub Check: Formatting | Dedupe | Changeset
- GitHub Check: Analyze (javascript-typescript)
- GitHub Check: semgrep-cloud-platform/scan
- GitHub Check: semgrep-cloud-platform/scan
🔇 Additional comments (2)
packages/clerk-js/src/core/resources/SignIn.ts (1)
394-396: Good validation for Solana walletName requirement.The validation correctly enforces that
walletNameis required when using the Solana provider, using the establishedclerkMissingOptionErrorpattern.packages/clerk-js/package.json (1)
72-78: All four Solana/wallet-standard dependencies are actively used in the codebase.Verification found imports across multiple files:
@solana/wallet-adapter-base: Used in Web3WalletButtons.tsx for WalletReadyState@solana/wallet-adapter-react: Used in Web3WalletButtons.tsx for ConnectionProvider, useWallet, WalletProvider@solana/wallet-standard: Used in Web3WalletButtons.tsx, web3.ts, and injectedWeb3SolanaProviders.ts for types and MAINNET_ENDPOINT@wallet-standard/core: Used in injectedWeb3SolanaProviders.ts for Wallet type and getWallets() functionNo unnecessary dependencies were found. These packages serve distinct purposes in the Web3 wallet integration and should not be removed.
packages/clerk-js/src/ui/components/SignUp/SignUpStartSolanaWalletsCard.tsx
Outdated
Show resolved
Hide resolved
| if (provider === 'solana') { | ||
| const identifiers = await walletProvider.features[StandardConnect].connect(); | ||
| return (identifiers && identifiers.accounts[0].address) || ''; | ||
| } |
There was a problem hiding this comment.
🛠️ Refactor suggestion | 🟠 Major
Add type safety for Solana wallet features and accounts.
The code accesses walletProvider.features[StandardConnect].connect() and then .accounts[0].address without type annotations. Since the SolanaWalletAdapterWallet type on Line 2 doesn't exist, there's no type safety here.
After fixing the import issue, add proper typing:
if (provider === 'solana') {
const wallet = walletProvider as Wallet; // Wallet from @wallet-standard/base
const connectFeature = wallet.features[StandardConnect];
if (!connectFeature) {
throw new ClerkRuntimeError('Wallet does not support standard:connect', {
code: 'wallet_feature_not_supported',
});
}
const result = await connectFeature.connect();
return (result?.accounts?.[0]?.address) || '';
}This provides better error handling and type safety.
🤖 Prompt for AI Agents
In packages/clerk-js/src/utils/web3.ts around lines 32 to 35, the code calls
walletProvider.features[StandardConnect].connect() and indexes
.accounts[0].address without types or feature existence checks; fix by importing
and casting to the Wallet type from @wallet-standard/base, read the connect
feature into a local variable, check that the feature exists and throw a
ClerkRuntimeError with code 'wallet_feature_not_supported' if missing, then
await connectFeature.connect() into a typed result and safely return
result?.accounts?.[0]?.address || '' to ensure type safety and robust error
handling.
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (1)
packages/clerk-js/src/ui/elements/Web3WalletButtons.tsx (1)
36-68: Avoid long artificial sleeps and duplicate card state management instartWeb3AuthFlow
startWeb3AuthFlowcurrently:
- Calls
card.setLoading(walletName),- On error: sleeps 1s, then calls
card.setError(error), and- In
finally: sleeps an additional 5s, then callscard.setIdle().This has a few downsides:
- Keeps the card “loading” for ~5s even on success, which is unnecessary and may delay user interaction if navigation doesn’t immediately replace the view.
- On error, users are blocked for ~6s before the card returns to idle.
- The
errorcatch variable is implicitlyany/unknownand passed directly tosetError, which expects a typed error shape; this is brittle from a TS perspective.A cleaner approach is to delegate state transitions to
card.runAsyncand drop the arbitrary sleeps, e.g.:- const startWeb3AuthFlow = (walletName: string) => async () => { - card.setLoading(walletName); - try { - await web3AuthCallback({ walletName }); - } catch (error) { - await sleep(1000); - card.setError(error); - } finally { - await sleep(5000); - card.setIdle(); - } - }; + const startWeb3AuthFlow = (walletName: string) => () => + card.runAsync( + web3AuthCallback({ walletName }), + walletName, + ).catch((error: unknown) => { + // optional brief delay purely for UX, if you still want it + return sleep(1000).finally(() => { + card.setError(error as unknown); + }); + });This way the card’s loading/idle lifecycle is consistent with other flows, and you avoid unnecessary delays while keeping type usage explicit.
In @solana/wallet-adapter-react and typical Clerk flows, is there any requirement to hold a loading state for several seconds after a wallet auth call completes, or is it standard to clear loading immediately once the promise settles?
🧹 Nitpick comments (1)
packages/clerk-js/src/ui/elements/Web3WalletButtons.tsx (1)
173-192: Expose an accessible label for the icon-only wallet button
WalletButtonIconrenders only the icon and ignores thelabelprop, which means screen readers may not have any textual description for the button.Consider applying
labelas an accessible name, for example viaaria-label(or visible text if desired):- const { icon, label, id, ...rest } = props; + const { icon, label, id, ...rest } = props; return ( <Button ref={ref} textVariant='buttonLarge' variant='outline' colorScheme='neutral' hoverAsFocus + aria-label={label} sx={t => ({ minHeight: t.sizes.$8, width: '100%', })} {...rest} > {icon} </Button> );This keeps the visual design while making the control discoverable to assistive technologies.
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Disabled knowledge base sources:
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (5)
packages/clerk-js/src/ui/components/SignIn/SignInFactorOneSolanaWalletsCard.tsx(1 hunks)packages/clerk-js/src/ui/components/SignUp/SignUpStartSolanaWalletsCard.tsx(1 hunks)packages/clerk-js/src/ui/elements/Web3WalletButtons.tsx(1 hunks)packages/localizations/src/en-US.ts(2 hunks)packages/shared/src/types/localization.ts(3 hunks)
🧰 Additional context used
📓 Path-based instructions (12)
packages/clerk-js/src/ui/**/*.{ts,tsx}
📄 CodeRabbit inference engine (.cursor/rules/clerk-js-ui.mdc)
packages/clerk-js/src/ui/**/*.{ts,tsx}: Element descriptors should be written in camelCase
Use useCardState for card-level state management
Use useFormState for form-level state management
Use useLoadingStatus for managing loading states
Use useFormControl hook for form field state management with validation and localization support
All rendered values must be localized using useLocalizations hook - hard coded values are not allowed
Use localizationKeys for translating UI text with support for parameters and error messages
Use handleError utility for API error handling and provide field states for proper error mapping
Use the styled system sx prop with theme tokens for custom styling instead of inline styles
Use the Card component pattern with Card.Root, Card.Header, Card.Title, Card.Content, and Card.Footer for consistent card layouts
Use FormContainer with headerTitle and headerSubtitle localization keys combined with Form.Root and FormButtons for consistent form layouts
When form submission occurs, manage loading and error states by calling status.setLoading(), card.setLoading(), and card.setError() appropriately
Files:
packages/clerk-js/src/ui/components/SignIn/SignInFactorOneSolanaWalletsCard.tsxpackages/clerk-js/src/ui/elements/Web3WalletButtons.tsxpackages/clerk-js/src/ui/components/SignUp/SignUpStartSolanaWalletsCard.tsx
**/*.{js,jsx,ts,tsx}
📄 CodeRabbit inference engine (.cursor/rules/development.mdc)
All code must pass ESLint checks with the project's configuration
Files:
packages/clerk-js/src/ui/components/SignIn/SignInFactorOneSolanaWalletsCard.tsxpackages/clerk-js/src/ui/elements/Web3WalletButtons.tsxpackages/clerk-js/src/ui/components/SignUp/SignUpStartSolanaWalletsCard.tsxpackages/shared/src/types/localization.tspackages/localizations/src/en-US.ts
**/*.{js,jsx,ts,tsx,json,md,yml,yaml}
📄 CodeRabbit inference engine (.cursor/rules/development.mdc)
Use Prettier for consistent code formatting
Files:
packages/clerk-js/src/ui/components/SignIn/SignInFactorOneSolanaWalletsCard.tsxpackages/clerk-js/src/ui/elements/Web3WalletButtons.tsxpackages/clerk-js/src/ui/components/SignUp/SignUpStartSolanaWalletsCard.tsxpackages/shared/src/types/localization.tspackages/localizations/src/en-US.ts
packages/**/src/**/*.{ts,tsx}
📄 CodeRabbit inference engine (.cursor/rules/development.mdc)
TypeScript is required for all packages
Files:
packages/clerk-js/src/ui/components/SignIn/SignInFactorOneSolanaWalletsCard.tsxpackages/clerk-js/src/ui/elements/Web3WalletButtons.tsxpackages/clerk-js/src/ui/components/SignUp/SignUpStartSolanaWalletsCard.tsxpackages/shared/src/types/localization.tspackages/localizations/src/en-US.ts
**/*.{ts,tsx,js,jsx}
📄 CodeRabbit inference engine (.cursor/rules/development.mdc)
Follow established naming conventions (PascalCase for components, camelCase for variables)
Prefer importing types from
@clerk/shared/typesinstead of the deprecated@clerk/typesalias
Files:
packages/clerk-js/src/ui/components/SignIn/SignInFactorOneSolanaWalletsCard.tsxpackages/clerk-js/src/ui/elements/Web3WalletButtons.tsxpackages/clerk-js/src/ui/components/SignUp/SignUpStartSolanaWalletsCard.tsxpackages/shared/src/types/localization.tspackages/localizations/src/en-US.ts
packages/**/src/**/*.{ts,tsx,js,jsx}
📄 CodeRabbit inference engine (.cursor/rules/development.mdc)
packages/**/src/**/*.{ts,tsx,js,jsx}: Maintain comprehensive JSDoc comments for public APIs
Use tree-shaking friendly exports
Validate all inputs and sanitize outputs
All public APIs must be documented with JSDoc
Use dynamic imports for optional features
Provide meaningful error messages to developers
Include error recovery suggestions where applicable
Log errors appropriately for debugging
Lazy load components and features when possible
Implement proper caching strategies
Use efficient data structures and algorithms
Implement proper logging with different levels
Files:
packages/clerk-js/src/ui/components/SignIn/SignInFactorOneSolanaWalletsCard.tsxpackages/clerk-js/src/ui/elements/Web3WalletButtons.tsxpackages/clerk-js/src/ui/components/SignUp/SignUpStartSolanaWalletsCard.tsxpackages/shared/src/types/localization.tspackages/localizations/src/en-US.ts
**/*.ts?(x)
📄 CodeRabbit inference engine (.cursor/rules/development.mdc)
Use proper TypeScript error types
Files:
packages/clerk-js/src/ui/components/SignIn/SignInFactorOneSolanaWalletsCard.tsxpackages/clerk-js/src/ui/elements/Web3WalletButtons.tsxpackages/clerk-js/src/ui/components/SignUp/SignUpStartSolanaWalletsCard.tsxpackages/shared/src/types/localization.tspackages/localizations/src/en-US.ts
**/*.tsx
📄 CodeRabbit inference engine (.cursor/rules/development.mdc)
**/*.tsx: Use error boundaries in React components
Minimize re-renders in React components
**/*.tsx: Use proper type definitions for props and state in React components
Leverage TypeScript's type inference where possible in React components
Use proper event types for handlers in React components
Implement proper generic types for reusable React components
Use proper type guards for conditional rendering in React components
Files:
packages/clerk-js/src/ui/components/SignIn/SignInFactorOneSolanaWalletsCard.tsxpackages/clerk-js/src/ui/elements/Web3WalletButtons.tsxpackages/clerk-js/src/ui/components/SignUp/SignUpStartSolanaWalletsCard.tsx
**/*.{md,tsx}
📄 CodeRabbit inference engine (.cursor/rules/development.mdc)
Update documentation for API changes
Files:
packages/clerk-js/src/ui/components/SignIn/SignInFactorOneSolanaWalletsCard.tsxpackages/clerk-js/src/ui/elements/Web3WalletButtons.tsxpackages/clerk-js/src/ui/components/SignUp/SignUpStartSolanaWalletsCard.tsx
**/*.{jsx,tsx}
📄 CodeRabbit inference engine (.cursor/rules/react.mdc)
**/*.{jsx,tsx}: Always use functional components with hooks instead of class components
Follow PascalCase naming for components (e.g.,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
Separate UI components from business logic components
Use useState for simple state management in React components
Use useReducer for complex state logic in React components
Implement proper state initialization in React components
Use proper state updates with callbacks in React components
Implement proper state cleanup in React components
Use Context API for theme/authentication state management
Implement proper state persistence in React applications
Use React.memo for expensive components
Implement proper useCallback for handlers in React components
Use proper useMemo for expensive computations in React components
Implement proper virtualization for lists in React components
Use proper code splitting with React.lazy in React applications
Implement proper cleanup in useEffect hooks
Use proper refs for DOM access in React components
Implement proper event listener cleanup in React components
Use proper abort controllers for fetch in React components
Implement proper subscription cleanup in React components
Use proper HTML elements for semantic HTML in React components
Implement proper ARIA attributes for accessibility in React components
Use proper heading hierarchy in React components
Implement proper form labels in React components
Use proper button types in React components
Implement proper focus management for keyboard navigation in React components
Use proper keyboard shortcuts in React components
Implement proper tab order in React components
Use proper ...
Files:
packages/clerk-js/src/ui/components/SignIn/SignInFactorOneSolanaWalletsCard.tsxpackages/clerk-js/src/ui/elements/Web3WalletButtons.tsxpackages/clerk-js/src/ui/components/SignUp/SignUpStartSolanaWalletsCard.tsx
**/*.{ts,tsx}
📄 CodeRabbit inference engine (.cursor/rules/typescript.mdc)
**/*.{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
Implement type guards forunknowntypes using the patternfunction isType(value: unknown): value is Type
Useinterfacefor object shapes that might be extended
Usetypefor unions, primitives, and computed types
Preferreadonlyproperties for immutable data structures
Useprivatefor internal implementation details in classes
Useprotectedfor inheritance hierarchies
Usepublicexplicitly for clarity in public APIs
Use mixins for shared behavior across unrelated classes in TypeScript
Use generic constraints with bounded type parameters like<T extends { id: string }>
Use utility types likeOmit,Partial, andPickfor data transformation instead of manual type construction
Use discriminated unions instead of boolean flags for state management and API responses
Use mapped types for transforming object types
Use conditional types for type-level logic
Leverage template literal types for string manipulation at the type level
Use ES6 imports/exports consistently
Use default exports sparingly, prefer named exports
Document functions with JSDoc comments including @param, @returns, @throws, and @example tags
Create custom error classes that extend Error for specific error types
Use the Result pattern for error handling instead of throwing exceptions
Use optional chaining (?.) and nullish coalescing (??) operators for safe property access
Let TypeScript infer obvious types to reduce verbosity
Useconst assertionswithas constfor literal types
Usesatisfiesoperator for type checking without widening types
Declare readonly arrays and objects for immutable data structures
Use spread operator and array spread for immutable updates instead of mutations
Use lazy loading for large types...
Files:
packages/clerk-js/src/ui/components/SignIn/SignInFactorOneSolanaWalletsCard.tsxpackages/clerk-js/src/ui/elements/Web3WalletButtons.tsxpackages/clerk-js/src/ui/components/SignUp/SignUpStartSolanaWalletsCard.tsxpackages/shared/src/types/localization.tspackages/localizations/src/en-US.ts
packages/localizations/**
📄 CodeRabbit inference engine (.cursor/rules/monorepo.mdc)
packages/localizations/**: Localization support must include translations for 30+ languages using a modular localization system
Support RTL languages in the localization system
Files:
packages/localizations/src/en-US.ts
🧬 Code graph analysis (2)
packages/clerk-js/src/ui/components/SignIn/SignInFactorOneSolanaWalletsCard.tsx (6)
packages/clerk-js/src/ui/elements/contexts/index.tsx (2)
useCardState(42-70)withCardStateProvider(72-81)packages/clerk-js/src/ui/customizables/Flow.tsx (1)
Flow(41-44)packages/clerk-js/src/ui/elements/Header.tsx (1)
Header(103-108)packages/clerk-js/src/ui/elements/Web3WalletButtons.tsx (1)
Web3WalletButtons(264-279)packages/clerk-js/src/ui/utils/web3CallbackErrorHandler.ts (1)
web3CallbackErrorHandler(10-23)packages/clerk-js/src/ui/common/withRedirect.tsx (2)
withRedirectToSignInTask(93-113)withRedirectToAfterSignIn(55-72)
packages/clerk-js/src/ui/elements/Web3WalletButtons.tsx (5)
packages/clerk-js/src/ui/elements/contexts/index.tsx (1)
useCardState(42-70)packages/clerk-js/src/ui/elements/utils.ts (1)
distributeStrategiesIntoRows(7-54)packages/clerk-js/src/ui/elements/LinkRenderer.tsx (1)
LinkRenderer(12-44)packages/clerk-js/src/ui/common/ProviderInitialIcon.tsx (1)
ProviderInitialIcon(12-42)packages/clerk-js/src/ui/styledSystem/types.ts (1)
PropsOfComponent(58-58)
⏰ 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). (3)
- GitHub Check: semgrep-cloud-platform/scan
- GitHub Check: semgrep-cloud-platform/scan
- GitHub Check: Analyze (javascript-typescript)
🔇 Additional comments (4)
packages/shared/src/types/localization.ts (1)
372-376: web3Solana and web3WalletButtons localization shapes look consistentThe added
signUp.web3Solana,signIn.web3Solana, andweb3WalletButtonsblocks are structurally consistent with existing localization patterns and align with how the keys are consumed in the new Solana UI components. No issues from a typing/shape perspective.Also applies to: 548-551, 1296-1300
packages/clerk-js/src/ui/components/SignUp/SignUpStartSolanaWalletsCard.tsx (1)
15-69: Sign-up Solana wallet card wiring and localization look correctThe card correctly uses the
signUp.web3Solana.*localization keys, delegates wallet selection toWeb3WalletButtons, and passes Solana-specific params (strategy: 'web3_solana_signature',walletName,unsafeMetadata, redirects) intoauthenticateWithWeb3with centralized error handling. This matches the intended Solana sign-up flow.packages/localizations/src/en-US.ts (1)
744-747: Solana and web3 wallet button localizations are consistent and parameter-safeThe new
signIn.web3Solana,signUp.web3Solana, andweb3WalletButtonsstrings are well-phrased, use the correctwalletNameandsolanaWalletsLinkplaceholders, and align with the corresponding localization types and component usages.Also applies to: 840-849
packages/clerk-js/src/ui/components/SignIn/SignInFactorOneSolanaWalletsCard.tsx (1)
15-67: Factor-one Solana sign-in card is wired correctly into the flowThe component cleanly integrates Solana wallet selection into factor-one sign-in: it uses the new
signIn.web3Solana.*localization keys, passes the expected Solana options (strategy: 'web3_solana_signature',walletName,secondFactorUrl, combined-flowsignUpContinueUrl) toauthenticateWithWeb3, and centralizes error handling viaweb3CallbackErrorHandler.
| export const Web3WalletButtons = (props: Web3WalletButtonsProps) => { | ||
| const network = MAINNET_ENDPOINT; | ||
| const wallets = useMemo(() => [], [network]); | ||
| return ( | ||
| <ConnectionProvider endpoint={network}> | ||
| <WalletProvider | ||
| wallets={wallets} | ||
| onError={err => { | ||
| console.error(err); | ||
| }} | ||
| > | ||
| <Web3WalletButtonsInner web3AuthCallback={props.web3AuthCallback} /> | ||
| </WalletProvider> | ||
| </ConnectionProvider> | ||
| ); | ||
| }; |
There was a problem hiding this comment.
WalletProvider is always given an empty wallets array, so no wallets can ever be selected
Web3WalletButtons memoizes wallets as [] and passes that into WalletProvider. As a result, useWallet().wallets in Web3WalletButtonsInner will always be empty, installedWallets.length will always be 0, and users will only ever see the “no Solana Web3 wallets detected” message, never actual wallet options.
You’ll want to populate wallets with the detected/adapted Solana wallets (e.g., from your injectedWeb3SolanaProviders / wallet-standard integration) so that useWallet can expose them to the UI.
🤖 Prompt for AI Agents
packages/clerk-js/src/ui/elements/Web3WalletButtons.tsx around lines 264-279:
the component memoizes wallets as an empty array and passes that into
WalletProvider, so no wallets are ever exposed to useWallet; replace the empty
memo with a computed list of adapted/detected Solana wallets (e.g., map
injectedWeb3SolanaProviders or other wallet-standard adapters into the expected
wallet objects), use useMemo to derive that list from network and provider
detection results so it remains stable, and pass the populated wallets array
into WalletProvider so Web3WalletButtonsInner can read installed wallets; ensure
the adapters conform to the WalletProvider API and include any necessary imports
or detection logic.
There was a problem hiding this comment.
The wallets are automatically detected at page load based on if they support the Wallet Standard for Solana wallets, and this error message is not present to users due to this autonomous flow within the browser window on load.
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
@solana/wallet-adapter-react WalletProvider empty wallets array auto-discovery wallet-standard
💡 Result:
Yes — passing an empty array to WalletProvider enables Wallet Standard auto-discovery (the adapter will detect Wallet‑Standard wallets at runtime). This is the intended pattern when all target wallets implement the Wallet Standard; you only need to include explicit adapters for legacy/non‑standard wallets or to support certain iOS behaviors. [1][2][3]
Notes / gotchas:
- iOS has limited auto‑discovery (Safari/in‑app browsers or Safari extensions are required); many developers still include explicit adapters (Phantom, Solflare, etc.) to ensure iOS users can connect. [3]
- For Mobile Wallet Adapter / MWA behavior, follow the Solana docs and ensure you’re on a wallet-adapter version that includes/supports the relevant features (upgrade guidance referenced in Solana docs). [4]
References
- Solana developers cookbook: WalletProvider with empty wallets array (auto-discovery). [1]
- Solana Stack Exchange discussion on using Wallet Standard with WalletAdapter (example using wallets = []). [2]
- iOS limitations and recommendation to include explicit adapters for iOS. [3]
- Solana Mobile / MWA migration notes and wallet-adapter version guidance. [4]
Sources:
[1] Solana developers cookbook — Connect a Wallet with React.
[2] Solana Stack Exchange — "How to use the wallet standard?"
[3] Solana Stack Exchange — "Wallet Adapter (Standard) doesn't work on the iOS device."
[4] Solana Mobile docs — Migrate to Wallet Standard / MWA guidance.
@kduprey, you're absolutely right! I've confirmed that passing an empty array to WalletProvider is the intended pattern for enabling Wallet Standard auto-discovery. According to the Solana documentation, when wallets={[]} is used, the adapter automatically detects wallets that implement the Wallet Standard at runtime—exactly as you described.
This is the recommended approach when targeting Wallet Standard-compliant wallets, and you only need to include explicit adapters for legacy wallets or specific platform requirements.
One minor note from the documentation: iOS has some limitations with auto-discovery (requires Safari or Safari extensions), so some developers include explicit adapters (like Phantom, Solflare) to ensure iOS users can connect. This might be worth considering depending on your target audience, but it's not a blocker for the core functionality.
Thank you for the clarification—the implementation is correct as-is!
✏️ Learnings added
Learnt from: kduprey
Repo: clerk/javascript PR: 7293
File: packages/clerk-js/src/ui/elements/Web3WalletButtons.tsx:262-277
Timestamp: 2025-12-04T09:35:20.152Z
Learning: In packages/clerk-js/src/ui/elements/Web3WalletButtons.tsx, passing an empty wallets array (`wallets={[]}`) to solana/wallet-adapter-react's WalletProvider is the correct pattern for enabling Wallet Standard auto-discovery. Wallets that implement the Wallet Standard are automatically detected at runtime without requiring explicit adapters.
Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.
There was a problem hiding this comment.
Actionable comments posted: 2
♻️ Duplicate comments (2)
packages/clerk-js/src/utils/web3.ts (2)
32-35: Add safety checks for Solana StandardConnect feature.The code directly accesses
walletProvider.features[StandardConnect].connect()without verifying the feature exists. If the wallet doesn't supportstandard:connect, this will throw an error.Apply this diff to add proper feature validation:
if (provider === 'solana') { - const identifiers = await walletProvider.features[StandardConnect].connect(); - return (identifiers && identifiers.accounts[0].address) || ''; + const connectFeature = walletProvider.features[StandardConnect]; + if (!connectFeature) { + throw new ClerkRuntimeError('Wallet does not support standard:connect', { + code: 'wallet_feature_not_supported', + }); + } + const identifiers = await connectFeature.connect(); + return identifiers?.accounts?.[0]?.address || ''; }
2-2: Replace non-existentSolanaWalletAdapterWallettype withWalletfrom@wallet-standard/core.The type
SolanaWalletAdapterWalletdoes not exist in@solana/wallet-standard. The codebase already imports the correctWallettype from@wallet-standard/core(v1.1.1, already in dependencies) in other locations. Update line 2 and the type casts on lines 56 and 61:-import type { SolanaWalletAdapterWallet } from '@solana/wallet-standard'; +import type { Wallet } from '@wallet-standard/core';Then update the type casts:
- Line 56:
(wallet as SolanaWalletAdapterWallet)→(wallet as Wallet)- Line 61:
(wallet as SolanaWalletAdapterWallet)→(wallet as Wallet)
🧹 Nitpick comments (1)
packages/clerk-js/src/core/resources/SignUp.ts (1)
382-397: Consider simplifying the generateSignature wrapper to avoid redundancy.The
generateSignaturewrapper on line 391 addswalletName: params.walletName, butwalletNameis already passed toauthenticateWithWeb3on line 395 and subsequently forwarded togenerateSignatureon line 303. This meanswalletNameis effectively set twice to the same value—once by the spread in the wrapper and once by the explicit parameter.While this doesn't cause incorrect behavior, it adds unnecessary complexity. Consider one of these approaches:
- Remove the explicit
walletNamefrom line 395 and rely solely on the wrapper to inject it- Simplify the wrapper to just pass
generateSignatureWithSolanadirectly if you ensure line 395 always provideswalletName
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Disabled knowledge base sources:
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (4)
packages/clerk-js/src/core/clerk.ts(9 hunks)packages/clerk-js/src/core/resources/SignIn.ts(12 hunks)packages/clerk-js/src/core/resources/SignUp.ts(4 hunks)packages/clerk-js/src/utils/web3.ts(4 hunks)
🧰 Additional context used
📓 Path-based instructions (7)
**/*.{js,jsx,ts,tsx}
📄 CodeRabbit inference engine (.cursor/rules/development.mdc)
All code must pass ESLint checks with the project's configuration
Files:
packages/clerk-js/src/utils/web3.tspackages/clerk-js/src/core/resources/SignIn.tspackages/clerk-js/src/core/clerk.tspackages/clerk-js/src/core/resources/SignUp.ts
**/*.{js,jsx,ts,tsx,json,md,yml,yaml}
📄 CodeRabbit inference engine (.cursor/rules/development.mdc)
Use Prettier for consistent code formatting
Files:
packages/clerk-js/src/utils/web3.tspackages/clerk-js/src/core/resources/SignIn.tspackages/clerk-js/src/core/clerk.tspackages/clerk-js/src/core/resources/SignUp.ts
packages/**/src/**/*.{ts,tsx}
📄 CodeRabbit inference engine (.cursor/rules/development.mdc)
TypeScript is required for all packages
Files:
packages/clerk-js/src/utils/web3.tspackages/clerk-js/src/core/resources/SignIn.tspackages/clerk-js/src/core/clerk.tspackages/clerk-js/src/core/resources/SignUp.ts
**/*.{ts,tsx,js,jsx}
📄 CodeRabbit inference engine (.cursor/rules/development.mdc)
Follow established naming conventions (PascalCase for components, camelCase for variables)
Prefer importing types from
@clerk/shared/typesinstead of the deprecated@clerk/typesalias
Files:
packages/clerk-js/src/utils/web3.tspackages/clerk-js/src/core/resources/SignIn.tspackages/clerk-js/src/core/clerk.tspackages/clerk-js/src/core/resources/SignUp.ts
packages/**/src/**/*.{ts,tsx,js,jsx}
📄 CodeRabbit inference engine (.cursor/rules/development.mdc)
packages/**/src/**/*.{ts,tsx,js,jsx}: Maintain comprehensive JSDoc comments for public APIs
Use tree-shaking friendly exports
Validate all inputs and sanitize outputs
All public APIs must be documented with JSDoc
Use dynamic imports for optional features
Provide meaningful error messages to developers
Include error recovery suggestions where applicable
Log errors appropriately for debugging
Lazy load components and features when possible
Implement proper caching strategies
Use efficient data structures and algorithms
Implement proper logging with different levels
Files:
packages/clerk-js/src/utils/web3.tspackages/clerk-js/src/core/resources/SignIn.tspackages/clerk-js/src/core/clerk.tspackages/clerk-js/src/core/resources/SignUp.ts
**/*.ts?(x)
📄 CodeRabbit inference engine (.cursor/rules/development.mdc)
Use proper TypeScript error types
Files:
packages/clerk-js/src/utils/web3.tspackages/clerk-js/src/core/resources/SignIn.tspackages/clerk-js/src/core/clerk.tspackages/clerk-js/src/core/resources/SignUp.ts
**/*.{ts,tsx}
📄 CodeRabbit inference engine (.cursor/rules/typescript.mdc)
**/*.{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
Implement type guards forunknowntypes using the patternfunction isType(value: unknown): value is Type
Useinterfacefor object shapes that might be extended
Usetypefor unions, primitives, and computed types
Preferreadonlyproperties for immutable data structures
Useprivatefor internal implementation details in classes
Useprotectedfor inheritance hierarchies
Usepublicexplicitly for clarity in public APIs
Use mixins for shared behavior across unrelated classes in TypeScript
Use generic constraints with bounded type parameters like<T extends { id: string }>
Use utility types likeOmit,Partial, andPickfor data transformation instead of manual type construction
Use discriminated unions instead of boolean flags for state management and API responses
Use mapped types for transforming object types
Use conditional types for type-level logic
Leverage template literal types for string manipulation at the type level
Use ES6 imports/exports consistently
Use default exports sparingly, prefer named exports
Document functions with JSDoc comments including @param, @returns, @throws, and @example tags
Create custom error classes that extend Error for specific error types
Use the Result pattern for error handling instead of throwing exceptions
Use optional chaining (?.) and nullish coalescing (??) operators for safe property access
Let TypeScript infer obvious types to reduce verbosity
Useconst assertionswithas constfor literal types
Usesatisfiesoperator for type checking without widening types
Declare readonly arrays and objects for immutable data structures
Use spread operator and array spread for immutable updates instead of mutations
Use lazy loading for large types...
Files:
packages/clerk-js/src/utils/web3.tspackages/clerk-js/src/core/resources/SignIn.tspackages/clerk-js/src/core/clerk.tspackages/clerk-js/src/core/resources/SignUp.ts
🧬 Code graph analysis (2)
packages/clerk-js/src/core/clerk.ts (3)
packages/shared/src/types/clerk.ts (1)
AuthenticateWithSolanaParams(2302-2309)packages/clerk-js/src/utils/web3.ts (2)
getWeb3Identifier(21-41)generateSignatureWithSolana(131-133)packages/shared/src/types/web3Wallet.ts (1)
GenerateSignature(28-28)
packages/clerk-js/src/core/resources/SignUp.ts (3)
packages/shared/src/types/signUpCommon.ts (1)
SignUpAuthenticateWithWeb3Params(116-118)packages/shared/src/types/signUp.ts (1)
SignUpResource(41-123)packages/clerk-js/src/utils/web3.ts (2)
getSolanaIdentifier(102-104)generateSignatureWithSolana(131-133)
⏰ 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). (1)
- GitHub Check: Analyze (javascript-typescript)
🔇 Additional comments (4)
packages/clerk-js/src/core/clerk.ts (2)
2260-2265: LGTM! Clean Solana authentication entry point.The
authenticateWithSolanamethod correctly delegates toauthenticateWithWeb3with the Solana-specific strategy and forwards all necessary parameters.
2296-2304: Good validation for required walletName parameter.The explicit check for
walletNamewhenprovider === 'solana'correctly enforces that Solana authentication requires a wallet name, throwing a clear error with an appropriate code if missing.packages/clerk-js/src/core/resources/SignIn.ts (1)
472-480: LGTM! Solana authentication method correctly structured.The
authenticateWithSolanamethod properly retrieves the Solana identifier usingparams.walletNameand sets up the signature generation wrapper with the requiredwalletNameparameter.packages/clerk-js/src/utils/web3.ts (1)
172-178: Good validation for Solana walletName requirement.The explicit check and error throwing when
walletNameis missing for Solana providers correctly enforces the requirement and provides clear error messaging.
| const walletAccount = (wallet as SolanaWalletAdapterWallet).accounts.find(a => a.address === identifier); | ||
| if (!walletAccount) { | ||
| console.warn(`Wallet account with address ${identifier} not found`); | ||
| return ''; | ||
| } | ||
| const signedMessages = await (wallet as SolanaWalletAdapterWallet).features[SolanaSignMessage]?.signMessage({ | ||
| account: walletAccount, | ||
| message: new TextEncoder().encode(nonce), | ||
| }); | ||
| // Convert signature Uint8Array to base64 string | ||
| return signedMessages?.[0]?.signature ? btoa(String.fromCharCode(...signedMessages[0].signature)) : ''; |
There was a problem hiding this comment.
Critical: Remove unsound cast to non-existent type.
The cast to SolanaWalletAdapterWallet on lines 56 and 61 relies on the type imported on line 2, which past review comments indicate doesn't exist. Additionally, there's no validation that the SolanaSignMessage feature exists before accessing it.
If using the standard Wallet type from @wallet-standard/base, apply this diff:
if (provider === 'solana') {
try {
- const walletAccount = (wallet as SolanaWalletAdapterWallet).accounts.find(a => a.address === identifier);
+ const walletAccount = wallet.accounts.find(a => a.address === identifier);
if (!walletAccount) {
console.warn(`Wallet account with address ${identifier} not found`);
return '';
}
- const signedMessages = await (wallet as SolanaWalletAdapterWallet).features[SolanaSignMessage]?.signMessage({
+ const signMessageFeature = wallet.features[SolanaSignMessage];
+ if (!signMessageFeature) {
+ throw new ClerkRuntimeError('Wallet does not support solana:signMessage', {
+ code: 'wallet_feature_not_supported',
+ });
+ }
+ const signedMessages = await signMessageFeature.signMessage({
account: walletAccount,
message: new TextEncoder().encode(nonce),
});🤖 Prompt for AI Agents
In packages/clerk-js/src/utils/web3.ts around lines 56 to 66, remove the unsound
casts to the non-existent SolanaWalletAdapterWallet type and instead treat the
object as the standard Wallet type from @wallet-standard/base; validate that the
wallet has an accounts array and that the SolanaSignMessage feature exists on
wallet.features before calling signMessage, guard the account lookup
accordingly, and return an empty string if the feature or account is missing or
signMessage is unavailable; ensure you access features in a type-safe way
(narrow feature presence with an if-check) and avoid any direct cast to the
non-existent type.
…Web3Signature Signed-off-by: Kenton Duprey <kenton@clerk.dev>
…ure generation Signed-off-by: Kenton Duprey <kenton@clerk.dev>
Co-authored-by: Dylan Staley <88163+dstaley@users.noreply.github.com>
Signed-off-by: Kenton Duprey <kenton@clerk.dev>
kduprey
force-pushed
the
kenton/user-3770-add-functionality-to-clerk-js-to-be-able-to-detect-all
branch
from
7d28035 to
e4e606d
Compare
kduprey
changed the title
kduprey
changed the title
There was a problem hiding this comment.
Actionable comments posted: 3
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
packages/elements/src/react/hooks/use-third-party-provider.hook.ts (1)
110-110: Update dashboard path logic to include Solana.The current logic only maps
'metamask'to the'web3'dashboard path. Since'solana'is also a Web3 provider (like'base','coinbase_wallet', and'okx_wallet'), consider updating the condition to handle all Web3 providers consistently.Apply this diff to include Solana in the Web3 dashboard path:
- const dashboardPath = `https://dashboard.clerk.com/last-active?path=/user-authentication/${provider === 'metamask' ? 'web3' : 'social-connections'}`; + const dashboardPath = `https://dashboard.clerk.com/last-active?path=/user-authentication/${provider === 'metamask' || provider === 'solana' ? 'web3' : 'social-connections'}`;Alternatively, for better maintainability, consider checking against all Web3 providers:
- const dashboardPath = `https://dashboard.clerk.com/last-active?path=/user-authentication/${provider === 'metamask' ? 'web3' : 'social-connections'}`; + const isWeb3 = ['base', 'metamask', 'coinbase_wallet', 'okx_wallet', 'solana'].includes(provider); + const dashboardPath = `https://dashboard.clerk.com/last-active?path=/user-authentication/${isWeb3 ? 'web3' : 'social-connections'}`;
♻️ Duplicate comments (3)
packages/clerk-js/src/ui/elements/Web3WalletButtons.tsx (1)
36-39: WalletProvider always receives an empty wallets array, so no Solana wallets are ever surfaced
Web3WalletButtonsmemoizeswalletsas[]and passes that intoWalletProvider. As a result:
useWallet().walletsinsideWeb3WalletButtonsInneris always empty.installedWallets.lengthis always0.- The component will only ever render the “no Solana Web3 wallets detected”
<Card.Alert>, never actual wallet buttons.You’ll need to replace the
useMemo(() => [], [network])placeholder with the real set of Solana wallet adapters detected from your wallet-standard / injected providers (e.g., yourinjectedWeb3SolanaProvidersintegration) so thatuseWalletcan expose them to the UI.Also applies to: 73-91, 262-275
packages/clerk-js/src/utils/injectedWeb3SolanaProviders.ts (1)
6-22: Make Solana provider initialization idempotent and SSR‑safe, and type the factory explicitlyTwo issues here:
#initializere-imports and re-attaches listeners on everyget()call and runs unguarded in non‑browser environments
- Each
get()triggers a freshimport('@wallet-standard/core')and registers newregister/unregisterlisteners without ever unsubscribing, which can cause duplicate handlers and wasted work over time.- There is no
typeof window === 'undefined'guard, so this path can execute during SSR ifget()is called there, depending on how@wallet-standard/corebehaves outside the browser.Consider an idempotent, env‑aware initializer:
class InjectedWeb3SolanaProviders { #wallets: readonly Wallet[] | undefined = undefined; static #instance: InjectedWeb3SolanaProviders | null = null; + #initialized = false; private constructor() {} async #initialize() { - const wallets = await import('@wallet-standard/core').then(mod => mod.getWallets()); + if (this.#initialized || typeof window === 'undefined') { + return; + } + + const wallets = await import('@wallet-standard/core').then(mod => mod.getWallets()); this.#wallets = wallets.get(); @@ wallets.on('unregister', () => { this.#wallets = wallets.get(); }); + this.#initialized = true; } @@ -export const getInjectedWeb3SolanaProviders = () => InjectedWeb3SolanaProviders.getInstance(); +export const getInjectedWeb3SolanaProviders = (): InjectedWeb3SolanaProviders => + InjectedWeb3SolanaProviders.getInstance();Exported factory should declare an explicit return type
Adding(): InjectedWeb3SolanaProvidersongetInjectedWeb3SolanaProviderskeeps the public utility aligned with the TypeScript guideline for explicit return types on exported functions.Also applies to: 39-63, 66-66
packages/clerk-js/src/core/resources/SignIn.ts (1)
1059-1064: IncludewalletNamein the Coinbase retry path for consistency.The retry logic for
coinbase_walletomitswalletNamewhen callinggenerateSignature. While Coinbase doesn't require it, including it maintains consistency with the main signature call (lines 1046-1051) and aligns with theGenerateSignaturetype signature.Apply this diff:
if (provider === 'coinbase_wallet' && err.code === 4001) { signature = await generateSignature({ identifier, nonce: message, provider, + walletName: params?.walletName, }); } else {
🧹 Nitpick comments (10)
packages/shared/src/types/factors.ts (1)
46-46: Add JSDoc documentation for the walletName property.The
walletNameproperty should be documented with a JSDoc comment explaining its purpose, when it's provided versus undefined, and any expected format or constraints. This is a public API in a shared types package.Apply this diff to add documentation:
export type Web3SignatureFactor = { strategy: Web3Strategy; web3WalletId: string; primary?: boolean; + /** + * The name of the Web3 wallet used for authentication. + * Optional - only provided when a specific wallet is selected (e.g., during Solana authentication). + */ walletName?: string; };As per coding guidelines, all public APIs must be documented with JSDoc.
packages/clerk-js/src/ui/components/SignUp/index.tsx (1)
90-92: Consider adding acanActivateguard for defensive routing (optional).The route implementation aligns with the SignIn component's similar
choose-walletroute, both lacking guard checks. However, unlikeverify-email-addressandverify-phone-numberroutes that guard on specific properties, this route can be accessed directly via URL.If direct URL navigation to this route when Solana sign-up isn't enabled should be prevented, a guard may be worth adding. Note that the appropriate guard condition depends on how Solana enablement is exposed on the
clerk.client.signUpobject (thesupportedWeb3Providersproperty mentioned above would need verification). The component's internal HOC wrappers (withRedirectToSignUpTask,withRedirectToAfterSignUp) and programmatic navigation may already handle this, making an explicit guard unnecessary.packages/clerk-js/src/ui/elements/Web3WalletButtons.tsx (2)
68-71: SimplifygridTemplateColumns;wallets.length < 1branch is effectively unreachableBecause you early-return when
installedWallets.length === 0, thegridTemplateColumnsternary onwallets.length < 1will never hit therepeat(1, minmax(0, 1fr))branch in practice.You can simplify by basing the condition on
installedWallets.length(if you need it) or by inlining the “non-empty” case only, which will make the layout logic easier to follow.Also applies to: 113-122
165-169:idprop on WalletButton components is unused; either forward it or drop it
WalletButtonPropsrequires anid, and callers passid={w.name}, but bothWalletButtonIconandWalletButtonBlockdestructureidand never use it, so it never reaches the underlyingButton/SimpleButton.If you intended to use it for DOM ids, test selectors, or analytics, forward it via
{...rest}instead of destructuring it away; otherwise, consider removingidfrom the prop type and call sites to avoid confusion.Also applies to: 192-260
packages/localizations/src/en-US.ts (1)
1-3: Consider importingLocalizationResourcefrom@clerk/shared/typesinstead of@clerk/typesCoding guidelines call out
@clerk/typesas a deprecated alias for internal code. If it doesn’t break package boundaries, prefer:-import type { LocalizationResource } from '@clerk/types'; +import type { LocalizationResource } from '@clerk/shared/types';to align with the recommended source of truth for shared types.
packages/clerk-js/src/core/resources/SignUp.ts (1)
45-58: Sign-up Solana flow wiring looks correct; consider tightening Future API typing
The Solana path for sign-up is wired coherently:
authenticateWithWeb3now acceptswalletNameand forwards it intogenerateSignature({ ..., provider, walletName }).authenticateWithSolanarequireswalletName, usesgetSolanaIdentifier(walletName), and delegates toauthenticateWithWeb3withstrategy: 'web3_solana_signature'and a Solana-specificgenerateSignatureWithSolanaclosure.- This matches the shared types and core Clerk web3 handling.
One follow-up to consider:
SignUpFuture.web3still only handles Ethereum providers but derivesproviderfromstrategytyped asWeb3Provider. If you don’t intend to support Solana in the Future API yet, you might:
- Narrow that
providertype toEthereumWeb3Provider, or- Add a
case 'solana'there when you’re ready to support it, instead of relying on thedefaultbranch throwing"Unsupported Web3 provider: solana".Also applies to: 271-304, 382-397
packages/clerk-js/src/core/clerk.ts (1)
40-40: Clerk-level Solana auth integration and walletName threading look solid
Clerk.authenticateWithSolanais a thin, type-safe wrapper overauthenticateWithWeb3that fixesstrategy: 'web3_solana_signature'and relies onAuthenticateWithSolanaParams(with requiredwalletName), which is appropriate given the need to disambiguate wallets.- In
authenticateWithWeb3:
provideris derived fromstrategyas before, but nowidentifiercomes fromgetWeb3Identifier({ provider, walletName }), allowing Solana to reuse the shared web3 identifier path.- The new
case 'solana'enforceswalletNameat runtime and binds it intogenerateSignatureWithSolana, while other providers continue to use their existing helpers unchanged.walletNameis forwarded into bothsignIn.authenticateWithWeb3andsignUp.authenticateWithWeb3, so downstream Solana flows have access to it for provider resolution/signing without affecting existing Ethereum flows.If you want to be extra defensive, you could short-circuit the Solana branch before calling
getWeb3IdentifierwhenwalletNameis missing, but given the dedicatedauthenticateWithSolanaentry point and the runtime guard, the current behavior is acceptable.Also applies to: 55-56, 119-124, 2364-2370, 2371-2412, 2433-2449
packages/clerk-js/src/utils/web3.ts (3)
32-35: Add defensive checks for StandardConnect feature availability.The code directly accesses
walletProvider.features[StandardConnect].connect()without verifying the feature exists. If a wallet doesn't support thestandard:connectfeature, this will throw a runtime error.if (provider === 'solana') { + const connectFeature = walletProvider.features[StandardConnect]; + if (!connectFeature) { + throw new ClerkRuntimeError('Wallet does not support standard:connect', { + code: 'wallet_feature_not_supported', + }); + } - const identifiers = await walletProvider.features[StandardConnect].connect(); + const identifiers = await connectFeature.connect(); return (identifiers && identifiers.accounts[0].address) || ''; }
54-77: Add defensive check forSolanaSignMessagefeature before accessing it.The code uses optional chaining (
?.signMessage) but proceeds to access the result without handling the case where the feature doesn't exist. IfSolanaSignMessageis not present, the function silently returns an empty string, which may mask configuration issues.if (provider === 'solana') { try { const walletAccount = (wallet as SolanaWalletAdapterWallet).accounts.find(a => a.address === identifier); if (!walletAccount) { console.warn(`Wallet account with address ${identifier} not found`); return ''; } - const signedMessages = await (wallet as SolanaWalletAdapterWallet).features[SolanaSignMessage]?.signMessage({ + const signMessageFeature = (wallet as SolanaWalletAdapterWallet).features[SolanaSignMessage]; + if (!signMessageFeature) { + throw new ClerkRuntimeError('Wallet does not support solana:signMessage', { + code: 'wallet_feature_not_supported', + }); + } + const signedMessages = await signMessageFeature.signMessage({ account: walletAccount, message: new TextEncoder().encode(nonce), });
65-66: Consider using a more robust base64 encoding approach.The current approach
btoa(String.fromCharCode(...signedMessages[0].signature))may fail for large signatures due to the spread operator's stack size limits. Consider using a chunked approach orBuffer(if available).- return signedMessages?.[0]?.signature ? btoa(String.fromCharCode(...signedMessages[0].signature)) : ''; + if (!signedMessages?.[0]?.signature) { + return ''; + } + // Convert Uint8Array to base64 using a safer approach for large arrays + const signature = signedMessages[0].signature; + let binary = ''; + for (let i = 0; i < signature.length; i++) { + binary += String.fromCharCode(signature[i]); + } + return btoa(binary);
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Disabled knowledge base sources:
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (32)
packages/clerk-js/bundle-check.mjs(2 hunks)packages/clerk-js/bundlewatch.config.json(2 hunks)packages/clerk-js/package.json(1 hunks)packages/clerk-js/rspack.config.js(1 hunks)packages/clerk-js/src/core/clerk.ts(9 hunks)packages/clerk-js/src/core/resources/SignIn.ts(12 hunks)packages/clerk-js/src/core/resources/SignUp.ts(4 hunks)packages/clerk-js/src/ui/components/SignIn/SignInFactorOneSolanaWalletsCard.tsx(1 hunks)packages/clerk-js/src/ui/components/SignIn/SignInSocialButtons.tsx(1 hunks)packages/clerk-js/src/ui/components/SignIn/index.tsx(2 hunks)packages/clerk-js/src/ui/components/SignUp/SignUpSocialButtons.tsx(1 hunks)packages/clerk-js/src/ui/components/SignUp/SignUpStartSolanaWalletsCard.tsx(1 hunks)packages/clerk-js/src/ui/components/SignUp/index.tsx(2 hunks)packages/clerk-js/src/ui/elements/Web3WalletButtons.tsx(1 hunks)packages/clerk-js/src/ui/elements/contexts/index.tsx(1 hunks)packages/clerk-js/src/ui/utils/web3CallbackErrorHandler.ts(1 hunks)packages/clerk-js/src/utils/injectedWeb3EthProviders.ts(3 hunks)packages/clerk-js/src/utils/injectedWeb3SolanaProviders.ts(1 hunks)packages/clerk-js/src/utils/web3.ts(4 hunks)packages/elements/src/react/hooks/use-third-party-provider.hook.ts(1 hunks)packages/localizations/src/en-US.ts(3 hunks)packages/react/src/isomorphicClerk.ts(2 hunks)packages/shared/src/types/clerk.ts(3 hunks)packages/shared/src/types/factors.ts(1 hunks)packages/shared/src/types/localization.ts(4 hunks)packages/shared/src/types/signIn.ts(2 hunks)packages/shared/src/types/signInFuture.ts(2 hunks)packages/shared/src/types/signUp.ts(2 hunks)packages/shared/src/types/signUpCommon.ts(1 hunks)packages/shared/src/types/web3.ts(1 hunks)packages/shared/src/types/web3Wallet.ts(1 hunks)packages/shared/src/web3.ts(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (14)
- packages/react/src/isomorphicClerk.ts
- packages/shared/src/types/signUpCommon.ts
- packages/shared/src/types/signInFuture.ts
- packages/clerk-js/src/ui/components/SignIn/SignInFactorOneSolanaWalletsCard.tsx
- packages/shared/src/types/signUp.ts
- packages/clerk-js/package.json
- packages/clerk-js/src/ui/components/SignIn/index.tsx
- packages/clerk-js/src/ui/components/SignUp/SignUpStartSolanaWalletsCard.tsx
- packages/clerk-js/bundle-check.mjs
- packages/shared/src/web3.ts
- packages/clerk-js/src/ui/components/SignUp/SignUpSocialButtons.tsx
- packages/clerk-js/src/ui/components/SignIn/SignInSocialButtons.tsx
- packages/clerk-js/rspack.config.js
- packages/shared/src/types/web3Wallet.ts
🧰 Additional context used
📓 Path-based instructions (12)
packages/clerk-js/src/ui/**/*.{ts,tsx}
📄 CodeRabbit inference engine (.cursor/rules/clerk-js-ui.mdc)
packages/clerk-js/src/ui/**/*.{ts,tsx}: Element descriptors should be written in camelCase
Use useCardState for card-level state management
Use useFormState for form-level state management
Use useLoadingStatus for managing loading states
Use useFormControl hook for form field state management with validation and localization support
All rendered values must be localized using useLocalizations hook - hard coded values are not allowed
Use localizationKeys for translating UI text with support for parameters and error messages
Use handleError utility for API error handling and provide field states for proper error mapping
Use the styled system sx prop with theme tokens for custom styling instead of inline styles
Use the Card component pattern with Card.Root, Card.Header, Card.Title, Card.Content, and Card.Footer for consistent card layouts
Use FormContainer with headerTitle and headerSubtitle localization keys combined with Form.Root and FormButtons for consistent form layouts
When form submission occurs, manage loading and error states by calling status.setLoading(), card.setLoading(), and card.setError() appropriately
Files:
packages/clerk-js/src/ui/components/SignUp/index.tsxpackages/clerk-js/src/ui/utils/web3CallbackErrorHandler.tspackages/clerk-js/src/ui/elements/Web3WalletButtons.tsxpackages/clerk-js/src/ui/elements/contexts/index.tsx
**/*.{js,jsx,ts,tsx}
📄 CodeRabbit inference engine (.cursor/rules/development.mdc)
All code must pass ESLint checks with the project's configuration
Files:
packages/clerk-js/src/ui/components/SignUp/index.tsxpackages/elements/src/react/hooks/use-third-party-provider.hook.tspackages/shared/src/types/factors.tspackages/shared/src/types/clerk.tspackages/clerk-js/src/ui/utils/web3CallbackErrorHandler.tspackages/clerk-js/src/ui/elements/Web3WalletButtons.tsxpackages/clerk-js/src/utils/injectedWeb3SolanaProviders.tspackages/shared/src/types/signIn.tspackages/shared/src/types/web3.tspackages/localizations/src/en-US.tspackages/clerk-js/src/ui/elements/contexts/index.tsxpackages/shared/src/types/localization.tspackages/clerk-js/src/core/resources/SignUp.tspackages/clerk-js/src/utils/injectedWeb3EthProviders.tspackages/clerk-js/src/core/resources/SignIn.tspackages/clerk-js/src/core/clerk.tspackages/clerk-js/src/utils/web3.ts
**/*.{js,jsx,ts,tsx,json,md,yml,yaml}
📄 CodeRabbit inference engine (.cursor/rules/development.mdc)
Use Prettier for consistent code formatting
Files:
packages/clerk-js/src/ui/components/SignUp/index.tsxpackages/elements/src/react/hooks/use-third-party-provider.hook.tspackages/shared/src/types/factors.tspackages/shared/src/types/clerk.tspackages/clerk-js/src/ui/utils/web3CallbackErrorHandler.tspackages/clerk-js/src/ui/elements/Web3WalletButtons.tsxpackages/clerk-js/src/utils/injectedWeb3SolanaProviders.tspackages/clerk-js/bundlewatch.config.jsonpackages/shared/src/types/signIn.tspackages/shared/src/types/web3.tspackages/localizations/src/en-US.tspackages/clerk-js/src/ui/elements/contexts/index.tsxpackages/shared/src/types/localization.tspackages/clerk-js/src/core/resources/SignUp.tspackages/clerk-js/src/utils/injectedWeb3EthProviders.tspackages/clerk-js/src/core/resources/SignIn.tspackages/clerk-js/src/core/clerk.tspackages/clerk-js/src/utils/web3.ts
packages/**/src/**/*.{ts,tsx}
📄 CodeRabbit inference engine (.cursor/rules/development.mdc)
TypeScript is required for all packages
Files:
packages/clerk-js/src/ui/components/SignUp/index.tsxpackages/elements/src/react/hooks/use-third-party-provider.hook.tspackages/shared/src/types/factors.tspackages/shared/src/types/clerk.tspackages/clerk-js/src/ui/utils/web3CallbackErrorHandler.tspackages/clerk-js/src/ui/elements/Web3WalletButtons.tsxpackages/clerk-js/src/utils/injectedWeb3SolanaProviders.tspackages/shared/src/types/signIn.tspackages/shared/src/types/web3.tspackages/localizations/src/en-US.tspackages/clerk-js/src/ui/elements/contexts/index.tsxpackages/shared/src/types/localization.tspackages/clerk-js/src/core/resources/SignUp.tspackages/clerk-js/src/utils/injectedWeb3EthProviders.tspackages/clerk-js/src/core/resources/SignIn.tspackages/clerk-js/src/core/clerk.tspackages/clerk-js/src/utils/web3.ts
**/*.{ts,tsx,js,jsx}
📄 CodeRabbit inference engine (.cursor/rules/development.mdc)
Follow established naming conventions (PascalCase for components, camelCase for variables)
Prefer importing types from
@clerk/shared/typesinstead of the deprecated@clerk/typesalias
Files:
packages/clerk-js/src/ui/components/SignUp/index.tsxpackages/elements/src/react/hooks/use-third-party-provider.hook.tspackages/shared/src/types/factors.tspackages/shared/src/types/clerk.tspackages/clerk-js/src/ui/utils/web3CallbackErrorHandler.tspackages/clerk-js/src/ui/elements/Web3WalletButtons.tsxpackages/clerk-js/src/utils/injectedWeb3SolanaProviders.tspackages/shared/src/types/signIn.tspackages/shared/src/types/web3.tspackages/localizations/src/en-US.tspackages/clerk-js/src/ui/elements/contexts/index.tsxpackages/shared/src/types/localization.tspackages/clerk-js/src/core/resources/SignUp.tspackages/clerk-js/src/utils/injectedWeb3EthProviders.tspackages/clerk-js/src/core/resources/SignIn.tspackages/clerk-js/src/core/clerk.tspackages/clerk-js/src/utils/web3.ts
packages/**/src/**/*.{ts,tsx,js,jsx}
📄 CodeRabbit inference engine (.cursor/rules/development.mdc)
packages/**/src/**/*.{ts,tsx,js,jsx}: Maintain comprehensive JSDoc comments for public APIs
Use tree-shaking friendly exports
Validate all inputs and sanitize outputs
All public APIs must be documented with JSDoc
Use dynamic imports for optional features
Provide meaningful error messages to developers
Include error recovery suggestions where applicable
Log errors appropriately for debugging
Lazy load components and features when possible
Implement proper caching strategies
Use efficient data structures and algorithms
Implement proper logging with different levels
Files:
packages/clerk-js/src/ui/components/SignUp/index.tsxpackages/elements/src/react/hooks/use-third-party-provider.hook.tspackages/shared/src/types/factors.tspackages/shared/src/types/clerk.tspackages/clerk-js/src/ui/utils/web3CallbackErrorHandler.tspackages/clerk-js/src/ui/elements/Web3WalletButtons.tsxpackages/clerk-js/src/utils/injectedWeb3SolanaProviders.tspackages/shared/src/types/signIn.tspackages/shared/src/types/web3.tspackages/localizations/src/en-US.tspackages/clerk-js/src/ui/elements/contexts/index.tsxpackages/shared/src/types/localization.tspackages/clerk-js/src/core/resources/SignUp.tspackages/clerk-js/src/utils/injectedWeb3EthProviders.tspackages/clerk-js/src/core/resources/SignIn.tspackages/clerk-js/src/core/clerk.tspackages/clerk-js/src/utils/web3.ts
**/*.ts?(x)
📄 CodeRabbit inference engine (.cursor/rules/development.mdc)
Use proper TypeScript error types
Files:
packages/clerk-js/src/ui/components/SignUp/index.tsxpackages/elements/src/react/hooks/use-third-party-provider.hook.tspackages/shared/src/types/factors.tspackages/shared/src/types/clerk.tspackages/clerk-js/src/ui/utils/web3CallbackErrorHandler.tspackages/clerk-js/src/ui/elements/Web3WalletButtons.tsxpackages/clerk-js/src/utils/injectedWeb3SolanaProviders.tspackages/shared/src/types/signIn.tspackages/shared/src/types/web3.tspackages/localizations/src/en-US.tspackages/clerk-js/src/ui/elements/contexts/index.tsxpackages/shared/src/types/localization.tspackages/clerk-js/src/core/resources/SignUp.tspackages/clerk-js/src/utils/injectedWeb3EthProviders.tspackages/clerk-js/src/core/resources/SignIn.tspackages/clerk-js/src/core/clerk.tspackages/clerk-js/src/utils/web3.ts
**/*.tsx
📄 CodeRabbit inference engine (.cursor/rules/development.mdc)
**/*.tsx: Use error boundaries in React components
Minimize re-renders in React components
**/*.tsx: Use proper type definitions for props and state in React components
Leverage TypeScript's type inference where possible in React components
Use proper event types for handlers in React components
Implement proper generic types for reusable React components
Use proper type guards for conditional rendering in React components
Files:
packages/clerk-js/src/ui/components/SignUp/index.tsxpackages/clerk-js/src/ui/elements/Web3WalletButtons.tsxpackages/clerk-js/src/ui/elements/contexts/index.tsx
**/*.{md,tsx}
📄 CodeRabbit inference engine (.cursor/rules/development.mdc)
Update documentation for API changes
Files:
packages/clerk-js/src/ui/components/SignUp/index.tsxpackages/clerk-js/src/ui/elements/Web3WalletButtons.tsxpackages/clerk-js/src/ui/elements/contexts/index.tsx
**/*.{jsx,tsx}
📄 CodeRabbit inference engine (.cursor/rules/react.mdc)
**/*.{jsx,tsx}: Always use functional components with hooks instead of class components
Follow PascalCase naming for components (e.g.,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
Separate UI components from business logic components
Use useState for simple state management in React components
Use useReducer for complex state logic in React components
Implement proper state initialization in React components
Use proper state updates with callbacks in React components
Implement proper state cleanup in React components
Use Context API for theme/authentication state management
Implement proper state persistence in React applications
Use React.memo for expensive components
Implement proper useCallback for handlers in React components
Use proper useMemo for expensive computations in React components
Implement proper virtualization for lists in React components
Use proper code splitting with React.lazy in React applications
Implement proper cleanup in useEffect hooks
Use proper refs for DOM access in React components
Implement proper event listener cleanup in React components
Use proper abort controllers for fetch in React components
Implement proper subscription cleanup in React components
Use proper HTML elements for semantic HTML in React components
Implement proper ARIA attributes for accessibility in React components
Use proper heading hierarchy in React components
Implement proper form labels in React components
Use proper button types in React components
Implement proper focus management for keyboard navigation in React components
Use proper keyboard shortcuts in React components
Implement proper tab order in React components
Use proper ...
Files:
packages/clerk-js/src/ui/components/SignUp/index.tsxpackages/clerk-js/src/ui/elements/Web3WalletButtons.tsxpackages/clerk-js/src/ui/elements/contexts/index.tsx
**/*.{ts,tsx}
📄 CodeRabbit inference engine (.cursor/rules/typescript.mdc)
**/*.{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
Implement type guards forunknowntypes using the patternfunction isType(value: unknown): value is Type
Useinterfacefor object shapes that might be extended
Usetypefor unions, primitives, and computed types
Preferreadonlyproperties for immutable data structures
Useprivatefor internal implementation details in classes
Useprotectedfor inheritance hierarchies
Usepublicexplicitly for clarity in public APIs
Use mixins for shared behavior across unrelated classes in TypeScript
Use generic constraints with bounded type parameters like<T extends { id: string }>
Use utility types likeOmit,Partial, andPickfor data transformation instead of manual type construction
Use discriminated unions instead of boolean flags for state management and API responses
Use mapped types for transforming object types
Use conditional types for type-level logic
Leverage template literal types for string manipulation at the type level
Use ES6 imports/exports consistently
Use default exports sparingly, prefer named exports
Document functions with JSDoc comments including @param, @returns, @throws, and @example tags
Create custom error classes that extend Error for specific error types
Use the Result pattern for error handling instead of throwing exceptions
Use optional chaining (?.) and nullish coalescing (??) operators for safe property access
Let TypeScript infer obvious types to reduce verbosity
Useconst assertionswithas constfor literal types
Usesatisfiesoperator for type checking without widening types
Declare readonly arrays and objects for immutable data structures
Use spread operator and array spread for immutable updates instead of mutations
Use lazy loading for large types...
Files:
packages/clerk-js/src/ui/components/SignUp/index.tsxpackages/elements/src/react/hooks/use-third-party-provider.hook.tspackages/shared/src/types/factors.tspackages/shared/src/types/clerk.tspackages/clerk-js/src/ui/utils/web3CallbackErrorHandler.tspackages/clerk-js/src/ui/elements/Web3WalletButtons.tsxpackages/clerk-js/src/utils/injectedWeb3SolanaProviders.tspackages/shared/src/types/signIn.tspackages/shared/src/types/web3.tspackages/localizations/src/en-US.tspackages/clerk-js/src/ui/elements/contexts/index.tsxpackages/shared/src/types/localization.tspackages/clerk-js/src/core/resources/SignUp.tspackages/clerk-js/src/utils/injectedWeb3EthProviders.tspackages/clerk-js/src/core/resources/SignIn.tspackages/clerk-js/src/core/clerk.tspackages/clerk-js/src/utils/web3.ts
packages/localizations/**
📄 CodeRabbit inference engine (.cursor/rules/monorepo.mdc)
packages/localizations/**: Localization support must include translations for 30+ languages using a modular localization system
Support RTL languages in the localization system
Files:
packages/localizations/src/en-US.ts
🧬 Code graph analysis (7)
packages/clerk-js/src/ui/components/SignUp/index.tsx (1)
packages/clerk-js/src/ui/components/SignUp/SignUpStartSolanaWalletsCard.tsx (1)
SignUpStartSolanaWalletsCard(75-77)
packages/shared/src/types/signIn.ts (1)
packages/shared/src/types/clerk.ts (1)
AuthenticateWithSolanaParams(2336-2343)
packages/clerk-js/src/core/resources/SignUp.ts (3)
packages/shared/src/types/signUpCommon.ts (1)
SignUpAuthenticateWithWeb3Params(116-118)packages/shared/src/types/signUp.ts (1)
SignUpResource(41-123)packages/clerk-js/src/utils/web3.ts (2)
getSolanaIdentifier(102-104)generateSignatureWithSolana(131-133)
packages/clerk-js/src/utils/injectedWeb3EthProviders.ts (1)
packages/shared/src/types/web3.ts (2)
MetamaskWeb3Provider(9-9)OKXWalletWeb3Provider(11-11)
packages/clerk-js/src/core/resources/SignIn.ts (5)
packages/shared/src/types/web3.ts (1)
Web3Provider(15-15)packages/clerk-js/src/core/errors.ts (1)
clerkMissingOptionError(75-77)packages/shared/src/types/clerk.ts (1)
AuthenticateWithSolanaParams(2336-2343)packages/shared/src/types/signIn.ts (1)
SignInResource(36-96)packages/clerk-js/src/utils/web3.ts (2)
getSolanaIdentifier(102-104)generateSignatureWithSolana(131-133)
packages/clerk-js/src/core/clerk.ts (3)
packages/shared/src/types/clerk.ts (1)
AuthenticateWithSolanaParams(2336-2343)packages/clerk-js/src/utils/web3.ts (2)
getWeb3Identifier(21-41)generateSignatureWithSolana(131-133)packages/shared/src/types/web3Wallet.ts (1)
GenerateSignature(28-28)
packages/clerk-js/src/utils/web3.ts (4)
packages/shared/src/types/web3.ts (1)
Web3Provider(15-15)packages/shared/src/types/web3Wallet.ts (2)
GenerateSignature(28-28)GenerateSignatureParams(37-42)packages/clerk-js/src/utils/injectedWeb3SolanaProviders.ts (3)
wallet(24-26)wallet(28-30)getInjectedWeb3SolanaProviders(66-66)packages/clerk-js/src/utils/injectedWeb3EthProviders.ts (1)
getInjectedWeb3EthProviders(75-75)
⏰ 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). (3)
- GitHub Check: Build Packages
- GitHub Check: Formatting | Dedupe | Changeset
- GitHub Check: Analyze (javascript-typescript)
🔇 Additional comments (21)
packages/clerk-js/bundlewatch.config.json (4)
5-5: Clarify scope of new bundle entries.Multiple new bundle entries were added (clerk.channel.browser.js, impersonationfab*.js, organizationprofile*.js, pricingTable*.js, checkout*.js, billing pages, statement pages, sessionTasks*.js). Most of these appear unrelated to Solana wallet authentication.
Verify whether these entries are:
- Legitimate additions introduced as part of this PR (perhaps bundled simultaneously)
- Pre-existing entries that were previously missing from the config
- Introduced by an incomplete or inaccurate summary
Also applies to: 14-15, 27-35
19-19: Size increase for signup.js aligns with new Solana auth flow.*The 1.5KB increase (9.5KB → 11KB) is reasonable given that Solana wallet selection and authentication logic is being added to the sign-up flow.
23-23: Verify onetap.js size increase is justified.*The onetap bundle increased by 2KB (1KB → 3KB). Clarify whether onetap was modified to support Solana authentication or if this increase is unrelated.
3-3: Code-splitting and lazy-loading for Solana dependencies are already implemented in the build configuration.The
rspack.config.jsexplicitly excludes all Solana packages (@solana,@wallet-standard,bs58, and transitive dependencies) from the mainvendorsbundle, preventing them from bloating the main clerk.js bundle. Additionally, Solana wallet UI components use dynamic imports with dedicated chunk names (e.g.,web3-wallet-buttons), ensuring code is only loaded on demand. The bundle size increase is already optimized through existing build strategies.packages/clerk-js/src/ui/components/SignUp/index.tsx (1)
5-5: LGTM!The import follows the project's path alias conventions and uses a named export, which aligns with tree-shaking best practices.
packages/shared/src/types/localization.ts (2)
372-376: Solana sign-up/sign-in localization groups look consistent with the new flowThe added
web3Solanagroups undersignUpandsignInhave cleartitle/subtitle(andnoAvailableWalletsfor sign-up), and align with the en-US entries and UI usage. Typing viaLocalizationValueis correct and will keep consumers honest.Please just make sure any UI that intends to use
noAvailableWalletseither handlesundefinedgracefully or that all base/localized resources eventually define it so users always see a friendly message.Also applies to: 555-558
1311-1315: web3WalletButtons group and Solana error codes are correctly exposed on the type surfaceThe
web3WalletButtonsblock (with thesolanaWalletsLinkparam) and the new unstable error keys (web3_solana_signature_generation_failed,web3_signature_request_rejected) are wired into__internal_LocalizationResource/UnstableErrorsas expected. Names match the en-US definitions and give you type-safe coverage for the new Solana flows.Also applies to: 1334-1335
packages/localizations/src/en-US.ts (1)
750-753: Solana/web3 localization strings are clear; ensure behavior and locale coverage match expectations
signIn.web3Solana/signUp.web3Solanatitles and subtitles read well and align with the new Solana wallet-selection screens.web3WalletButtons.connect/continuecorrectly interpolate{{walletName}}for both alt text and button labels.web3WalletButtons.noneAvailableintroduces{{ solanaWalletsLink || link("wallet extension") }}; given the UI passes asolanaWalletsLinkparam intot(...)and then intoLinkRenderer, please verify at runtime that this yields the intended clickable “wallet extension” link (and not just a raw URL string).- The new unstable errors
web3_signature_request_rejectedandweb3_solana_signature_generation_failedare user-friendly and map cleanly onto the Solana/web3 failure cases introduced elsewhere.Also, remember to propagate these new keys (or acceptable fallbacks) to the other locales so Solana flows remain fully localized.
Also applies to: 846-849, 851-856, 954-956
packages/shared/src/types/clerk.ts (1)
890-893: Solana params shape and walletName requirement look consistent across APIs
AuthenticateWithSolanaParamscorrectly requireswalletName, whileClerkAuthenticateWithWeb3ParamskeepswalletName?optional andClerk.authenticateWithSolanaenforces the Solana‑specific type. This matches the core implementation inpackages/clerk-js/src/core/clerk.tsand resolves the earlier optionality mismatch between generic web3 and Solana‑only flows.Also applies to: 2284-2293, 2336-2343
packages/clerk-js/src/utils/injectedWeb3EthProviders.ts (1)
30-39: Eth‑specific provider alias and rename look soundConstraining the map to
InjectedWeb3EthProvider = MetamaskWeb3Provider | OKXWalletWeb3Providerand renaming toInjectedWeb3EthProviderskeeps typings precise and mirrors the new Solana split without changing behavior.Also applies to: 48-53, 55-65, 75-75
packages/shared/src/types/signIn.ts (1)
1-1: SignIn Solana auth contract aligns with shared and Clerk typesImporting
AuthenticateWithSolanaParamsand wiringauthenticateWithSolana: (params: AuthenticateWithSolanaParams)keeps the SignIn resource API aligned with the sharedclerk.tsdefinition and Clerk’s top‑levelauthenticateWithSolana, withwalletNamerequired at the call site.Also applies to: 36-37, 80-81
packages/clerk-js/src/ui/utils/web3CallbackErrorHandler.ts (1)
11-15: Safer error access with optional chainingSwitching to
err.errors?.[0]?.meta?.paramNameanderr.errors?.[0]?.codeavoids runtime crashes whenerrorsis missing or empty while preserving the existing condition semantics.packages/shared/src/types/web3.ts (1)
13-21: Clean split between Ethereum and Solana web3 provider typesDefining
EthereumWeb3ProviderandSolanaWeb3Providerand composingWeb3Provider = EthereumWeb3Provider | SolanaWeb3Providersimplifies downstream typing and cleanly separates Eth vs Solana logic for functions likegetWeb3Identifier.packages/clerk-js/src/core/resources/SignIn.ts (5)
10-10: LGTM on imports for Solana authentication.The imports for
AuthenticateWithSolanaParams,GenerateSignature,generateSignatureWithSolana, andgetSolanaIdentifierare correctly added to support the new Solana authentication flow.Also applies to: 19-19
219-220: LGTM: Solana signature strategy added to prepareFirstFactor.The
web3_solana_signaturecase correctly follows the same pattern as other Web3 signature strategies.
394-396: Good validation for walletName requirement on Solana provider.The early validation ensures
walletNameis present before proceeding with Solana authentication, preventing downstream errors.
472-480: LGTM: authenticateWithSolana implementation is well-structured.The method correctly:
- Requires
walletNamevia params type (non-optional per shared types)- Fetches the Solana identifier using the wallet name
- Wraps
generateSignatureWithSolanato passwalletNamethrough- Delegates to the existing
authenticateWithWeb3flow
1012-1020: LGTM: SignInFuture.web3 Solana branch properly validates walletName.The Solana case correctly throws a
ClerkRuntimeErrorwith an appropriate code whenwalletNameis missing, and properly threadswalletNamethrough thegenerateSignatureWithSolanacall.packages/clerk-js/src/utils/web3.ts (3)
17-19: LGTM: Wallet Standard feature constants are correctly defined.The
StandardConnectandSolanaSignMessageconstants match the Wallet Standard specifications for Solana wallet features.
102-104: LGTM: Solana helpers correctly enforcewalletNameat compile time.The type system properly requires
walletNamefor Solana operations:
getSolanaIdentifier(walletName: string)requires the parameterGenerateSolanaSignatureParamsextends base params with requiredwalletNamegenerateSignatureWithSolanauses the stricter typeThis addresses the past review comment about type safety.
Also applies to: 111-113, 131-133
172-178: LGTM: Solana wallet resolution correctly validateswalletName.The code properly validates that
walletNameis present and non-empty before attempting to resolve a Solana wallet provider, throwing viaerrorThrowerif missing.
| | 'enterpriseConnections' | ||
| | 'choose-wallet'; |
There was a problem hiding this comment.
🛠️ Refactor suggestion | 🟠 Major
🧩 Analysis chain
🏁 Script executed:
cat -n packages/clerk-js/src/ui/elements/contexts/index.tsx | head -150 | tail -40Repository: clerk/javascript
Length of output: 1542
🏁 Script executed:
rg -n "choose-wallet|chooseWallet" --type=ts --type=tsx --type=js --type=jsx -B2 -A2Repository: clerk/javascript
Length of output: 87
🏁 Script executed:
git ls-files | head -20Repository: clerk/javascript
Length of output: 584
🏁 Script executed:
rg -n "choose-wallet|chooseWallet" -B2 -A2Repository: clerk/javascript
Length of output: 3356
🏁 Script executed:
rg -n "choose-wallet" --type ts --type js -B2 -A2Repository: clerk/javascript
Length of output: 3356
🏁 Script executed:
fd -e ts -e tsx -e js -e jsx | xargs grep -l "choose-wallet" 2>/dev/null | head -20Repository: clerk/javascript
Length of output: 508
Change 'choose-wallet' to 'chooseWallet' to comply with camelCase naming requirement for element descriptors.
The new 'choose-wallet' value uses kebab-case, violating the coding guideline requiring camelCase for element descriptors in UI files. All existing values in this union use camelCase ('emailCode', 'ssoCallback', 'chooseOrganization', etc.). Additionally, 'choose-wallet' is used in 6 other files as the part prop value in Flow.Part components (element descriptors), requiring systematic updates.
Update the type definition and all usages across:
- packages/clerk-js/src/ui/elements/contexts/index.tsx (type definition)
- packages/clerk-js/src/ui/components/SignUp/index.tsx (route path)
- packages/clerk-js/src/ui/components/SignUp/SignUpSocialButtons.tsx (navigate call)
- packages/clerk-js/src/ui/components/SignUp/SignUpStartSolanaWalletsCard.tsx (Flow.Part prop)
- packages/clerk-js/src/ui/components/SignIn/index.tsx (route path)
- packages/clerk-js/src/ui/components/SignIn/SignInSocialButtons.tsx (navigate call)
- packages/clerk-js/src/ui/components/SignIn/SignInFactorOneSolanaWalletsCard.tsx (Flow.Part prop)
🤖 Prompt for AI Agents
In packages/clerk-js/src/ui/elements/contexts/index.tsx around lines 131-132,
the union member 'choose-wallet' uses kebab-case and must be renamed to
'chooseWallet' to follow camelCase convention; update that type definition and
then update all usages to the new descriptor across the codebase: replace route
path occurrences in packages/clerk-js/src/ui/components/SignUp/index.tsx and
packages/clerk-js/src/ui/components/SignIn/index.tsx, update navigate(...) calls
in packages/clerk-js/src/ui/components/SignUp/SignUpSocialButtons.tsx and
packages/clerk-js/src/ui/components/SignIn/SignInSocialButtons.tsx, and update
Flow.Part prop values in
packages/clerk-js/src/ui/components/SignUp/SignUpStartSolanaWalletsCard.tsx and
packages/clerk-js/src/ui/components/SignIn/SignInFactorOneSolanaWalletsCard.tsx
so they use 'chooseWallet' consistently; run tests/TypeScript compile to ensure
no remaining references to 'choose-wallet'.
| @@ -1,50 +1,87 @@ | |||
| import type { Web3Provider } from '@clerk/shared/types'; | |||
| import type { GenerateSignature, Web3Provider } from '@clerk/shared/types'; | |||
| import type { SolanaWalletAdapterWallet } from '@solana/wallet-standard'; | |||
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
cat packages/clerk-js/package.json | jq '.dependencies["@solana/wallet-standard"], .devDependencies["@solana/wallet-standard"]'Repository: clerk/javascript
Length of output: 72
🏁 Script executed:
# Search for web3.ts to understand context and usage
fd -type f "web3.ts" packages/clerk-js/src/utils/Repository: clerk/javascript
Length of output: 230
🏁 Script executed:
# Check the actual imports and usage of SolanaWalletAdapterWallet
rg "SolanaWalletAdapterWallet" packages/clerk-js/src/utils/web3.ts -A 3 -B 3Repository: clerk/javascript
Length of output: 829
🏁 Script executed:
# Check if there are any type definitions or exports in the codebase
rg "SolanaWalletAdapterWallet" --type ts --type tsxRepository: clerk/javascript
Length of output: 87
🏁 Script executed:
# Check the actual file structure and imports more completely
cat packages/clerk-js/src/utils/web3.ts | head -30Repository: clerk/javascript
Length of output: 1252
🏁 Script executed:
# Search for any error messages or compilation issues related to this import
rg "SolanaWalletAdapterWallet" packages/clerk-jsRepository: clerk/javascript
Length of output: 1000
🏁 Script executed:
# Check if there's a tsconfig or type checking configuration
fd tsconfig.json packages/clerk-jsRepository: clerk/javascript
Length of output: 91
🌐 Web query:
@solana/wallet-standard 1.1.4 SolanaWalletAdapterWallet type exports
💡 Result:
There is no exported type named SolanaWalletAdapterWallet in @solana/wallet-standard v1.1.4. The package (v1.1.4) and its published files show the package/types but do not include an export with that exact name. [1][2]
Sources:
- @solana/wallet-standard (npm/package info) — v1.1.4. [1]
- Package contents on UNPKG for @solana/wallet-standard (published files). [2]
🏁 Script executed:
# Check what types are actually exported from @solana/wallet-standard
# by looking at how the package is used elsewhere or checking package documentation
rg "from '@solana/wallet-standard'" packages/clerk-js -A 1Repository: clerk/javascript
Length of output: 663
🏁 Script executed:
# Check if there's a type with a different name that should be used
rg "Wallet" packages/clerk-js/src/utils/injectedWeb3SolanaProviders.ts -B 2 -A 2 | head -50Repository: clerk/javascript
Length of output: 1305
🌐 Web query:
@solana/wallet-standard correct Wallet type export v1.1.4
💡 Result:
Use the named type export Wallet. Example:
import type { Wallet } from '@solana/wallet-standard';
(confirmed in the package artifacts for @solana/wallet-standard v1.1.4). [1][2]
Sources:
- npm package @solana/wallet-standard (v1.1.4). [1]
- solana-labs wallet-standard repo (package/docs). [2]
Replace SolanaWalletAdapterWallet with the correct Wallet type from @solana/wallet-standard.
The import statement uses a non-existent type. @solana/wallet-standard@1.1.4 does not export SolanaWalletAdapterWallet; it exports Wallet. Update line 2 to:
import type { Wallet } from '@solana/wallet-standard';
This affects packages/clerk-js/src/utils/injectedWeb3SolanaProviders.ts as well, where the same incorrect import is used for type guards and return types. Replace all occurrences of SolanaWalletAdapterWallet with Wallet across both files.
🤖 Prompt for AI Agents
In packages/clerk-js/src/utils/web3.ts around line 2, and in
packages/clerk-js/src/utils/injectedWeb3SolanaProviders.ts (same import usages),
the code imports a non-existent SolanaWalletAdapterWallet type from
'@solana/wallet-standard'; replace that import with import type { Wallet } from
'@solana/wallet-standard' and then update all occurrences of the
SolanaWalletAdapterWallet identifier in both files (type annotations, type
guards, function return types, and any casts) to Wallet so the types align with
@solana/wallet-standard@1.1.4 exports.
There was a problem hiding this comment.
SolanaWalletAdapterWallet is exported from @solana/wallet-standard@1.1.4 and does not provide Wallet. This is the correct type to use.
There was a problem hiding this comment.
Seems like the humans are having a chat. I'll hop back into my burrow for now. If you need me again, just tag @coderabbitai in a new comment, and I'll come hopping out!
| if (provider === 'solana') { | ||
| return ref.send({ type: 'AUTHENTICATE.WEB3', strategy: 'web3_solana_signature' }); | ||
| } |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Verify 'solana' is defined in Web3Provider type and providerToDisplayData mapping
echo "=== Searching for Web3Provider type definition ==="
rg -n --type=ts -A10 "type Web3Provider\s*="
echo -e "\n=== Searching for providerToDisplayData mapping ==="
rg -n --type=ts -A30 "providerToDisplayData\s*[=:]"
echo -e "\n=== Checking imports in the hook file ==="
head -30 packages/elements/src/react/hooks/use-third-party-provider.hook.ts | grep -E "import|from"Repository: clerk/javascript
Length of output: 11395
🏁 Script executed:
#!/bin/bash
# Verify WEB3_PROVIDERS includes 'solana' and check dashboard path handling
echo "=== Searching for WEB3_PROVIDERS definition ==="
rg -n --type=ts -A15 "WEB3_PROVIDERS\s*[=:]" | head -60
echo -e "\n=== Checking for SolanaWeb3Provider type definition ==="
rg -n --type=ts -B2 -A5 "SolanaWeb3Provider"
echo -e "\n=== Checking line 110 area for dashboard path handling ==="
sed -n '105,115p' packages/elements/src/react/hooks/use-third-party-provider.hook.tsRepository: clerk/javascript
Length of output: 3344
🏁 Script executed:
#!/bin/bash
# Get complete WEB3_PROVIDERS definition and verify solana entry
echo "=== Complete WEB3_PROVIDERS from runtime-values.ts ==="
rg -n --type=ts -A50 "export const WEB3_PROVIDERS:" packages/shared/src/types/runtime-values.ts
echo -e "\n=== Checking if solana is in WEB3_PROVIDERS ==="
rg --type=ts "provider.*solana" packages/shared/src/types/runtime-values.tsRepository: clerk/javascript
Length of output: 1519
🏁 Script executed:
#!/bin/bash
# Verify the actual impact - check where WEB3_PROVIDERS is used and what happens with missing solana
echo "=== Check if solana should be in WEB3_PROVIDERS ==="
cat packages/shared/src/types/runtime-values.ts | head -35
echo -e "\n=== Check the hook file for error handling around line 113 ==="
sed -n '108,118p' packages/elements/src/react/hooks/use-third-party-provider.hook.tsRepository: clerk/javascript
Length of output: 1481
Add 'solana' provider to WEB3_PROVIDERS array and fix dashboard path logic.
The implementation at lines 100-102 adds Solana authentication support but is incomplete and will fail at runtime:
-
Missing WEB3_PROVIDERS entry: The
WEB3_PROVIDERSarray inpackages/shared/src/types/runtime-values.tsdoes not include a 'solana' provider entry. This causesproviderToDisplayData['solana']to be undefined, breaking line 113 when accessingdetails.name. -
Incorrect dashboard path logic: Line 110's condition
provider === 'metamask' ? 'web3' : 'social-connections'only handles MetaMask correctly. All other Web3 providers (including Solana, Base, Coinbase Wallet, OKX Wallet) incorrectly use the 'social-connections' path instead of 'web3'. Update to:['metamask', 'base', 'coinbase_wallet', 'okx_wallet', 'solana'].includes(provider) ? 'web3' : 'social-connections' -
Deprecated import: The hook imports
Web3Providerfrom@clerk/typesinstead of@clerk/shared/typesper coding guidelines.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (4)
packages/clerk-js/src/ui/components/SignIn/SignInFactorOneSolanaWalletsCard.tsx (4)
18-19: Move static imports above thelazy()call.Static imports should be grouped together at the top of the file before any inline code. Placing these imports after the
lazy()call breaks conventional import ordering and may conflict with ESLint import rules.import { useClerk } from '@clerk/shared/react'; import { lazy, Suspense } from 'react'; import { withRedirectToAfterSignIn, withRedirectToSignInTask } from '@/ui/common/withRedirect'; import { descriptors, Flex, Flow, localizationKeys } from '@/ui/customizables'; import { BackLink } from '@/ui/elements/BackLink'; import { Card } from '@/ui/elements/Card'; import { useCardState, withCardStateProvider } from '@/ui/elements/contexts'; import { Header } from '@/ui/elements/Header'; import { web3CallbackErrorHandler } from '@/ui/utils/web3CallbackErrorHandler'; +import { useSignInContext } from '../../contexts'; +import { useRouter } from '../../router'; const Web3WalletButtons = lazy(() => import(/* webpackChunkName: "web3-wallet-buttons" */ '@/ui/elements/Web3WalletButtons').then(m => ({ default: m.Web3WalletButtons, })), ); - -import { useSignInContext } from '../../contexts'; -import { useRouter } from '../../router';
44-44: Consider adding a loading indicator for the Suspense fallback.Using
fallback={null}means users see nothing while the wallet buttons load. A spinner or skeleton would provide better visual feedback during the lazy load.
46-57: Manage loading state during the async authentication.The
authenticateWithWeb3call doesn't set loading state, which could leave the UI in an unclear state during authentication and allow users to trigger multiple wallet selections.As per coding guidelines, use
card.setLoading()orcard.runAsync()to manage loading states during async operations.<Web3WalletButtons web3AuthCallback={({ walletName }) => { - return clerk - .authenticateWithWeb3({ + card.setLoading(); + return clerk.authenticateWithWeb3({ customNavigate: router.navigate, redirectUrl: ctx.afterSignInUrl || '/', secondFactorUrl: 'factor-two', signUpContinueUrl: ctx.isCombinedFlow ? '../create/continue' : ctx.signUpContinueUrl, strategy: 'web3_solana_signature', walletName, }) - .catch(err => web3CallbackErrorHandler(err, card.setError)); + .catch(err => web3CallbackErrorHandler(err, card.setError)) + .finally(() => card.setIdle()); }} />
74-76: Add JSDoc documentation for the exported component.As per coding guidelines, public APIs should have comprehensive JSDoc comments describing the component's purpose and usage context.
+/** + * Sign-in card for Solana wallet selection. + * Renders available Solana wallets and handles Web3 authentication flow. + */ export const SignInFactorOneSolanaWalletsCard = withRedirectToSignInTask( withRedirectToAfterSignIn(withCardStateProvider(SignInFactorOneSolanaWalletsCardInner)), );
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Disabled knowledge base sources:
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (3)
packages/clerk-js/src/ui/components/SignIn/SignInFactorOneSolanaWalletsCard.tsx(1 hunks)packages/clerk-js/src/ui/components/SignUp/SignUpStartSolanaWalletsCard.tsx(1 hunks)packages/clerk-js/src/ui/elements/contexts/index.tsx(1 hunks)
✅ Files skipped from review due to trivial changes (1)
- packages/clerk-js/src/ui/components/SignUp/SignUpStartSolanaWalletsCard.tsx
🧰 Additional context used
📓 Path-based instructions (11)
packages/clerk-js/src/ui/**/*.{ts,tsx}
📄 CodeRabbit inference engine (.cursor/rules/clerk-js-ui.mdc)
packages/clerk-js/src/ui/**/*.{ts,tsx}: Element descriptors should be written in camelCase
Use useCardState for card-level state management
Use useFormState for form-level state management
Use useLoadingStatus for managing loading states
Use useFormControl hook for form field state management with validation and localization support
All rendered values must be localized using useLocalizations hook - hard coded values are not allowed
Use localizationKeys for translating UI text with support for parameters and error messages
Use handleError utility for API error handling and provide field states for proper error mapping
Use the styled system sx prop with theme tokens for custom styling instead of inline styles
Use the Card component pattern with Card.Root, Card.Header, Card.Title, Card.Content, and Card.Footer for consistent card layouts
Use FormContainer with headerTitle and headerSubtitle localization keys combined with Form.Root and FormButtons for consistent form layouts
When form submission occurs, manage loading and error states by calling status.setLoading(), card.setLoading(), and card.setError() appropriately
Files:
packages/clerk-js/src/ui/elements/contexts/index.tsxpackages/clerk-js/src/ui/components/SignIn/SignInFactorOneSolanaWalletsCard.tsx
**/*.{js,jsx,ts,tsx}
📄 CodeRabbit inference engine (.cursor/rules/development.mdc)
All code must pass ESLint checks with the project's configuration
Files:
packages/clerk-js/src/ui/elements/contexts/index.tsxpackages/clerk-js/src/ui/components/SignIn/SignInFactorOneSolanaWalletsCard.tsx
**/*.{js,jsx,ts,tsx,json,md,yml,yaml}
📄 CodeRabbit inference engine (.cursor/rules/development.mdc)
Use Prettier for consistent code formatting
Files:
packages/clerk-js/src/ui/elements/contexts/index.tsxpackages/clerk-js/src/ui/components/SignIn/SignInFactorOneSolanaWalletsCard.tsx
packages/**/src/**/*.{ts,tsx}
📄 CodeRabbit inference engine (.cursor/rules/development.mdc)
TypeScript is required for all packages
Files:
packages/clerk-js/src/ui/elements/contexts/index.tsxpackages/clerk-js/src/ui/components/SignIn/SignInFactorOneSolanaWalletsCard.tsx
**/*.{ts,tsx,js,jsx}
📄 CodeRabbit inference engine (.cursor/rules/development.mdc)
Follow established naming conventions (PascalCase for components, camelCase for variables)
Prefer importing types from
@clerk/shared/typesinstead of the deprecated@clerk/typesalias
Files:
packages/clerk-js/src/ui/elements/contexts/index.tsxpackages/clerk-js/src/ui/components/SignIn/SignInFactorOneSolanaWalletsCard.tsx
packages/**/src/**/*.{ts,tsx,js,jsx}
📄 CodeRabbit inference engine (.cursor/rules/development.mdc)
packages/**/src/**/*.{ts,tsx,js,jsx}: Maintain comprehensive JSDoc comments for public APIs
Use tree-shaking friendly exports
Validate all inputs and sanitize outputs
All public APIs must be documented with JSDoc
Use dynamic imports for optional features
Provide meaningful error messages to developers
Include error recovery suggestions where applicable
Log errors appropriately for debugging
Lazy load components and features when possible
Implement proper caching strategies
Use efficient data structures and algorithms
Implement proper logging with different levels
Files:
packages/clerk-js/src/ui/elements/contexts/index.tsxpackages/clerk-js/src/ui/components/SignIn/SignInFactorOneSolanaWalletsCard.tsx
**/*.ts?(x)
📄 CodeRabbit inference engine (.cursor/rules/development.mdc)
Use proper TypeScript error types
Files:
packages/clerk-js/src/ui/elements/contexts/index.tsxpackages/clerk-js/src/ui/components/SignIn/SignInFactorOneSolanaWalletsCard.tsx
**/*.tsx
📄 CodeRabbit inference engine (.cursor/rules/development.mdc)
**/*.tsx: Use error boundaries in React components
Minimize re-renders in React components
**/*.tsx: Use proper type definitions for props and state in React components
Leverage TypeScript's type inference where possible in React components
Use proper event types for handlers in React components
Implement proper generic types for reusable React components
Use proper type guards for conditional rendering in React components
Files:
packages/clerk-js/src/ui/elements/contexts/index.tsxpackages/clerk-js/src/ui/components/SignIn/SignInFactorOneSolanaWalletsCard.tsx
**/*.{md,tsx}
📄 CodeRabbit inference engine (.cursor/rules/development.mdc)
Update documentation for API changes
Files:
packages/clerk-js/src/ui/elements/contexts/index.tsxpackages/clerk-js/src/ui/components/SignIn/SignInFactorOneSolanaWalletsCard.tsx
**/*.{jsx,tsx}
📄 CodeRabbit inference engine (.cursor/rules/react.mdc)
**/*.{jsx,tsx}: Always use functional components with hooks instead of class components
Follow PascalCase naming for components (e.g.,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
Separate UI components from business logic components
Use useState for simple state management in React components
Use useReducer for complex state logic in React components
Implement proper state initialization in React components
Use proper state updates with callbacks in React components
Implement proper state cleanup in React components
Use Context API for theme/authentication state management
Implement proper state persistence in React applications
Use React.memo for expensive components
Implement proper useCallback for handlers in React components
Use proper useMemo for expensive computations in React components
Implement proper virtualization for lists in React components
Use proper code splitting with React.lazy in React applications
Implement proper cleanup in useEffect hooks
Use proper refs for DOM access in React components
Implement proper event listener cleanup in React components
Use proper abort controllers for fetch in React components
Implement proper subscription cleanup in React components
Use proper HTML elements for semantic HTML in React components
Implement proper ARIA attributes for accessibility in React components
Use proper heading hierarchy in React components
Implement proper form labels in React components
Use proper button types in React components
Implement proper focus management for keyboard navigation in React components
Use proper keyboard shortcuts in React components
Implement proper tab order in React components
Use proper ...
Files:
packages/clerk-js/src/ui/elements/contexts/index.tsxpackages/clerk-js/src/ui/components/SignIn/SignInFactorOneSolanaWalletsCard.tsx
**/*.{ts,tsx}
📄 CodeRabbit inference engine (.cursor/rules/typescript.mdc)
**/*.{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
Implement type guards forunknowntypes using the patternfunction isType(value: unknown): value is Type
Useinterfacefor object shapes that might be extended
Usetypefor unions, primitives, and computed types
Preferreadonlyproperties for immutable data structures
Useprivatefor internal implementation details in classes
Useprotectedfor inheritance hierarchies
Usepublicexplicitly for clarity in public APIs
Use mixins for shared behavior across unrelated classes in TypeScript
Use generic constraints with bounded type parameters like<T extends { id: string }>
Use utility types likeOmit,Partial, andPickfor data transformation instead of manual type construction
Use discriminated unions instead of boolean flags for state management and API responses
Use mapped types for transforming object types
Use conditional types for type-level logic
Leverage template literal types for string manipulation at the type level
Use ES6 imports/exports consistently
Use default exports sparingly, prefer named exports
Document functions with JSDoc comments including @param, @returns, @throws, and @example tags
Create custom error classes that extend Error for specific error types
Use the Result pattern for error handling instead of throwing exceptions
Use optional chaining (?.) and nullish coalescing (??) operators for safe property access
Let TypeScript infer obvious types to reduce verbosity
Useconst assertionswithas constfor literal types
Usesatisfiesoperator for type checking without widening types
Declare readonly arrays and objects for immutable data structures
Use spread operator and array spread for immutable updates instead of mutations
Use lazy loading for large types...
Files:
packages/clerk-js/src/ui/elements/contexts/index.tsxpackages/clerk-js/src/ui/components/SignIn/SignInFactorOneSolanaWalletsCard.tsx
🧬 Code graph analysis (1)
packages/clerk-js/src/ui/components/SignIn/SignInFactorOneSolanaWalletsCard.tsx (5)
packages/clerk-js/src/ui/elements/Web3WalletButtons.tsx (1)
Web3WalletButtons(262-277)packages/clerk-js/src/ui/elements/contexts/index.tsx (2)
useCardState(42-70)withCardStateProvider(72-81)packages/clerk-js/src/ui/contexts/components/SignIn.ts (1)
useSignInContext(38-171)packages/clerk-js/src/ui/utils/web3CallbackErrorHandler.ts (1)
web3CallbackErrorHandler(10-23)packages/clerk-js/src/ui/common/withRedirect.tsx (2)
withRedirectToSignInTask(93-113)withRedirectToAfterSignIn(55-72)
⏰ 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). (4)
- GitHub Check: Formatting | Dedupe | Changeset
- GitHub Check: Build Packages
- GitHub Check: semgrep-cloud-platform/scan
- GitHub Check: Analyze (javascript-typescript)
🔇 Additional comments (1)
packages/clerk-js/src/ui/elements/contexts/index.tsx (1)
131-132: FlowMetadata.part additions use correct camelCase descriptor naming
enterpriseConnectionsandchooseWalletfollow the camelCase convention used by otherpartvalues and satisfy the guideline that element descriptors be camelCase. This also addresses the earlier concern about the kebab-case'choose-wallet'descriptor in this union.
kduprey
force-pushed
the
kenton/user-3770-add-functionality-to-clerk-js-to-be-able-to-detect-all
branch
from
55bbaf8 to
efea5dd
Compare
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
packages/clerk-js/src/ui/components/SignIn/SignInFactorOneSolanaWalletsCard.tsx (2)
44-57: Consider driving card loading state aroundauthenticateWithWeb3Right now the
web3AuthCallbackonly updatescard.errorviaweb3CallbackErrorHandleron rejection but never toggles loading, so the card UI may not reflect that an async auth action is in progress.If
cardexposes asetLoadinghelper (as it does in other flows), consider wrapping the call like:- <Web3WalletButtons - web3AuthCallback={({ walletName }) => { - return clerk - .authenticateWithWeb3({ - customNavigate: router.navigate, - redirectUrl: ctx.afterSignInUrl || '/', - secondFactorUrl: 'factor-two', - signUpContinueUrl: ctx.isCombinedFlow ? '../create/continue' : ctx.signUpContinueUrl, - strategy: 'web3_solana_signature', - walletName, - }) - .catch(err => web3CallbackErrorHandler(err, card.setError)); - }} - /> + <Web3WalletButtons + web3AuthCallback={async ({ walletName }) => { + card.setLoading(true); + try { + await clerk.authenticateWithWeb3({ + customNavigate: router.navigate, + redirectUrl: ctx.afterSignInUrl || '/', + secondFactorUrl: 'factor-two', + signUpContinueUrl: ctx.isCombinedFlow ? '../create/continue' : ctx.signUpContinueUrl, + strategy: 'web3_solana_signature', + walletName, + }); + } catch (err) { + web3CallbackErrorHandler(err, card.setError); + } finally { + card.setLoading(false); + } + }} + />This would keep card-level loading UX consistent with other form/submit flows.
As per coding guidelines, this aligns with using
useCardStateto manage loading and error states.
44-59: Optional: provide a non-null Suspense fallback for wallet buttons
<Suspense fallback={null}>will leave the wallet area blank whileWeb3WalletButtonsloads. Consider a lightweight skeleton or spinner in the card body so users get feedback that wallets are being discovered/loaded.
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Disabled knowledge base sources:
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (4)
packages/clerk-js/bundlewatch.config.json(2 hunks)packages/clerk-js/src/ui/components/SignIn/SignInFactorOneSolanaWalletsCard.tsx(1 hunks)packages/clerk-js/src/ui/components/SignUp/SignUpStartSolanaWalletsCard.tsx(1 hunks)packages/clerk-js/src/ui/elements/contexts/index.tsx(1 hunks)
✅ Files skipped from review due to trivial changes (1)
- packages/clerk-js/src/ui/components/SignUp/SignUpStartSolanaWalletsCard.tsx
🚧 Files skipped from review as they are similar to previous changes (1)
- packages/clerk-js/src/ui/elements/contexts/index.tsx
🧰 Additional context used
📓 Path-based instructions (11)
packages/clerk-js/src/ui/**/*.{ts,tsx}
📄 CodeRabbit inference engine (.cursor/rules/clerk-js-ui.mdc)
packages/clerk-js/src/ui/**/*.{ts,tsx}: Element descriptors should be written in camelCase
Use useCardState for card-level state management
Use useFormState for form-level state management
Use useLoadingStatus for managing loading states
Use useFormControl hook for form field state management with validation and localization support
All rendered values must be localized using useLocalizations hook - hard coded values are not allowed
Use localizationKeys for translating UI text with support for parameters and error messages
Use handleError utility for API error handling and provide field states for proper error mapping
Use the styled system sx prop with theme tokens for custom styling instead of inline styles
Use the Card component pattern with Card.Root, Card.Header, Card.Title, Card.Content, and Card.Footer for consistent card layouts
Use FormContainer with headerTitle and headerSubtitle localization keys combined with Form.Root and FormButtons for consistent form layouts
When form submission occurs, manage loading and error states by calling status.setLoading(), card.setLoading(), and card.setError() appropriately
Files:
packages/clerk-js/src/ui/components/SignIn/SignInFactorOneSolanaWalletsCard.tsx
**/*.{js,jsx,ts,tsx}
📄 CodeRabbit inference engine (.cursor/rules/development.mdc)
All code must pass ESLint checks with the project's configuration
Files:
packages/clerk-js/src/ui/components/SignIn/SignInFactorOneSolanaWalletsCard.tsx
**/*.{js,jsx,ts,tsx,json,md,yml,yaml}
📄 CodeRabbit inference engine (.cursor/rules/development.mdc)
Use Prettier for consistent code formatting
Files:
packages/clerk-js/src/ui/components/SignIn/SignInFactorOneSolanaWalletsCard.tsxpackages/clerk-js/bundlewatch.config.json
packages/**/src/**/*.{ts,tsx}
📄 CodeRabbit inference engine (.cursor/rules/development.mdc)
TypeScript is required for all packages
Files:
packages/clerk-js/src/ui/components/SignIn/SignInFactorOneSolanaWalletsCard.tsx
**/*.{ts,tsx,js,jsx}
📄 CodeRabbit inference engine (.cursor/rules/development.mdc)
Follow established naming conventions (PascalCase for components, camelCase for variables)
Prefer importing types from
@clerk/shared/typesinstead of the deprecated@clerk/typesalias
Files:
packages/clerk-js/src/ui/components/SignIn/SignInFactorOneSolanaWalletsCard.tsx
packages/**/src/**/*.{ts,tsx,js,jsx}
📄 CodeRabbit inference engine (.cursor/rules/development.mdc)
packages/**/src/**/*.{ts,tsx,js,jsx}: Maintain comprehensive JSDoc comments for public APIs
Use tree-shaking friendly exports
Validate all inputs and sanitize outputs
All public APIs must be documented with JSDoc
Use dynamic imports for optional features
Provide meaningful error messages to developers
Include error recovery suggestions where applicable
Log errors appropriately for debugging
Lazy load components and features when possible
Implement proper caching strategies
Use efficient data structures and algorithms
Implement proper logging with different levels
Files:
packages/clerk-js/src/ui/components/SignIn/SignInFactorOneSolanaWalletsCard.tsx
**/*.ts?(x)
📄 CodeRabbit inference engine (.cursor/rules/development.mdc)
Use proper TypeScript error types
Files:
packages/clerk-js/src/ui/components/SignIn/SignInFactorOneSolanaWalletsCard.tsx
**/*.tsx
📄 CodeRabbit inference engine (.cursor/rules/development.mdc)
**/*.tsx: Use error boundaries in React components
Minimize re-renders in React components
**/*.tsx: Use proper type definitions for props and state in React components
Leverage TypeScript's type inference where possible in React components
Use proper event types for handlers in React components
Implement proper generic types for reusable React components
Use proper type guards for conditional rendering in React components
Files:
packages/clerk-js/src/ui/components/SignIn/SignInFactorOneSolanaWalletsCard.tsx
**/*.{md,tsx}
📄 CodeRabbit inference engine (.cursor/rules/development.mdc)
Update documentation for API changes
Files:
packages/clerk-js/src/ui/components/SignIn/SignInFactorOneSolanaWalletsCard.tsx
**/*.{jsx,tsx}
📄 CodeRabbit inference engine (.cursor/rules/react.mdc)
**/*.{jsx,tsx}: Always use functional components with hooks instead of class components
Follow PascalCase naming for components (e.g.,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
Separate UI components from business logic components
Use useState for simple state management in React components
Use useReducer for complex state logic in React components
Implement proper state initialization in React components
Use proper state updates with callbacks in React components
Implement proper state cleanup in React components
Use Context API for theme/authentication state management
Implement proper state persistence in React applications
Use React.memo for expensive components
Implement proper useCallback for handlers in React components
Use proper useMemo for expensive computations in React components
Implement proper virtualization for lists in React components
Use proper code splitting with React.lazy in React applications
Implement proper cleanup in useEffect hooks
Use proper refs for DOM access in React components
Implement proper event listener cleanup in React components
Use proper abort controllers for fetch in React components
Implement proper subscription cleanup in React components
Use proper HTML elements for semantic HTML in React components
Implement proper ARIA attributes for accessibility in React components
Use proper heading hierarchy in React components
Implement proper form labels in React components
Use proper button types in React components
Implement proper focus management for keyboard navigation in React components
Use proper keyboard shortcuts in React components
Implement proper tab order in React components
Use proper ...
Files:
packages/clerk-js/src/ui/components/SignIn/SignInFactorOneSolanaWalletsCard.tsx
**/*.{ts,tsx}
📄 CodeRabbit inference engine (.cursor/rules/typescript.mdc)
**/*.{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
Implement type guards forunknowntypes using the patternfunction isType(value: unknown): value is Type
Useinterfacefor object shapes that might be extended
Usetypefor unions, primitives, and computed types
Preferreadonlyproperties for immutable data structures
Useprivatefor internal implementation details in classes
Useprotectedfor inheritance hierarchies
Usepublicexplicitly for clarity in public APIs
Use mixins for shared behavior across unrelated classes in TypeScript
Use generic constraints with bounded type parameters like<T extends { id: string }>
Use utility types likeOmit,Partial, andPickfor data transformation instead of manual type construction
Use discriminated unions instead of boolean flags for state management and API responses
Use mapped types for transforming object types
Use conditional types for type-level logic
Leverage template literal types for string manipulation at the type level
Use ES6 imports/exports consistently
Use default exports sparingly, prefer named exports
Document functions with JSDoc comments including @param, @returns, @throws, and @example tags
Create custom error classes that extend Error for specific error types
Use the Result pattern for error handling instead of throwing exceptions
Use optional chaining (?.) and nullish coalescing (??) operators for safe property access
Let TypeScript infer obvious types to reduce verbosity
Useconst assertionswithas constfor literal types
Usesatisfiesoperator for type checking without widening types
Declare readonly arrays and objects for immutable data structures
Use spread operator and array spread for immutable updates instead of mutations
Use lazy loading for large types...
Files:
packages/clerk-js/src/ui/components/SignIn/SignInFactorOneSolanaWalletsCard.tsx
⏰ 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). (3)
- GitHub Check: Formatting | Dedupe | Changeset
- GitHub Check: triage
- GitHub Check: Analyze (javascript-typescript)
🔇 Additional comments (5)
packages/clerk-js/bundlewatch.config.json (4)
1-37: JSON formatting is consistent and Prettier-compliant.The file maintains uniform 2-space indentation and follows proper JSON structure throughout.
5-5: Verify the purpose and necessity of the newclerk.channel.browser.jsentry.This is a new runtime bundle entry introduced in this PR. The name suggests a channel/messaging module rather than Web3/Solana-specific functionality. Clarify whether this bundle is intentional for the Solana integration or if it's an unrelated addition that should be tracked separately.
23-23: Verify the 200% bundle size increase foronetap*.js(1KB → 3KB).While bundle increases are expected when adding features, the jump from 1KB to 3KB warrants verification to ensure it reflects actual feature additions rather than unnecessary dependencies. Confirm that the onetap module was modified to support Solana or if this is an unrelated change.
3-7: Bundle size increases align with Solana wallet authentication feature scope.The increases across clerk.js, clerk.browser.js, clerk.legacy.browser.js, clerk.headless*.js, ui-common*.legacy..js, vendors.js, and signup*.js are reasonable given the PR adds Solana authentication dependencies (@solana/wallet-standard, @solana/wallet-adapter-base, @solana/wallet-adapter-react, bs58) and new wallet-selection UI flows. The signup*.js increase of ~1.5KB is proportionate to the new Solana sign-up functionality.
Also applies to: 9-10, 19-19
packages/clerk-js/src/ui/components/SignIn/SignInFactorOneSolanaWalletsCard.tsx (1)
21-76: Overall Solana wallets card wiring looks solidComponent composition, routing, and auth wiring look consistent with existing patterns: you use
Flow.Part('chooseWallet'), the Card/Header/BackLink pattern, threadwalletNameintoauthenticateWithWeb3, and wrap the inner card withwithCardStateProvider,withRedirectToAfterSignIn, andwithRedirectToSignInTask. I don’t see any blocking issues here.
…r.js Signed-off-by: Kenton Duprey <kenton@clerk.dev>
…o 'chooseWallet' Signed-off-by: Kenton Duprey <kenton@clerk.dev>
kduprey
force-pushed
the
kenton/user-3770-add-functionality-to-clerk-js-to-be-able-to-detect-all
branch
from
efea5dd to
c727058
Compare
kduprey
changed the title
Signed-off-by: Kenton Duprey <kenton@clerk.dev>
kduprey
changed the title
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
packages/clerk-js/src/ui/components/SignIn/SignInFactorOneSolanaWalletsCard.tsx (2)
27-29: Add explicit return type annotation.Per TypeScript guidelines, functions should have explicit return types for clarity and type safety.
Apply this diff:
- const onBackLinkClick = () => { + const onBackLinkClick = (): void => { void router.navigate('../'); };
46-57: Consider usingcard.runAsyncfor consistent loading state management.The current implementation sets the error state but doesn't manage loading/idle states. The
useCardStatehook provides arunAsynchelper that automatically handles loading and idle states, ensuring consistent UI feedback.Apply this diff:
<Web3WalletButtons - web3AuthCallback={({ walletName }) => { - return clerk - .authenticateWithWeb3({ - customNavigate: router.navigate, - redirectUrl: ctx.afterSignInUrl || '/', - secondFactorUrl: 'factor-two', - signUpContinueUrl: ctx.isCombinedFlow ? '../create/continue' : ctx.signUpContinueUrl, - strategy: 'web3_solana_signature', - walletName, - }) - .catch(err => web3CallbackErrorHandler(err, card.setError)); + web3AuthCallback={({ walletName }) => { + return card + .runAsync( + clerk.authenticateWithWeb3({ + customNavigate: router.navigate, + redirectUrl: ctx.afterSignInUrl || '/', + secondFactorUrl: 'factor-two', + signUpContinueUrl: ctx.isCombinedFlow ? '../create/continue' : ctx.signUpContinueUrl, + strategy: 'web3_solana_signature', + walletName, + }), + ) + .catch(err => web3CallbackErrorHandler(err, card.setError)); }}
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Disabled knowledge base sources:
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (5)
.changeset/legal-jokes-beg.md(1 hunks)packages/clerk-js/bundlewatch.config.json(2 hunks)packages/clerk-js/src/ui/components/SignIn/SignInFactorOneSolanaWalletsCard.tsx(1 hunks)packages/clerk-js/src/ui/components/SignUp/SignUpStartSolanaWalletsCard.tsx(1 hunks)packages/clerk-js/src/ui/elements/contexts/index.tsx(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (2)
- packages/clerk-js/src/ui/components/SignUp/SignUpStartSolanaWalletsCard.tsx
- packages/clerk-js/bundlewatch.config.json
🧰 Additional context used
📓 Path-based instructions (11)
packages/clerk-js/src/ui/**/*.{ts,tsx}
📄 CodeRabbit inference engine (.cursor/rules/clerk-js-ui.mdc)
packages/clerk-js/src/ui/**/*.{ts,tsx}: Element descriptors should be written in camelCase
Use useCardState for card-level state management
Use useFormState for form-level state management
Use useLoadingStatus for managing loading states
Use useFormControl hook for form field state management with validation and localization support
All rendered values must be localized using useLocalizations hook - hard coded values are not allowed
Use localizationKeys for translating UI text with support for parameters and error messages
Use handleError utility for API error handling and provide field states for proper error mapping
Use the styled system sx prop with theme tokens for custom styling instead of inline styles
Use the Card component pattern with Card.Root, Card.Header, Card.Title, Card.Content, and Card.Footer for consistent card layouts
Use FormContainer with headerTitle and headerSubtitle localization keys combined with Form.Root and FormButtons for consistent form layouts
When form submission occurs, manage loading and error states by calling status.setLoading(), card.setLoading(), and card.setError() appropriately
Files:
packages/clerk-js/src/ui/elements/contexts/index.tsxpackages/clerk-js/src/ui/components/SignIn/SignInFactorOneSolanaWalletsCard.tsx
**/*.{js,jsx,ts,tsx}
📄 CodeRabbit inference engine (.cursor/rules/development.mdc)
All code must pass ESLint checks with the project's configuration
Files:
packages/clerk-js/src/ui/elements/contexts/index.tsxpackages/clerk-js/src/ui/components/SignIn/SignInFactorOneSolanaWalletsCard.tsx
**/*.{js,jsx,ts,tsx,json,md,yml,yaml}
📄 CodeRabbit inference engine (.cursor/rules/development.mdc)
Use Prettier for consistent code formatting
Files:
packages/clerk-js/src/ui/elements/contexts/index.tsxpackages/clerk-js/src/ui/components/SignIn/SignInFactorOneSolanaWalletsCard.tsx
packages/**/src/**/*.{ts,tsx}
📄 CodeRabbit inference engine (.cursor/rules/development.mdc)
TypeScript is required for all packages
Files:
packages/clerk-js/src/ui/elements/contexts/index.tsxpackages/clerk-js/src/ui/components/SignIn/SignInFactorOneSolanaWalletsCard.tsx
**/*.{ts,tsx,js,jsx}
📄 CodeRabbit inference engine (.cursor/rules/development.mdc)
Follow established naming conventions (PascalCase for components, camelCase for variables)
Prefer importing types from
@clerk/shared/typesinstead of the deprecated@clerk/typesalias
Files:
packages/clerk-js/src/ui/elements/contexts/index.tsxpackages/clerk-js/src/ui/components/SignIn/SignInFactorOneSolanaWalletsCard.tsx
packages/**/src/**/*.{ts,tsx,js,jsx}
📄 CodeRabbit inference engine (.cursor/rules/development.mdc)
packages/**/src/**/*.{ts,tsx,js,jsx}: Maintain comprehensive JSDoc comments for public APIs
Use tree-shaking friendly exports
Validate all inputs and sanitize outputs
All public APIs must be documented with JSDoc
Use dynamic imports for optional features
Provide meaningful error messages to developers
Include error recovery suggestions where applicable
Log errors appropriately for debugging
Lazy load components and features when possible
Implement proper caching strategies
Use efficient data structures and algorithms
Implement proper logging with different levels
Files:
packages/clerk-js/src/ui/elements/contexts/index.tsxpackages/clerk-js/src/ui/components/SignIn/SignInFactorOneSolanaWalletsCard.tsx
**/*.ts?(x)
📄 CodeRabbit inference engine (.cursor/rules/development.mdc)
Use proper TypeScript error types
Files:
packages/clerk-js/src/ui/elements/contexts/index.tsxpackages/clerk-js/src/ui/components/SignIn/SignInFactorOneSolanaWalletsCard.tsx
**/*.tsx
📄 CodeRabbit inference engine (.cursor/rules/development.mdc)
**/*.tsx: Use error boundaries in React components
Minimize re-renders in React components
**/*.tsx: Use proper type definitions for props and state in React components
Leverage TypeScript's type inference where possible in React components
Use proper event types for handlers in React components
Implement proper generic types for reusable React components
Use proper type guards for conditional rendering in React components
Files:
packages/clerk-js/src/ui/elements/contexts/index.tsxpackages/clerk-js/src/ui/components/SignIn/SignInFactorOneSolanaWalletsCard.tsx
**/*.{md,tsx}
📄 CodeRabbit inference engine (.cursor/rules/development.mdc)
Update documentation for API changes
Files:
packages/clerk-js/src/ui/elements/contexts/index.tsxpackages/clerk-js/src/ui/components/SignIn/SignInFactorOneSolanaWalletsCard.tsx
**/*.{jsx,tsx}
📄 CodeRabbit inference engine (.cursor/rules/react.mdc)
**/*.{jsx,tsx}: Always use functional components with hooks instead of class components
Follow PascalCase naming for components (e.g.,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
Separate UI components from business logic components
Use useState for simple state management in React components
Use useReducer for complex state logic in React components
Implement proper state initialization in React components
Use proper state updates with callbacks in React components
Implement proper state cleanup in React components
Use Context API for theme/authentication state management
Implement proper state persistence in React applications
Use React.memo for expensive components
Implement proper useCallback for handlers in React components
Use proper useMemo for expensive computations in React components
Implement proper virtualization for lists in React components
Use proper code splitting with React.lazy in React applications
Implement proper cleanup in useEffect hooks
Use proper refs for DOM access in React components
Implement proper event listener cleanup in React components
Use proper abort controllers for fetch in React components
Implement proper subscription cleanup in React components
Use proper HTML elements for semantic HTML in React components
Implement proper ARIA attributes for accessibility in React components
Use proper heading hierarchy in React components
Implement proper form labels in React components
Use proper button types in React components
Implement proper focus management for keyboard navigation in React components
Use proper keyboard shortcuts in React components
Implement proper tab order in React components
Use proper ...
Files:
packages/clerk-js/src/ui/elements/contexts/index.tsxpackages/clerk-js/src/ui/components/SignIn/SignInFactorOneSolanaWalletsCard.tsx
**/*.{ts,tsx}
📄 CodeRabbit inference engine (.cursor/rules/typescript.mdc)
**/*.{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
Implement type guards forunknowntypes using the patternfunction isType(value: unknown): value is Type
Useinterfacefor object shapes that might be extended
Usetypefor unions, primitives, and computed types
Preferreadonlyproperties for immutable data structures
Useprivatefor internal implementation details in classes
Useprotectedfor inheritance hierarchies
Usepublicexplicitly for clarity in public APIs
Use mixins for shared behavior across unrelated classes in TypeScript
Use generic constraints with bounded type parameters like<T extends { id: string }>
Use utility types likeOmit,Partial, andPickfor data transformation instead of manual type construction
Use discriminated unions instead of boolean flags for state management and API responses
Use mapped types for transforming object types
Use conditional types for type-level logic
Leverage template literal types for string manipulation at the type level
Use ES6 imports/exports consistently
Use default exports sparingly, prefer named exports
Document functions with JSDoc comments including @param, @returns, @throws, and @example tags
Create custom error classes that extend Error for specific error types
Use the Result pattern for error handling instead of throwing exceptions
Use optional chaining (?.) and nullish coalescing (??) operators for safe property access
Let TypeScript infer obvious types to reduce verbosity
Useconst assertionswithas constfor literal types
Usesatisfiesoperator for type checking without widening types
Declare readonly arrays and objects for immutable data structures
Use spread operator and array spread for immutable updates instead of mutations
Use lazy loading for large types...
Files:
packages/clerk-js/src/ui/elements/contexts/index.tsxpackages/clerk-js/src/ui/components/SignIn/SignInFactorOneSolanaWalletsCard.tsx
🧬 Code graph analysis (1)
packages/clerk-js/src/ui/components/SignIn/SignInFactorOneSolanaWalletsCard.tsx (5)
packages/clerk-js/src/ui/elements/Web3WalletButtons.tsx (1)
Web3WalletButtons(262-277)packages/clerk-js/src/ui/elements/contexts/index.tsx (2)
useCardState(42-70)withCardStateProvider(72-81)packages/clerk-js/src/ui/contexts/components/SignIn.ts (1)
useSignInContext(38-171)packages/clerk-js/src/ui/utils/web3CallbackErrorHandler.ts (1)
web3CallbackErrorHandler(10-23)packages/clerk-js/src/ui/common/withRedirect.tsx (2)
withRedirectToSignInTask(93-113)withRedirectToAfterSignIn(55-72)
⏰ 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). (32)
- GitHub Check: Integration Tests (nextjs, chrome, 16)
- GitHub Check: Integration Tests (machine, chrome)
- GitHub Check: Integration Tests (quickstart, chrome, 16)
- GitHub Check: Integration Tests (react-router, chrome)
- GitHub Check: Integration Tests (machine, chrome, RQ)
- GitHub Check: Integration Tests (billing, chrome)
- GitHub Check: Integration Tests (nextjs, chrome, 14)
- GitHub Check: Integration Tests (billing, chrome, RQ)
- GitHub Check: Integration Tests (nextjs, chrome, 15, RQ)
- GitHub Check: Integration Tests (custom, chrome)
- GitHub Check: Integration Tests (quickstart, chrome, 15)
- GitHub Check: Integration Tests (nextjs, chrome, 15)
- GitHub Check: Integration Tests (nuxt, chrome)
- GitHub Check: Integration Tests (handshake:staging, chrome)
- GitHub Check: Integration Tests (tanstack-react-start, chrome)
- GitHub Check: Integration Tests (expo-web, chrome)
- GitHub Check: Integration Tests (handshake, chrome)
- GitHub Check: Integration Tests (vue, chrome)
- GitHub Check: Integration Tests (sessions, chrome)
- GitHub Check: Integration Tests (astro, chrome)
- GitHub Check: Integration Tests (sessions:staging, chrome)
- GitHub Check: Integration Tests (generic, chrome)
- GitHub Check: Integration Tests (localhost, chrome)
- GitHub Check: Integration Tests (elements, chrome)
- GitHub Check: Integration Tests (express, chrome)
- GitHub Check: Integration Tests (ap-flows, chrome)
- GitHub Check: Publish with pkg-pr-new
- GitHub Check: Unit Tests (22, shared, clerk-js, RQ)
- GitHub Check: Static analysis
- GitHub Check: Unit Tests (22, **)
- GitHub Check: Analyze (javascript-typescript)
- GitHub Check: semgrep-cloud-platform/scan
🔇 Additional comments (5)
.changeset/legal-jokes-beg.md (1)
1-9: Changeset is well-structured and version levels are appropriate.The changeset correctly lists all packages mentioned in the PR scope and marks them with minor version bumps, which is appropriate for adding new Solana authentication functionality without introducing breaking changes. The description accurately summarizes the feature being added.
Please verify that this changeset includes all monorepo packages with modifications. Based on the PR description, the listed packages appear complete, but confirm that any other workspace packages that received updates (e.g., if @clerk/backend, @clerk/types, or other internal packages were modified) are included.
packages/clerk-js/src/ui/elements/contexts/index.tsx (1)
131-132: Camelcase naming convention correctly applied.The 'chooseWallet' descriptor at line 132 correctly uses camelCase as required by the coding guidelines. No kebab-case 'choose-wallet' references remain in the codebase.
packages/clerk-js/src/ui/components/SignIn/SignInFactorOneSolanaWalletsCard.tsx (3)
1-20: LGTM! Clean imports with proper lazy loading setup.The imports follow the project conventions, use the correct
@clerk/shared/reactsource, and set up lazy loading for performance optimization.
31-72: LGTM! Component follows clerk-js UI patterns correctly.The component properly uses:
- Card component pattern with Root/Content/Footer
- Localization keys for all user-facing text
- camelCase for element descriptors ('chooseWallet')
- Card.Alert for error display
- Suspense boundary for lazy-loaded content
- Proper navigation handler with BackLink
74-76: LGTM! Proper HOC composition for redirect and state management.The composition correctly layers:
withCardStateProvider- provides card state contextwithRedirectToAfterSignIn- handles post-authentication redirectswithRedirectToSignInTask- handles task-based redirectsThis follows the established pattern in the codebase for sign-in components.
| }, | ||
| totpMfa: { | ||
| formTitle: 'Verification code', | ||
| subtitle: 'To continue, please enter the verification code generated by your authenticator app', |
There was a problem hiding this comment.
❕ Let's not forget to run pnpm generate in the localizations package before merging
…egated Signed-off-by: Kenton Duprey <kenton@clerk.dev>
There was a problem hiding this comment.
Actionable comments posted: 10
♻️ Duplicate comments (2)
packages/localizations/src/en-GB.ts (1)
849-852: Consider providing British English translations for Solana sign-up text.Similar to the sign-in flow, the
web3Solanakeys undersignUpare undefined. For consistency with the rest of the localization file and improved UX, consider adding explicit en-GB translations.packages/localizations/src/ja-JP.ts (1)
859-862: Missing Japanese translations for Solana sign-up UI.Same issue as the sign-in block (lines 762-765): Japanese users will see no localized text for Solana wallet sign-up flows due to
undefinedvalues.
🧹 Nitpick comments (57)
packages/localizations/src/zh-TW.ts (1)
740-743: Consider adding Traditional Chinese translations for new Solana/Web3 features.All newly added Solana/Web3 localization keys are set to
undefined:
signIn.web3Solana(subtitle, title)signUp.web3Solana(subtitle, title)unstable__errors.web3_signature_request_rejectedunstable__errors.web3_solana_signature_generation_failedweb3WalletButtons(connect, continue, noneAvailable)This means Traditional Chinese users will see fallback text (likely English) when interacting with Solana authentication flows, which degrades the localized experience. While the file's disclaimer acknowledges this is a community contribution without completeness guarantees, providing translations would improve UX consistency for zh-TW speakers.
Also applies to: 835-838, 931-932, 1320-1324
packages/localizations/src/sr-RS.ts (1)
751-754: Consider providing Serbian translations for the new Solana wallet keys.The new Solana-related localization keys (
signIn.web3Solana,signUp.web3Solana, error messages forweb3_signature_request_rejectedandweb3_solana_signature_generation_failed, andweb3WalletButtons) are all set toundefined. While this is consistent with the community-contributed nature of this file and many existing undefined keys, providing Serbian translations would improve the user experience for Serbian-speaking users when they interact with the new Solana wallet authentication features.Also applies to: 845-848, 947-948, 1352-1356
packages/localizations/src/es-UY.ts (1)
756-759: LGTM! Solana localization placeholders added correctly.The structural additions for Solana Web3 authentication support are correct:
signIn.web3SolanaandsignUp.web3Solanablocks for authentication UI strings- New error keys
web3_signature_request_rejectedandweb3_solana_signature_generation_failed- Top-level
web3WalletButtonsgrouping for wallet selection UIAll new keys are set to
undefined, which is expected and acceptable for this community-maintained locale (per the disclaimer at the top). Spanish (Uruguay) users will see fallback text until translations are contributed.Optionally, verify that the key structure and placement match other locale files modified in this PR to ensure consistency across the localization system.
Also applies to: 854-857, 959-960, 1366-1370
packages/localizations/src/es-CR.ts (4)
758-761: Localization placeholders for Solana sign-in flow.The
web3Solanablock structure is correct. Theundefinedvalues are placeholders awaiting Spanish translations for Costa Rica. While this aligns with the community contribution model (see file disclaimer), users will see fallback text until translations are provided.Consider adding Spanish translations:
web3Solana: { - subtitle: undefined, - title: undefined, + subtitle: 'para continuar con {{applicationName}}', + title: 'Verificar billetera Solana', },
854-857: Localization placeholders for Solana sign-up flow.The
web3Solanablock structure mirrors the sign-in equivalent. Theundefinedplaceholders are consistent with the community contribution model. Users will see fallback text until Spanish translations are added.Consider adding Spanish translations:
web3Solana: { - subtitle: undefined, - title: undefined, + subtitle: 'para continuar con {{applicationName}}', + title: 'Conectar billetera Solana', },
957-958: Add translations for Solana error messages.These error keys handle authentication failures during Solana wallet operations. While
undefinedis acceptable for this community-contributed locale, user-facing error messages benefit from localization more than other UI text, as they appear when users need troubleshooting guidance.Consider adding Spanish translations for these error messages:
-web3_signature_request_rejected: undefined, -web3_solana_signature_generation_failed: undefined, +web3_signature_request_rejected: 'Solicitud de firma rechazada. Por favor, aprueba la firma en tu billetera para continuar.', +web3_solana_signature_generation_failed: 'No se pudo generar la firma de Solana. Por favor, intenta de nuevo.',
1366-1370: Localization placeholders for Web3 wallet buttons.The top-level
web3WalletButtonsblock structure is correct. These keys control wallet interaction button labels throughout the Solana authentication flow. Theundefinedplaceholders align with the community contribution model.Consider adding Spanish translations:
web3WalletButtons: { - connect: undefined, - continue: undefined, - noneAvailable: undefined, + connect: 'Conectar billetera', + continue: 'Continuar con {{wallet}}', + noneAvailable: 'No hay billeteras disponibles', },packages/localizations/src/pt-PT.ts (4)
750-753: Portuguese translations missing for Solana sign-in flow.The
web3Solanasection undersignIn.starthas bothsubtitleandtitleset toundefined. While this is consistent with the pattern used throughout this community-contributed localization file, providing Portuguese translations would improve the user experience for Portuguese-speaking users authenticating with Solana wallets.
845-848: Portuguese translations missing for Solana sign-up flow.Similar to the sign-in flow, the
web3Solanasection undersignUphassubtitleandtitleset toundefined. Consider adding Portuguese translations for consistency across both sign-in and sign-up authentication flows.
947-948: Error messages for Solana authentication are untranslated.The error keys
web3_signature_request_rejectedandweb3_solana_signature_generation_failedare set toundefined. Error messages are particularly important to localize since they communicate critical feedback to users during authentication failures. Portuguese-speaking users would benefit from clear, translated error messages when Solana wallet authentication issues occur.
1352-1356: Portuguese translations missing for Web3 wallet button labels.The
web3WalletButtonssection contains action labels (connect,continue) and status messages (noneAvailable) that are all set toundefined. These button labels are part of the user interaction flow for wallet selection and would benefit from Portuguese translations.packages/localizations/src/uk-UA.ts (3)
750-753: Missing Ukrainian translations for Solana sign-in UI.The
web3Solanablock undersignInhas bothsubtitleandtitleset toundefined, meaning Ukrainian users will see fallback text (likely English) when using Solana wallet authentication.If translations are planned for a future PR, consider tracking completion of Ukrainian localization for all Solana-related keys to ensure feature parity across supported locales.
944-945: Missing Ukrainian translations for Solana error messages.The Solana-specific error keys
web3_signature_request_rejectedandweb3_solana_signature_generation_failedare undefined, which means Ukrainian users encountering these errors will see fallback text.Error messages are particularly important for localization as they help users understand and resolve issues. Consider prioritizing translations for error-related keys to improve user experience when troubleshooting Solana authentication failures.
1350-1354: Missing Ukrainian translations for wallet button labels.The
web3WalletButtonsblock contains UI strings (connect,continue,noneAvailable) that are all undefined. These appear to be button labels for the wallet selection interface.Button labels and user-facing UI text are high-visibility elements. Consider ensuring these translations are completed to maintain a consistent Ukrainian language experience throughout the Solana wallet connection flow.
packages/localizations/src/en-GB.ts (3)
753-756: Consider providing British English translations for Solana sign-in text.The
web3Solanalocalization keys are set toundefined, which will cause the UI to fall back to the default locale. While this follows the pattern of other undefined keys in this community-contributed file, providing explicit British English translations would improve consistency and user experience for en-GB users.
953-954: Consider providing British English error messages for Solana authentication failures.Error messages help users understand what went wrong. While these keys follow the file's pattern of undefined values, providing explicit en-GB error text would ensure proper British English spelling and phrasing (e.g., "cancelled" vs "canceled") for better user experience.
1359-1363: Consider localizing Web3 wallet button labels.The
web3WalletButtonssection contains undefined values for button labels (connect,continue,noneAvailable). While this follows the established pattern in this file, providing explicit British English text would ensure consistency with the rest of the UI.packages/localizations/src/kk-KZ.ts (1)
744-747: Consider providing Kazakh translations for the new Solana wallet features.All new Solana-related localization entries (
signIn.web3Solana,signUp.web3Solana, error messages, andweb3WalletButtons) are set toundefined, meaning Kazakh-speaking users will see fallback text (likely English) for these features. While this is consistent with the file's existing pattern and its disclaimer as a community-contributed locale, providing translations would improve the user experience for Kazakh speakers.Also applies to: 839-842, 937-938, 1332-1336
packages/localizations/src/zh-CN.ts (1)
740-743: Consider providing Chinese translations for Solana-related localization keys.All new Solana-related keys (
signIn.web3Solana,signUp.start.web3Solana, error keysweb3_signature_request_rejectedandweb3_solana_signature_generation_failed, andweb3WalletButtonsfields) are set toundefined. While this is consistent with the file's existing pattern for untranslated strings and acceptable given the community-maintained disclaimer, providing actual Chinese (Simplified) translations would improve the user experience for zh-CN users when the Solana authentication feature is enabled.Also applies to: 834-837, 931-932, 1322-1326
packages/localizations/src/ro-RO.ts (4)
763-766: Translation placeholders for Solana sign-in.The
web3Solanablock undersignIncontains undefined placeholders for Romanian translations. While acceptable for this community-contributed locale file, these should eventually be translated to provide proper UI text for Romanian users authenticating with Solana wallets.
860-863: Translation placeholders for Solana sign-up.The
web3Solanablock undersignUpcontains undefined placeholders for Romanian translations. These should eventually be populated to support Romanian users creating accounts via Solana wallet authentication.
963-964: Error message placeholders for Solana wallet failures.These undefined error keys (
web3_signature_request_rejected,web3_solana_signature_generation_failed) will be shown to users when Solana wallet operations fail. Error messages should be prioritized for translation to ensure Romanian users receive clear feedback during authentication failures.
1368-1372: Wallet button UI text placeholders.The
web3WalletButtonsblock contains undefined placeholders for button labels and messages in the wallet selection UI. These control the text users see when connecting Solana wallets and should be translated for Romanian locale.packages/localizations/src/pl-PL.ts (4)
754-757: Consider adding Polish translations for Solana sign-in strings.The
web3Solanasection has been added with bothsubtitleandtitleset toundefined. While this is consistent with the pattern in this community-contributed locale, Polish-speaking users will experience missing or fallback text during the Solana wallet sign-in flow.Consider providing Polish translations for these keys to improve the user experience:
web3Solana: { - subtitle: undefined, - title: undefined, + subtitle: 'wybierz portfel Solana', + title: 'Zaloguj się za pomocą portfela Solana', },Note: As this is a community-contributed localization file (per the disclaimer), undefined values may be acceptable, but translations would enhance completeness.
852-855: Consider adding Polish translations for Solana sign-up strings.Similar to the sign-in section, the
web3Solanaentries in the sign-up flow are undefined. Polish users will see missing or fallback text during account creation with Solana wallets.Consider providing Polish translations:
web3Solana: { - subtitle: undefined, - title: undefined, + subtitle: 'wybierz portfel Solana', + title: 'Zarejestruj się za pomocą portfela Solana', },
956-957: Consider adding Polish translations for Solana error messages.The new error keys
web3_signature_request_rejectedandweb3_solana_signature_generation_failedare undefined. Error messages are particularly important for user experience as they help users understand and troubleshoot issues.Consider providing Polish translations for these error messages:
- web3_signature_request_rejected: undefined, - web3_solana_signature_generation_failed: undefined, + web3_signature_request_rejected: 'Żądanie podpisu zostało odrzucone. Spróbuj ponownie lub użyj innej metody.', + web3_solana_signature_generation_failed: 'Nie udało się wygenerować podpisu Solana. Upewnij się, że Twój portfel jest prawidłowo skonfigurowany.',
1363-1367: Consider adding Polish translations for wallet button labels.The new
web3WalletButtonssection contains button labels that are undefined. These are interactive elements users will encounter when connecting Solana wallets.Consider providing Polish translations:
web3WalletButtons: { - connect: undefined, - continue: undefined, - noneAvailable: undefined, + connect: 'Połącz portfel', + continue: 'Kontynuuj z portfelem', + noneAvailable: 'Brak dostępnych portfeli Solana', },packages/localizations/src/vi-VN.ts (4)
759-762: Add Vietnamese translations for Solana sign-in.The
web3Solanablock has been added withundefinedplaceholders. Vietnamese users will not see translated text for the Solana wallet sign-in flow. Consider adding Vietnamese translations forsubtitleandtitleto provide a complete localized experience.Example structure (translations needed):
web3Solana: { - subtitle: undefined, - title: undefined, + subtitle: 'Vietnamese translation for Solana wallet subtitle', + title: 'Vietnamese translation for Solana wallet title', },
855-858: Add Vietnamese translations for Solana sign-up.Similar to the sign-in flow, the
web3Solanablock in the sign-up section usesundefinedplaceholders. Vietnamese users will not see translated text during the Solana wallet sign-up flow.
955-955: Add Vietnamese translation for Solana signature error.The error key
web3_solana_signature_generation_failedis undefined. When Solana signature generation fails, Vietnamese users will not see a localized error message. Error messages are important for user understanding and troubleshooting.
1362-1366: Add Vietnamese translations for Web3 wallet button labels.The new
web3WalletButtonssection contains three button labels (connect,continue,noneAvailable) that are all undefined. These are user-facing button labels in the wallet selection UI and should be translated for Vietnamese users.Example translations needed:
web3WalletButtons: { - connect: undefined, - continue: undefined, - noneAvailable: undefined, + connect: 'Vietnamese translation for connect', + continue: 'Vietnamese translation for continue', + noneAvailable: 'Vietnamese translation for none available', },packages/localizations/src/th-TH.ts (2)
753-756: Placeholder localization keys for Solana sign-in.The
web3Solanakeys undersignIn.startare correctly structured but haveundefinedvalues awaiting Thai translation. This follows the established pattern for this community-contributed localization file.Consider tracking these untranslated keys to ensure Thai translations are provided in a follow-up:
signIn.start.web3Solana.subtitlesignIn.start.web3Solana.title
948-949: Prioritize translation of Solana error messages.The new error keys
web3_signature_request_rejectedandweb3_solana_signature_generation_failedare correctly placed underunstable__errors, but error messages are critical for user experience. Consider prioritizing Thai translations for these keys, as users encountering authentication failures need clear feedback.packages/localizations/src/bg-BG.ts (3)
753-756: Solana sign‑in/sign‑up keys look structurally correct; translations can be added laterThe new
signIn.web3SolanaandsignUp.web3Solanablocks are correctly placed and shaped to match the rest of the localization tree; leavingtitle/subtitleasundefinedis consistent with other missing strings in this file and should be safe if you rely on fallback behavior. When you have Bulgarian copy available, it would be good to fill these in so Solana‑specific screens are fully localized.Also applies to: 848-851
946-947: New Solana web3 error keys wired in; consider providing BG strings for UX completenessAdding
unstable__errors.web3_signature_request_rejectedandunstable__errors.web3_solana_signature_generation_failedkeeps this locale aligned with the expanded error surface. As with otherundefinederrors here, the app will likely fall back to a default message; when convenient, add Bulgarian messages so Solana‑related failures are understandable for BG‑only users.
1353-1357:web3WalletButtonsblock aligns with new Web3 UI; optional follow‑up to localize labelsThe new
web3WalletButtonsgroup at the root matches the expected structure for shared Web3 wallet button labels and shouldn’t cause typing or runtime issues asundefined. As a low‑priority follow‑up, adding Bulgarian strings forconnect,continue, andnoneAvailablewould keep the new Solana/Web3 wallet picker fully localized.packages/localizations/src/it-IT.ts (3)
759-762: Consider adding Italian copy for new Solana sign‑in/sign‑up steps
signIn.web3SolanaandsignUp.web3Solanaare currently allundefined, which likely falls back to the default locale or produces generic copy. For a smoother Italian UX around the new Solana flows, you could inline simple translations like:@@ - web3Solana: { - subtitle: undefined, - title: undefined, - }, + web3Solana: { + subtitle: 'Seleziona il tuo wallet Solana per continuare.', + title: 'Accedi con Solana', + }, @@ - web3Solana: { - subtitle: undefined, - title: undefined, - }, + web3Solana: { + subtitle: 'Seleziona il tuo wallet Solana per creare il tuo account.', + title: 'Registrati con Solana', + },Also applies to: 855-858
956-957: Optionally localize new Solana/web3 error messagesThe new
unstable__errorskeys for Solana are defined but leftundefined. To avoid falling back to English (or showing empty text) in Italian for these new cases, you could add brief translations:- web3_signature_request_rejected: undefined, - web3_solana_signature_generation_failed: undefined, + web3_signature_request_rejected: 'La richiesta di firma dal wallet è stata rifiutata.', + web3_solana_signature_generation_failed: + 'Non è stato possibile generare la firma dal wallet Solana. Riprova.',
1365-1369: Provide Italian labels for shared Web3 wallet buttonsThe new
web3WalletButtonsblock is a good central place for wallet UI copy; right now it’s allundefined. If you want full Italian coverage for the Solana/Web3 flows, consider:web3WalletButtons: { - connect: undefined, - continue: undefined, - noneAvailable: undefined, + connect: 'Connetti wallet', + continue: 'Continua', + noneAvailable: 'Nessun wallet compatibile disponibile', },packages/localizations/src/ms-MY.ts (5)
13-13: Consider switchingLocalizationResourceimport to@clerk/shared/typesGuidelines prefer importing types from
@clerk/shared/typesinstead of the deprecated@clerk/typesalias. If the shared types entry point is available in this package version, consider updating the import (ideally in all locale files together for consistency):-import type { LocalizationResource } from '@clerk/types'; +import type { LocalizationResource } from '@clerk/shared/types';
757-760: Solana sign-in strings defined structurally; currently fall back to default localeThe new
signIn.web3Solanakeys are correctly added so the locale shape matches the core schema. Withsubtitleandtitleset toundefined, the UI will fall back to the default locale, which is acceptable for a community-maintained locale but not ideal long term. When you have Malay translations available, you can safely fill these in without further code changes.
855-858: Solana sign-up strings added with fallback behavior
signUp.web3Solanais wired up with the expectedsubtitleandtitlekeys, currentlyundefinedso they fall back to the base locale. This keeps the resource type-safe and aligned with other locales; consider adding Malay copy later so users of this locale see fully localized Solana flows.
963-965: New Solana web3 error messages lack localized copyThe new error keys
unstable__errors.web3_signature_request_rejectedunstable__errors.web3_solana_signature_generation_failedare present but
undefined, so users on this locale will see fallback (likely English) messages. That’s functionally fine, but for consistency with the rest of this file you may want to add Malay translations when available so Solana-specific failures are localized as well.
1372-1376: web3 wallet button labels wired up but not localized yetThe
web3WalletButtonsblock is correctly introduced withconnect,continue, andnoneAvailablekeys so the new wallet-selection UI can bind to them. Leaving themundefinedis safe (fallback to default locale), but you may want to eventually provide Malay text here to align with other wallet-related strings likeweb3WalletPageandweb3WalletsSection.packages/localizations/src/ru-RU.ts (3)
761-764: Optional: Add Russian copy for newweb3Solanasign-in/sign-up headingsThe new
signIn.web3SolanaandsignUp.web3Solanablocks are structurally correct, but bothtitleandsubtitleareundefined. If you want full RU coverage for the new Solana flows, consider adding Russian strings here (or confirming that falling back to the base locale is acceptable for this language).Also applies to: 859-862
962-963: Optional: Localize new Solana/Web3 error messagesThe new
web3_signature_request_rejectedandweb3_solana_signature_generation_failederror keys are wired up but leftundefined. To avoid mixed-language error states for Russian users, you may want to add RU translations (or explicitly rely on a documented fallback behavior).
1373-1377: Optional: Provide RU labels forweb3WalletButtonsThe new
web3WalletButtonsgroup (connect,continue,noneAvailable) is correctly added but values areundefined. For a smoother RU UX in the Solana wallet picker, consider supplying Russian labels when translations are available.packages/localizations/src/nb-NO.ts (3)
752-755: Solana sign‑in/sign‑up localization keys added but left to base localeThe new
signIn.start.web3SolanaandsignUp.start.web3Solanablocks are correctly shaped and will fall back to the default locale because values areundefined. That’s consistent with the rest of this community file, but if you want to avoid mixed‑language UI for Solana flows, consider adding Norwegiantitle/subtitlestrings once the English copy is finalized.Also applies to: 846-849
947-948: Solana web3 error codes wired; optional follow‑up for Norwegian copy
unstable__errors.web3_signature_request_rejectedandunstable__errors.web3_solana_signature_generation_failedare present and will use the base locale text viaundefinedvalues, which is fine for keeping the shape in sync. As a later enhancement, you may want to provide Norwegian translations to keep error messaging consistent with the rest of this locale.
1353-1357:web3WalletButtonsgroup matches expected shape; translations can come laterThe new root
web3WalletButtonsobject withconnect,continue, andnoneAvailablealigns with the expected structure for the wallet selection UI and will fall back to the default language for now. Once the UX copy is stable, consider adding Norwegian strings here to avoid English buttons in an otherwise localized flow.packages/localizations/src/fr-FR.ts (4)
767-770: Clarify Solana sign‑in headings for the new flow
signIn.web3Solana.titleand.subtitle(Line 767–Line 770) are defined asundefined, so fr‑FR will fall back to the base locale for this new Solana wallet route. If the goal is full French coverage, consider adding localized strings consistent withen-US, e.g. quelque chose comme : “Se connecter avec un portefeuille Solana” / “Choisissez un portefeuille Solana pour continuer.”
863-866: Add or confirm Solana sign‑up copySimilarly,
signUp.web3Solana.titleand.subtitle(Line 863–Line 866) are leftundefined. If you want the Solana sign‑up wallet‑selection step localized, consider providing French text (e.g. “Créer un compte avec un portefeuille Solana” / “Choisissez un portefeuille Solana pour créer votre compte.”), otherwise confirm that falling back to the default locale is intentional.
966-967: Localize new Solana/Web3 error messages for consistencyNear
unstable__errors.web3_missing_identifier, the new keysweb3_signature_request_rejectedandweb3_solana_signature_generation_failed(Line 966–Line 967) remainundefined. To keep error messaging consistent in French, consider adding translations instead of relying on the fallback locale.For example:
- web3_signature_request_rejected: undefined, - web3_solana_signature_generation_failed: undefined, + web3_signature_request_rejected: 'La demande de signature a été refusée.', + web3_solana_signature_generation_failed: + 'La génération de la signature Solana a échoué. Veuillez réessayer.',
1376-1380: Consider localizing shared Web3 wallet button labelsThe new
web3WalletButtonsentries (Line 1376–Line 1380) are allundefined. These are likely used by the shared Web3 wallet selection UI, so French users will see fallback text.If you want full localization here, you could add something along these lines:
- web3WalletButtons: { - connect: undefined, - continue: undefined, - noneAvailable: undefined, - }, + web3WalletButtons: { + connect: 'Connecter un portefeuille Web3', + continue: 'Continuer', + noneAvailable: "Aucun portefeuille Web3 compatible n’a été trouvé", + },Adjust wording as needed to match the exact
en-USsemantics.packages/localizations/src/de-DE.ts (3)
1386-1390: Plan translations forweb3WalletButtonslabelsThe new top‑level group:
web3WalletButtons: { connect: undefined, continue: undefined, noneAvailable: undefined, },matches the expected shape, but with
undefinedvalues you’ll end up with fallback (likely English) labels on wallet buttons in this locale. Not urgent, but you may want to localize these later, for example:connect: 'Wallet verbinden', continue: 'Mit ausgewählter Wallet fortfahren', noneAvailable: 'Keine kompatiblen Wallets verfügbar',
973-975: Add German translations for new Web3/Solana error keysThe keys
web3_signature_request_rejectedandweb3_solana_signature_generation_failedare defined in en-US.ts but left asundefinedin de-DE.ts. German users will see English error messages instead of German ones.Consider translating them based on the English versions:
web3_signature_request_rejected: 'Sie haben die Signaturanfrage abgelehnt. Bitte versuchen Sie es erneut, um fortzufahren.', web3_solana_signature_generation_failed: 'Ein Fehler beim Generieren der Signatur ist aufgetreten. Bitte versuchen Sie es erneut, um fortzufahren.',
13-15: Consider aligningLocalizationResourceimport with newer path in a coordinated refactorAll localization files currently import from
@clerk/types, but coding guidelines recommend@clerk/shared/types. Since this is a codebase-wide pattern, updating de-DE.ts in isolation would create inconsistency. Plan this change as part of a coordinated refactor across all localization files.
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Disabled knowledge base sources:
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (49)
packages/localizations/src/ar-SA.ts(4 hunks)packages/localizations/src/be-BY.ts(4 hunks)packages/localizations/src/bg-BG.ts(4 hunks)packages/localizations/src/bn-IN.ts(4 hunks)packages/localizations/src/ca-ES.ts(4 hunks)packages/localizations/src/cs-CZ.ts(4 hunks)packages/localizations/src/da-DK.ts(4 hunks)packages/localizations/src/de-DE.ts(4 hunks)packages/localizations/src/el-GR.ts(4 hunks)packages/localizations/src/en-GB.ts(4 hunks)packages/localizations/src/en-US.ts(4 hunks)packages/localizations/src/es-CR.ts(4 hunks)packages/localizations/src/es-ES.ts(4 hunks)packages/localizations/src/es-MX.ts(4 hunks)packages/localizations/src/es-UY.ts(4 hunks)packages/localizations/src/fa-IR.ts(4 hunks)packages/localizations/src/fi-FI.ts(4 hunks)packages/localizations/src/fr-FR.ts(4 hunks)packages/localizations/src/he-IL.ts(4 hunks)packages/localizations/src/hi-IN.ts(4 hunks)packages/localizations/src/hr-HR.ts(4 hunks)packages/localizations/src/hu-HU.ts(4 hunks)packages/localizations/src/id-ID.ts(4 hunks)packages/localizations/src/is-IS.ts(4 hunks)packages/localizations/src/it-IT.ts(4 hunks)packages/localizations/src/ja-JP.ts(4 hunks)packages/localizations/src/kk-KZ.ts(4 hunks)packages/localizations/src/ko-KR.ts(4 hunks)packages/localizations/src/mn-MN.ts(4 hunks)packages/localizations/src/ms-MY.ts(4 hunks)packages/localizations/src/nb-NO.ts(4 hunks)packages/localizations/src/nl-BE.ts(4 hunks)packages/localizations/src/nl-NL.ts(4 hunks)packages/localizations/src/pl-PL.ts(4 hunks)packages/localizations/src/pt-BR.ts(4 hunks)packages/localizations/src/pt-PT.ts(4 hunks)packages/localizations/src/ro-RO.ts(4 hunks)packages/localizations/src/ru-RU.ts(4 hunks)packages/localizations/src/sk-SK.ts(4 hunks)packages/localizations/src/sr-RS.ts(4 hunks)packages/localizations/src/sv-SE.ts(4 hunks)packages/localizations/src/ta-IN.ts(4 hunks)packages/localizations/src/te-IN.ts(4 hunks)packages/localizations/src/th-TH.ts(4 hunks)packages/localizations/src/tr-TR.ts(4 hunks)packages/localizations/src/uk-UA.ts(4 hunks)packages/localizations/src/vi-VN.ts(4 hunks)packages/localizations/src/zh-CN.ts(4 hunks)packages/localizations/src/zh-TW.ts(4 hunks)
✅ Files skipped from review due to trivial changes (3)
- packages/localizations/src/nl-BE.ts
- packages/localizations/src/id-ID.ts
- packages/localizations/src/bn-IN.ts
🧰 Additional context used
📓 Path-based instructions (8)
**/*.{js,jsx,ts,tsx}
📄 CodeRabbit inference engine (.cursor/rules/development.mdc)
All code must pass ESLint checks with the project's configuration
Files:
packages/localizations/src/vi-VN.tspackages/localizations/src/el-GR.tspackages/localizations/src/hu-HU.tspackages/localizations/src/he-IL.tspackages/localizations/src/es-MX.tspackages/localizations/src/it-IT.tspackages/localizations/src/uk-UA.tspackages/localizations/src/es-CR.tspackages/localizations/src/ca-ES.tspackages/localizations/src/ja-JP.tspackages/localizations/src/fi-FI.tspackages/localizations/src/zh-TW.tspackages/localizations/src/en-US.tspackages/localizations/src/nb-NO.tspackages/localizations/src/zh-CN.tspackages/localizations/src/bg-BG.tspackages/localizations/src/tr-TR.tspackages/localizations/src/sr-RS.tspackages/localizations/src/fa-IR.tspackages/localizations/src/ko-KR.tspackages/localizations/src/mn-MN.tspackages/localizations/src/be-BY.tspackages/localizations/src/is-IS.tspackages/localizations/src/kk-KZ.tspackages/localizations/src/es-UY.tspackages/localizations/src/pt-PT.tspackages/localizations/src/hr-HR.tspackages/localizations/src/sk-SK.tspackages/localizations/src/de-DE.tspackages/localizations/src/th-TH.tspackages/localizations/src/cs-CZ.tspackages/localizations/src/da-DK.tspackages/localizations/src/sv-SE.tspackages/localizations/src/ar-SA.tspackages/localizations/src/nl-NL.tspackages/localizations/src/ro-RO.tspackages/localizations/src/es-ES.tspackages/localizations/src/ms-MY.tspackages/localizations/src/pt-BR.tspackages/localizations/src/pl-PL.tspackages/localizations/src/ta-IN.tspackages/localizations/src/en-GB.tspackages/localizations/src/te-IN.tspackages/localizations/src/ru-RU.tspackages/localizations/src/fr-FR.tspackages/localizations/src/hi-IN.ts
**/*.{js,jsx,ts,tsx,json,md,yml,yaml}
📄 CodeRabbit inference engine (.cursor/rules/development.mdc)
Use Prettier for consistent code formatting
Files:
packages/localizations/src/vi-VN.tspackages/localizations/src/el-GR.tspackages/localizations/src/hu-HU.tspackages/localizations/src/he-IL.tspackages/localizations/src/es-MX.tspackages/localizations/src/it-IT.tspackages/localizations/src/uk-UA.tspackages/localizations/src/es-CR.tspackages/localizations/src/ca-ES.tspackages/localizations/src/ja-JP.tspackages/localizations/src/fi-FI.tspackages/localizations/src/zh-TW.tspackages/localizations/src/en-US.tspackages/localizations/src/nb-NO.tspackages/localizations/src/zh-CN.tspackages/localizations/src/bg-BG.tspackages/localizations/src/tr-TR.tspackages/localizations/src/sr-RS.tspackages/localizations/src/fa-IR.tspackages/localizations/src/ko-KR.tspackages/localizations/src/mn-MN.tspackages/localizations/src/be-BY.tspackages/localizations/src/is-IS.tspackages/localizations/src/kk-KZ.tspackages/localizations/src/es-UY.tspackages/localizations/src/pt-PT.tspackages/localizations/src/hr-HR.tspackages/localizations/src/sk-SK.tspackages/localizations/src/de-DE.tspackages/localizations/src/th-TH.tspackages/localizations/src/cs-CZ.tspackages/localizations/src/da-DK.tspackages/localizations/src/sv-SE.tspackages/localizations/src/ar-SA.tspackages/localizations/src/nl-NL.tspackages/localizations/src/ro-RO.tspackages/localizations/src/es-ES.tspackages/localizations/src/ms-MY.tspackages/localizations/src/pt-BR.tspackages/localizations/src/pl-PL.tspackages/localizations/src/ta-IN.tspackages/localizations/src/en-GB.tspackages/localizations/src/te-IN.tspackages/localizations/src/ru-RU.tspackages/localizations/src/fr-FR.tspackages/localizations/src/hi-IN.ts
packages/**/src/**/*.{ts,tsx}
📄 CodeRabbit inference engine (.cursor/rules/development.mdc)
TypeScript is required for all packages
Files:
packages/localizations/src/vi-VN.tspackages/localizations/src/el-GR.tspackages/localizations/src/hu-HU.tspackages/localizations/src/he-IL.tspackages/localizations/src/es-MX.tspackages/localizations/src/it-IT.tspackages/localizations/src/uk-UA.tspackages/localizations/src/es-CR.tspackages/localizations/src/ca-ES.tspackages/localizations/src/ja-JP.tspackages/localizations/src/fi-FI.tspackages/localizations/src/zh-TW.tspackages/localizations/src/en-US.tspackages/localizations/src/nb-NO.tspackages/localizations/src/zh-CN.tspackages/localizations/src/bg-BG.tspackages/localizations/src/tr-TR.tspackages/localizations/src/sr-RS.tspackages/localizations/src/fa-IR.tspackages/localizations/src/ko-KR.tspackages/localizations/src/mn-MN.tspackages/localizations/src/be-BY.tspackages/localizations/src/is-IS.tspackages/localizations/src/kk-KZ.tspackages/localizations/src/es-UY.tspackages/localizations/src/pt-PT.tspackages/localizations/src/hr-HR.tspackages/localizations/src/sk-SK.tspackages/localizations/src/de-DE.tspackages/localizations/src/th-TH.tspackages/localizations/src/cs-CZ.tspackages/localizations/src/da-DK.tspackages/localizations/src/sv-SE.tspackages/localizations/src/ar-SA.tspackages/localizations/src/nl-NL.tspackages/localizations/src/ro-RO.tspackages/localizations/src/es-ES.tspackages/localizations/src/ms-MY.tspackages/localizations/src/pt-BR.tspackages/localizations/src/pl-PL.tspackages/localizations/src/ta-IN.tspackages/localizations/src/en-GB.tspackages/localizations/src/te-IN.tspackages/localizations/src/ru-RU.tspackages/localizations/src/fr-FR.tspackages/localizations/src/hi-IN.ts
**/*.{ts,tsx,js,jsx}
📄 CodeRabbit inference engine (.cursor/rules/development.mdc)
Follow established naming conventions (PascalCase for components, camelCase for variables)
Prefer importing types from
@clerk/shared/typesinstead of the deprecated@clerk/typesalias
Files:
packages/localizations/src/vi-VN.tspackages/localizations/src/el-GR.tspackages/localizations/src/hu-HU.tspackages/localizations/src/he-IL.tspackages/localizations/src/es-MX.tspackages/localizations/src/it-IT.tspackages/localizations/src/uk-UA.tspackages/localizations/src/es-CR.tspackages/localizations/src/ca-ES.tspackages/localizations/src/ja-JP.tspackages/localizations/src/fi-FI.tspackages/localizations/src/zh-TW.tspackages/localizations/src/en-US.tspackages/localizations/src/nb-NO.tspackages/localizations/src/zh-CN.tspackages/localizations/src/bg-BG.tspackages/localizations/src/tr-TR.tspackages/localizations/src/sr-RS.tspackages/localizations/src/fa-IR.tspackages/localizations/src/ko-KR.tspackages/localizations/src/mn-MN.tspackages/localizations/src/be-BY.tspackages/localizations/src/is-IS.tspackages/localizations/src/kk-KZ.tspackages/localizations/src/es-UY.tspackages/localizations/src/pt-PT.tspackages/localizations/src/hr-HR.tspackages/localizations/src/sk-SK.tspackages/localizations/src/de-DE.tspackages/localizations/src/th-TH.tspackages/localizations/src/cs-CZ.tspackages/localizations/src/da-DK.tspackages/localizations/src/sv-SE.tspackages/localizations/src/ar-SA.tspackages/localizations/src/nl-NL.tspackages/localizations/src/ro-RO.tspackages/localizations/src/es-ES.tspackages/localizations/src/ms-MY.tspackages/localizations/src/pt-BR.tspackages/localizations/src/pl-PL.tspackages/localizations/src/ta-IN.tspackages/localizations/src/en-GB.tspackages/localizations/src/te-IN.tspackages/localizations/src/ru-RU.tspackages/localizations/src/fr-FR.tspackages/localizations/src/hi-IN.ts
packages/**/src/**/*.{ts,tsx,js,jsx}
📄 CodeRabbit inference engine (.cursor/rules/development.mdc)
packages/**/src/**/*.{ts,tsx,js,jsx}: Maintain comprehensive JSDoc comments for public APIs
Use tree-shaking friendly exports
Validate all inputs and sanitize outputs
All public APIs must be documented with JSDoc
Use dynamic imports for optional features
Provide meaningful error messages to developers
Include error recovery suggestions where applicable
Log errors appropriately for debugging
Lazy load components and features when possible
Implement proper caching strategies
Use efficient data structures and algorithms
Implement proper logging with different levels
Files:
packages/localizations/src/vi-VN.tspackages/localizations/src/el-GR.tspackages/localizations/src/hu-HU.tspackages/localizations/src/he-IL.tspackages/localizations/src/es-MX.tspackages/localizations/src/it-IT.tspackages/localizations/src/uk-UA.tspackages/localizations/src/es-CR.tspackages/localizations/src/ca-ES.tspackages/localizations/src/ja-JP.tspackages/localizations/src/fi-FI.tspackages/localizations/src/zh-TW.tspackages/localizations/src/en-US.tspackages/localizations/src/nb-NO.tspackages/localizations/src/zh-CN.tspackages/localizations/src/bg-BG.tspackages/localizations/src/tr-TR.tspackages/localizations/src/sr-RS.tspackages/localizations/src/fa-IR.tspackages/localizations/src/ko-KR.tspackages/localizations/src/mn-MN.tspackages/localizations/src/be-BY.tspackages/localizations/src/is-IS.tspackages/localizations/src/kk-KZ.tspackages/localizations/src/es-UY.tspackages/localizations/src/pt-PT.tspackages/localizations/src/hr-HR.tspackages/localizations/src/sk-SK.tspackages/localizations/src/de-DE.tspackages/localizations/src/th-TH.tspackages/localizations/src/cs-CZ.tspackages/localizations/src/da-DK.tspackages/localizations/src/sv-SE.tspackages/localizations/src/ar-SA.tspackages/localizations/src/nl-NL.tspackages/localizations/src/ro-RO.tspackages/localizations/src/es-ES.tspackages/localizations/src/ms-MY.tspackages/localizations/src/pt-BR.tspackages/localizations/src/pl-PL.tspackages/localizations/src/ta-IN.tspackages/localizations/src/en-GB.tspackages/localizations/src/te-IN.tspackages/localizations/src/ru-RU.tspackages/localizations/src/fr-FR.tspackages/localizations/src/hi-IN.ts
**/*.ts?(x)
📄 CodeRabbit inference engine (.cursor/rules/development.mdc)
Use proper TypeScript error types
Files:
packages/localizations/src/vi-VN.tspackages/localizations/src/el-GR.tspackages/localizations/src/hu-HU.tspackages/localizations/src/he-IL.tspackages/localizations/src/es-MX.tspackages/localizations/src/it-IT.tspackages/localizations/src/uk-UA.tspackages/localizations/src/es-CR.tspackages/localizations/src/ca-ES.tspackages/localizations/src/ja-JP.tspackages/localizations/src/fi-FI.tspackages/localizations/src/zh-TW.tspackages/localizations/src/en-US.tspackages/localizations/src/nb-NO.tspackages/localizations/src/zh-CN.tspackages/localizations/src/bg-BG.tspackages/localizations/src/tr-TR.tspackages/localizations/src/sr-RS.tspackages/localizations/src/fa-IR.tspackages/localizations/src/ko-KR.tspackages/localizations/src/mn-MN.tspackages/localizations/src/be-BY.tspackages/localizations/src/is-IS.tspackages/localizations/src/kk-KZ.tspackages/localizations/src/es-UY.tspackages/localizations/src/pt-PT.tspackages/localizations/src/hr-HR.tspackages/localizations/src/sk-SK.tspackages/localizations/src/de-DE.tspackages/localizations/src/th-TH.tspackages/localizations/src/cs-CZ.tspackages/localizations/src/da-DK.tspackages/localizations/src/sv-SE.tspackages/localizations/src/ar-SA.tspackages/localizations/src/nl-NL.tspackages/localizations/src/ro-RO.tspackages/localizations/src/es-ES.tspackages/localizations/src/ms-MY.tspackages/localizations/src/pt-BR.tspackages/localizations/src/pl-PL.tspackages/localizations/src/ta-IN.tspackages/localizations/src/en-GB.tspackages/localizations/src/te-IN.tspackages/localizations/src/ru-RU.tspackages/localizations/src/fr-FR.tspackages/localizations/src/hi-IN.ts
packages/localizations/**
📄 CodeRabbit inference engine (.cursor/rules/monorepo.mdc)
packages/localizations/**: Localization support must include translations for 30+ languages using a modular localization system
Support RTL languages in the localization system
Files:
packages/localizations/src/vi-VN.tspackages/localizations/src/el-GR.tspackages/localizations/src/hu-HU.tspackages/localizations/src/he-IL.tspackages/localizations/src/es-MX.tspackages/localizations/src/it-IT.tspackages/localizations/src/uk-UA.tspackages/localizations/src/es-CR.tspackages/localizations/src/ca-ES.tspackages/localizations/src/ja-JP.tspackages/localizations/src/fi-FI.tspackages/localizations/src/zh-TW.tspackages/localizations/src/en-US.tspackages/localizations/src/nb-NO.tspackages/localizations/src/zh-CN.tspackages/localizations/src/bg-BG.tspackages/localizations/src/tr-TR.tspackages/localizations/src/sr-RS.tspackages/localizations/src/fa-IR.tspackages/localizations/src/ko-KR.tspackages/localizations/src/mn-MN.tspackages/localizations/src/be-BY.tspackages/localizations/src/is-IS.tspackages/localizations/src/kk-KZ.tspackages/localizations/src/es-UY.tspackages/localizations/src/pt-PT.tspackages/localizations/src/hr-HR.tspackages/localizations/src/sk-SK.tspackages/localizations/src/de-DE.tspackages/localizations/src/th-TH.tspackages/localizations/src/cs-CZ.tspackages/localizations/src/da-DK.tspackages/localizations/src/sv-SE.tspackages/localizations/src/ar-SA.tspackages/localizations/src/nl-NL.tspackages/localizations/src/ro-RO.tspackages/localizations/src/es-ES.tspackages/localizations/src/ms-MY.tspackages/localizations/src/pt-BR.tspackages/localizations/src/pl-PL.tspackages/localizations/src/ta-IN.tspackages/localizations/src/en-GB.tspackages/localizations/src/te-IN.tspackages/localizations/src/ru-RU.tspackages/localizations/src/fr-FR.tspackages/localizations/src/hi-IN.ts
**/*.{ts,tsx}
📄 CodeRabbit inference engine (.cursor/rules/typescript.mdc)
**/*.{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
Implement type guards forunknowntypes using the patternfunction isType(value: unknown): value is Type
Useinterfacefor object shapes that might be extended
Usetypefor unions, primitives, and computed types
Preferreadonlyproperties for immutable data structures
Useprivatefor internal implementation details in classes
Useprotectedfor inheritance hierarchies
Usepublicexplicitly for clarity in public APIs
Use mixins for shared behavior across unrelated classes in TypeScript
Use generic constraints with bounded type parameters like<T extends { id: string }>
Use utility types likeOmit,Partial, andPickfor data transformation instead of manual type construction
Use discriminated unions instead of boolean flags for state management and API responses
Use mapped types for transforming object types
Use conditional types for type-level logic
Leverage template literal types for string manipulation at the type level
Use ES6 imports/exports consistently
Use default exports sparingly, prefer named exports
Document functions with JSDoc comments including @param, @returns, @throws, and @example tags
Create custom error classes that extend Error for specific error types
Use the Result pattern for error handling instead of throwing exceptions
Use optional chaining (?.) and nullish coalescing (??) operators for safe property access
Let TypeScript infer obvious types to reduce verbosity
Useconst assertionswithas constfor literal types
Usesatisfiesoperator for type checking without widening types
Declare readonly arrays and objects for immutable data structures
Use spread operator and array spread for immutable updates instead of mutations
Use lazy loading for large types...
Files:
packages/localizations/src/vi-VN.tspackages/localizations/src/el-GR.tspackages/localizations/src/hu-HU.tspackages/localizations/src/he-IL.tspackages/localizations/src/es-MX.tspackages/localizations/src/it-IT.tspackages/localizations/src/uk-UA.tspackages/localizations/src/es-CR.tspackages/localizations/src/ca-ES.tspackages/localizations/src/ja-JP.tspackages/localizations/src/fi-FI.tspackages/localizations/src/zh-TW.tspackages/localizations/src/en-US.tspackages/localizations/src/nb-NO.tspackages/localizations/src/zh-CN.tspackages/localizations/src/bg-BG.tspackages/localizations/src/tr-TR.tspackages/localizations/src/sr-RS.tspackages/localizations/src/fa-IR.tspackages/localizations/src/ko-KR.tspackages/localizations/src/mn-MN.tspackages/localizations/src/be-BY.tspackages/localizations/src/is-IS.tspackages/localizations/src/kk-KZ.tspackages/localizations/src/es-UY.tspackages/localizations/src/pt-PT.tspackages/localizations/src/hr-HR.tspackages/localizations/src/sk-SK.tspackages/localizations/src/de-DE.tspackages/localizations/src/th-TH.tspackages/localizations/src/cs-CZ.tspackages/localizations/src/da-DK.tspackages/localizations/src/sv-SE.tspackages/localizations/src/ar-SA.tspackages/localizations/src/nl-NL.tspackages/localizations/src/ro-RO.tspackages/localizations/src/es-ES.tspackages/localizations/src/ms-MY.tspackages/localizations/src/pt-BR.tspackages/localizations/src/pl-PL.tspackages/localizations/src/ta-IN.tspackages/localizations/src/en-GB.tspackages/localizations/src/te-IN.tspackages/localizations/src/ru-RU.tspackages/localizations/src/fr-FR.tspackages/localizations/src/hi-IN.ts
⏰ 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). (3)
- GitHub Check: Formatting | Dedupe | Changeset
- GitHub Check: Build Packages
- GitHub Check: Analyze (javascript-typescript)
| web3Solana: { | ||
| subtitle: undefined, | ||
| title: undefined, | ||
| }, |
There was a problem hiding this comment.
Provide Persian translations for Solana localization entries.
All new Solana-related localization keys are set to undefined, which will cause the application to fall back to the default language (likely English) for these features. This creates an inconsistent user experience where the rest of the application is in Persian but Solana wallet functionality displays in English.
Since Persian (fa-IR) is an RTL language, proper translations are especially important to ensure correct layout and text directionality for the new Solana features.
Consider providing translations for:
signIn.web3Solana.subtitleandsignIn.web3Solana.titlesignUp.web3Solana.subtitleandsignUp.web3Solana.titleunstable__errors.web3_signature_request_rejectedandunstable__errors.web3_solana_signature_generation_failedweb3WalletButtons.connect,web3WalletButtons.continue, andweb3WalletButtons.noneAvailable
Also applies to: 858-861, 957-958, 1363-1367
🤖 Prompt for AI Agents
In packages/localizations/src/fa-IR.ts around lines 761-764 (and also apply the
same fix at 858-861, 957-958, and 1363-1367), several Solana-related keys are
set to undefined; replace each undefined value with proper Persian (fa-IR)
translations for signIn.web3Solana.subtitle, signIn.web3Solana.title,
signUp.web3Solana.subtitle, signUp.web3Solana.title,
unstable__errors.web3_signature_request_rejected,
unstable__errors.web3_solana_signature_generation_failed, and
web3WalletButtons.connect/continue/noneAvailable using the existing translation
style and placeholders in this file, ensuring strings are natural Persian,
RTL-friendly, and match punctuation/placeholder patterns used elsewhere in the
module.
| web3Solana: { | ||
| subtitle: undefined, | ||
| title: undefined, | ||
| }, |
There was a problem hiding this comment.
Provide Hindi translations for Solana sign-in strings.
The web3Solana block has been added with undefined placeholders. Hindi-speaking users will experience degraded UX when using Solana wallet sign-in, as they'll see fallback text (likely English) or missing strings.
Consider either:
- Providing Hindi translations for
subtitleandtitlenow - Opening a tracking issue for localization to be completed before the feature is enabled for production
🤖 Prompt for AI Agents
In packages/localizations/src/hi-IN.ts around lines 755 to 758, the web3Solana
block contains subtitle and title set to undefined which leaves Hindi users
without translations; replace the undefined placeholders with appropriate Hindi
strings for the Solana sign-in title and subtitle (e.g., concise Hindi
translations matching tone/length of other localizations), or if translations
are not available, set temporary descriptive Hindi placeholders and add a
TODO/tracking issue reference comment to ensure proper localization is completed
before enabling the feature in production.
| web3Solana: { | ||
| subtitle: undefined, | ||
| title: undefined, | ||
| }, |
There was a problem hiding this comment.
Provide Hindi translations for Solana sign-up strings.
Similar to the sign-in flow, the web3Solana block under signUp contains undefined placeholders. This will result in inconsistent localization during the sign-up flow for Hindi users.
🤖 Prompt for AI Agents
In packages/localizations/src/hi-IN.ts around lines 852 to 855, the web3Solana
block under signUp has subtitle and title set to undefined; replace those
undefined values with proper Hindi translations (e.g., a concise title and a
short subtitle consistent with the signIn/web3Solana translations used
elsewhere), ensuring they are string literals in Hindi and follow the same tone
and phrasing as other sign-up/localization entries.
| web3_signature_request_rejected: undefined, | ||
| web3_solana_signature_generation_failed: undefined, |
There was a problem hiding this comment.
Provide Hindi translations for Solana error messages.
Error messages are critical for user understanding when operations fail. Users encountering signature rejection or generation failures will see untranslated error text, making troubleshooting difficult.
These translations should be prioritized as error messages directly impact the user's ability to resolve issues.
🤖 Prompt for AI Agents
In packages/localizations/src/hi-IN.ts around lines 958 to 959, the keys
web3_signature_request_rejected and web3_solana_signature_generation_failed are
set to undefined; add appropriate Hindi translations for both error messages.
Replace undefined values with concise, user-facing Hindi strings that clearly
convey "signature request was rejected" and "failed to generate Solana
signature" respectively, matching tone and style of other translations in the
file and ensuring proper punctuation and diacritics.
| web3WalletButtons: { | ||
| connect: undefined, | ||
| continue: undefined, | ||
| noneAvailable: undefined, | ||
| }, |
There was a problem hiding this comment.
Provide Hindi translations for wallet button labels.
The web3WalletButtons group contains action labels (connect, continue) and a fallback message (noneAvailable) that users will see when interacting with Solana wallets. These are primary UI elements in the wallet selection flow.
The noneAvailable message is particularly important as it explains why users cannot proceed when no compatible wallets are detected.
🤖 Prompt for AI Agents
packages/localizations/src/hi-IN.ts around lines 1364 to 1368: the
web3WalletButtons keys are undefined; replace them with Hindi UI strings — set
connect to "कनेक्ट करें", continue to "जारी रखें", and noneAvailable to "कोई
संगत वॉलेट उपलब्ध नहीं है — कृपया वॉलेट इंस्टॉल करें या कनेक्ट करें" so the
wallet selection flow shows meaningful Hindi labels and a helpful fallback
message.
| web3Solana: { | ||
| subtitle: undefined, | ||
| title: undefined, | ||
| }, |
There was a problem hiding this comment.
Missing Icelandic translations for new Solana authentication keys.
All new Solana-related localization keys are set to undefined, meaning Icelandic users will see fallback text (likely English) when using the new Solana wallet authentication feature. While this follows the existing pattern in this community-maintained file, consider providing Icelandic translations for:
signIn.web3Solana.subtitleandsignIn.web3Solana.title(lines 754-757)signUp.web3Solana.subtitleandsignUp.web3Solana.title(lines 849-852)unstable__errors.web3_signature_request_rejectedandunstable__errors.web3_solana_signature_generation_failed(lines 952-953)web3WalletButtons.connect,web3WalletButtons.continue, andweb3WalletButtons.noneAvailable(lines 1360-1364)
Based on learnings, ... (Actually, no learnings were provided, so I won't reference them)
Would you like me to help generate suggested Icelandic translations for these keys, or should this be tracked separately for community translation contributions?
Also applies to: 849-852, 952-953, 1360-1364
🤖 Prompt for AI Agents
In packages/localizations/src/is-IS.ts around lines 754-757 (and additionally
update the other affected ranges: 849-852, 952-953, 1360-1364), replace the
undefined placeholders for the new Solana-related localization keys with proper
Icelandic string values; specifically set signIn.web3Solana.title and .subtitle,
signUp.web3Solana.title and .subtitle,
unstable__errors.web3_signature_request_rejected and
.web3_solana_signature_generation_failed, and web3WalletButtons.connect,
.continue, and .noneAvailable to Icelandic translations (preserve existing key
structure and quoting/escaping conventions), and run the project’s lint/format
step to ensure the file remains valid JSON/TS and compiles.
| web3Solana: { | ||
| subtitle: undefined, | ||
| title: undefined, | ||
| }, |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Search for localization resource handling and fallback logic
rg -nP --type=ts -C3 'LocalizationResource|useLocalizations' packages/ --max-count=20Repository: clerk/javascript
Length of output: 50373
🏁 Script executed:
#!/bin/bash
# Look for how localization values are accessed and any fallback logic
rg -nP --type=ts -C4 '\?..*\(|fallback|??.*locale|undefined.*locale' packages/ --max-count=20Repository: clerk/javascript
Length of output: 149
🏁 Script executed:
#!/bin/bash
# Check the localization system in packages to understand its structure
fd -t f 'localization' packages/ --type f | head -20Repository: clerk/javascript
Length of output: 625
🏁 Script executed:
#!/bin/bash
# Look at the ja-JP file structure to understand the full context
head -50 packages/localizations/src/ja-JP.ts
tail -50 packages/localizations/src/ja-JP.ts
wc -l packages/localizations/src/ja-JP.tsRepository: clerk/javascript
Length of output: 3796
🏁 Script executed:
#!/bin/bash
# Check what other localization files look like for comparison
ls -la packages/localizations/src/ | head -10Repository: clerk/javascript
Length of output: 597
🏁 Script executed:
#!/bin/bash
# Look at English localization to see if it has values for web3Solana
grep -A5 'web3Solana' packages/localizations/src/en-US.ts 2>/dev/null | head -20Repository: clerk/javascript
Length of output: 416
🏁 Script executed:
#!/bin/bash
# Look at parseLocalization.ts to understand how undefined values are handled
head -100 packages/clerk-js/src/ui/localization/parseLocalization.tsRepository: clerk/javascript
Length of output: 1098
🏁 Script executed:
#!/bin/bash
# Check the defaultEnglishResource to see fallback patterns
grep -A5 -B5 'defaultResource\|fallback\|undefined' packages/clerk-js/src/ui/localization/parseLocalization.ts | head -60Repository: clerk/javascript
Length of output: 822
🏁 Script executed:
#!/bin/bash
# Search for how undefined localization values are processed
rg -nP --type=ts -A10 'if.*undefined|parseLocalization|deepMerge' packages/clerk-js/src/ui/localization/parseLocalization.ts | head -80Repository: clerk/javascript
Length of output: 628
🏁 Script executed:
#!/bin/bash
# Check if there's a merge or fallback strategy with defaultResource
rg -nP --type=ts -B3 -A10 'defaultResource|mergeLocalization|fallback' packages/clerk-js/src/ui/localization/ --max-count=40Repository: clerk/javascript
Length of output: 9091
🏁 Script executed:
#!/bin/bash
# Find and examine the fastDeepMergeAndReplace implementation
rg -nP --type=ts -B5 -A20 'fastDeepMergeAndReplace' packages/shared/src/utils/fastDeepMerge.ts | head -80Repository: clerk/javascript
Length of output: 1514
🏁 Script executed:
#!/bin/bash
# Search for the implementation in the shared package
fd -t f 'fastDeepMerge' packages/shared/Repository: clerk/javascript
Length of output: 154
🏁 Script executed:
#!/bin/bash
# Check if web3Solana is undefined in other non-English locales too
rg -nP 'web3Solana' packages/localizations/src/*.ts | grep -c 'undefined'Repository: clerk/javascript
Length of output: 61
🏁 Script executed:
#!/bin/bash
# Sample a few other language files to see the web3Solana pattern
rg -A3 'web3Solana:' packages/localizations/src/de-DE.ts packages/localizations/src/fr-FR.ts packages/localizations/src/es-ES.ts 2>/dev/null | head -30Repository: clerk/javascript
Length of output: 1394
All non-English localizations are missing Solana sign-in/sign-up translations, which will result in empty UI text for users in non-English locales.
The web3Solana blocks with undefined values across all localization files (ja-JP, de-DE, fr-FR, es-ES, and others) will overwrite the English defaults. The localization system merges user-provided translations on top of English defaults; undefined values do not fall back to English but instead render as missing text. This affects the user experience for all users selecting non-English languages.
Add translations for web3Solana.subtitle and web3Solana.title in the signIn and signUp sections for each localization file, or provide English fallbacks as placeholders until proper translations are available.
🤖 Prompt for AI Agents
In packages/localizations/src/ja-JP.ts around lines 762 to 765, the web3Solana
entry sets subtitle and title to undefined which will overwrite English defaults
and produce empty UI text; replace the undefined values with proper Japanese
translations for web3Solana.title and web3Solana.subtitle in both the signIn and
signUp sections, or temporarily supply English fallback strings (e.g., "Sign in
with Solana" / "Sign up with Solana") until accurate translations are available,
ensuring the localization object contains string values rather than undefined.
| web3_signature_request_rejected: undefined, | ||
| web3_solana_signature_generation_failed: undefined, |
There was a problem hiding this comment.
Missing Japanese translations for critical Solana error messages.
The two new Solana error keys (web3_signature_request_rejected and web3_solana_signature_generation_failed) are set to undefined. Error messages are particularly important for user understanding when operations fail. Japanese users experiencing Solana wallet errors will receive no localized explanation of what went wrong.
While this follows the established pattern in the file (many other errors are also undefined), error messages have a higher UX impact than UI labels since they appear during failure scenarios when clear communication is most needed.
🤖 Prompt for AI Agents
In packages/localizations/src/ja-JP.ts around lines 960 to 961, the two Solana
error keys are set to undefined which yields no Japanese message for critical
wallet failures; replace web3_signature_request_rejected and
web3_solana_signature_generation_failed values with concise, user-facing
Japanese error strings (e.g., a rejection notice for user-cancelled signature
requests and a clear failure message for signature generation errors), ensuring
phrasing matches existing tone and placeholders (if any) used elsewhere in the
file, and add translations for both keys so Japanese users receive clear
localized error explanations.
| web3WalletButtons: { | ||
| connect: undefined, | ||
| continue: undefined, | ||
| noneAvailable: undefined, | ||
| }, |
There was a problem hiding this comment.
Missing Japanese translations for Web3 wallet button labels.
The new web3WalletButtons block has all three button labels set to undefined (connect, continue, noneAvailable). The noneAvailable message is particularly important as it informs users when no Solana-capable wallets are detected in their browser.
🤖 Prompt for AI Agents
In packages/localizations/src/ja-JP.ts around lines 1363 to 1367, the
web3WalletButtons object has connect, continue and noneAvailable set to
undefined; replace those undefined values with proper Japanese translations
(e.g., connect -> "接続", continue -> "続行", noneAvailable -> "利用可能なウォレットが見つかりません"
or a similar natural Japanese message), ensuring the strings are i18n-safe and
follow existing file formatting and quotation style.
| web3Solana: { | ||
| subtitle: undefined, | ||
| title: undefined, | ||
| }, |
There was a problem hiding this comment.
Complete Turkish translations for Solana Web3 features.
The new Solana-related localization keys are set to undefined, which means Turkish-speaking users will not see properly localized text for:
- Sign-in and sign-up with Solana wallet flows
- Wallet connection buttons and status messages
- Error messages for signature request failures
While this is consistent with the community-contribution pattern in this file, error messages (lines 950-951) should be prioritized, as users need to understand what went wrong when authentication fails.
Would you like me to help identify which locale file (e.g., en-US) contains the English source strings that need to be translated to Turkish?
Also applies to: 848-851, 950-951, 1356-1360
Description
<SignIn />,<SignUp />components and flowschoose-wallet) andSignInFactorOneSolanaWalletsCardcomponent to choose an installed Solana walletauthenticateWithSolanatoSignIn,SignUp,IsomorphicClerk, and the publicClerkinterfaceinjectedWeb3SolanaProviders.tssingleton mirroring Ethereum provider structure (EIP-6963 style pattern), using wallet-standard eventsweb3.tsto fetch identifier viaStandardConnectand sign messages viasolana:signMessagefeature, encoding with base64 in BAPI request for verification of signatureAuthenticateWithSolanaParams,SignUpAuthenticateWithSolanaParams)@solana/wallet-standard,@solana/wallet-adapter-react,@solana/wallet-adapter-base, and@wallet-standard/corelibs to add React support for rendering Wallet provider buttons and enabling access to wallet extension window injectionswalletNamethrough Clerk core (clerk.ts) during web3 authentication attemptsTesting
This can be tested with a Clerk application that has Sign in with Solana enabled on the instance, by installing this branch of Clerk's libs into a boilerplate application to render the
<SignIn />or<SignUp />components. This does require the browser to have a Web3 wallet extension with a valid Solana chain account to be able to successfully complete the flow.Fixes:
Checklist
pnpm testruns as expected.pnpm buildruns as expected.Type of change
Summary by CodeRabbit
New Features
Bug Fixes
Chores
Localization
✏️ Tip: You can customize this high-level summary in your review settings.