Skip to content

Conversation

@nikosdouvlis
Copy link
Member

@nikosdouvlis nikosdouvlis commented Oct 17, 2025

Description

WIP

Checklist

  • pnpm test runs as expected.
  • pnpm build runs as expected.
  • (If applicable) JSDoc comments have been added or updated for any package exports
  • (If applicable) Documentation has been updated

Type of change

  • 🐛 Bug fix
  • 🌟 New feature
  • 🔨 Breaking change
  • 📖 Refactoring / dependency upgrade / documentation
  • other:

Summary by CodeRabbit

  • New Features

    • Added paymentMethodId field to billing subscription items.
  • Documentation

    • Published deprecation guide for @clerk/types with migration path to @clerk/shared/types; backward compatibility maintained through re-exports.
  • Configuration

    • Updated bundle size thresholds and TypeScript compiler options across packages.

@changeset-bot
Copy link

changeset-bot bot commented Oct 17, 2025

🦋 Changeset detected

Latest commit: 4b299d5

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 22 packages
Name Type
@clerk/types Minor
@clerk/shared Minor
@clerk/astro Patch
@clerk/backend Patch
@clerk/chrome-extension Patch
@clerk/clerk-js Patch
@clerk/elements Patch
@clerk/themes Patch
@clerk/vue Patch
@clerk/agent-toolkit Patch
@clerk/expo-passkeys Patch
@clerk/clerk-expo Patch
@clerk/express Patch
@clerk/fastify Patch
@clerk/localizations Patch
@clerk/nextjs Patch
@clerk/nuxt Patch
@clerk/react-router Patch
@clerk/remix Patch
@clerk/tanstack-react-start Patch
@clerk/testing Patch
@clerk/clerk-react Patch

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

@vercel
Copy link

vercel bot commented Oct 17, 2025

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Preview Comments Updated (UTC)
clerk-js-sandbox Ready Ready Preview Comment Oct 30, 2025 6:33am

@coderabbitai
Copy link
Contributor

coderabbitai bot commented Oct 17, 2025

Walkthrough

This pull request migrates type imports across the codebase from @clerk/types to @clerk/shared/types as part of a broader deprecation strategy. Additionally, it updates build configuration, adds new dependencies (rolldown, tsdown), modifies package management, and documents the type package deprecation.

Changes

Cohort / File(s) Summary
Package Configuration
package.json, .changeset/deprecate-clerk-types.md
Added rolldown and tsdown dependencies, moved jest-snapshot-prettier to overrides, removed patchedDependencies block. Added deprecation notice documenting migration from @clerk/types to @clerk/shared/types with backward compatibility maintained.
Build & Linting Configuration
eslint.config.mjs, packages/chrome-extension/tsconfig.json, packages/clerk-js/bundlewatch.config.json
Added tsdown.config.mjs to ESLint ignore list. Updated chrome-extension tsconfig module/moduleResolution from "esnext"/"node" to "nodenext". Increased bundlewatch maxSize values (Clerk 821KB→840KB, Vendors 45KB→47KB).
Type Signature Changes
packages/astro/src/stores/external.ts, packages/clerk-js/src/core/resources/BillingSubscription.ts
Added SignedInSessionResource type cast to $sessionStore. Added paymentMethodId field to BillingSubscriptionItem and populated from data.payment_method_id.
Shared Module Restructuring
packages/backend/src/util/shared.ts
Reorganized and repositioned exports from @clerk/shared modules, consolidating keys-related exports and reordering deprecated/retry exports without changing public API surface.
Core Type Migration (clerk-js)
packages/clerk-js/src/core/**, packages/clerk-js/src/ui/**, packages/clerk-js/src/test/**
Updated ~180+ files to import types from @clerk/shared/types instead of @clerk/types. Includes imports in resources, utilities, UI components, test files, and fixtures.
Integration & Template Updates
integration/tests/custom-flows/sign-in.test.ts, integration/tests/custom-flows/sign-up.test.ts, integration/templates/expo-web/metro.config.js
Reorganized imports (split type-only imports), added "link:" prefix handling in metro.config.js getClerkExpoPath.
Type System Cleanup
.typedoc/__tests__/file-structure.test.ts, packages/chrome-extension/README.md
Removed "types" from expected Typedoc snapshot. Minor formatting adjustment in README.
Tooling Updates
.github/workflows/ci.yml, packages/clerk-js/package.json
Normalized YAML string quoting, updated Node version from 18 to 22 in unit-tests, removed @clerk/types dependency from packages/clerk-js.
Agent Toolkit Refactor
packages/agent-toolkit/src/langchain/adapter.ts
Restructured tool invocation to separate executeFn and toolConfig objects with additional type casts.

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
Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Areas requiring extra attention:

  • Type import verification: Confirm that all migrated types (@clerk/shared/types) actually export the expected symbols with matching signatures
  • @clerk/types deprecation strategy: Verify the backward compatibility promise—ensure @clerk/types re-exports all types from @clerk/shared/types correctly
  • Chrome-extension tsconfig change: Module resolution strategy shift from "esnext"/"node" to "nodenext" can have subtle effects on conditional exports; verify no regressions
  • Bundlewatch config increases: Verify bundle size increases (Clerk +19KB, Vendors +2KB) are justified and not regressing
  • Package.json dependency changes: Confirm rolldown and tsdown catalog mappings resolve correctly and don't introduce conflicts with patchedDependencies removal
  • BillingSubscriptionItem new field: Verify paymentMethodId mapping from data.payment_method_id is comprehensive across all use cases
  • Agent toolkit adapter restructuring: Confirm type casts and tool binding logic maintains existing behavior with new intermediate variables

🐰 With types now shared and unified clean,
The migration flows smooth as a stream,
From scattered imports to one shared sight,
The refactor bounces left and right! 🌟

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)
Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. You can run @coderabbitai generate docstrings to improve docstring coverage.
✅ Passed checks (2 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title Check ✅ Passed The pull request title "feat(shared,types): Migrate @clerk/types to @clerk/shared/types" accurately reflects the primary objective of the changeset. The raw summary demonstrates that the vast majority of changes involve updating import paths from @clerk/types to @clerk/shared/types across numerous files throughout the codebase (well over 100 files modified). While the PR also includes secondary changes such as package.json updates, configuration adjustments, deprecation documentation, and type field additions, the dominant and most impactful change is the migration of type imports. The title is concise, specific, and clearly communicates the main change without vague language or noise. A developer scanning the PR history would immediately understand that this PR involves a package migration for type definitions.
✨ Finishing touches
  • 📝 Generate docstrings
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment
  • Commit unit tests in branch nikos/migrate-types-to-shared

📜 Recent 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.

📥 Commits

Reviewing files that changed from the base of the PR and between a7f5d85 and 4b299d5.

📒 Files selected for processing (2)
  • packages/clerk-js/package.json (0 hunks)
  • packages/clerk-js/src/ui/components/OrganizationSwitcher/__tests__/OrganizationSwitcher.test.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 (1)
  • packages/clerk-js/src/ui/components/OrganizationSwitcher/tests/OrganizationSwitcher.test.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). (29)
  • GitHub Check: Integration Tests (custom, chrome)
  • GitHub Check: Integration Tests (nextjs, chrome, 15)
  • GitHub Check: Integration Tests (nextjs, chrome, 14)
  • GitHub Check: Integration Tests (quickstart, chrome, 15)
  • GitHub Check: Integration Tests (quickstart, chrome, 16)
  • GitHub Check: Integration Tests (nextjs, chrome, 16)
  • GitHub Check: Integration Tests (nuxt, chrome)
  • GitHub Check: Integration Tests (react-router, chrome)
  • GitHub Check: Integration Tests (machine, chrome)
  • GitHub Check: Integration Tests (vue, chrome)
  • GitHub Check: Integration Tests (billing, chrome)
  • GitHub Check: Integration Tests (tanstack-react-start, chrome)
  • GitHub Check: Integration Tests (astro, chrome)
  • GitHub Check: Integration Tests (expo-web, chrome)
  • GitHub Check: Integration Tests (handshake, chrome)
  • GitHub Check: Integration Tests (sessions, chrome)
  • GitHub Check: Integration Tests (handshake:staging, chrome)
  • GitHub Check: Integration Tests (express, chrome)
  • GitHub Check: Integration Tests (localhost, chrome)
  • GitHub Check: Integration Tests (sessions:staging, chrome)
  • GitHub Check: Integration Tests (ap-flows, chrome)
  • GitHub Check: Integration Tests (elements, chrome)
  • GitHub Check: Integration Tests (generic, chrome)
  • GitHub Check: Publish with pkg-pr-new
  • GitHub Check: Static analysis
  • GitHub Check: Unit Tests (22, **)
  • GitHub Check: semgrep-cloud-platform/scan
  • GitHub Check: semgrep-cloud-platform/scan
  • GitHub Check: Analyze (javascript-typescript)

Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link
Contributor

@coderabbitai coderabbitai bot left a 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 broadening types if package is meant for browser environments.

Currently types: ["node"] restricts ambient types to Node only. Since lib includes "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: Avoid Function and 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 object recurses 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, splitByScope to createCheckAuthorization, 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 @default values and @deprecated annotations 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: colorPrimary default '#2F3037'
  • Line 680: colorDanger default '#EF4444'
  • Line 686: colorSuccess default '#22C543'
packages/shared/package.json (2)

155-170: Consider marking package as side-effect free.

If modules are pure, add "sideEffects": false to improve tree-shaking.

   "peerDependenciesMeta": {
@@
   "engines": {
     "node": ">=18.17.0"
   },
+  "sideEffects": false,
   "publishConfig": {

139-143: Remove unnecessary src argument from dev script for consistency.

The tsdown.config.mts already explicitly defines entry points (entry: ['./src/types/index.ts']), making the src argument in the npm script redundant. All other packages in the monorepo use --watch without 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).

makeDefault returns Promise<null>. Consider Promise<void> unless null is 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:

  • lib should match target (use es2020 instead of es6)
  • noUnusedLocals should be enabled for consistency with noUnusedParameters
  • allowJs is unnecessary; disable it for a TS-only package
-    "lib": ["es6", "dom"],
+    "lib": ["es2020", "dom"],
@@
-    "noUnusedLocals": false,
+    "noUnusedLocals": true,
@@
-    "allowJs": true,
+    "allowJs": false
packages/shared/src/types/json copy.ts (3)

133-133: Replace any with unknown (and narrow where needed).

  • external_account: anyunknown (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: Prefer type alias 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 narrowing object to 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 object values 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 $authStore can produce undefined, prefer SignedInSessionResource | null to 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 undefined is expected before load, consider typing via computed< SignedInSessionResource | null | undefined >(...) and document the pre‑load state.

packages/shared/src/types/json.ts (3)

133-141: Avoid any in public JSON types

Use unknown for external_account to comply with TS guidelines and avoid unsafe any.

-  external_account: any;
+  external_account: unknown;

As per coding guidelines.


849-851: Prefer unknown over any for claims

Record<string, any> weakens type safety. Use unknown.

-  claims: Record<string, any> | null;
+  claims: Record<string, unknown> | null;

As per coding guidelines.


351-362: VerificationJSON.error likely optional

Errors exist only on failed verifications; make error optional 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.

Comment on lines +138 to +142
"rolldown": "catalog:repo",
"statuses": "^1.5.0",
"tree-kill": "^1.2.2",
"ts-jest": "29.2.5",
"tsdown": "catalog:repo",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🔴 Critical

🧩 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:

  1. All packages using these tools have appropriate configuration files (e.g., tsdown.config.mts)
  2. Build scripts in individual packages are updated to use the new tooling
  3. 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 -l

Length 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/shared has tsdown.config.mts and uses tsdown in build scripts
  • 19 packages unmigrated: Still have tsup.config.ts files and tsup commands 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';
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🔴 Critical

🧩 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.ts

Length 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 -20

Length 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 tsx

Length of output: 27


🏁 Script executed:

#!/bin/bash
# Search for SignedInSessionResource in packages/shared (corrected syntax)
rg -n "SignedInSessionResource" packages/shared --type ts

Length 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 2

Length 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 -30

Length 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 -30

Length 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 ts

Length 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.

Suggested change
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;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🔴 Critical

🧩 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.ts

Length 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.

Comment on lines +44 to 45
// @ts-expect-error - ignore error for now
clerk,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

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:

  1. Updating the SignInRouterInitEvent type definition to include the clerk property, or
  2. Removing the clerk property 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.

Comment on lines +44 to 45
// @ts-expect-error - ignore error for now
clerk,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

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 = {
  $$$
}'

},
environment: 'jsdom',
include: ['**/*.{spec,test}.{js,ts,jsx,tsx}'],
include: ['**/*..{js,ts,jsx,tsx}'],
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🔴 Critical

🧩 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 -20

Length 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/shared

Length 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.

Suggested change
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.

Comment on lines +26 to 41
"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": [
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🔴 Critical

🧩 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.json

Length 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.json

Length 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.

Suggested change
"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.

Comment on lines 42 to 49
"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"
},
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🔴 Critical

🧩 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 -20

Length 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:

  1. Compile .ts.js/.mjs before publishing, or
  2. Exclude .ts files from the files array: ["src", "!src/**/*.ts"], or
  3. 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.

Comment on lines +4 to +11
import type {
Clerk,
ClientResource,
InitialState,
MultiDomainAndOrProxy,
Resources,
Without,
} from '@clerk/shared/types';
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🔴 Critical

🧩 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.

Copy link
Contributor

@coderabbitai coderabbitai bot left a 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.

📥 Commits

Reviewing files that changed from the base of the PR and between c98b464 and 5520fb7.

📒 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.

Copy link
Contributor

@coderabbitai coderabbitai bot left a 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.

📥 Commits

Reviewing files that changed from the base of the PR and between 5520fb7 and 083ef3d.

📒 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.

Comment on lines 35 to 48
{
...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,
},
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🔴 Critical

🧩 Analysis chain

Verify intentional duplication of types entry and consider maintenance of explicit entry patterns.

Two observations:

  1. Types entry duplication: ./src/types/index.ts is 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.

  2. 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 spec

Length 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:

  1. 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)
  2. 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.

Copy link
Contributor

@coderabbitai coderabbitai bot left a 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:

  1. Key interface (currently lines 45-51)
  2. Path type (currently lines 82-85)
  3. ParseOptions interface (currently lines 3-12)
  4. RegexpToFunctionOptions interface (currently lines 13-18)
  5. TokensToRegexpOptions interface (currently lines 52-81)
  6. MatchResult, Match, MatchFunction types (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.

📥 Commits

Reviewing files that changed from the base of the PR and between 083ef3d and 31dd221.

📒 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
Avoid any type - prefer unknown when type is uncertain, then narrow with type guards
Use interface for object shapes that might be extended
Use type for unions, primitives, and computed types
Prefer readonly properties for immutable data structures
Use private for internal implementation details
Use protected for inheritance hierarchies
Use public explicitly for clarity in public APIs
Prefer readonly for 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
Use const assertions for literal types: as const
Use satisfies operator 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 ...
No any types without justification
Proper error handling with typed errors
Consistent use of readonly for 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

@pkg-pr-new
Copy link

pkg-pr-new bot commented Oct 17, 2025

Open in StackBlitz

@clerk/agent-toolkit

npm i https://pkg.pr.new/@clerk/agent-toolkit@7022

@clerk/astro

npm i https://pkg.pr.new/@clerk/astro@7022

@clerk/backend

npm i https://pkg.pr.new/@clerk/backend@7022

@clerk/chrome-extension

npm i https://pkg.pr.new/@clerk/chrome-extension@7022

@clerk/clerk-js

npm i https://pkg.pr.new/@clerk/clerk-js@7022

@clerk/dev-cli

npm i https://pkg.pr.new/@clerk/dev-cli@7022

@clerk/elements

npm i https://pkg.pr.new/@clerk/elements@7022

@clerk/clerk-expo

npm i https://pkg.pr.new/@clerk/clerk-expo@7022

@clerk/expo-passkeys

npm i https://pkg.pr.new/@clerk/expo-passkeys@7022

@clerk/express

npm i https://pkg.pr.new/@clerk/express@7022

@clerk/fastify

npm i https://pkg.pr.new/@clerk/fastify@7022

@clerk/localizations

npm i https://pkg.pr.new/@clerk/localizations@7022

@clerk/nextjs

npm i https://pkg.pr.new/@clerk/nextjs@7022

@clerk/nuxt

npm i https://pkg.pr.new/@clerk/nuxt@7022

@clerk/clerk-react

npm i https://pkg.pr.new/@clerk/clerk-react@7022

@clerk/react-router

npm i https://pkg.pr.new/@clerk/react-router@7022

@clerk/remix

npm i https://pkg.pr.new/@clerk/remix@7022

@clerk/shared

npm i https://pkg.pr.new/@clerk/shared@7022

@clerk/tanstack-react-start

npm i https://pkg.pr.new/@clerk/tanstack-react-start@7022

@clerk/testing

npm i https://pkg.pr.new/@clerk/testing@7022

@clerk/themes

npm i https://pkg.pr.new/@clerk/themes@7022

@clerk/types

npm i https://pkg.pr.new/@clerk/types@7022

@clerk/upgrade

npm i https://pkg.pr.new/@clerk/upgrade@7022

@clerk/vue

npm i https://pkg.pr.new/@clerk/vue@7022

commit: 4b299d5

Copy link
Contributor

@coderabbitai coderabbitai bot left a 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 specifies node-version: 22 only; 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 replacing any types with proper typing.

The confirm method contains any type assertions that violate the coding guidelines:

  • Line 69: body: params as any
  • Line 76: error: any parameter

Consider refactoring to use unknown with type guards, or proper type annotations based on the _basePatch signature and isClerkAPIResponseError function.

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.

📥 Commits

Reviewing files that changed from the base of the PR and between 55c4907 and 27850c1.

📒 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
Avoid any type - prefer unknown when type is uncertain, then narrow with type guards
Use interface for object shapes that might be extended
Use type for unions, primitives, and computed types
Prefer readonly properties for immutable data structures
Use private for internal implementation details
Use protected for inheritance hierarchies
Use public explicitly for clarity in public APIs
Prefer readonly for 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
Use const assertions for literal types: as const
Use satisfies operator 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 ...
No any types without justification
Proper error handling with typed errors
Consistent use of readonly for 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 in actionlint.yaml to 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/types to @clerk/shared/types, following TypeScript best practices with the import type syntax.

packages/clerk-js/src/ui/elements/ThreeDotsMenu.tsx (1)

1-1: LGTM! MenuId is properly exported from @clerk/shared/types and the import is correct.

Verification confirms that MenuId is defined in packages/shared/src/types/elementIds.ts with the export type 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.ts and accessible via the @clerk/shared/types import path per the package export configuration.

@nikosdouvlis nikosdouvlis merged commit 2587aa6 into main Oct 30, 2025
70 of 71 checks passed
@nikosdouvlis nikosdouvlis deleted the nikos/migrate-types-to-shared branch October 30, 2025 07:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants