- 
                Notifications
    You must be signed in to change notification settings 
- Fork 403
feat(shared,types): Migrate @clerk/types to @clerk/shared/types #7022
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
| 🦋 Changeset detectedLatest commit: 4b299d5 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. 
 | 
| WalkthroughThis pull request migrates type imports across the codebase from  Changes
 Sequence Diagram(s)sequenceDiagram
    participant OldTypes as @clerk/types
    participant NewTypes as @clerk/shared/types
    participant Module as User Module
    
    Note over OldTypes,Module: Before Migration
    Module->>OldTypes: import type { Resource }
    OldTypes-->>Module: Type definition
    
    Note over OldTypes,Module: After Migration
    Module->>NewTypes: import type { Resource }
    NewTypes-->>Module: Type definition (re-exported)
    NewTypes->>OldTypes: Re-exports all types
    OldTypes-->>NewTypes: Types available for compatibility
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Areas requiring extra attention: 
 
 Pre-merge checks and finishing touches❌ Failed checks (1 warning)
 ✅ Passed checks (2 passed)
 ✨ Finishing touches
 🧪 Generate unit tests (beta)
 📜 Recent review detailsConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Disabled knowledge base sources: 
 
 📒 Files selected for processing (2)
 💤 Files with no reviewable changes (1)
 🚧 Files skipped from review as they are similar to previous changes (1)
 ⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (29)
 Comment  | 
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 27
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/react/contexts.tsx (1)
26-26: OptionsContext default prevents the intended error path.createContext is initialized with {}, so useOptionsContext can never see undefined and won’t throw when provider is missing. Initialize with undefined to restore the guard.
-const OptionsContext = React.createContext<ClerkOptions>({}); +const OptionsContext = React.createContext<ClerkOptions | undefined>(undefined); function useOptionsContext(): ClerkOptions { const context = React.useContext(OptionsContext); - if (context === undefined) { + if (context === undefined) { throw new Error('useOptions must be used within an OptionsContext'); } return context; }As per coding guidelines.
Also applies to: 43-49
🧹 Nitpick comments (28)
packages/shared/src/react/hooks/useOrganizationList.tsx (1)
104-104: Avoid shadowing the type name with the parameter name.On line 104, the parameter is named
CreateOrganizationParams, which shadows the imported type of the same name. This creates confusion and violates naming conventions. Use a lowercase, descriptive parameter name instead.- createOrganization: (CreateOrganizationParams: CreateOrganizationParams) => Promise<OrganizationResource>; + createOrganization: (params: CreateOrganizationParams) => Promise<OrganizationResource>;packages/shared/tsconfig.json (1)
5-5: Minor: Consider broadeningtypesif package is meant for browser environments.Currently
types: ["node"]restricts ambient types to Node only. Sincelibincludes"DOM"and"WebWorker", this is functionally sufficient (those libs provide necessary types), but if the package is meant to be used in both Node and browser contexts, you may want to reconsider this restriction or document it clearly. This is a minor point if usage is Node-only.packages/shared/src/types/utils.ts (4)
92-103: AvoidFunctionand the ESLint override; detect callables safely.Use a callable signature instead of
Function, remove the disable, and keep “no any” where possible.-// eslint-disable-next-line @typescript-eslint/no-unsafe-function-type -type IsSerializable<T> = T extends Function ? false : true; +type IsSerializable<T> = T extends (...args: unknown[]) => unknown ? false : true;As per coding guidelines.
40-46: DeepPartial/DeepRequired should respect arrays, dates, errors, and functions.Current
extends objectrecurses into arrays/functions and mutates built-ins. Guard common built-ins and handle arrays.-export type DeepPartial<T> = { - [P in keyof T]?: T[P] extends object ? DeepPartial<T[P]> : T[P]; -}; +export type DeepPartial<T> = + T extends (...args: unknown[]) => unknown ? T : + T extends Date | RegExp | Error ? T : + T extends readonly (infer U)[] ? readonly DeepPartial<U>[] : + T extends (infer U)[] ? DeepPartial<U>[] : + T extends object ? { [P in keyof T]?: DeepPartial<T[P]> } : + T; -export type DeepRequired<T> = Required<{ - [P in keyof T]: T[P] extends object | undefined ? DeepRequired<Required<T[P]>> : T[P]; -}>; +export type DeepRequired<T> = + T extends (...args: unknown[]) => unknown ? T : + T extends Date | RegExp | Error ? T : + T extends readonly (infer U)[] ? readonly DeepRequired<U>[] : + T extends (infer U)[] ? DeepRequired<U>[] : + T extends object ? { [P in keyof T]-?: DeepRequired<NonNullable<T[P]>> } : + T;As per coding guidelines.
21-35: Camel→snake currently prefixes an underscore for leading uppercase and splits every uppercase run.
'FooBar'becomes'_foo_bar'. Prefer a head/tail approach to avoid a leading underscore and only underscore on transitions.Add helpers (place near these types):
type SnakeFromRest<S extends string> = S extends `${infer C}${infer R}` ? C extends Lowercase<C> ? `${C}${SnakeFromRest<R>}` : `_${Lowercase<C>}${SnakeFromRest<R>}` : ''; type CamelToSnakeString<S extends string> = S extends `${infer First}${infer Rest}` ? `${Lowercase<First>}${SnakeFromRest<Rest>}` : S;Then update:
-export type DeepCamelToSnake<T> = T extends `${infer C0}${infer R}` - ? `${C0 extends Uppercase<C0> ? '_' : ''}${Lowercase<C0>}${DeepCamelToSnake<R>}` - : T extends object - ? { - [K in keyof T as DeepCamelToSnake<Extract<K, string>>]: DeepCamelToSnake<T[K]>; - } - : T; +export type DeepCamelToSnake<T> = + T extends string + ? CamelToSnakeString<T> + : T extends object + ? { [K in keyof T as K extends string ? CamelToSnakeString<K> : K]: DeepCamelToSnake<T[K]> } + : T; -export type CamelToSnake<T> = T extends `${infer C0}${infer R}` - ? `${C0 extends Uppercase<C0> ? '_' : ''}${Lowercase<C0>}${CamelToSnake<R>}` - : T extends object - ? { - [K in keyof T as CamelToSnake<Extract<K, string>>]: T[K]; - } - : T; +export type CamelToSnake<T> = + T extends string + ? CamelToSnakeString<T> + : T extends object + ? { [K in keyof T as K extends string ? CamelToSnakeString<K> : K]: T[K] } + : T;As per coding guidelines.
9-19: Constrain key remapping to strings and add array handling for deep variant.Prevents accidental remapping of symbol/number keys and improves consistency.
-export type SnakeToCamel<T> = T extends `${infer A}_${infer B}` - ? `${Uncapitalize<A>}${Capitalize<SnakeToCamel<B>>}` - : T extends object - ? { [K in keyof T as SnakeToCamel<K>]: T[K] } - : T; +export type SnakeToCamel<T> = + T extends string + ? (T extends `${infer A}_${infer B}` ? `${Uncapitalize<A>}${Capitalize<SnakeToCamel<B>>}` : T) + : T extends object + ? { [K in keyof T as K extends string ? SnakeToCamel<K> : K]: T[K] } + : T; -export type DeepSnakeToCamel<T> = T extends `${infer A}_${infer B}` - ? `${Uncapitalize<A>}${Capitalize<DeepSnakeToCamel<B>>}` - : T extends object - ? { [K in keyof T as DeepSnakeToCamel<K>]: DeepSnakeToCamel<T[K]> } - : T; +export type DeepSnakeToCamel<T> = + T extends string + ? (T extends `${infer A}_${infer B}` ? `${Uncapitalize<A>}${Capitalize<DeepSnakeToCamel<B>>}` : T) + : T extends readonly (infer U)[] ? readonly DeepSnakeToCamel<U>[] : + T extends (infer U)[] ? DeepSnakeToCamel<U>[] : + T extends object ? { [K in keyof T as K extends string ? DeepSnakeToCamel<K> : K]: DeepSnakeToCamel<T[K]> } : + T;As per coding guidelines.
pnpm-workspace.yaml (1)
28-28: v1.0.0-beta.43 is currently the latest stable release, but consider caution due to recency.v1.0.0-beta.43 is the current stable release (published Oct 13, 2025). While it's officially stable, it was released only 4 days ago. The original recommendations remain prudent:
- Review the rolldown changelog for fixes and changes in this version
- Set up monitoring for build failures during the rollout
- Have a rollback plan if unforeseen issues arise
packages/shared/src/types/organizationInvitation.ts (1)
21-21: Minor JSDoc formatting change - no functional impact.The added blank line in the JSDoc comment is a formatting-only change. While it doesn't affect functionality, ensure JSDoc formatting is consistent across the codebase.
packages/themes/src/createTheme.ts (1)
1-3: Type import migrated successfully. Consider updating the comment.The type imports have been correctly migrated to
@clerk/shared/types. However, the comment on lines 1-2 mentions this is a "temp way to import the type" and references extracting theming into its own package. With the type migration now complete, consider updating or removing this comment if it's no longer accurate.packages/shared/src/authorization.ts (1)
344-344: Export order changed - non-breaking but worth noting.The exported functions have been reordered (from
createCheckAuthorization, validateReverificationConfig, resolveAuthState, splitByScopetocreateCheckAuthorization, resolveAuthState, splitByScope, validateReverificationConfig). Since these are named exports, this change is non-breaking and has no runtime impact. The reordering appears intentional but consider whether a consistent ordering convention (alphabetical, by importance, etc.) should be documented.packages/shared/src/types/appearance.ts (1)
657-856: Excellent documentation improvements.The enhanced JSDoc comments with
@defaultvalues and@deprecatedannotations significantly improve the developer experience. The deprecation guidance properly directs developers to new property names.Consider spot-checking a few default values to ensure accuracy, especially for color values like:
- Line 658:
colorPrimarydefault '#2F3037'- Line 680:
colorDangerdefault '#EF4444'- Line 686:
colorSuccessdefault '#22C543'packages/shared/package.json (2)
155-170: Consider marking package as side-effect free.If modules are pure, add
"sideEffects": falseto improve tree-shaking."peerDependenciesMeta": { @@ "engines": { "node": ">=18.17.0" }, + "sideEffects": false, "publishConfig": {
139-143: Remove unnecessarysrcargument from dev script for consistency.The
tsdown.config.mtsalready explicitly defines entry points (entry: ['./src/types/index.ts']), making thesrcargument in the npm script redundant. All other packages in the monorepo use--watchwithout a path argument, relying on their configuration files to define entry points. Removing this argument aligns with the established pattern.- "dev": "tsdown --watch src", + "dev": "tsdown --watch",packages/shared/src/types/billing.ts (2)
620-671: Mark money amount object fields readonly (optional).Immutability reduces accidental mutation and aligns with value-object semantics.
-export interface BillingMoneyAmount { +export interface BillingMoneyAmount { /** * The raw amount as a number, usually in the smallest unit of the currency (like cents for USD). For example, `1000` for $10.00. */ - amount: number; + readonly amount: number; @@ - amountFormatted: string; + readonly amountFormatted: string; @@ - currency: string; + readonly currency: string; @@ - currencySymbol: string; + readonly currencySymbol: string; }As per coding guidelines.
281-332: Return type could be void instead of null (optional).
makeDefaultreturnsPromise<null>. ConsiderPromise<void>unlessnullis significant to callers.- makeDefault: (params?: MakeDefaultPaymentMethodParams) => Promise<null>; + makeDefault: (params?: MakeDefaultPaymentMethodParams) => Promise<void>;packages/themes/tsconfig.json (1)
3-21: Align TypeScript config: lib/target mismatch, enable unused locals check, disable unnecessary JS compilation.The package contains only TypeScript files and has tslib properly declared. Three improvements are recommended:
libshould matchtarget(use es2020 instead of es6)
noUnusedLocalsshould be enabled for consistency withnoUnusedParameters
allowJsis unnecessary; disable it for a TS-only package- "lib": ["es6", "dom"], + "lib": ["es2020", "dom"], @@ - "noUnusedLocals": false, + "noUnusedLocals": true, @@ - "allowJs": true, + "allowJs": falsepackages/shared/src/types/json copy.ts (3)
133-133: Replaceanywithunknown(and narrow where needed).
external_account: any→unknown(or a precise union if known).
claims: Record<string, any>→Record<string, unknown>.Apply:
- external_account: any; + external_account: unknown; @@ - claims: Record<string, any> | null; + claims: Record<string, unknown> | null;As per coding guidelines (avoid any).
Also applies to: 849-849
799-801: Prefertypealias over empty interface with eslint-disable.This avoids disabling lint and is clearer.
Apply:
-// eslint-disable-next-line @typescript-eslint/no-empty-object-type -export interface BillingStatementTotalsJSON extends Omit<BillingCheckoutTotalsJSON, 'total_due_now'> {} +export type BillingStatementTotalsJSON = Omit<BillingCheckoutTotalsJSON, 'total_due_now'>;As per coding guidelines.
194-197: Consider narrowingobjectto a string literal for discriminated unions.Several resources extend ClerkResourceJSON but don’t narrow
object(e.g., IdentificationLinkJSON, SignUpEnterpriseConnectionJSON, EnterpriseAccountConnectionJSON, ApiKeyJSON). Narrowing improves type safety and switches.Please confirm the canonical
objectvalues and update accordingly. Example:export interface IdentificationLinkJSON extends ClerkResourceJSON { - id: string; - type: string; + object: 'identification_link'; + id: string; + type: string; }As per coding guidelines.
Also applies to: 147-151, 260-274, 843-859
packages/astro/src/stores/external.ts (1)
55-55: Narrow the session store type (drop undefined or justify)Unless
$authStorecan produceundefined, preferSignedInSessionResource | nullto reduce consumer nullability.-export const $sessionStore = computed([$authStore], auth => auth.session as SignedInSessionResource | null | undefined); +export const $sessionStore = computed([$authStore], auth => auth.session as SignedInSessionResource | null);If
undefinedis expected before load, consider typing viacomputed< SignedInSessionResource | null | undefined >(...)and document the pre‑load state.packages/shared/src/types/json.ts (3)
133-141: Avoidanyin public JSON typesUse
unknownforexternal_accountto comply with TS guidelines and avoid unsafe any.- external_account: any; + external_account: unknown;As per coding guidelines.
849-851: Preferunknownoveranyfor claims
Record<string, any>weakens type safety. Useunknown.- claims: Record<string, any> | null; + claims: Record<string, unknown> | null;As per coding guidelines.
351-362:VerificationJSON.errorlikely optionalErrors exist only on failed verifications; make
erroroptional to model API reality.- error: ClerkAPIErrorJSON; + error?: ClerkAPIErrorJSON;packages/backend/src/util/shared.ts (1)
12-15: Stale build-tool note.Comment references tsup; repo is moving to tsdown/rolldown. Update the TODO to match current toolchain to avoid confusion.
packages/shared/src/workerTimers/workerTimers.built.ts (2)
1-19: Mark as generated and exclude from lint/coverage.Add standard headers so tools don’t “fix” this file and coverage ignores it.
/** * * This is the minified string output of transforming workerTimers.worker.ts @@ * }; * */ +/* @generated File is auto-produced from workerTimers.worker.ts — do not edit by hand. */ +/* eslint-disable */ +/* istanbul ignore file */
20-20: Worker timer logic: OK; note CSP requirement (operational).The blob URL worker pattern requires allowing blob: in worker-src/connect-src in strict CSPs. Document this where createWorkerTimers consumes this string.
packages/shared/src/react/contexts.tsx (2)
36-38: Add explicit return type for public component.Annotate __experimental_CheckoutProvider return type.
-const __experimental_CheckoutProvider = ({ children, ...rest }: PropsWithChildren<UseCheckoutOptions>) => { +const __experimental_CheckoutProvider = ( + { children, ...rest }: PropsWithChildren<UseCheckoutOptions> +): React.JSX.Element => { return <CheckoutContext.Provider value={{ value: rest }}>{children}</CheckoutContext.Provider>; };As per coding guidelines.
62-67: Avoid any; prefer unknown (or a minimal local type) for swrConfig.Using any here leaks unsoundness. If importing SWR types breaks dts, use unknown instead.
- swrConfig?: any; + swrConfig?: unknown;As per coding guidelines.
| "rolldown": "catalog:repo", | ||
| "statuses": "^1.5.0", | ||
| "tree-kill": "^1.2.2", | ||
| "ts-jest": "29.2.5", | ||
| "tsdown": "catalog:repo", | 
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🧩 Analysis chain
Verify the new build tooling is properly configured across all packages.
Two new build tools have been added as dev dependencies:
- rolldown(line 138) - a Rust-based bundler
- tsdown(line 142) - a TypeScript declaration bundler
Since this is part of the migration from tsup to tsdown/rolldown, ensure that:
- All packages using these tools have appropriate configuration files (e.g., tsdown.config.mts)
- Build scripts in individual packages are updated to use the new tooling
- The build pipeline works end-to-end with the new tools
Run the following to verify the build tooling setup:
🏁 Script executed:
#!/bin/bash
# Check for tsdown config files
echo "=== Checking for tsdown configuration files ==="
fd -t f "tsdown.config" packages/
# Check if tsup configs still exist (should be removed/replaced)
echo -e "\n=== Checking for remaining tsup configs (should be minimal) ==="
fd -t f "tsup.config" packages/
# Check package.json build scripts that reference the new tools
echo -e "\n=== Checking for build script references ==="
fd -t f "package.json" packages/ --exec grep -l "tsdown\|rolldown" {}
# Verify the new tools are in the catalog
echo -e "\n=== Checking pnpm workspace catalog ==="
cat pnpm-workspace.yaml | grep -A 2 "tsdown\|rolldown"Length of output: 986
I need to verify if this partial migration is intentional and check the build scripts in packages that still use tsup.
Let me check the build scripts to see which tools are being used in the packages:
Let me examine the actual build scripts in the packages to understand the state better:
🏁 Script executed:
#!/bin/bash
# Check build scripts in shared package (already migrated)
echo "=== shared package.json build scripts ==="
cat packages/shared/package.json | grep -A 20 '"scripts"'
# Check one package still using tsup
echo -e "\n=== One example: agent-toolkit package.json build scripts ==="
cat packages/agent-toolkit/package.json | grep -A 20 '"scripts"'
# Count packages and their tooling
echo -e "\n=== Build tool references in package.json files ==="
echo "Packages with tsdown reference:"
fd -t f "package.json" packages/ --exec grep -l "tsdown" {} | wc -l
echo "Packages with tsup reference:"
fd -t f "package.json" packages/ --exec grep -l "tsup" {} | wc -l
echo "Packages with neither (might use rolldown directly):"
fd -t f "package.json" packages/ -not -exec grep -l "tsdown\|tsup\|rolldown" {} \; | wc -lLength of output: 2357
Build tooling migration is incomplete—only 1 of ~20 packages has been migrated to tsdown.
The verification confirms the review comment's concern: the migration from tsup to tsdown/rolldown is not yet complete across all packages.
Current state:
- 1 package migrated: packages/sharedhastsdown.config.mtsand usestsdownin build scripts
- 19 packages unmigrated: Still have tsup.config.tsfiles andtsupcommands in build scripts (agent-toolkit,astro,backend,chrome-extension,elements,expo,expo-passkeys,express,fastify,localizations,nextjs,nuxt,react,react-router,remix,tanstack-react-start,testing,themes,vue)
Both tooling versions remain in the pnpm workspace catalog (tsup: 8.5.0, tsdown: 0.15.7, rolldown: 1.0.0-beta.43).
Either complete the migration across remaining packages or document why the partial migration is intentional.
🤖 Prompt for AI Agents
package.json lines 138-142: the repo shows only one package migrated to
tsdown/rolldown while ~19 still use tsup; either finish migration or document
the intentional partial state. To fix, either (A) complete migration across the
listed packages by converting each package's tsup.config.ts to tsdown (create
tsdown.config.mts where needed), update package.json build scripts to use
tsdown/rolldown commands, update the pnpm workspace catalog to remove/replace
tsup with the chosen tsdown/rolldown versions and ensure lockfile is refreshed,
and remove tsup entries from package.json; or (B) if partial migration is
intentional, add a top-level migration note in the repo (README or MIGRATION.md)
listing migrated packages, those pending, rationale, and an action
plan/timeline, and keep package.json entries consistent with that documentation.
| @@ -1,5 +1,6 @@ | |||
| import { deriveState } from '@clerk/shared/deriveState'; | |||
| import { eventMethodCalled } from '@clerk/shared/telemetry'; | |||
| import type { SignedInSessionResource } from '@clerk/types'; | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🧩 Analysis chain
Leftover import from @clerk/types—migrate to @clerk/shared/types
This file still pulls SignedInSessionResource from @clerk/types. Switch to the shared path to align with the migration.
-import type { SignedInSessionResource } from '@clerk/types';
+import type { SignedInSessionResource } from '@clerk/shared/types';🏁 Script executed:
#!/usr/bin/env bash
# Audit repo for lingering @clerk/types imports
rg -nP --type=ts --type=tsx --type=js --type=jsx -g '!**/node_modules/**' "\@clerk/types"Length of output: 27
---
🏁 Script executed:
```shell
#!/bin/bash
# Audit repo for lingering @clerk/types imports with corrected syntax
rg -nP "@clerk/types" --type ts --type js -g '!**/node_modules/**'
Length of output: 68479
🏁 Script executed:
#!/bin/bash
# Verify the specific file mentioned in the review
cat packages/astro/src/stores/external.tsLength of output: 5381
🏁 Script executed:
#!/bin/bash
# Check if @clerk/shared/types exists and what it exports
find . -path '*/node_modules' -prune -o -type f -name 'index.ts' -o -name 'types.ts' | grep -i "clerk/shared"Length of output: 0
🏁 Script executed:
#!/bin/bash
# Find the @clerk/shared package structure
find packages/shared -type f -name "*.ts" -o -name "*.tsx" | head -20Length of output: 992
🏁 Script executed:
#!/bin/bash
# Check package.json exports for @clerk/shared
cat packages/shared/package.json 2>/dev/null | grep -A 20 '"exports"'Length of output: 512
🏁 Script executed:
#!/bin/bash
# Search for SignedInSessionResource export in @clerk/shared
rg -n "SignedInSessionResource" packages/shared --type ts --type tsxLength of output: 27
🏁 Script executed:
#!/bin/bash
# Search for SignedInSessionResource in packages/shared (corrected syntax)
rg -n "SignedInSessionResource" packages/shared --type tsLength of output: 1544
🏁 Script executed:
#!/bin/bash
# Check packages/types to see where SignedInSessionResource is defined
rg -n "SignedInSessionResource" packages/types/src --type ts -A 2Length of output: 0
🏁 Script executed:
#!/bin/bash
# List top-level source files in packages/shared
ls -la packages/shared/src/*.ts 2>/dev/null | head -30Length of output: 2575
🏁 Script executed:
#!/bin/bash
# Check if packages/shared has a types.ts or similar
find packages/shared/src -maxdepth 1 -name "*types*" -o -name "*index*"Length of output: 54
🏁 Script executed:
#!/bin/bash
# Verify packages/types re-exports from @clerk/shared
cat packages/types/src/index.d.ts 2>/dev/null | head -30Length of output: 313
🏁 Script executed:
#!/bin/bash
# Check if other astro files still use @clerk/types for comparison
rg -n "@clerk/types" packages/astro/src --type tsLength of output: 1984
Migrate import to @clerk/shared/types for consistency with package deprecation
The review comment is correct. The packages/types package documentation explicitly states that "@clerk/types is now merged with @clerk/shared" and indicates "Please import from @clerk/shared/types instead." The SignedInSessionResource type is available from @clerk/shared/types, and this file already imports from @clerk/shared (lines 1–2), so the import should be migrated.
-import type { SignedInSessionResource } from '@clerk/types';
+import type { SignedInSessionResource } from '@clerk/shared/types';📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| import type { SignedInSessionResource } from '@clerk/types'; | |
| import type { SignedInSessionResource } from '@clerk/shared/types'; | 
🤖 Prompt for AI Agents
In packages/astro/src/stores/external.ts around line 3, the file imports
SignedInSessionResource from '@clerk/types' but the package has been merged and
types should be imported from '@clerk/shared/types'; update the import to pull
SignedInSessionResource from '@clerk/shared/types' (keeping any existing imports
from '@clerk/shared') and remove the '@clerk/types' import to maintain
consistency with the deprecation.
|  | ||
| export class BillingSubscriptionItem extends BaseResource implements BillingSubscriptionItemResource { | ||
| id!: string; | ||
| paymentMethodId!: string; | 
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🧩 Analysis chain
Verify that paymentMethodId should be a required field.
The field is marked as required with the ! operator, which means it cannot be null or undefined. Please ensure that the backend always provides payment_method_id in the JSON response.
Run the following script to check if there are any existing tests or usage patterns that might expect this field to be optional:
🏁 Script executed:
#!/bin/bash
# Search for BillingSubscriptionItem usage and check if paymentMethodId is always present
echo "Checking for BillingSubscriptionItem usage patterns..."
rg -n -C3 "BillingSubscriptionItem" --type ts --type tsx -g '!**/dist/**' -g '!**/node_modules/**'
echo -e "\nChecking for payment_method_id in test fixtures or mocks..."
rg -n "payment_method_id" --type ts --type tsx --type json -g '!**/dist/**' -g '!**/node_modules/**'Length of output: 171
🏁 Script executed:
#!/bin/bash
# Find and examine the BillingSubscription.ts file
echo "=== Finding BillingSubscription.ts ==="
fd -n "BillingSubscription.ts" --type f
# Look at the file content if it exists
echo -e "\n=== Content of BillingSubscription.ts ==="
find . -name "BillingSubscription.ts" -type f ! -path "*/node_modules/*" ! -path "*/dist/*" -exec cat {} \;
# Search for paymentMethodId usage more broadly
echo -e "\n=== Searching for paymentMethodId usage ==="
rg -n "paymentMethodId" -g '!**/dist/**' -g '!**/node_modules/**'
# Search for payment_method_id (snake_case) in all file types
echo -e "\n=== Searching for payment_method_id ==="
rg -n "payment_method_id" -g '!**/dist/**' -g '!**/node_modules/**'Length of output: 5883
🏁 Script executed:
#!/bin/bash
# Find and examine the BillingSubscription.ts file
echo "=== Finding BillingSubscription.ts ==="
fd -n "BillingSubscription.ts" --type f
# Look at the file content if it exists
echo -e "\n=== Content of BillingSubscription.ts ==="
find . -name "BillingSubscription.ts" -type f ! -path "*/node_modules/*" ! -path "*/dist/*" -exec cat {} \;
# Search for paymentMethodId usage more broadly
echo -e "\n=== Searching for paymentMethodId usage ==="
rg -n "paymentMethodId" -g '!**/dist/**' -g '!**/node_modules/**'
# Search for payment_method_id (snake_case) in all file types
echo -e "\n=== Searching for payment_method_id ==="
rg -n "payment_method_id" -g '!**/dist/**' -g '!**/node_modules/**'
# Search for BillingSubscriptionItem definition
echo -e "\n=== Searching for BillingSubscriptionItem ==="
rg -n "BillingSubscriptionItem" -g '!**/dist/**' -g '!**/node_modules/**'Length of output: 17657
🏁 Script executed:
#!/bin/bash
# Check the BillingSubscriptionItemJSON interface definition
echo "=== BillingSubscriptionItemJSON interface in packages/types/src/json.ts ==="
rg -n -A 30 "interface BillingSubscriptionItemJSON" packages/types/src/json.ts
echo -e "\n=== BillingSubscriptionItemJSON interface in packages/shared/src/types/json.ts ==="
rg -n -A 30 "interface BillingSubscriptionItemJSON" packages/shared/src/types/json.ts
# Check if there's any code path that could leave paymentMethodId undefined
echo -e "\n=== Check for optional handling or null checks on paymentMethodId ==="
rg -n -B2 -A2 "paymentMethodId\s*=" packages/clerk-js/src/core/resources/BillingSubscription.tsLength of output: 3003
🏁 Script executed:
#!/bin/bash
# Get full BillingSubscriptionItemJSON interface from packages/types
echo "=== Full BillingSubscriptionItemJSON from packages/types/src/json.ts ==="
rg -n -A 50 "interface BillingSubscriptionItemJSON" packages/types/src/json.ts | head -60
# Check if there's any mention of payment_method_id in packages/types/src/json.ts
echo -e "\n=== Looking for payment_method_id in packages/types/src/json.ts ==="
rg -n "payment_method_id" packages/types/src/json.ts
# Check package resolution - what does @clerk/types point to
echo -e "\n=== Check @clerk/types resolution ==="
find . -name "package.json" -path "*/packages/types/*" ! -path "*/node_modules/*" -exec grep -l "@clerk/types\|clerk-js" {} \;Length of output: 2364
Add missing payment_method_id field to BillingSubscriptionItemJSON interface in packages/types/src/json.ts.
The type definition is incomplete. While packages/shared/src/types/json.ts includes payment_method_id: string; in the BillingSubscriptionItemJSON interface at line 733, packages/types/src/json.ts is missing this required field. The implementation at packages/clerk-js/src/core/resources/BillingSubscription.ts line 90 assigns data.payment_method_id, but this field doesn't exist in the imported type definition, creating a type safety gap.
The field should be added to packages/types/src/json.ts after the credit property (around line 732):
payment_method_id: string;This ensures consistency across type definitions and maintains type safety for the required field marked with ! at line 63 of BillingSubscription.ts.
🤖 Prompt for AI Agents
In packages/types/src/json.ts around line ~732, the BillingSubscriptionItemJSON
interface is missing the required payment_method_id field referenced in
packages/clerk-js/src/core/resources/BillingSubscription.ts (line 63) and used
elsewhere; add payment_method_id: string; immediately after the credit property
in that interface so the type matches packages/shared/src/types/json.ts and the
implementation that reads data.payment_method_id compiles with proper type
safety.
| // @ts-expect-error - ignore error for now | ||
| clerk, | 
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Address type mismatch before merging.
The @ts-expect-error suppression indicates that the clerk property doesn't match the SignInRouterInitEvent type signature. This technical debt should be resolved before the PR is merged out of WIP status.
Consider either:
- Updating the SignInRouterInitEventtype definition to include theclerkproperty, or
- Removing the clerkproperty if it's not needed
To verify the current type definition:
#!/bin/bash
# Find the SignInRouterInitEvent type definition
ast-grep --pattern 'type SignInRouterInitEvent = {
  $$$
}'🤖 Prompt for AI Agents
In packages/elements/src/react/sign-in/root.tsx around lines 44 to 45, the clerk
property is being passed despite a TypeScript mismatch (suppressed with
@ts-expect-error); resolve by either updating the SignInRouterInitEvent type to
include clerk (extend the interface/type with the correct clerk shape) or remove
the clerk property where it’s unused, and then remove the @ts-expect-error
comment; ensure any changes are mirrored in the type definition file found by
the project’s type declarations so the compiler no longer reports a mismatch.
| // @ts-expect-error - ignore error for now | ||
| clerk, | 
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Address type mismatch before merging.
This has the same issue as packages/elements/src/react/sign-in/root.tsx (Lines 44-45). The @ts-expect-error suppression indicates a type mismatch that should be resolved before merging.
Update the SignUpRouterInitEvent type definition to properly include the clerk property:
#!/bin/bash
# Find the SignUpRouterInitEvent type definition
ast-grep --pattern 'type SignUpRouterInitEvent = {
  $$$
}'        
          
                packages/shared/vitest.config.mts
              
                Outdated
          
        
      | }, | ||
| environment: 'jsdom', | ||
| include: ['**/*.{spec,test}.{js,ts,jsx,tsx}'], | ||
| include: ['**/*..{js,ts,jsx,tsx}'], | 
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🧩 Analysis chain
Broken test include glob stops Vitest from discovering tests.
Current pattern '**/*..{js,ts,jsx,tsx}' is invalid. Use standard spec/test glob.
-    include: ['**/*..{js,ts,jsx,tsx}'],
+    include: ['**/*.{spec,test}.{js,ts,jsx,tsx}'],🏁 Script executed:
#!/bin/bash
# List matched tests with the new pattern to confirm discovery.
fd -t f -a -g '**/*.{spec,test}.{js,ts,jsx,tsx}' packages/shared | sed 's/^/test file: /'Length of output: 3222
This will show me the actual file content to verify if the broken pattern exists and what the current state is.
🏁 Script executed:
#!/bin/bash
# Read the vitest.config.mts file, specifically around line 16
sed -n '10,25p' packages/shared/vitest.config.mts | head -20Length of output: 224
This will verify the proposed pattern captures all test files and nothing is missed.
🏁 Script executed:
#!/bin/bash
# Check if there are any test files using .test. naming (not .spec.)
fd -t f -g '**/*.test.{js,ts,jsx,tsx}' packages/sharedLength of output: 0
Fix broken Vitest include glob to restore test discovery.
The current pattern **/*..{js,ts,jsx,tsx} contains invalid glob syntax and matches no files. Update to the standard pattern:
-    include: ['**/*..{js,ts,jsx,tsx}'],
+    include: ['**/*.{spec,test}.{js,ts,jsx,tsx}'],This fix enables discovery of all 37 test files in packages/shared/src.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| include: ['**/*..{js,ts,jsx,tsx}'], | |
| include: ['**/*.{spec,test}.{js,ts,jsx,tsx}'], | 
🤖 Prompt for AI Agents
In packages/shared/vitest.config.mts around line 16 the include glob is invalid
(`**/*..{js,ts,jsx,tsx}`) and matches nothing; replace it with a correct
file-extension glob (for example `**/*.{js,ts,jsx,tsx}`) so Vitest can discover
test files.
| "exports": { | ||
| ".": { | ||
| "import": { | ||
| "types": "./src/index.d.mts", | ||
| "default": "./src/index.mjs" | ||
| }, | ||
| "require": { | ||
| "types": "./src/index.d.ts", | ||
| "default": "./src/index.js" | ||
| } | ||
| } | ||
| }, | ||
| "main": "src/index.js", | ||
| "module": "src/index.js", | ||
| "types": "src/index.d.ts", | ||
| "files": [ | 
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🧩 Analysis chain
Exports map: prefer canonical 'types' mapping and verify files exist.
Placing types nested under import/require is non-standard and may confuse TS resolvers/publint. Use a top-level types entry for the subpath.
   "exports": {
     ".": {
-      "import": {
-        "types": "./src/index.d.mts",
-        "default": "./src/index.mjs"
-      },
-      "require": {
-        "types": "./src/index.d.ts",
-        "default": "./src/index.js"
-      }
+      "types": "./src/index.d.ts",
+      "import": "./src/index.mjs",
+      "require": "./src/index.js",
+      "default": "./src/index.js"
     }
   },As per coding guidelines.
🏁 Script executed:
#!/bin/bash
# Ensure exported files actually exist before publishing.
for f in packages/types/src/index.js packages/types/src/index.mjs packages/types/src/index.d.ts; do
  [[ -f "$f" ]] || { echo "Missing $f" >&2; fi
done
# Spot-check nested 'types' usage (should be absent after change)
jq -r '.exports["."].import.types? // empty' packages/types/package.json
jq -r '.exports["."].require.types? // empty' packages/types/package.jsonLength of output: 134
🏁 Script executed:
#!/bin/bash
# Ensure exported files actually exist before publishing.
for f in packages/types/src/index.js packages/types/src/index.mjs packages/types/src/index.d.ts; do
  if [[ -f "$f" ]]; then
    echo "Found: $f"
  else
    echo "Missing: $f" >&2
  fi
done
# Check current exports structure
echo "=== Current exports structure ==="
jq '.exports' packages/types/package.json
# Spot-check nested 'types' usage in import/require
echo "=== Nested types in import ==="
jq -r '.exports["."].import.types? // "not found"' packages/types/package.json
echo "=== Nested types in require ==="
jq -r '.exports["."].require.types? // "not found"' packages/types/package.jsonLength of output: 442
🏁 Script executed:
#!/bin/bash
# Check specifically for index.d.mts
if [[ -f "packages/types/src/index.d.mts" ]]; then
  echo "Found: packages/types/src/index.d.mts"
else
  echo "Missing: packages/types/src/index.d.mts" >&2
fi
# List all files in packages/types/src to see what's actually there
echo "=== Files in packages/types/src/ ==="
ls -la packages/types/src/Length of output: 549
Exports map: prefer canonical 'types' mapping - verified.
All exported files exist (index.js, index.mjs, index.d.mts, index.d.ts). The current nested types structure under import/require is non-standard and should be flattened to a top-level types entry for proper TypeScript and tool resolution.
   "exports": {
     ".": {
-      "import": {
-        "types": "./src/index.d.mts",
-        "default": "./src/index.mjs"
-      },
-      "require": {
-        "types": "./src/index.d.ts",
-        "default": "./src/index.js"
-      }
+      "types": "./src/index.d.ts",
+      "import": "./src/index.mjs",
+      "require": "./src/index.js",
+      "default": "./src/index.js"
     }
   },📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| "exports": { | |
| ".": { | |
| "import": { | |
| "types": "./src/index.d.mts", | |
| "default": "./src/index.mjs" | |
| }, | |
| "require": { | |
| "types": "./src/index.d.ts", | |
| "default": "./src/index.js" | |
| } | |
| } | |
| }, | |
| "main": "src/index.js", | |
| "module": "src/index.js", | |
| "types": "src/index.d.ts", | |
| "files": [ | |
| "exports": { | |
| ".": { | |
| "types": "./src/index.d.ts", | |
| "import": "./src/index.mjs", | |
| "require": "./src/index.js", | |
| "default": "./src/index.js" | |
| } | |
| }, | |
| "main": "src/index.js", | |
| "module": "src/index.js", | |
| "types": "src/index.d.ts", | |
| "files": [ | 
🤖 Prompt for AI Agents
In packages/types/package.json around lines 26 to 41, the exports map currently
nests "types" under the "import" and "require" conditionals which is
non-standard; remove the nested "types" properties and add a single top-level
"types" entry (pointing to the canonical declaration file, e.g. src/index.d.ts)
so TypeScript and bundlers resolve typings correctly, and ensure the exports
keys keep only the runtime defaults (default/import/require) while relying on
the top-level "types" field for type resolution.
| "src" | ||
| ], | ||
| "scripts": { | ||
| "build": "tsup --env.NODE_ENV production", | ||
| "build:declarations": "tsc -p tsconfig.declarations.json", | ||
| "clean": "rimraf ./dist", | ||
| "dev": "tsup --watch", | ||
| "format": "node ../../scripts/format-package.mjs", | ||
| "format:check": "node ../../scripts/format-package.mjs --check", | ||
| "lint": "eslint src", | ||
| "lint:attw": "attw --pack . --profile node16", | ||
| "publish:local": "pnpm yalc push --replace --sig" | ||
| "lint:attw": "attw --pack . --profile node16" | ||
| }, | 
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🧩 Analysis chain
Publishing only "src": confirm no build step is required.
With "files": ["src"] and main/module pointing to src, consumers will load source files. Ensure these are plain JS (.js/.mjs) and not TS, and that sourcemaps are not needed.
🏁 Script executed:
#!/bin/bash
# Verify there are no .ts in the published "src" for this package.
fd -t f -a -g 'packages/types/src/**/*' | rg -n '\.ts$' && echo "Found TS sources in published files"Length of output: 0
I need to verify the package setup more thoroughly since the initial script was inconclusive. Let me check the actual package.json entries and directly inspect the src directory structure.
🏁 Script executed:
#!/bin/bash
# Check the main/module entries and files array in packages/types/package.json
echo "=== package.json entries ==="
jq '.main, .module, .exports, .files' packages/types/package.json
echo ""
echo "=== Files in packages/types/src with extensions ==="
fd -t f . packages/types/src --max-depth 3 | head -20Length of output: 501
Remove .ts source files from published "src" directory or implement a build step.
The package currently publishes TypeScript source files to npm. With "files": ["src"], consumers will receive billing.ts and json.ts as-is. Either:
- Compile .ts→.js/.mjsbefore publishing, or
- Exclude .tsfiles from the files array:["src", "!src/**/*.ts"], or
- Use a dist/ directory from a build step
Affected files:
- packages/types/src/billing.ts
- packages/types/src/json.ts
🤖 Prompt for AI Agents
In packages/types/package.json around lines 42 to 49, the package currently
publishes raw TypeScript sources via "files": ["src"] which exposes .ts files
(billing.ts, json.ts); fix by either adding a build step that compiles TS to JS
into a dist/ (or lib/) folder and updating "files" to include only that output
(and add prepare/build scripts to run before publish), or exclude .ts sources by
changing "files" to exclude TS (for example keep "src" but add an exclusion
pattern for "**/*.ts"), and ensure package.json's "main"/"module"/"types" fields
point to the compiled outputs or .d.ts files; implement the chosen change and
update npm scripts so consumers receive only compiled artifacts.
| import type { | ||
| Clerk, | ||
| ClientResource, | ||
| InitialState, | ||
| MultiDomainAndOrProxy, | ||
| Resources, | ||
| Without, | ||
| } from '@clerk/shared/types'; | 
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🧩 Analysis chain
Verify migration completeness across the entire codebase.
Since this is a large-scale type migration marked as WIP, ensure all affected files have been updated and the build configuration supports the new import paths.
🏁 Script executed:
#!/bin/bash
# Description: Comprehensive verification of the type migration
# 1. Find any remaining @clerk/types imports in shared and vue packages
echo "=== Scanning for remaining @clerk/types imports ==="
rg -n "from ['\"]@clerk/types['\"]" packages/shared/src/ packages/vue/src/ \
  -g '!*.spec.ts' -g '!*.test.ts' \
  || echo "✓ No remaining @clerk/types imports in source files"
# 2. Check TypeScript configuration for path mappings
echo -e "\n=== Checking TypeScript path configurations ==="
fd -e json "tsconfig" packages/shared packages/vue --exec cat {} \; | \
  jq -r 'select(.compilerOptions.paths != null) | .compilerOptions.paths'
# 3. Check if @clerk/types is still listed as a dependency
echo -e "\n=== Checking package.json dependencies ==="
echo "Shared package @clerk/types dependency:"
cat packages/shared/package.json | jq -r '.dependencies["@clerk/types"] // .devDependencies["@clerk/types"] // "Not found"'
echo "Vue package @clerk/types dependency:"
cat packages/vue/package.json | jq -r '.dependencies["@clerk/types"] // .devDependencies["@clerk/types"] // "Not found"'
# 4. Verify @clerk/shared types are properly exported
echo -e "\n=== Verifying @clerk/shared/types export in package.json ==="
cat packages/shared/package.json | jq -r '.exports."./types"'Length of output: 559
I need to verify whether the @clerk/types dependency in the vue package should be removed, and ensure the migration is truly complete across all code paths.
Now I need to run a direct verification on the codebase to understand the complete state of the migration.
🏁 Script executed:
#!/bin/bash
# Check if @clerk/types package still exists as a workspace package
echo "=== Searching for @clerk/types package definition ==="
find packages -name package.json -exec grep -l '"name".*@clerk/types' {} \;
echo -e "\n=== Looking for packages/ directories ==="
ls -la packages/ | grep -E "^d" | awk '{print $NF}'
echo -e "\n=== Full vue package.json to understand dependencies ==="
cat packages/vue/package.json | jq '.dependencies, .devDependencies' | head -40
echo -e "\n=== Checking shared package exports more carefully ==="
cat packages/shared/package.json | jq '.exports'Length of output: 2535
I need to check what's in the @clerk/types package and whether it's actually being used anywhere.
🏁 Script executed:
#!/bin/bash
# Investigate @clerk/types package and its usage
echo "=== @clerk/types package.json details ==="
cat packages/types/package.json | jq '.name, .main, .exports, .description' | head -30
echo -e "\n=== Searching for ALL @clerk/types imports in the entire codebase ==="
rg "from ['\"]@clerk/types['\"]" packages/ -n || echo "✓ No @clerk/types imports found"
echo -e "\n=== Checking if @clerk/types is referenced as a peer dependency or in any configs ==="
rg "@clerk/types" packages/vue/ -n -g '!node_modules' || echo "✓ No @clerk/types references in vue"
echo -e "\n=== Check if any packages declare @clerk/types as peer or optional dependency ==="
find packages -name package.json -exec sh -c 'echo "=== {} ===" && cat "$1" | jq ".peerDependencies, .optionalDependencies" 2>/dev/null | grep -A5 "@clerk/types" && echo "$1"' _ {} \;Length of output: 79029
Remove @clerk/types dependency from vue/package.json to complete the migration.
The code change correctly imports from @clerk/shared/types, but vue's package.json still declares @clerk/types as a workspace dependency. Since no files in the vue package import from @clerk/types, this dependency should be removed. Additionally, note that @clerk/types remains heavily used across many other packages in the codebase (elements, testing, nextjs, react, clerk-js, etc.), suggesting this is a work-in-progress migration that may require similar cleanup elsewhere.
🤖 Prompt for AI Agents
In packages/vue/src/plugin.ts around lines 4 to 11 the imports have been
switched to @clerk/shared/types but packages/vue/package.json still declares
@clerk/types as a workspace dependency; remove the @clerk/types entry from
packages/vue/package.json (from dependencies/devDependencies/peerDependencies
where it appears), update any workspace references if present, and run the
package manager (yarn/pnpm/npm install) to refresh the lockfile and ensure no
remaining references to @clerk/types remain in the vue package.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 1
🧹 Nitpick comments (1)
packages/shared/tsdown.config.mts (1)
26-34: Remove the empty comment on line 29.The standalone
//comment serves no purpose and can be removed.{ ...common, entry: [ - // './src/types/index.ts', ], unbundle: false, outDir: './dist/types', },
📜 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 (2)
- packages/shared/src/pathToRegexp.ts(1 hunks)
- packages/shared/tsdown.config.mts(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- packages/shared/src/pathToRegexp.ts
🧰 Additional context used
🧬 Code graph analysis (1)
packages/shared/tsdown.config.mts (1)
packages/dev-cli/src/commands/watch.js (1)
watch(16-61)
⏰ 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). (2)
- GitHub Check: semgrep-cloud-platform/scan
- GitHub Check: semgrep-cloud-platform/scan
🔇 Additional comments (2)
packages/shared/tsdown.config.mts (2)
7-23: LGTM! Well-structured build configuration.The common options are appropriate for a library package:
- Dual CJS/ESM output ensures broad compatibility
- React externalization prevents bundling peer dependencies
- Define block correctly injects package metadata and dev flag
- Target es2022 balances modern features with reasonable browser support
35-47: Runtime build configuration looks correct.The explicit entry patterns successfully target the known module structure (react, utils, workerTimers, dom) and exclude test files. While a wildcard pattern like
'./src/**/*.{ts,tsx}'with exclusions would be more maintainable for future additions, the current explicit approach provides clear control over build inputs and aligns with the package.json exports structure.
5520fb7    to
    083ef3d      
    Compare
  
    There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 1
♻️ Duplicate comments (1)
packages/shared/tsdown.config.mts (1)
4-5: Node engine constraint mismatch remains unresolved.This critical issue was flagged in a previous review but has not yet been addressed. The JSON import syntax
with { type: 'json' }requires Node >=18.20.0, but 25 package.json files still declare"engines.node": ">=18.17.0", creating a breaking incompatibility on Node 18.17.x through 18.19.x.
📜 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 (2)
- packages/shared/src/pathToRegexp.ts(1 hunks)
- packages/shared/tsdown.config.mts(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- packages/shared/src/pathToRegexp.ts
🧰 Additional context used
🧬 Code graph analysis (1)
packages/shared/tsdown.config.mts (1)
packages/dev-cli/src/commands/watch.js (1)
watch(16-61)
⏰ 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: semgrep-cloud-platform/scan
- GitHub Check: semgrep-cloud-platform/scan
- GitHub Check: Analyze (javascript-typescript)
🔇 Additional comments (1)
packages/shared/tsdown.config.mts (1)
25-34: Types build configuration looks correct.The types build properly targets a single entry point with bundling disabled, which is appropriate for generating consolidated type declarations at
dist/types.
| { | ||
| ...common, | ||
| entry: [ | ||
| './src/*.{ts,tsx}', | ||
| './src/react/index.ts', | ||
| './src/utils/index.ts', | ||
| './src/workerTimers/index.ts', | ||
| './src/types/index.ts', | ||
| './src/dom/*.ts', | ||
| '!./src/**/*.{test,spec}.{ts,tsx}', | ||
| ], | ||
| outDir: './dist/runtime', | ||
| unbundle: true, | ||
| }, | 
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🧩 Analysis chain
Verify intentional duplication of types entry and consider maintenance of explicit entry patterns.
Two observations:
- 
Types entry duplication: ./src/types/index.tsis included in both the types build (line 30) and the runtime build (line 42). If this is intentional—to make types available at runtime—please confirm. Otherwise, this could lead to output duplication or confusion about which build produces the canonical types.
- 
Explicit entry pattern maintenance: The current approach uses explicit paths (lines 38-43) rather than a broad glob pattern with negations. While this provides precise control, it requires manual updates when adding new modules. Consider whether the maintenance overhead is acceptable or if a pattern like './src/**/*.{ts,tsx}'with explicit negations would be more maintainable.
Run this script to verify the intended structure and check for any missing source files:
🏁 Script executed:
#!/bin/bash
# Verify source structure matches entry configuration
echo "=== Source files that match glob patterns ==="
fd -e ts -e tsx . packages/shared/src --max-depth 1
echo -e "\n=== Subdirectories with index files ==="
fd -t f '^index\.(ts|tsx)$' packages/shared/src --max-depth 2
echo -e "\n=== Verify types/index.ts exists ==="
ls -la packages/shared/src/types/index.ts 2>&1
echo -e "\n=== Check for modules not covered by explicit entries ==="
fd -e ts -e tsx . packages/shared/src --max-depth 2 -x echo {} | grep -v test | grep -v specLength of output: 8576
Critical: Runtime build entry configuration is missing entire subdirectories (errors, router, telemetry).
The script reveals a significant gap in the entry configuration. While the current setup includes:
- Root-level files via ./src/*.{ts,tsx}
- Specific index.ts entries for react,utils,workerTimers,types
- DOM files via ./src/dom/*.ts
It does not cover:
- ./src/errors/(6+ files including errorThrower.ts, clerkError.ts, etc.)
- ./src/router/(3 files including router.ts, react.tsx)
- ./src/telemetry/(3 files including collector.ts, throttler.ts)
These nested subdirectories contain actual source files that are not accessible through index entry points. They will be excluded from the runtime build bundle, likely breaking exports or creating missing dependencies.
Secondary concern: ./src/types/index.ts appears in both the types build and runtime build entries. Clarify whether this duplication is intentional or should be removed from one build.
Required actions:
- Add explicit entries for ./src/errors/*.ts,./src/router/*.ts,./src/telemetry/*.ts(or use./src/**/*.{ts,tsx}pattern with exclusions if comprehensive coverage is intended)
- Confirm the types entry duplication is intentional; remove if not
🤖 Prompt for AI Agents
In packages/shared/tsdown.config.mts around lines 35 to 48, the runtime entry
list omits entire subdirectories (./src/errors, ./src/router, ./src/telemetry)
so those source files won't be included in the runtime bundle; update the entry
configuration to include either explicit globs './src/errors/*.ts',
'./src/router/*.ts', './src/telemetry/*.ts' (or replace the current entries with
a broader pattern like './src/**/*.{ts,tsx}' plus the existing exclusions) so
all nested files are picked up, and also review the duplicate
'./src/types/index.ts' entry—confirm if it should remain in both runtime and
types builds or remove it from one to avoid redundancy.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 2
🧹 Nitpick comments (1)
packages/shared/src/pathToRegexp.ts (1)
3-85: Consider reordering type declarations to improve readability.While TypeScript handles forward references through hoisting, several types are referenced before they're declared:
Key(referenced at line 17, declared at lines 45-51)
TokensToRegexpOptions(referenced at line 40, declared at lines 52-81)
Path(referenced at line 39, declared at lines 82-85)Declaring types before they're referenced would improve code readability and make the file easier to navigate.
Consider this ordering:
Keyinterface (currently lines 45-51)
Pathtype (currently lines 82-85)
ParseOptionsinterface (currently lines 3-12)
RegexpToFunctionOptionsinterface (currently lines 13-18)
TokensToRegexpOptionsinterface (currently lines 52-81)
MatchResult,Match,MatchFunctiontypes (currently lines 19-34)
📜 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 (2)
- packages/shared/src/compiled/path-to-regexp/index.d.ts(0 hunks)
- packages/shared/src/pathToRegexp.ts(2 hunks)
💤 Files with no reviewable changes (1)
- packages/shared/src/compiled/path-to-regexp/index.d.ts
🧰 Additional context used
📓 Path-based instructions (6)
**/*.{js,jsx,ts,tsx}
📄 CodeRabbit inference engine (.cursor/rules/development.mdc)
**/*.{js,jsx,ts,tsx}: All code must pass ESLint checks with the project's configuration
Follow established naming conventions (PascalCase for components, camelCase for variables)
Maintain comprehensive JSDoc comments for public APIs
Use dynamic imports for optional features
All public APIs must be documented with JSDoc
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
Profile and optimize critical paths
Validate all inputs and sanitize outputs
Implement proper logging with different levels
Files:
- packages/shared/src/pathToRegexp.ts
**/*.{js,jsx,ts,tsx,json,css,scss,md,yaml,yml}
📄 CodeRabbit inference engine (.cursor/rules/development.mdc)
Use Prettier for consistent code formatting
Files:
- packages/shared/src/pathToRegexp.ts
packages/**/*.{ts,tsx}
📄 CodeRabbit inference engine (.cursor/rules/development.mdc)
TypeScript is required for all packages
Files:
- packages/shared/src/pathToRegexp.ts
packages/**/*.{ts,tsx,d.ts}
📄 CodeRabbit inference engine (.cursor/rules/development.mdc)
Packages should export TypeScript types alongside runtime code
Files:
- packages/shared/src/pathToRegexp.ts
**/*.{ts,tsx}
📄 CodeRabbit inference engine (.cursor/rules/development.mdc)
Use proper TypeScript error types
**/*.{ts,tsx}: Always define explicit return types for functions, especially public APIs
Use proper type annotations for variables and parameters where inference isn't clear
Avoidanytype - preferunknownwhen type is uncertain, then narrow with type guards
Useinterfacefor object shapes that might be extended
Usetypefor unions, primitives, and computed types
Preferreadonlyproperties for immutable data structures
Useprivatefor internal implementation details
Useprotectedfor inheritance hierarchies
Usepublicexplicitly for clarity in public APIs
Preferreadonlyfor properties that shouldn't change after construction
Prefer composition and interfaces over deep inheritance chains
Use mixins for shared behavior across unrelated classes
Implement dependency injection for loose coupling
Let TypeScript infer when types are obvious
Useconst assertionsfor literal types:as const
Usesatisfiesoperator for type checking without widening
Use mapped types for transforming object types
Use conditional types for type-level logic
Leverage template literal types for string manipulation
Use ES6 imports/exports consistently
Use default exports sparingly, prefer named exports
Use type-only imports:import type { ... } from ...
Noanytypes without justification
Proper error handling with typed errors
Consistent use ofreadonlyfor immutable data
Proper generic constraints
No unused type parameters
Proper use of utility types instead of manual type construction
Type-only imports where possible
Proper tree-shaking friendly exports
No circular dependencies
Efficient type computations (avoid deep recursion)
Files:
- packages/shared/src/pathToRegexp.ts
**/*.{js,ts,tsx,jsx}
📄 CodeRabbit inference engine (.cursor/rules/monorepo.mdc)
Support multiple Clerk environment variables (CLERK_, NEXT_PUBLIC_CLERK_, etc.) for configuration.
Files:
- packages/shared/src/pathToRegexp.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). (5)
- GitHub Check: Formatting | Dedupe | Changeset
- GitHub Check: Build Packages
- GitHub Check: Analyze (javascript-typescript)
- GitHub Check: semgrep-cloud-platform/scan
- GitHub Check: semgrep-cloud-platform/scan
| @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:  | 
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️  Outside diff range comments (1)
.github/workflows/ci.yml (1)
225-225: Update stale comment referencing outdated Node version.Line 225 contains the comment
# Ensures that all builds are cached appropriately with a consistent run name 'Unit Tests (18)'.However, the matrix at line 211 now specifiesnode-version: 22only; version 18 has been removed. This comment should be updated to reflect the current configuration to avoid confusion for future maintainers.- # Ensures that all builds are cached appropriately with a consistent run name `Unit Tests (18)`. + # Ensures that all builds are cached appropriately with a consistent run name `Unit Tests (22)`.
🧹 Nitpick comments (1)
packages/clerk-js/src/core/resources/BillingCheckout.ts (1)
61-90: Consider replacinganytypes with proper typing.The
confirmmethod containsanytype assertions that violate the coding guidelines:
- Line 69:
body: params as any- Line 76:
error: anyparameterConsider refactoring to use
unknownwith type guards, or proper type annotations based on the_basePatchsignature andisClerkAPIResponseErrorfunction.As per coding guidelines.
📜 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 (11)
- .github/workflows/ci.yml(12 hunks)
- package.json(2 hunks)
- packages/clerk-js/bundlewatch.config.json(1 hunks)
- packages/clerk-js/package.json(0 hunks)
- packages/clerk-js/src/core/modules/billing/payment-source-methods.ts(1 hunks)
- packages/clerk-js/src/core/modules/checkout/__tests__/manager.test.ts(1 hunks)
- packages/clerk-js/src/core/resources/BillingCheckout.ts(1 hunks)
- packages/clerk-js/src/test/fixture-helpers.ts(1 hunks)
- packages/clerk-js/src/ui/components/Checkout/CheckoutForm.tsx(1 hunks)
- packages/clerk-js/src/ui/components/OrganizationProfile/ProfileForm.tsx(1 hunks)
- packages/clerk-js/src/ui/elements/ThreeDotsMenu.tsx(1 hunks)
💤 Files with no reviewable changes (1)
- packages/clerk-js/package.json
🚧 Files skipped from review as they are similar to previous changes (6)
- packages/clerk-js/src/core/modules/checkout/tests/manager.test.ts
- packages/clerk-js/src/test/fixture-helpers.ts
- packages/clerk-js/bundlewatch.config.json
- package.json
- packages/clerk-js/src/core/modules/billing/payment-source-methods.ts
- packages/clerk-js/src/ui/components/Checkout/CheckoutForm.tsx
🧰 Additional context used
📓 Path-based instructions (10)
**/*.{js,jsx,ts,tsx}
📄 CodeRabbit inference engine (.cursor/rules/development.mdc)
**/*.{js,jsx,ts,tsx}: All code must pass ESLint checks with the project's configuration
Follow established naming conventions (PascalCase for components, camelCase for variables)
Maintain comprehensive JSDoc comments for public APIs
Use dynamic imports for optional features
All public APIs must be documented with JSDoc
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
Profile and optimize critical paths
Validate all inputs and sanitize outputs
Implement proper logging with different levels
Files:
- packages/clerk-js/src/core/resources/BillingCheckout.ts
- packages/clerk-js/src/ui/components/OrganizationProfile/ProfileForm.tsx
- packages/clerk-js/src/ui/elements/ThreeDotsMenu.tsx
**/*.{js,jsx,ts,tsx,json,css,scss,md,yaml,yml}
📄 CodeRabbit inference engine (.cursor/rules/development.mdc)
Use Prettier for consistent code formatting
Files:
- packages/clerk-js/src/core/resources/BillingCheckout.ts
- packages/clerk-js/src/ui/components/OrganizationProfile/ProfileForm.tsx
- packages/clerk-js/src/ui/elements/ThreeDotsMenu.tsx
packages/**/*.{ts,tsx}
📄 CodeRabbit inference engine (.cursor/rules/development.mdc)
TypeScript is required for all packages
Files:
- packages/clerk-js/src/core/resources/BillingCheckout.ts
- packages/clerk-js/src/ui/components/OrganizationProfile/ProfileForm.tsx
- packages/clerk-js/src/ui/elements/ThreeDotsMenu.tsx
packages/**/*.{ts,tsx,d.ts}
📄 CodeRabbit inference engine (.cursor/rules/development.mdc)
Packages should export TypeScript types alongside runtime code
Files:
- packages/clerk-js/src/core/resources/BillingCheckout.ts
- packages/clerk-js/src/ui/components/OrganizationProfile/ProfileForm.tsx
- packages/clerk-js/src/ui/elements/ThreeDotsMenu.tsx
**/*.{ts,tsx}
📄 CodeRabbit inference engine (.cursor/rules/development.mdc)
Use proper TypeScript error types
**/*.{ts,tsx}: Always define explicit return types for functions, especially public APIs
Use proper type annotations for variables and parameters where inference isn't clear
Avoidanytype - preferunknownwhen type is uncertain, then narrow with type guards
Useinterfacefor object shapes that might be extended
Usetypefor unions, primitives, and computed types
Preferreadonlyproperties for immutable data structures
Useprivatefor internal implementation details
Useprotectedfor inheritance hierarchies
Usepublicexplicitly for clarity in public APIs
Preferreadonlyfor properties that shouldn't change after construction
Prefer composition and interfaces over deep inheritance chains
Use mixins for shared behavior across unrelated classes
Implement dependency injection for loose coupling
Let TypeScript infer when types are obvious
Useconst assertionsfor literal types:as const
Usesatisfiesoperator for type checking without widening
Use mapped types for transforming object types
Use conditional types for type-level logic
Leverage template literal types for string manipulation
Use ES6 imports/exports consistently
Use default exports sparingly, prefer named exports
Use type-only imports:import type { ... } from ...
Noanytypes without justification
Proper error handling with typed errors
Consistent use ofreadonlyfor immutable data
Proper generic constraints
No unused type parameters
Proper use of utility types instead of manual type construction
Type-only imports where possible
Proper tree-shaking friendly exports
No circular dependencies
Efficient type computations (avoid deep recursion)
Files:
- packages/clerk-js/src/core/resources/BillingCheckout.ts
- packages/clerk-js/src/ui/components/OrganizationProfile/ProfileForm.tsx
- packages/clerk-js/src/ui/elements/ThreeDotsMenu.tsx
**/*.{js,ts,tsx,jsx}
📄 CodeRabbit inference engine (.cursor/rules/monorepo.mdc)
Support multiple Clerk environment variables (CLERK_, NEXT_PUBLIC_CLERK_, etc.) for configuration.
Files:
- packages/clerk-js/src/core/resources/BillingCheckout.ts
- packages/clerk-js/src/ui/components/OrganizationProfile/ProfileForm.tsx
- packages/clerk-js/src/ui/elements/ThreeDotsMenu.tsx
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 always be camelCase
Use element descriptors in UI components to enable consistent theming and styling via appearance.elements
Element descriptors should generate unique, stable CSS classes for theming
Element descriptors should handle state classes (e.g., cl-loading, cl-active, cl-error, cl-open) automatically based on component state
Do not render hard-coded values; all user-facing strings must be localized using provided localization methods
Use the useLocalizations hook and localizationKeys utility for all text and error messages
Use the styled system (sx prop, theme tokens, responsive values) for custom component styling
Use useCardState for card-level state, useFormState for form-level state, and useLoadingStatus for loading states
Always use handleError utility for API errors and use translateError for localized error messages
Use useFormControl for form field state, implement proper validation, and handle loading and error states in forms
Use localization keys for all form labels and placeholders
Use element descriptors for consistent styling and follow the theme token system
Use the Card and FormContainer patterns for consistent UI structure
Files:
- packages/clerk-js/src/ui/components/OrganizationProfile/ProfileForm.tsx
- packages/clerk-js/src/ui/elements/ThreeDotsMenu.tsx
**/*.{jsx,tsx}
📄 CodeRabbit inference engine (.cursor/rules/development.mdc)
**/*.{jsx,tsx}: Use error boundaries in React components
Minimize re-renders in React components
**/*.{jsx,tsx}: Always use functional components with hooks instead of class components
Follow PascalCase naming for components:UserProfile,NavigationMenu
Keep components focused on a single responsibility - split large components
Limit component size to 150-200 lines; extract logic into custom hooks
Use composition over inheritance - prefer smaller, composable components
Export components as named exports for better tree-shaking
One component per file with matching filename and component name
Use useState for simple state management
Use useReducer for complex state logic
Implement proper state initialization
Use proper state updates with callbacks
Implement proper state cleanup
Use Context API for theme/authentication
Implement proper state selectors
Use proper state normalization
Implement proper state persistence
Use React.memo for expensive components
Implement proper useCallback for handlers
Use proper useMemo for expensive computations
Implement proper virtualization for lists
Use proper code splitting with React.lazy
Implement proper cleanup in useEffect
Use proper refs for DOM access
Implement proper event listener cleanup
Use proper abort controllers for fetch
Implement proper subscription cleanup
Use proper HTML elements
Implement proper ARIA attributes
Use proper heading hierarchy
Implement proper form labels
Use proper button types
Implement proper focus management
Use proper keyboard shortcuts
Implement proper tab order
Use proper skip links
Implement proper focus traps
Implement proper error boundaries
Use proper error logging
Implement proper error recovery
Use proper error messages
Implement proper error fallbacks
Use proper form validation
Implement proper error states
Use proper error messages
Implement proper form submission
Use proper form reset
Use proper component naming
Implement proper file naming
Use proper prop naming
Implement proper...
Files:
- packages/clerk-js/src/ui/components/OrganizationProfile/ProfileForm.tsx
- packages/clerk-js/src/ui/elements/ThreeDotsMenu.tsx
**/*.tsx
📄 CodeRabbit inference engine (.cursor/rules/react.mdc)
**/*.tsx: Use proper type definitions for props and state
Leverage TypeScript's type inference where possible
Use proper event types for handlers
Implement proper generic types for reusable components
Use proper type guards for conditional rendering
Files:
- packages/clerk-js/src/ui/components/OrganizationProfile/ProfileForm.tsx
- packages/clerk-js/src/ui/elements/ThreeDotsMenu.tsx
.github/workflows/*.yml
📄 CodeRabbit inference engine (.cursor/rules/monorepo.mdc)
CI/CD must be configured with GitHub Actions.
Files:
- .github/workflows/ci.yml
🪛 actionlint (1.7.8)
.github/workflows/ci.yml
21-21: label "blacksmith-8vcpu-ubuntu-2204" is unknown. available labels are "windows-latest", "windows-latest-8-cores", "windows-2025", "windows-2022", "windows-11-arm", "ubuntu-latest", "ubuntu-latest-4-cores", "ubuntu-latest-8-cores", "ubuntu-latest-16-cores", "ubuntu-24.04", "ubuntu-24.04-arm", "ubuntu-22.04", "ubuntu-22.04-arm", "macos-latest", "macos-latest-xl", "macos-latest-xlarge", "macos-latest-large", "macos-26-xlarge", "macos-26", "macos-15-intel", "macos-15-xlarge", "macos-15-large", "macos-15", "macos-14-xl", "macos-14-xlarge", "macos-14-large", "macos-14", "macos-13-xl", "macos-13-xlarge", "macos-13-large", "macos-13", "self-hosted", "x64", "arm", "arm64", "linux", "macos", "windows". if it is a custom label for self-hosted runner, set list of labels in actionlint.yaml config file
(runner-label)
51-51: label "blacksmith-8vcpu-ubuntu-2204" is unknown. available labels are "windows-latest", "windows-latest-8-cores", "windows-2025", "windows-2022", "windows-11-arm", "ubuntu-latest", "ubuntu-latest-4-cores", "ubuntu-latest-8-cores", "ubuntu-latest-16-cores", "ubuntu-24.04", "ubuntu-24.04-arm", "ubuntu-22.04", "ubuntu-22.04-arm", "macos-latest", "macos-latest-xl", "macos-latest-xlarge", "macos-latest-large", "macos-26-xlarge", "macos-26", "macos-15-intel", "macos-15-xlarge", "macos-15-large", "macos-15", "macos-14-xl", "macos-14-xlarge", "macos-14-large", "macos-14", "macos-13-xl", "macos-13-xlarge", "macos-13-large", "macos-13", "self-hosted", "x64", "arm", "arm64", "linux", "macos", "windows". if it is a custom label for self-hosted runner, set list of labels in actionlint.yaml config file
(runner-label)
92-92: label "blacksmith-8vcpu-ubuntu-2204" is unknown. available labels are "windows-latest", "windows-latest-8-cores", "windows-2025", "windows-2022", "windows-11-arm", "ubuntu-latest", "ubuntu-latest-4-cores", "ubuntu-latest-8-cores", "ubuntu-latest-16-cores", "ubuntu-24.04", "ubuntu-24.04-arm", "ubuntu-22.04", "ubuntu-22.04-arm", "macos-latest", "macos-latest-xl", "macos-latest-xlarge", "macos-latest-large", "macos-26-xlarge", "macos-26", "macos-15-intel", "macos-15-xlarge", "macos-15-large", "macos-15", "macos-14-xl", "macos-14-xlarge", "macos-14-large", "macos-14", "macos-13-xl", "macos-13-xlarge", "macos-13-large", "macos-13", "self-hosted", "x64", "arm", "arm64", "linux", "macos", "windows". if it is a custom label for self-hosted runner, set list of labels in actionlint.yaml config file
(runner-label)
138-138: label "blacksmith-8vcpu-ubuntu-2204" is unknown. available labels are "windows-latest", "windows-latest-8-cores", "windows-2025", "windows-2022", "windows-11-arm", "ubuntu-latest", "ubuntu-latest-4-cores", "ubuntu-latest-8-cores", "ubuntu-latest-16-cores", "ubuntu-24.04", "ubuntu-24.04-arm", "ubuntu-22.04", "ubuntu-22.04-arm", "macos-latest", "macos-latest-xl", "macos-latest-xlarge", "macos-latest-large", "macos-26-xlarge", "macos-26", "macos-15-intel", "macos-15-xlarge", "macos-15-large", "macos-15", "macos-14-xl", "macos-14-xlarge", "macos-14-large", "macos-14", "macos-13-xl", "macos-13-xlarge", "macos-13-large", "macos-13", "self-hosted", "x64", "arm", "arm64", "linux", "macos", "windows". if it is a custom label for self-hosted runner, set list of labels in actionlint.yaml config file
(runner-label)
198-198: label "blacksmith-8vcpu-ubuntu-2204" is unknown. available labels are "windows-latest", "windows-latest-8-cores", "windows-2025", "windows-2022", "windows-11-arm", "ubuntu-latest", "ubuntu-latest-4-cores", "ubuntu-latest-8-cores", "ubuntu-latest-16-cores", "ubuntu-24.04", "ubuntu-24.04-arm", "ubuntu-22.04", "ubuntu-22.04-arm", "macos-latest", "macos-latest-xl", "macos-latest-xlarge", "macos-latest-large", "macos-26-xlarge", "macos-26", "macos-15-intel", "macos-15-xlarge", "macos-15-large", "macos-15", "macos-14-xl", "macos-14-xlarge", "macos-14-large", "macos-14", "macos-13-xl", "macos-13-xlarge", "macos-13-large", "macos-13", "self-hosted", "x64", "arm", "arm64", "linux", "macos", "windows". if it is a custom label for self-hosted runner, set list of labels in actionlint.yaml config file
(runner-label)
269-269: label "blacksmith-8vcpu-ubuntu-2204" is unknown. available labels are "windows-latest", "windows-latest-8-cores", "windows-2025", "windows-2022", "windows-11-arm", "ubuntu-latest", "ubuntu-latest-4-cores", "ubuntu-latest-8-cores", "ubuntu-latest-16-cores", "ubuntu-24.04", "ubuntu-24.04-arm", "ubuntu-22.04", "ubuntu-22.04-arm", "macos-latest", "macos-latest-xl", "macos-latest-xlarge", "macos-latest-large", "macos-26-xlarge", "macos-26", "macos-15-intel", "macos-15-xlarge", "macos-15-large", "macos-15", "macos-14-xl", "macos-14-xlarge", "macos-14-large", "macos-14", "macos-13-xl", "macos-13-xlarge", "macos-13-large", "macos-13", "self-hosted", "x64", "arm", "arm64", "linux", "macos", "windows". if it is a custom label for self-hosted runner, set list of labels in actionlint.yaml config file
(runner-label)
444-444: label "blacksmith-8vcpu-ubuntu-2204" is unknown. available labels are "windows-latest", "windows-latest-8-cores", "windows-2025", "windows-2022", "windows-11-arm", "ubuntu-latest", "ubuntu-latest-4-cores", "ubuntu-latest-8-cores", "ubuntu-latest-16-cores", "ubuntu-24.04", "ubuntu-24.04-arm", "ubuntu-22.04", "ubuntu-22.04-arm", "macos-latest", "macos-latest-xl", "macos-latest-xlarge", "macos-latest-large", "macos-26-xlarge", "macos-26", "macos-15-intel", "macos-15-xlarge", "macos-15-large", "macos-15", "macos-14-xl", "macos-14-xlarge", "macos-14-large", "macos-14", "macos-13-xl", "macos-13-xlarge", "macos-13-large", "macos-13", "self-hosted", "x64", "arm", "arm64", "linux", "macos", "windows". if it is a custom label for self-hosted runner, set list of labels in actionlint.yaml config file
(runner-label)
⏰ 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: Analyze (javascript-typescript)
- GitHub Check: semgrep-cloud-platform/scan
- GitHub Check: semgrep-cloud-platform/scan
🔇 Additional comments (5)
.github/workflows/ci.yml (2)
21-21: Double-quoting runs-on labels is safe; verify custom runner configuration.Quoting standardization from single to double quotes is cosmetic and does not affect YAML parsing. However, the static analysis tool flags
"blacksmith-8vcpu-ubuntu-2204"as an unknown label across all job definitions. If these are self-hosted runners, ensure they are registered with this label and configured inactionlint.yamlto suppress warnings in future runs.Also applies to: 51-51, 92-92, 138-138, 198-198, 269-269, 444-444
212-212: Test-filter quoting change is valid.The change from single to double quotes for
test-filter: "**"is consistent and does not affect the conditional logic at line 234, where the comparison[ "${{ matrix.test-filter }}" = "**" ]will continue to work correctly.packages/clerk-js/src/ui/components/OrganizationProfile/ProfileForm.tsx (1)
2-2: LGTM! Clean import path migration.The type-only import has been correctly updated from
@clerk/typesto@clerk/shared/types, following TypeScript best practices with theimport typesyntax.packages/clerk-js/src/ui/elements/ThreeDotsMenu.tsx (1)
1-1: LGTM! MenuId is properly exported from@clerk/shared/typesand the import is correct.Verification confirms that
MenuIdis defined inpackages/shared/src/types/elementIds.tswith the exporttype MenuId = 'invitation' | 'member' | ProfileSectionId;, and is properly exported from@clerk/shared/types. The type-only import in ThreeDotsMenu.tsx is correct, and other UI files like Menu.tsx follow the same import pattern. The migration is complete.packages/clerk-js/src/core/resources/BillingCheckout.ts (1)
3-11: Import migration verified successfully.All seven imported types are properly exported from
@clerk/shared/types:
BillingCheckoutJSON(json.ts)
BillingCheckoutResource,BillingCheckoutTotals,BillingPayerResource,BillingPaymentMethodResource,BillingSubscriptionPlanPeriod,ConfirmCheckoutParams(billing.ts)The types are re-exported through
types/index.tsand accessible via the@clerk/shared/typesimport path per the package export configuration.
ac6607f    to
    a7f5d85      
    Compare
  
    f4f557d    to
    01ff272      
    Compare
  
    01ff272    to
    e32de45      
    Compare
  
    22ff0df    to
    bbc3738      
    Compare
  
    
Description
WIP
Checklist
pnpm testruns as expected.pnpm buildruns as expected.Type of change
Summary by CodeRabbit
New Features
paymentMethodIdfield to billing subscription items.Documentation
Configuration