8000 refactor(clerk-js): Update color logic utils to support CSS variable usage by alexcarpenter · Pull Request #6187 · clerk/javascript · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

refactor(clerk-js): Update color logic utils to support CSS variable usage #6187

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 51 commits into
base: main
Choose a base branch
from

Conversation

alexcarpenter
Copy link
Member
@alexcarpenter alexcarpenter commented Jun 24, 2025

Description

Resolves USER-2201

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

    • Introduced advanced color manipulation utilities that automatically leverage modern CSS features when available, improving color scale generation and theming flexibility.
    • Added new color utility functions for lightening, transparency, solidifying, and adjusting colors, with automatic fallback for older browsers.
    • Enhanced theming support with robust color scale generation for UI customization.
    • Added CSS feature detection utilities to optimize color rendering based on browser capabilities.
  • Bug Fixes

    • Improved handling and fallback for color transparency and lightness adjustments, ensuring consistent appearance across browsers.
  • Tests

    • Added comprehensive test suites for all color utility modules, covering both modern and legacy implementations, constants, scales, utilities, and CSS feature detection.
  • Chores

    • Refactored and consolidated color-related constants and utilities for maintainability and consistency.
    • Removed outdated color scale utilities and legacy tests.

Copy link
changeset-bot bot commented Jun 24, 2025

🦋 Changeset detected

Latest commit: 7522f71

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

This PR includes changesets to release 3 packages
Name Type
@clerk/clerk-js Minor
@clerk/chrome-extension Patch
@clerk/clerk-expo 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

Copy link
vercel bot commented Jun 24, 2025

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Comments Updated (UTC)
clerk-js-sandbox ✅ Ready (Inspect) Visit Preview 💬 Add feedback Jun 27, 2025 0:38am

- Added custom appearance variables in app.ts for improved styling.
- Introduced a new CSS variable for brand color in template.html.
- Removed unused simpleColorMix function from color utilities in utils.ts.
@alexcarpenter
Copy link
Member Author

!snapshot

@clerk-cookie
Copy link
Collaborator

Hey @alexcarpenter - the snapshot version command generated the following package versions:

Package Version
@clerk/clerk-expo 2.14.0-snapshot.v20250625145444

Tip: Use the snippet copy button below to quickly install the required packages.
@clerk/clerk-expo

npm i @clerk/clerk-expo@2.14.0-snapshot.v20250625145444 --save-exact

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

♻️ Duplicate comments (2)
packages/clerk-js/src/ui/utils/colors/modern.ts (2)

10-13: Remove duplicate JSDoc comment.

This JSDoc comment duplicates the one at the top of the file (lines 1-4).

-/**
- * Modern CSS-based color manipulation utilities
- * Uses color-mix() and relative color syntax when supported
- */

33-33: Consider error handling for unsupported browsers.

Based on the retrieved learning, modern CSS features are fully supported in target browsers. However, the current fallback silently returns the original color when features aren't supported, which could mask issues during development.

Given that @clerk/clerk-js only supports browsers from the last two years where modern CSS features are available, should we throw an error instead of silently falling back? This would help catch configuration issues early.

🧹 Nitpick comments (2)
packages/clerk-js/src/ui/utils/colors/modern.ts (1)

75-75: Simplify redundant string check.

The color.toString() check is redundant since color is already checked for truthiness on line 73.

-    if (!color.toString()) return color;
packages/clerk-js/src/ui/utils/colors/colorOptionToHslaScale.ts (1)

172-185: Optimize modern CSS path by avoiding unnecessary parsing.

The modern CSS path should avoid HSLA conversion entirely for better performance.

-    // Fall back to HSLA approach - only parse if modern CSS is not supported
-    const userScale = processColorInput(colorOption, false);
-    const finalScale = generateLegacyAlphaScale(userScale['500']);
-    return prefixAndStringifyScale(finalScale, prefix);
+    // Fall back to HSLA approach
+    const hslaColor = colors.toHslaColor(colorOption);
+    if (hslaColor && typeof hslaColor === 'object') {
+      const finalScale = generateLegacyAlphaScale(hslaColor);
+      return prefixAndStringifyScale(finalScale, prefix);
+    }
+    return undefined;
📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 3189c48 and 91a9800.

📒 Files selected for processing (4)
  • packages/clerk-js/src/ui/utils/colors/cache.ts (1 hunks)
  • packages/clerk-js/src/ui/utils/colors/colorOptionToHslaScale.ts (1 hunks)
  • packages/clerk-js/src/ui/utils/colors/constants.ts (1 hunks)
  • packages/clerk-js/src/ui/utils/colors/modern.ts (1 hunks)
🚧 Files skipped from review as they are similar to previous changes (2)
  • packages/clerk-js/src/ui/utils/colors/cache.ts
  • packages/clerk-js/src/ui/utils/colors/constants.ts
🧰 Additional context used
📓 Path-based instructions (4)
`**/*.{js,ts,tsx,jsx}`: All code must pass ESLint checks with the project's configuration. Use Prettier for consistent code formatting.

**/*.{js,ts,tsx,jsx}: All code must pass ESLint checks with the project's configuration.
Use Prettier for consistent code formatting.

📄 Source: CodeRabbit Inference Engine (.cursor/rules/development.mdc)

List of files the instruction was applied to:

  • packages/clerk-js/src/ui/utils/colors/modern.ts
  • packages/clerk-js/src/ui/utils/colors/colorOptionToHslaScale.ts
`**/*.{ts,tsx}`: Maintain comprehensive JSDoc comments for public APIs.

**/*.{ts,tsx}: Maintain comprehensive JSDoc comments for public APIs.

📄 Source: CodeRabbit Inference Engine (.cursor/rules/development.mdc)

List of files the instruction was applied to:

  • packages/clerk-js/src/ui/utils/colors/modern.ts
  • packages/clerk-js/src/ui/utils/colors/colorOptionToHslaScale.ts
`packages/**`: All publishable packages under the @clerk namespace must be located in the packages/ directory.

packages/**: All publishable packages under the @clerk namespace must be located in the packages/ directory.

📄 Source: CodeRabbit Inference Engine (.cursor/rules/global.mdc)

List of files the instruction was applied to:

  • packages/clerk-js/src/ui/utils/colors/modern.ts
  • packages/clerk-js/src/ui/utils/colors/colorOptionToHslaScale.ts
`**/*.ts`: Always define explicit return types for functions, especially public ...

**/*.ts: Always define explicit return types for functions, especially public APIs.
Use proper type annotations for variables and parameters where inference isn't clear.
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, protected for inheritance, and public explicitly for clarity in public APIs.
Prefer composition and interfaces over deep inheritance chains; use mixins for shared behavior.
Use ES6 imports/exports consistently; avoid barrel files (index.ts re-exports) to prevent circular dependencies.
Use type-only imports (import type { ... }) where possible.
Use as const for literal types and the satisfies operator for type checking without widening.
Enable --incremental and --tsBuildInfoFile for faster builds.
Use ESLint with @typescript-eslint/recommended rules and Prettier for formatting.
Use lint-staged and Husky for pre-commit checks.
Use type-coverage to measure type safety.

📄 Source: CodeRabbit Inference Engine (.cursor/rules/typescript.mdc)

List of files the instruction was applied to:

  • packages/clerk-js/src/ui/utils/colors/modern.ts
  • packages/clerk-js/src/ui/utils/colors/colorOptionToHslaScale.ts
🧠 Learnings (3)
📓 Common learnings
Learnt from: dstaley
PR: clerk/javascript#6100
File: packages/clerk-js/src/ui/components/OAuthConsent/OAuthConsent.tsx:121-124
Timestamp: 2025-06-16T17:08:58.414Z
Learning: The @clerk/clerk-js package only supports browsers released in the last two years (since May 8, 2023), so modern CSS features like color-mix() are fully supported across all target browsers without requiring fallbacks.
Learnt from: dstaley
PR: clerk/javascript#6116
File: .changeset/tangy-garlics-say.md:1-2
Timestamp: 2025-06-13T16:09:53.061Z
Learning: In the Clerk JavaScript repository, contributors create intentionally empty changeset files (containing only the YAML delimiters) when a PR touches only non-published parts of the codebase (e.g., sandbox assets). This signals that no package release is required, so such changesets should not be flagged as missing content.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/monorepo.mdc:0-0
Timestamp: 2025-06-23T12:25:40.214Z
Learning: Environment variables prefixed with CLERK_* and NEXT_PUBLIC_CLERK_* are supported for configuration across different environments.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/monorepo.mdc:0-0
Timestamp: 2025-06-23T12:25:40.214Z
Learning: Framework packages depend on @clerk/clerk-js for core functionality, while @clerk/shared and @clerk/types provide common utilities and TypeScript definitions used across packages.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/monorepo.mdc:0-0
Timestamp: 2025-06-23T12:25:40.214Z
Learning: All packages are published under the @clerk namespace on npm, ensuring consistent naming and discoverability.
packages/clerk-js/src/ui/utils/colors/modern.ts (12)
Learnt from: dstaley
PR: clerk/javascript#6100
File: packages/clerk-js/src/ui/components/OAuthConsent/OAuthConsent.tsx:121-124
Timestamp: 2025-06-16T17:08:58.414Z
Learning: The @clerk/clerk-js package only supports browsers released in the last two years (since May 8, 2023), so modern CSS features like color-mix() are fully supported across all target browsers without requiring fallbacks.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/typescript.mdc:0-0
Timestamp: 2025-06-23T12:26:09.855Z
Learning: Leverage modern TypeScript features such as generics, utility types (Omit, Partial, Pick), mapped types, conditional types, and template literal types for expressive and type-safe code.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/typescript.mdc:0-0
Timestamp: 2025-06-23T12:26:09.855Z
Learning: Use ES6 module syntax (import/export) consistently for maintainability and compatibility.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/monorepo.mdc:0-0
Timestamp: 2025-06-23T12:25:40.214Z
Learning: Framework packages depend on @clerk/clerk-js for core functionality, while @clerk/shared and @clerk/types provide common utilities and TypeScript definitions used across packages.
Learnt from: jacekradko
PR: clerk/javascript#5905
File: .changeset/six-ears-wash.md:1-3
Timestamp: 2025-06-26T03:27:05.511Z
Learning: In the Clerk JavaScript repository, changeset headers support single quotes syntax (e.g., '@clerk/backend': minor) and work fine with their current changesets integration, so there's no need to change them to double quotes.
Learnt from: dstaley
PR: clerk/javascript#6116
File: .changeset/tangy-garlics-say.md:1-2
Timestamp: 2025-06-13T16:09:53.061Z
Learning: In the Clerk JavaScript repository, contributors create intentionally empty changeset files (containing only the YAML delimiters) when a PR touches only non-published parts of the codebase (e.g., sandbox assets). This signals that no package release is required, so such changesets should not be flagged as missing content.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/monorepo.mdc:0-0
Timestamp: 2025-06-23T12:25:40.214Z
Learning: All packages are published under the @clerk namespace on npm, ensuring consistent naming and discoverability.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/monorepo.mdc:0-0
Timestamp: 2025-06-23T12:25:40.214Z
Learning: Backend utilities are isolated in @clerk/backend, which is independent and used for server-side operations.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/global.mdc:0-0
Timestamp: 2025-06-23T12:25:34.662Z
Learning: All packages published from this repository must use the @clerk namespace.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/monorepo.mdc:0-0
Timestamp: 2025-06-23T12:25:40.214Z
Learning: Environment variables prefixed with CLERK_* and NEXT_PUBLIC_CLERK_* are supported for configuration across different environments.
Learnt from: panteliselef
PR: clerk/javascript#6097
File: packages/clerk-js/src/ui/elements/LineItems.tsx:89-89
Timestamp: 2025-06-10T09:38:56.214Z
Learning: In packages/clerk-js/src/ui/elements/LineItems.tsx, the Title component's React.forwardRef should use HTMLTableCellElement as the generic type parameter, even though it renders a Dt element. This is the correct implementation according to the codebase maintainer.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/typescript.mdc:0-0
Timestamp: 2025-06-23T12:26:09.855Z
Learning: In TypeScript, always define explicit return types for functions, especially for public APIs, to ensure type safety and clarity.
packages/clerk-js/src/ui/utils/colors/colorOptionToHslaScale.ts (2)
Learnt from: dstaley
PR: clerk/javascript#6100
File: packages/clerk-js/src/ui/components/OAuthConsent/OAuthConsent.tsx:121-124
Timestamp: 2025-06-16T17:08:58.414Z
Learning: The @clerk/clerk-js package only supports browsers released in the last two years (since May 8, 2023), so modern CSS features like color-mix() are fully supported across all target browsers without requiring fallbacks.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/monorepo.mdc:0-0
Timestamp: 2025-06-23T12:25:40.214Z
Learning: Framework packages depend on @clerk/clerk-js for core functionality, while @clerk/shared and @clerk/types provide common utilities and TypeScript definitions used across packages.
🧬 Code Graph Analysis (1)
packages/clerk-js/src/ui/utils/colors/colorOptionToHslaScale.ts (5)
packages/types/src/appearance.ts (3)
  • ColorScale (45-45)
  • CssColorOrAlphaScale (53-53)
  • CssColorOrScale (52-52)
packages/clerk-js/src/ui/utils/colors/constants.ts (5)
  • ALL_SHADES (20-20)
  • LIGHTNESS_CONFIG (23-28)
  • LIGHT_SHADES (18-18)
  • DARK_SHADES (19-19)
  • ALPHA_VALUES (31-31)
packages/clerk-js/src/ui/utils/colors/index.ts (2)
  • colors (7-61)
  • hasModernColorSupport (63-63)
packages/clerk-js/src/ui/utils/colors/modern.ts (1)
  • hasModernColorSupport (124-126)
packages/clerk-js/src/ui/utils/colors/utils.ts (1)
  • applyScalePrefix (85-98)
⏰ Context from checks skipped due to timeout of 90000ms (5)
  • GitHub Check: semgrep-cloud-platform/scan
  • GitHub Check: Formatting | Dedupe | Changeset
  • GitHub Check: Build Packages
  • GitHub Check: semgrep/ci
  • GitHub Check: Analyze (javascript-typescript)
🔇 Additional comments (8)
packages/clerk-js/src/ui/utils/colors/modern.ts (2)

14-119: Well-structured modern color utilities with proper feature detection.

The implementation correctly prioritizes relative color syntax over color-mix() where appropriate, uses proper bounds checking with constants, and provides consistent fallback behavior. The caching mechanism integration is also well done.


124-126: Clean wrapper function for cached color support detection.

Simple and effective wrapper that leverages the caching mechanism.

packages/clerk-js/src/ui/utils/colors/colorOptionToHslaScale.ts (6)

7-11: Excellent use of TypeScript mapped types.

The type definitions effectively use mapped types and template literal types to create type-safe prefixed color scales.


34-47: Comprehensive validation with clear error messages.

The validation functions provide helpful error messages that clearly indicate missing shades and requirements.


87-109: Well-implemented lightness scale generation.

The algorithm correctly calculates lightness steps using the configuration constants and applies them systematically to generate light and dark shades from the base color.


162-191: Smart modern/legacy fallback strategy for alpha scales.

The function intelligently chooses between modern CSS and legacy HSLA approaches based on browser support, optimizing performance while maintaining compatibility.


193-235: Robust lightness scale generation with proper user override support.

The implementation correctly handles both single color inputs and partial scales, merging user-defined shades with generated ones while maintaining the base color requirement.


1-6: Verify file duplication concern.

A previous comment questioned if this file differs from packages/clerk-js/src/ui/utils/colorOptionToHslaScale.ts. The file paths suggest potential duplication.

#!/bin/bash
# Check if there's another colorOptionToHslaScale file outside the colors directory
fd -t f "colorOptionToHslaScale" --exclude "packages/clerk-js/src/ui/utils/colors/"

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

♻️ Duplicate comments (1)
packages/clerk-js/src/ui/utils/colors/index.ts (1)

9-63: Optimize performance by avoiding repeated feature detection calls.

The current implementation calls hasModernColorSupport() on every function invocation, which is inefficient since CSS feature support doesn't change during runtime.

Consider implementing the suggestion from the past review to define the colors object once:

-export const colors = {
-  toHslaColor: (color: string | undefined): string | HslaColor | undefined => {
-    if (!color) return undefined;
-    if (hasModernColorSupport()) {
-      return color;
-    }
-    return legacyColors.toHslaColor(color);
-  },
-  // ... other functions with repeated hasModernColorSupport() calls
-};
+export const colors = hasModernColorSupport() ? {
+  toHslaColor: (color: string | undefined): string | HslaColor | undefined => {
+    if (!color) return undefined;
+    return color;
+  },
+  toHslaString: (color: HslaColor | string | undefined): string | undefined => {
+    if (!color) return undefined;
+    if (typeof color === 'string') {
+      return color;
+    }
+    return legacyColors.toHslaString(color);
+  },
+  changeHslaLightness: legacyColors.changeHslaLightness,
+  setHslaAlpha: legacyColors.setHslaAlpha,
+  lighten: modernColors.lighten,
+  makeTransparent: modernColors.makeTransparent,
+  makeSolid: modernColors.makeSolid,
+  setAlpha: modernColors.setAlpha,
+  adjustForLightness: modernColors.adjustForLightness,
+} : {
+  toHslaColor: legacyColors.toHslaColor,
+  toHslaString: legacyColors.toHslaString,
+  changeHslaLightness: legacyColors.changeHslaLightness,
+  setHslaAlpha: legacyColors.setHslaAlpha,
+  lighten: legacyColors.lighten,
+  makeTransparent: legacyColors.makeTransparent,
+  makeSolid: legacyColors.makeSolid,
+  setAlpha: legacyColors.setAlpha,
+  adjustForLightness: legacyColors.adjustForLightness,
+};
🧹 Nitpick comments (1)
packages/clerk-js/src/ui/utils/memoize.ts (1)

24-28: Add explicit return type annotation.

According to coding guidelines, explicit return types are required for functions, especially public APIs.

-export function getCacheStats(): { size: number } {
+export function getCacheStats(): { size: number } {

The return type is already explicit, so this is good.

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between b31b45b 67E6 and 1ae5c97.

📒 Files selected for processing (17)
  • packages/clerk-js/src/ui/utils/__tests__/colors.test.ts (0 hunks)
  • packages/clerk-js/src/ui/utils/__tests__/memoize.spec.ts (1 hunks)
  • packages/clerk-js/src/ui/utils/colors/__tests__/colorOptionToHslaScale.spec.ts (1 hunks)
  • packages/clerk-js/src/ui/utils/colors/__tests__/constants.spec.ts (1 hunks)
  • packages/clerk-js/src/ui/utils/colors/__tests__/index.spec.ts (1 hunks)
  • packages/clerk-js/src/ui/utils/colors/__tests__/legacy.spec.ts (1 hunks)
  • packages/clerk-js/src/ui/utils/colors/__tests__/modern.spec.ts (1 hunks)
  • packages/clerk-js/src/ui/utils/colors/__tests__/scales.spec.ts (1 hunks)
  • packages/clerk-js/src/ui/utils/colors/__tests__/utils.spec.ts (1 hunks)
  • packages/clerk-js/src/ui/utils/colors/colorOptionToHslaScale.ts (1 hunks)
  • packages/clerk-js/src/ui/utils/colors/constants.ts (1 hunks)
  • packages/clerk-js/src/ui/utils/colors/index.ts (1 hunks)
  • packages/clerk-js/src/ui/utils/colors/modern.ts (1 hunks)
  • packages/clerk-js/src/ui/utils/colors/scales.ts (1 hunks)
  • packages/clerk-js/src/ui/utils/colors/utils.ts (1 hunks)
  • packages/clerk-js/src/ui/utils/cssSupports.ts (1 hunks)
  • packages/clerk-js/src/ui/utils/memoize.ts (1 hunks)
💤 Files with no reviewable changes (1)
  • packages/clerk-js/src/ui/utils/tests/colors.test.ts
🚧 Files skipped from review as they are similar to previous changes (7)
  • packages/clerk-js/src/ui/utils/colors/modern.ts
  • packages/clerk-js/src/ui/utils/colors/tests/scales.spec.ts
  • packages/clerk-js/src/ui/utils/cssSupports.ts
  • packages/clerk-js/src/ui/utils/colors/scales.ts
  • packages/clerk-js/src/ui/utils/colors/constants.ts
  • packages/clerk-js/src/ui/utils/colors/tests/utils.spec.ts
  • packages/clerk-js/src/ui/utils/colors/utils.ts
🧰 Additional context used
📓 Path-based instructions (7)
`**/*.{js,ts,tsx,jsx}`: All code must pass ESLint checks with the project's configuration. Use Prettier for consistent code formatting.

**/*.{js,ts,tsx,jsx}: All code must pass ESLint checks with the project's configuration.
Use Prettier for consistent code formatting.

📄 Source: CodeRabbit Inference Engine (.cursor/rules/development.mdc)

List of files the instruction was applied to:

  • packages/clerk-js/src/ui/utils/memoize.ts
  • packages/clerk-js/src/ui/utils/__tests__/memoize.spec.ts
  • packages/clerk-js/src/ui/utils/colors/__tests__/modern.spec.ts
  • packages/clerk-js/src/ui/utils/colors/index.ts
  • packages/clerk-js/src/ui/utils/colors/__tests__/index.spec.ts
  • packages/clerk-js/src/ui/utils/colors/colorOptionToHslaScale.ts
  • packages/clerk-js/src/ui/utils/colors/__tests__/colorOptionToHslaScale.spec.ts
  • packages/clerk-js/src/ui/utils/colors/__tests__/legacy.spec.ts
  • packages/clerk-js/src/ui/utils/colors/__tests__/constants.spec.ts
`**/*.{ts,tsx}`: Maintain comprehensive JSDoc comments for public APIs.

**/*.{ts,tsx}: Maintain comprehensive JSDoc comments for public APIs.

📄 Source: CodeRabbit Inference Engine (.cursor/rules/development.mdc)

List of files the instruction was applied to:

  • packages/clerk-js/src/ui/utils/memoize.ts
  • packages/clerk-js/src/ui/utils/__tests__/memoize.spec.ts
  • packages/clerk-js/src/ui/utils/colors/__tests__/modern.spec.ts
  • packages/clerk-js/src/ui/utils/colors/index.ts
  • packages/clerk-js/src/ui/utils/colors/__tests__/index.spec.ts
  • packages/clerk-js/src/ui/utils/colors/colorOptionToHslaScale.ts
  • packages/clerk-js/src/ui/utils/colors/__tests__/colorOptionToHslaScale.spec.ts
  • packages/clerk-js/src/ui/utils/colors/__tests__/legacy.spec.ts
  • packages/clerk-js/src/ui/utils/colors/__tests__/constants.spec.ts
`packages/**`: All publishable packages under the @clerk namespace must be located in the packages/ directory.

packages/**: All publishable packages under the @clerk namespace must be located in the packages/ directory.

📄 Source: CodeRabbit Inference Engine (.cursor/rules/global.mdc)

List of files the instruction was applied to:

  • packages/clerk-js/src/ui/utils/memoize.ts
  • packages/clerk-js/src/ui/utils/__tests__/memoize.spec.ts
  • packages/clerk-js/src/ui/utils/colors/__tests__/modern.spec.ts
  • packages/clerk-js/src/ui/utils/colors/index.ts
  • packages/clerk-js/src/ui/utils/colors/__tests__/index.spec.ts
  • packages/clerk-js/src/ui/utils/colors/colorOptionToHslaScale.ts
  • packages/clerk-js/src/ui/utils/colors/__tests__/colorOptionToHslaScale.spec.ts
  • packages/clerk-js/src/ui/utils/colors/__tests__/legacy.spec.ts
  • packages/clerk-js/src/ui/utils/colors/__tests__/constants.spec.ts
`**/*.ts`: Always define explicit return types for functions, especially public ...

**/*.ts: Always define explicit return types for functions, especially public APIs.
Use proper type annotations for variables and parameters where inference isn't clear.
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, protected for inheritance, and public explicitly for clarity in public APIs.
Prefer composition and interfaces over deep inheritance chains; use mixins for shared behavior.
Use ES6 imports/exports consistently; avoid barrel files (index.ts re-exports) to prevent circular dependencies.
Use type-only imports (import type { ... }) where possible.
Use as const for literal types and the satisfies operator for type checking without widening.
Enable --incremental and --tsBuildInfoFile for faster builds.
Use ESLint with @typescript-eslint/recommended rules and Prettier for formatting.
Use lint-staged and Husky for pre-commit checks.
Use type-coverage to measure type safety.

📄 Source: CodeRabbit Inference Engine (.cursor/rules/typescript.mdc)

List of files the instruction was applied to:

  • packages/clerk-js/src/ui/utils/memoize.ts
  • packages/clerk-js/src/ui/utils/__tests__/memoize.spec.ts
  • packages/clerk-js/src/ui/utils/colors/__tests__/modern.spec.ts
  • packages/clerk-js/src/ui/utils/colors/index.ts
  • packages/clerk-js/src/ui/utils/colors/__tests__/index.spec.ts
  • packages/clerk-js/src/ui/utils/colors/colorOptionToHslaScale.ts
  • packages/clerk-js/src/ui/utils/colors/__tests__/colorOptionToHslaScale.spec.ts
  • packages/clerk-js/src/ui/utils/colors/__tests__/legacy.spec.ts
  • packages/clerk-js/src/ui/utils/colors/__tests__/constants.spec.ts
`**/*.{test,spec}.{js,ts,tsx,jsx}`: Unit tests are required for all new functionality.

**/*.{test,spec}.{js,ts,tsx,jsx}: Unit tests are required for all new functionality.

📄 Source: CodeRabbit Inference Engine (.cursor/rules/development.mdc)

List of files the instruction was applied to:

  • packages/clerk-js/src/ui/utils/__tests__/memoize.spec.ts
  • packages/clerk-js/src/ui/utils/colors/__tests__/modern.spec.ts
  • packages/clerk-js/src/ui/utils/colors/__tests__/index.spec.ts
  • packages/clerk-js/src/ui/utils/colors/__tests__/colorOptionToHslaScale.spec.ts
  • packages/clerk-js/src/ui/utils/colors/__tests__/legacy.spec.ts
  • packages/clerk-js/src/ui/utils/colors/__tests__/constants.spec.ts
`**/__tests__/**/*.{js,ts,tsx,jsx}`: Test files should be co-located with source files or in `__tests__` directories.

**/__tests__/**/*.{js,ts,tsx,jsx}: Test files should be co-located with source files or in __tests__ directories.

📄 Source: CodeRabbit Inference Engine (.cursor/rules/development.mdc)

List of files the instruction was applied to:

  • packages/clerk-js/src/ui/utils/__tests__/memoize.spec.ts
  • packages/clerk-js/src/ui/utils/colors/__tests__/modern.spec.ts
  • packages/clerk-js/src/ui/utils/colors/__tests__/index.spec.ts
  • packages/clerk-js/src/ui/utils/colors/__tests__/colorOptionToHslaScale.spec.ts
  • packages/clerk-js/src/ui/utils/colors/__tests__/legacy.spec.ts
  • packages/clerk-js/src/ui/utils/colors/__tests__/constants.spec.ts
`**/index.ts`: Use index.ts files for clean imports but avoid deep barrel exports.

**/index.ts: Use index.ts files for clean imports but avoid deep barrel exports.

📄 Source: CodeRabbit Inference Engine (.cursor/rules/react.mdc)

List of files the instruction was applied to:

  • packages/clerk-js/src/ui/utils/colors/index.ts
🧠 Learnings (10)
📓 Common learnings
Learnt from: dstaley
PR: clerk/javascript#6100
File: packages/clerk-js/src/ui/components/OAuthConsent/OAuthConsent.tsx:121-124
Timestamp: 2025-06-16T17:08:58.414Z
Learning: The @clerk/clerk-js package only supports browsers released in the last two years (since May 8, 2023), so modern CSS features like color-mix() are fully supported across all target browsers without requiring fallbacks.
Learnt from: dstaley
PR: clerk/javascript#6116
File: .changeset/tangy-garlics-say.md:1-2
Timestamp: 2025-06-13T16:09:53.061Z
Learning: In the Clerk JavaScript repository, contributors create intentionally empty changeset files (containing only the YAML delimiters) when a PR touches only non-published parts of the codebase (e.g., sandbox assets). This signals that no package release is required, so such changesets should not be flagged as missing content.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/monorepo.mdc:0-0
Timestamp: 2025-06-23T12:25:40.214Z
Learning: Environment variables prefixed with CLERK_* and NEXT_PUBLIC_CLERK_* are supported for configuration across different environments.
packages/clerk-js/src/ui/utils/memoize.ts (2)
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/monorepo.mdc:0-0
Timestamp: 2025-06-23T12:25:40.214Z
Learning: Framework packages depend on @clerk/clerk-js for core functionality, while @clerk/shared and @clerk/types provide common utilities and TypeScript definitions used across packages.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/react.mdc:0-0
Timestamp: 2025-06-23T12:25:57.184Z
Learning: Optimize rendering in React by using React.memo for expensive components, useCallback for handlers, useMemo for expensive computations, and implement virtualization for large lists.
packages/clerk-js/src/ui/utils/__tests__/memoize.spec.ts (6)
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/development.mdc:0-0
Timestamp: 2025-06-23T12:25:30.457Z
Learning: Unit tests are mandatory for all new functionality, and test coverage must remain above established thresholds.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/monorepo.mdc:0-0
Timestamp: 2025-06-23T12:25:40.214Z
Learning: Framework packages depend on @clerk/clerk-js for core functionality, while @clerk/shared and @clerk/types provide common utilities and TypeScript definitions used across packages.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/monorepo.mdc:0-0
Timestamp: 2025-06-23T12:25:40.214Z
Learning: Unit tests are run with Jest and Vitest, integration tests with Playwright, and component testing with React Testing Library, demonstrating a layered testing strategy.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/typescript.mdc:0-0
Timestamp: 2025-06-23T12:26:09.855Z
Learning: In tests (e.g., with Vitest), use type-safe mocks, test builders, and branded types for isolation and correctness.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/development.mdc:0-0
Timestamp: 2025-06-23T12:25:30.457Z
Learning: Use Jest for unit testing and React Testing Library for component testing; use Playwright for end-to-end integration tests.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/typescript.mdc:0-0
Timestamp: 2025-06-23T12:26:09.855Z
Learning: Follow a performance checklist: use type-only imports, ensure exports are tree-shaking friendly, avoid circular dependencies, and keep type computations efficient.
packages/clerk-js/src/ui/utils/colors/__tests__/modern.spec.ts (4)
Learnt from: dstaley
PR: clerk/javascript#6100
File: packages/clerk-js/src/ui/components/OAuthConsent/OAuthConsent.tsx:121-124
Timestamp: 2025-06-16T17:08:58.414Z
Learning: The @clerk/clerk-js package only supports browsers released in the last two years (since May 8, 2023), so modern CSS features like color-mix() are fully supported across all target browsers without requiring fallbacks.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/monorepo.mdc:0-0
Timestamp: 2025-06-23T12:25:40.214Z
Learning: Unit tests are run with Jest and Vitest, integration tests with Playwright, and component testing with React Testing Library, demonstrating a layered testing strategy.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/monorepo.mdc:0-0
Timestamp: 2025-06-23T12:25:40.214Z
Learning: Framework packages depend on @clerk/clerk-js for core functionality, while @clerk/shared and @clerk/types provide common utilities and TypeScript definitions used across packages.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/development.mdc:0-0
Timestamp: 2025-06-23T12:25:30.457Z
Learning: Use Jest for unit testing and React Testing Library for component testing; use Playwright for end-to-end integration tests.
packages/clerk-js/src/ui/utils/colors/index.ts (4)
Learnt from: dstaley
PR: clerk/javascript#6100
File: packages/clerk-js/src/ui/components/OAuthConsent/OAuthConsent.tsx:121-124
Timestamp: 2025-06-16T17:08:58.414Z
Learning: The @clerk/clerk-js package only supports browsers released in the last two years (since May 8, 2023), so modern CSS features like color-mix() are fully supported across all target browsers without requiring fallbacks.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/typescript.mdc:0-0
Timestamp: 2025-06-23T12:26:09.855Z
Learning: Use ES6 module syntax (import/export) consistently for maintainability and compatibility.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/monorepo.mdc:0-0
Timestamp: 2025-06-23T12:25:40.214Z
Learning: Framework packages depend on @clerk/clerk-js for core functionality, while @clerk/shared and @clerk/types provide common utilities and TypeScript definitions used across packages.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/monorepo.mdc:0-0
Timestamp: 2025-06-23T12:25:40.214Z
Learning: All packages are published under the @clerk namespace on npm, ensuring consistent naming and discoverability.
packages/clerk-js/src/ui/utils/colors/__tests__/index.spec.ts (4)
Learnt from: dstaley
PR: clerk/javascript#6100
File: packages/clerk-js/src/ui/components/OAuthConsent/OAuthConsent.tsx:121-124
Timestamp: 2025-06-16T17:08:58.414Z
Learning: The @clerk/clerk-js package only supports browsers released in the last two years (since May 8, 2023), so modern CSS features like color-mix() are fully supported across all target browsers without requiring fallbacks.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/monorepo.mdc:0-0
Timestamp: 2025-06-23T12:25:40.214Z
Learning: Unit tests are run with Jest and Vitest, integration tests with Playwright, and component testing with React Testing Library, demonstrating a layered testing strategy.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/monorepo.mdc:0-0
Timestamp: 2025-06-23T12:25:40.214Z
Learning: Framework packages depend on @clerk/clerk-js for core functionality, while @clerk/shared and @clerk/types provide common utilities and TypeScript definitions used across packages.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/typescript.mdc:0-0
Timestamp: 2025-06-23T12:26:09.855Z
Learning: Use ES6 module syntax (import/export) consistently for maintainability and compatibility.
packages/clerk-js/src/ui/utils/colors/colorOptionToHslaScale.ts (2)
Learnt from: dstaley
PR: clerk/javascript#6100
File: packages/clerk-js/src/ui/components/OAuthConsent/OAuthConsent.tsx:121-124
Timestamp: 2025-06-16T17:08:58.414Z
Learning: The @clerk/clerk-js package only supports browsers released in the last two years (since May 8, 2023), so modern CSS features like color-mix() are fully supported across all target browsers without requiring fallbacks.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/monorepo.mdc:0-0
Timestamp: 2025-06-23T12:25:40.214Z
Learning: Framework packages depend on @clerk/clerk-js for core functionality, while @clerk/shared and @clerk/types provide common utilities and TypeScript definitions used across packages.
packages/clerk-js/src/ui/utils/colors/__tests__/colorOptionToHslaScale.spec.ts (2)
Learnt from: dstaley
PR: clerk/javascript#6100
File: packages/clerk-js/src/ui/components/OAuthConsent/OAuthConsent.tsx:121-124
Timestamp: 2025-06-16T17:08:58.414Z
Learning: The @clerk/clerk-js package only supports browsers released in the last two years (since May 8, 2023), so modern CSS features like color-mix() are fully supported across all target browsers without requiring fallbacks.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/monorepo.mdc:0-0
Timestamp: 2025-06-23T12:25:40.214Z
Learning: Unit tests are run with Jest and Vitest, integration tests with Playwright, and component testing with React Testing Library, demonstrating a layered testing strategy.
packages/clerk-js/src/ui/utils/colors/__tests__/legacy.spec.ts (3)
Learnt from: dstaley
PR: clerk/javascript#6100
File: packages/clerk-js/src/ui/components/OAuthConsent/OAuthConsent.tsx:121-124
Timestamp: 2025-06-16T17:08:58.414Z
Learning: The @clerk/clerk-js package only supports browsers released in the last two years (since May 8, 2023), so modern CSS features like color-mix() are fully supported across all target browsers without requiring fallbacks.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/monorepo.mdc:0-0
Timestamp: 2025-06-23T12:25:40.214Z
Learning: Unit tests are run with Jest and Vitest, integration tests with Playwright, and component testing with React Testing Library, demonstrating a layered testing strategy.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/development.mdc:0-0
Timestamp: 2025-06-23T12:25:30.457Z
Learning: Unit tests are mandatory for all new functionality, and test coverage must remain above established thresholds.
packages/clerk-js/src/ui/utils/colors/__tests__/constants.spec.ts (3)
Learnt from: dstaley
PR: clerk/javascript#6100
File: packages/clerk-js/src/ui/components/OAuthConsent/OAuthConsent.tsx:121-124
Timestamp: 2025-06-16T17:08:58.414Z
Learning: The @clerk/clerk-js package only supports browsers released in the last two years (since May 8, 2023), so modern CSS features like color-mix() are fully supported across all target browsers without requiring fallbacks.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/typescript.mdc:0-0
Timestamp: 2025-06-23T12:26:09.855Z
Learning: Use const assertions (`as const`) and the `satisfies` operator to maintain literal types and precise type checking.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/monorepo.mdc:0-0
Timestamp: 2025-06-23T12:25:40.214Z
Learning: Unit tests are run with Jest and Vitest, integration tests with Playwright, and component testing with React Testing Library, demonstrating a layered testing strategy.
🧬 Code Graph Analysis (5)
packages/clerk-js/src/ui/utils/__tests__/memoize.spec.ts (1)
packages/clerk-js/src/ui/utils/memoize.ts (3)
  • clearMemoCache (34-36)
  • memoize (6-18)
  • getCacheStats (24-28)
packages/clerk-js/src/ui/utils/colors/__tests__/modern.spec.ts (4)
packages/clerk-js/src/ui/utils/cssSupports.ts (1)
  • cssSupports (65-81)
packages/clerk-js/src/ui/utils/colors/index.ts (1)
  • colors (9-63)
packages/clerk-js/src/ui/utils/colors/modern.ts (1)
  • colors (14-120)
packages/clerk-js/src/ui/utils/colors/legacy.ts (1)
  • colors (357-367)
packages/clerk-js/src/ui/utils/colors/__tests__/index.spec.ts (4)
packages/clerk-js/src/ui/utils/cssSupports.ts (1)
  • cssSupports (65-81)
packages/clerk-js/src/ui/utils/colors/index.ts (4)
  • legacyColors (65-65)
  • modernColors (65-65)
  • hasModernColorSupport (65-65)
  • colors (9-63)
packages/clerk-js/src/ui/utils/colors/modern.ts (1)
  • colors (14-120)
packages/clerk-js/src/ui/utils/colors/legacy.ts (1)
  • colors (357-367)
packages/clerk-js/src/ui/utils/colors/__tests__/legacy.spec.ts (1)
packages/clerk-js/src/ui/utils/colors/index.ts (1)
  • colors (9-63)
packages/clerk-js/src/ui/utils/colors/__tests__/constants.spec.ts (1)
packages/clerk-js/src/ui/utils/colors/constants.ts (11)
  • COLOR_SCALE (12-14)
  • LIGHT_SHADES (17-17)
  • DARK_SHADES (18-18)
  • ALL_SHADES (19-19)
  • LIGHTNESS_CONFIG (22-27)
  • ALPHA_VALUES (30-30)
  • ALPHA_PERCENTAGES (33-49)
  • LIGHTNESS_MIX_DATA (52-68)
  • RELATIVE_SHADE_STEPS (71-88)
  • COLOR_BOUNDS (91-96)
  • MODERN_CSS_LIMITS (99-106)
⏰ Context from checks skipped due to timeout of 90000ms (5)
  • GitHub Check: semgrep-cloud-platform/scan
  • GitHub Check: Build Packages
  • GitHub Check: Formatting | Dedupe | Changeset
  • GitHub Check: semgrep/ci
  • GitHub Check: Analyze (javascript-typescript)
🔇 Additional comments (48)
packages/clerk-js/src/ui/utils/colors/__tests__/colorOptionToHslaScale.spec.ts (4)

1-63: Excellent test setup with comprehensive mocking.

The test suite demonstrates thorough preparation with realistic mock implementations and proper isolation of dependencies. The beforeEach setup ensures clean state between tests, and the mock implementations accurately simulate the expected behavior of the color utilities.


65-141: Comprehensive alpha scale test coverage.

The tests cover all essential scenarios for alpha scale generation including undefined inputs, modern CSS support detection, legacy fallbacks, complete color scale objects, and prefix application. The test cases properly validate both the function calls and expected outcomes.


143-236: Thorough lightness scale testing with good error validation.

The lightness scale tests properly cover partial color scales, base color validation, and the critical requirement for the 500 shade. The error handling tests ensure proper validation of required shades and graceful handling of invalid inputs.


238-276: Good error handling and edge case coverage.

The tests properly validate error conditions including empty strings, incomplete scales, invalid color objects, and various prefix applications. This ensures robust behavior across different input scenarios.

packages/clerk-js/src/ui/utils/colors/colorOptionToHslaScale.ts (7)

1-12: Good TypeScript usage and clear type definitions.

The internal types InternalColorScale and WithPrefix are well-defined and provide good type safety for the scale conversion logic. The imports are well-organized and properly typed.


14-42: Solid validation and conversion utilities.

The validation functions provide clear error messages and proper checking for required shades. The convertToHslaScale function safely handles color conversion with proper null checking.


44-58: Type-safe prefix application with proper string handling.

The prefixAndStringifyScale function properly handles the type transformations and ensures only valid colors are included in the final result. The type assertion at line 53 is safe given the null check.


60-101: Well-implemented scale generation for both modern and legacy approaches.

The functions clearly separate modern CSS generation from legacy HSLA calculations. The legacy lightness scale uses proper mathematical calculations based on constants, and the alpha scale correctly applies predefined alpha values.


103-140: Good user preference handling and input processing.

The merge function properly prioritizes user-defined colors over generated ones, and the processColorInput function handles both string and object inputs with appropriate validation based on requirements.


142-171: Robust alpha scale generation with proper feature detection.

The function correctly checks for modern CSS support and falls back to legacy implementation when needed. The type assertions are safe given the controlled flow and validation performed.


173-215: Comprehensive lightness scale implementation with good error handling.

The function properly handles both string and object inputs, validates base color requirements, and merges user-defined colors with generated scales. The error handling for missing base colors is appropriate and clear.

packages/clerk-js/src/ui/utils/colors/__tests__/constants.spec.ts (5)

1-32: Thorough COLOR_SCALE validation with proper structure testing.

The tests verify not only the correct values and order but also the immutability characteristics and length validation. This ensures the fundamental color scale is correctly defined.


34-68: Comprehensive shade grouping and lightness configuration tests.

The tests properly validate the relationship between light shades, dark shades, and the complete ALL_SHADES array. The lightness configuration validation ensures the mathematical constants are correct for scale generation.


70-108: Excellent alpha values validation with boundary checking.

The tests ensure alpha values are within valid ranges (0-1), properly ordered, and correspond to the correct number of shades. The percentage validation covers all shades and validates boundaries.


110-186: Comprehensive lightness mix data and relative steps validation.

The tests thoroughly validate the structure of lightness mixing data, ensuring proper mix colors (white/black/null) and the special case for the 500 shade. The relative shade steps validation ensures proper step progression for both light and dark shades.


188-237: Complete bounds and limits validation with reasonable value checking.

The tests validate all color bounds (RGB, alpha, hue, percentage) and modern CSS limits, ensuring the values are within reasonable ranges and have the expected structure. This provides confidence in the constraint values used throughout the color system.

packages/clerk-js/src/ui/utils/memoize.ts (1)

34-36: Add explicit return type annotation.

The function already has explicit void return type, which follows the coding guidelines.

packages/clerk-js/src/ui/utils/__tests__/memoize.spec.ts (6)

1-12: Excellent test setup with proper cleanup.

The test setup properly clears the cache before and after each test, preventing test interference. This is essential for testing stateful utilities like memoization.


14-60: Comprehensive basic memoization tests.

The tests thoroughly cover:

  • Basic memoization behavior
  • Different argument scenarios
  • Multiple argument handling

This provides good coverage of the core functionality.


62-91: Good coverage of custom key function feature.

The tests validate both custom key function usage and default JSON.stringify behavior. The object equality test (lines 79-90) is particularly valuable for testing the default serialization behavior.


93-126: Excellent cache management testing.

Tests properly verify cache size tracking and clearing functionality. The verification that functions are called again after cache clearing (lines 122-124) is crucial for ensuring cache integrity.


128-149: Good TypeScript type preservation testing.

Tests verify that the memoized function maintains the original function's type signature, which is important for type safety in TypeScript.


151-194: Comprehensive edge case coverage.

The tests cover important edge cases including:

  • Undefined/null arguments
  • Complex objects
  • Error handling

However, the error handling test (lines 175-193) reveals a potential issue: errors are not being cached, which means failing functions will be called repeatedly. This might be intentional but should be documented.

Let me verify the error handling behavior in the memoize implementation:

#!/bin/bash
# Description: Check if the memoize function has any error handling logic
# Expected: Should find error handling code or confirm errors aren't cached

rg -A 5 -B 5 "catch|throw|error" packages/clerk-js/src/ui/utils/memoize.ts
packages/clerk-js/src/ui/utils/colors/index.ts (2)

1-8: LGTM! Clean imports and setup.

The imports are well-organized and the feature detection setup is appropriate.


65-65: LGTM! Proper re-exports for testing and direct usage.

The named exports provide good flexibility for testing and direct access to specific implementations.

packages/clerk-js/src/ui/utils/colors/__tests__/modern.spec.ts (7)

1-23: LGTM! Excellent test setup and mocking strategy.

The mocking of cssSupports is properly configured, and the beforeEach setup ensures clean test state. The use of vi.mocked() provides good type safety.


25-65: LGTM! Comprehensive coverage of lighten function scenarios.

The tests properly cover:

  • Undefined input handling
  • Different CSS feature support combinations
  • Edge cases like zero percentage and high percentages
  • Correct CSS syntax generation

67-99: LGTM! Thorough testing of makeTransparent function.

Good coverage of transparency handling including boundary conditions and feature detection fallbacks.


101-128: LGTM! Complete makeSolid function testing.

Tests properly verify the behavior across different CSS feature support scenarios.


130-173: LGTM! Excellent setAlpha function testing with proper boundary handling.

The alpha clamping tests (lines 154-172) are particularly valuable for ensuring robust behavior.


175-217: LGTM! Comprehensive adjustForLightness testing.

Good coverage of default values, custom values, and percentage limiting.


219-231: LGTM! Important fallback behavior testing.

This section ensures graceful degradation when modern CSS features are unavailable, which is crucial for robustness.

packages/clerk-js/src/ui/utils/colors/__tests__/index.spec.ts (5)

3-41: LGTM! Excellent mocking strategy for testing delegation logic.

The comprehensive mocking of all dependencies (cssSupports, legacy, and modern modules) allows for precise testing of the delegation behavior without implementation details bleeding through.


48-62: LGTM! Proper testing of re-exported functionality.

Good verification that the expected functions and modules are properly re-exported.


64-113: LGTM! Thorough testing of core conversion functions.

The tests properly verify:

  • Undefined input handling
  • Modern CSS path (returning color string as-is)
  • Legacy fallback path with proper function calls
  • Type-specific behavior for toHslaString

115-133: LGTM! Correct testing of always-legacy functions.

Proper verification that changeHslaLightness and setHslaAlpha always use legacy implementations regardless of CSS support.


135-249: LGTM! Comprehensive testing of conditional delegation.

Excellent coverage of all high-level utilities (lighten, makeTransparent, makeSolid, setAlpha, adjustForLightness) with proper verification of:

  • Modern implementation usage when supported
  • Legacy fallback when not supported
  • Default parameter handling
  • Function call arguments and return values
packages/clerk-js/src/ui/utils/colors/__tests__/legacy.spec.ts (11)

1-4: LGTM! Clean test setup.

Proper imports and module structure for testing the legacy color utilities.


6-58: LGTM! Comprehensive RGB/RGBA color parsing tests.

Excellent coverage of:

  • Various hex formats (3, 4, 6, 8 digit)
  • RGB/RGBA with numeric and percentage values
  • Different color combinations (red, blue, green, yellow)

The precision handling for alpha values (line 15, 25) shows good attention to floating-point accuracy.


60-85: LGTM! Thorough HSL/HSLA parsing with edge case handling.

Good coverage of:

  • Basic HSL/HSLA formats
  • Degree unit handling
  • Hue value normalization (>360 and negative values)

The hue normalization tests (lines 76-84) are particularly important for robust color handling.


87-103: LGTM! Proper HWB color format support.

Good coverage of HWB color space including alpha channel and boundary conditions.


105-121: LGTM! Comprehensive CSS keyword color support.

Excellent coverage of named colors including the important transparent keyword and gray/grey equivalents.


123-134: LGTM! Proper error handling with helpful messages.

Good verification that invalid colors throw appropriate errors with useful error messages.


136-159: LGTM! Complete toHslaString function testing.

Proper testing of HSLA object to string conversion with undefined alpha handling.


161-193: LGTM! Thorough HSLA manipulation function testing.

Good coverage of changeHslaLightness and setHslaAlpha with property preservation verification.


195-303: LGTM! Comprehensive high-level utility function testing.

Excellent coverage of all utility functions (lighten, makeSolid, makeTransparent, setAlpha, adjustForLightness) with:

  • Undefined input handling
  • Various color format inputs
  • Edge cases and boundary conditions
  • Percentage handling and clamping

305-326: LGTM! Important edge case and error boundary testing.

Critical tests for:

  • RGB value clamping
  • Alpha value clamping
  • Whitespace and case sensitivity error handling

These tests ensure robust parsing behavior.


328-356: LGTM! Excellent complex color conversion testing.

Thorough verification of color conversions across different color types (grayscale, bright colors, dark colors) ensuring mathematical accuracy of the color space conversions.

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

♻️ Duplicate comments (1)
packages/clerk-js/src/ui/utils/colors/utils.ts (1)

142-154: Consider renaming to reflect multiple implementation strategies.

The function name getColorMix is misleading since it doesn't always return color-mix syntax - it can return relative color syntax or the original color based on CSS support.

Consider renaming to better reflect its purpose:

-export function getColorMix(color: string, shade: ColorShade): string {
+export function getOptimalColorVariant(color: string, shade: ColorShade): string {

This name better reflects that it chooses the optimal color implementation strategy based on browser capabilities.

🧹 Nitpick comments (1)
packages/clerk-js/src/ui/utils/colors/utils.ts (1)

68-81: Duplicate JSDoc comment between functions.

Both createColorMix and createAlphaColorMix have nearly identical JSDoc comments, which could be confusing.

Apply this diff to fix the JSDoc for createAlphaColorMix:

 /**
- * Create a color-mix string
- * @param color - The base color
- * @param mixColor - The color to mix with
- * @param percentage - The percentage of the mix
- * @returns The color-mix string
+ * Create an alpha color-mix string with transparency
+ * @param color - The base color
+ * @param alphaPercentage - The alpha percentage (0-100)
+ * @returns The alpha color-mix string
  */
📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 1ae5c97 and f200029.

📒 Files selected for processing (6)
  • packages/clerk-js/src/ui/customizables/parseVariables.ts (1 hunks)
  • packages/clerk-js/src/ui/foundations/colors.ts (5 hunks)
  • packages/clerk-js/src/ui/utils/colors/__tests__/scales.spec.ts (1 hunks)
  • packages/clerk-js/src/ui/utils/colors/__tests__/utils.spec.ts (1 hunks)
  • packages/clerk-js/src/ui/utils/colors/scales.ts (1 hunks)
  • packages/clerk-js/src/ui/utils/colors/utils.ts (1 hunks)
✅ Files skipped from review due to trivial changes (1)
  • packages/clerk-js/src/ui/utils/colors/tests/utils.spec.ts
🚧 Files skipped from review as they are similar to previous changes (3)
  • packages/clerk-js/src/ui/foundations/colors.ts
  • packages/clerk-js/src/ui/customizables/parseVariables.ts
  • packages/clerk-js/src/ui/utils/colors/tests/scales.spec.ts
🧰 Additional context used
📓 Path-based instructions (4)
`**/*.{js,ts,tsx,jsx}`: All code must pass ESLint checks with the project's configuration. Use Prettier for consistent code formatting.

**/*.{js,ts,tsx,jsx}: All code must pass ESLint checks with the project's configuration.
Use Prettier for consistent code formatting.

📄 Source: CodeRabbit Inference Engine (.cursor/rules/development.mdc)

List of files the instruction was applied to:

  • packages/clerk-js/src/ui/utils/colors/utils.ts
  • packages/clerk-js/src/ui/utils/colors/scales.ts
`**/*.{ts,tsx}`: Maintain comprehensive JSDoc comments for public APIs.

**/*.{ts,tsx}: Maintain comprehensive JSDoc comments for public APIs.

📄 Source: CodeRabbit Inference Engine (.cursor/rules/development.mdc)

List of files the instruction was applied to:

  • packages/clerk-js/src/ui/utils/colors/utils.ts
  • packages/clerk-js/src/ui/utils/colors/scales.ts
`packages/**`: All publishable packages under the @clerk namespace must be located in the packages/ directory.

packages/**: All publishable packages under the @clerk namespace must be located in the packages/ directory.

📄 Source: CodeRabbit Inference Engine (.cursor/rules/global.mdc)

List of files the instruction was applied to:

  • packages/clerk-js/src/ui/utils/colors/utils.ts
  • packages/clerk-js/src/ui/utils/colors/scales.ts
`**/*.ts`: Always define explicit return types for functions, especially public ...

**/*.ts: Always define explicit return types for functions, especially public APIs.
Use proper type annotations for variables and parameters where inference isn't clear.
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, protected for inheritance, and public explicitly for clarity in public APIs.
Prefer composition and interfaces over deep inheritance chains; use mixins for shared behavior.
Use ES6 imports/exports consistently; avoid barrel files (index.ts re-exports) to prevent circular dependencies.
Use type-only imports (import type { ... }) where possible.
Use as const for literal types and the satisfies operator for type checking without widening.
Enable --incremental and --tsBuildInfoFile for faster builds.
Use ESLint with @typescript-eslint/recommended rules and Prettier for formatting.
Use lint-staged and Husky for pre-commit checks.
Use type-coverage to measure type safety.

📄 Source: CodeRabbit Inference Engine (.cursor/rules/typescript.mdc)

List of files the instruction was applied to:

  • packages/clerk-js/src/ui/utils/colors/utils.ts
  • packages/clerk-js/src/ui/utils/colors/scales.ts
🧠 Learnings (3)
📓 Common learnings
Learnt from: dstaley
PR: clerk/javascript#6100
File: packages/clerk-js/src/ui/components/OAuthConsent/OAuthConsent.tsx:121-124
Timestamp: 2025-06-16T17:08:58.414Z
Learning: The @clerk/clerk-js package only supports browsers released in the last two years (since May 8, 2023), so modern CSS features like color-mix() are fully supported across all target browsers without requiring fallbacks.
Learnt from: dstaley
PR: clerk/javascript#6116
File: .changeset/tangy-garlics-say.md:1-2
Timestamp: 2025-06-13T16:09:53.061Z
Learning: In the Clerk JavaScript repository, contributors create intentionally empty changeset files (containing only the YAML delimiters) when a PR touches only non-published parts of the codebase (e.g., sandbox assets). This signals that no package release is required, so such changesets should not be flagged as missing content.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/monorepo.mdc:0-0
Timestamp: 2025-06-23T12:25:40.214Z
Learning: Environment variables prefixed with CLERK_* and NEXT_PUBLIC_CLERK_* are supported for configuration across different environments.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/monorepo.mdc:0-0
Timestamp: 2025-06-23T12:25:40.214Z
Learning: Framework packages depend on @clerk/clerk-js for core functionality, while @clerk/shared and @clerk/types provide common utilities and TypeScript definitions used across packages.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/monorepo.mdc:0-0
Timestamp: 2025-06-23T12:25:40.214Z
Learning: All packages are published under the @clerk namespace on npm, ensuring consistent naming and discoverability.
packages/clerk-js/src/ui/utils/colors/utils.ts (6)
Learnt from: dstaley
PR: clerk/javascript#6100
File: packages/clerk-js/src/ui/components/OAuthConsent/OAuthConsent.tsx:121-124
Timestamp: 2025-06-16T17:08:58.414Z
Learning: The @clerk/clerk-js package only supports browsers released in the last two years (since May 8, 2023), so modern CSS features like color-mix() are fully supported across all target browsers without requiring fallbacks.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/monorepo.mdc:0-0
Timestamp: 2025-06-23T12:25:40.214Z
Learning: Framework packages depend on @clerk/clerk-js for core functionality, while @clerk/shared and @clerk/types provide common utilities and TypeScript definitions used across packages.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/typescript.mdc:0-0
Timestamp: 2025-06-23T12:26:09.855Z
Learning: Prefer `unknown` over `any` for uncertain types, and use type guards to narrow types safely.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/typescript.mdc:0-0
Timestamp: 2025-06-23T12:26:09.855Z
Learning: Follow a type safety checklist: avoid `any` without justification, handle errors with typed errors, use `readonly` consistently, apply proper generic constraints, avoid unused type parameters, and use utility types instead of manual type construction.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/typescript.mdc:0-0
Timestamp: 2025-06-23T12:26:09.855Z
Learning: Use const assertions (`as const`) and the `satisfies` operator to maintain literal types and precise type checking.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/typescript.mdc:0-0
Timestamp: 2025-06-23T12:26:09.855Z
Learning: In TypeScript, always define explicit return types for functions, especially for public APIs, to ensure type safety and clarity.
packages/clerk-js/src/ui/utils/colors/scales.ts (1)
Learnt from: dstaley
PR: clerk/javascript#6100
File: packages/clerk-js/src/ui/components/OAuthConsent/OAuthConsent.tsx:121-124
Timestamp: 2025-06-16T17:08:58.414Z
Learning: The @clerk/clerk-js package only supports browsers released in the last two years (since May 8, 2023), so modern CSS features like color-mix() are fully supported across all target browsers without requiring fallbacks.
⏰ Context from checks skipped due to timeout of 90000ms (5)
  • GitHub Check: semgrep-cloud-platform/scan
  • GitHub Check: Build Packages
  • GitHub Check: Formatting | Dedupe | Changeset
  • GitHub Check: semgrep/ci
  • GitHub Check: Analyze (javascript-typescript)
🔇 Additional comments (15)
packages/clerk-js/src/ui/utils/colors/utils.ts (5)

1-6: LGTM - Clean imports and type safety.

The imports are well-structured with proper type-only imports and clear dependency organization.


8-26: Excellent optimization with frozen empty scale.

The pre-computed frozen object pattern combined with spread operator cloning is an efficient approach for avoiding repeated object creation while ensuring immutability.


28-57: Well-implemented memoization with clear cache keys.

The memoized generators use descriptive cache key functions and follow consistent patterns. This will provide significant performance benefits for repeated color generations.


89-114: Robust relative color syntax generation with proper fallbacks.

The function correctly handles the base case (shade 500) and properly calculates lightness adjustments using the predefined configuration. The mathematical expressions for light and dark shade calculations are accurate.


122-134: Clean implementation with consistent patterns.

Both functions follow the same pattern of checking for the base shade and using the configuration data appropriately.

packages/clerk-js/src/ui/utils/colors/scales.ts (10)

1-6: Clean imports with proper type organization.

The imports are well-structured, separating types from implementation details and clearly showing dependencies.


8-12: Well-designed type definitions for internal use.

The InternalColorScale and WithPrefix types provide clear abstractions for the themed scale functionality.


20-33: Type-safe implementation addresses previous concerns.

The function correctly implements type-safe prefix application without using any type assertions, addressing the previous review comment about type safety.


35-63: Solid modern and legacy alpha scale implementations.

Both functions follow consistent patterns and properly handle the alpha value calculations. The modern version leverages the memoized generators while the legacy version directly manipulates HSLA values.


65-107: Comprehensive lightness scale generation with proper mathematical calculations.

The legacy implementation correctly calculates lightness steps and applies them in the right direction (lighter for shades < 500, darker for shades > 500). The modern version properly delegates to the memoized utilities.


112-139: Robust input processing and merging logic.

The processColorInput function handles all input types correctly with proper type guards, and mergeWithUserScale provides a clean way to combine generated and user-provided scales.


146-187: Excellent unified API with automatic capability detection.

Both generateAlphaScale and generateLightnessScale provide clean abstractions that automatically choose the best implementation based on CSS support, with proper fallbacks for invalid inputs.


189-203: Good separation of concerns with direct access to implementations.

Providing direct access to modern and legacy implementations is valuable for testing and scenarios where CSS support is guaranteed.


209-232: Clean CSS conversion and prefixing utilities.

The functions properly handle the conversion between internal representations and CSS-ready values while maintaining type safety.


241-276: Well-designed themed scale conversion functions.

Both colorOptionToThemedAlphaScale and colorOptionToThemedLightnessScale provide clean APIs for converting color inputs to themed, prefixed scales. The functions handle undefined inputs gracefully and maintain proper type safety.

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

🧹 Nitpick comments (3)
packages/clerk-js/src/ui/utils/colors/utils.ts (3)

52-60: Consider parameter validation for better robustness.

The function handles optional alpha parameter well, but consider adding basic validation for the color parameter format.

function createRelativeColorString(
  color: string,
  hue: string,
  saturation: string,
  lightness: string,
  alpha?: string,
): string {
+  if (!color) {
+    throw new Error('Color parameter is required');
+  }
  return `hsl(from ${color} ${hue} ${saturation} ${lightness}${alpha ? ` / ${alpha}` : ''})`;
}

108-117: Fix misleading JSDoc comment.

The JSDoc comment for createAlphaColorMix incorrectly describes it as creating a general "color-mix string" when it specifically creates an alpha color-mix string.

/**
- * Create a color-mix string
+ * Create an alpha color-mix string
  * @param color - The base color
- * @param mixColor - The color to mix with
- * @param percentage - The percentage of the mix
+ * @param alphaPercentage - The alpha percentage
  * @returns The color-mix string
  */
export function createAlphaColorMix(color: string, alphaPercentage: number): string {
  return colorGenerators.alphaColorMix(color, alphaPercentage);
}

158-165: Verify mix data structure and error handling.

The function assumes mixData.mixColor exists but could benefit from more defensive programming.

export function generateColorMixSyntax(color: string, shade: ColorShade): string {
  if (shade === 500) return color;

  const mixData = LIGHTNESS_MIX_DATA[shade];
-  if (!mixData.mixColor) return color;
+  if (!mixData || !mixData.mixColor) return color;

  return createColorMix(color, mixData.mixColor, mixData.percentage);
}
📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 065445c and d21c353.

📒 Files selected for processing (3)
  • packages/clerk-js/src/ui/utils/colors/__tests__/utils.spec.ts (1 hunks)
  • packages/clerk-js/src/ui/utils/colors/scales.ts (1 hunks)
  • packages/clerk-js/src/ui/utils/colors/utils.ts (1 hunks)
🚧 Files skipped from review as they are similar to previous changes (2)
  • packages/clerk-js/src/ui/utils/colors/scales.ts
  • packages/clerk-js/src/ui/utils/colors/tests/utils.spec.ts
🧰 Additional context used
📓 Path-based instructions (4)
`**/*.{js,ts,tsx,jsx}`: All code must pass ESLint checks with the project's configuration. Use Prettier for consistent code formatting.

**/*.{js,ts,tsx,jsx}: All code must pass ESLint checks with the project's configuration.
Use Prettier for consistent code formatting.

📄 Source: CodeRabbit Inference Engine (.cursor/rules/development.mdc)

List of files the instruction was applied to:

  • packages/clerk-js/src/ui/utils/colors/utils.ts
`**/*.{ts,tsx}`: Maintain comprehensive JSDoc comments for public APIs.

**/*.{ts,tsx}: Maintain comprehensive JSDoc comments for public APIs.

📄 Source: CodeRabbit Inference Engine (.cursor/rules/development.mdc)

List of files the instruction was applied to:

  • packages/clerk-js/src/ui/utils/colors/utils.ts
`packages/**`: All publishable packages under the @clerk namespace must be located in the packages/ directory.

packages/**: All publishable packages under the @clerk namespace must be located in the packages/ directory.

📄 Source: CodeRabbit Inference Engine (.cursor/rules/global.mdc)

List of files the instruction was applied to:

  • packages/clerk-js/src/ui/utils/colors/utils.ts
`**/*.ts`: Always define explicit return types for functions, especially public ...

**/*.ts: Always define explicit return types for functions, especially public APIs.
Use proper type annotations for variables and parameters where inference isn't clear.
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, protected for inheritance, and public explicitly for clarity in public APIs.
Prefer composition and interfaces over deep inheritance chains; use mixins for shared behavior.
Use ES6 imports/exports consistently; avoid barrel files (index.ts re-exports) to prevent circular dependencies.
Use type-only imports (import type { ... }) where possible.
Use as const for literal types and the satisfies operator for type checking without widening.
Enable --incremental and --tsBuildInfoFile for faster builds.
Use ESLint with @typescript-eslint/recommended rules and Prettier for formatting.
Use lint-staged and Husky for pre-commit checks.
Use type-coverage to measure type safety.

📄 Source: CodeRabbit Inference Engine (.cursor/rules/typescript.mdc)

List of files the instruction was applied to:

  • packages/clerk-js/src/ui/utils/colors/utils.ts
🧠 Learnings (2)
📓 Common learnings
Learnt from: dstaley
PR: clerk/javascript#6100
File: packages/clerk-js/src/ui/components/OAuthConsent/OAuthConsent.tsx:121-124
Timestamp: 2025-06-16T17:08:58.414Z
Learning: The @clerk/clerk-js package only supports browsers released in the last two years (since May 8, 2023), so modern CSS features like color-mix() are fully supported across all target browsers without requiring fallbacks.
Learnt from: dstaley
PR: clerk/javascript#6116
File: .changeset/tangy-garlics-say.md:1-2
Timestamp: 2025-06-13T16:09:53.061Z
Learning: In the Clerk JavaScript repository, contributors create intentionally empty changeset files (containing only the YAML delimiters) when a PR touches only non-published parts of the codebase (e.g., sandbox assets). This signals that no package release is required, so such changesets should not be flagged as missing content.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/monorepo.mdc:0-0
Timestamp: 2025-06-23T12:25:40.214Z
Learning: Environment variables prefixed with CLERK_* and NEXT_PUBLIC_CLERK_* are supported for configuration across different environments.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/monorepo.mdc:0-0
Timestamp: 2025-06-23T12:25:40.214Z
Learning: Framework packages depend on @clerk/clerk-js for core functionality, while @clerk/shared and @clerk/types provide common utilities and TypeScript definitions used across packages.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/monorepo.mdc:0-0
Timestamp: 2025-06-23T12:25:40.214Z
Learning: All packages are published under the @clerk namespace on npm, ensuring consistent naming and discoverability.
packages/clerk-js/src/ui/utils/colors/utils.ts (6)
Learnt from: dstaley
PR: clerk/javascript#6100
File: packages/clerk-js/src/ui/components/OAuthConsent/OAuthConsent.tsx:121-124
Timestamp: 2025-06-16T17:08:58.414Z
Learning: The @clerk/clerk-js package only supports browsers released in the last two years (since May 8, 2023), so modern CSS features like color-mix() are fully supported across all target browsers without requiring fallbacks.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/monorepo.mdc:0-0
Timestamp: 2025-06-23T12:25:40.214Z
Learning: Framework packages depend on @clerk/clerk-js for core functionality, while @clerk/shared and @clerk/types provide common utilities and TypeScript definitions used across packages.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/typescript.mdc:0-0
Timestamp: 2025-06-23T12:26:09.855Z
Learning: Prefer `unknown` over `any` for uncertain types, and use type guards to narrow types safely.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/typescript.mdc:0-0
Timestamp: 2025-06-23T12:26:09.855Z
Learning: Follow a type safety checklist: avoid `any` without justification, handle errors with typed errors, use `readonly` consistently, apply proper generic constraints, avoid unused type parameters, and use utility types instead of manual type construction.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/typescript.mdc:0-0
Timestamp: 2025-06-23T12:26:09.855Z
Learning: Use const assertions (`as const`) and the `satisfies` operator to maintain literal types and precise type checking.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/typescript.mdc:0-0
Timestamp: 2025-06-23T12:26:09.855Z
Learning: In TypeScript, always define explicit return types for functions, especially for public APIs, to ensure type safety and clarity.
⏰ Context from checks skipped due to timeout of 90000ms (5)
  • GitHub Check: semgrep-cloud-platform/scan
  • GitHub Check: Build Packages
  • GitHub Check: Formatting | Dedupe | Changeset
  • GitHub Check: semgrep/ci
  • GitHub Check: Analyze (javascript-typescript)
🔇 Additional comments (6)
packages/clerk-js/src/ui/utils/colors/utils.ts (6)

1-7: LGTM! Clean imports following TypeScript best practices.

The imports are well-organized with proper type-only imports and clear dependency structure.


8-26: Excellent performance optimization with pre-computed frozen object.

The approach of creating a pre-computed frozen empty color scale and providing a factory function is a smart optimization that avoids repeated object creation while maintaining immutability.


39-41: Add explicit return type for better type safety.

Following the TypeScript coding guidelines for explicit return types on public APIs.

-function createColorMixString(baseColor: string, mixColor: string, percentage: number): string {
+function createColorMixString(baseColor: string, mixColor: string, percentage: number): string {

Wait, the return type is already explicit. This function looks good as-is.


75-93: Excellent use of memoization for performance optimization.

The memoized generators with well-designed cache keys will significantly improve performance for repeated color calculations. The cache key strategy effectively captures all parameters.


125-150: Well-implemented relative color syntax generation with proper fallbacks.

The function correctly handles the base case (shade 500) and implements proper lightness calculations for both light and dark shades using the configuration constants.


178-190: Excellent progressive enhancement with CSS feature detection.

The function properly implements a cascade of modern CSS features with appropriate fallbacks, leveraging the known browser support for modern CSS features in the target environment.

Based on the retrieved learning, since @clerk/clerk-js only supports browsers from the last two years, modern CSS features like color-mix() and relative color syntax are fully supported, making this progressive enhancement approach ideal for graceful degradation in edge cases.

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 (2)
packages/clerk-js/src/ui/utils/colors/utils.ts (2)

7-18: Verify if this duplicates existing functionality.

Based on past review comments, there may already be a similar frozen empty color scale in a cache file. Please confirm this isn't duplicating existing functionality.

#!/bin/bash
# Search for existing empty color scale implementations
rg -A 5 -B 5 "EMPTY_COLOR_SCALE|createEmptyColorScale|Object\.freeze.*ColorScale"

125-137: Address function naming confusion.

Based on past review comments, there's confusion about using getSupportedColorVariant when it sometimes returns relative color syntax. Consider renaming for clarity or adding documentation to explain the naming choice.

The function correctly implements feature detection and fallback logic. Consider renaming to getOptimalColorVariant or adding JSDoc to clarify why "supported" is used when it may return different syntax types.

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between d21c353 and 441a41c.

📒 Files selected for processing (3)
  • packages/clerk-js/src/ui/utils/colors/__tests__/utils.spec.ts (1 hunks)
  • packages/clerk-js/src/ui/utils/colors/modern.ts (1 hunks)
  • packages/clerk-js/src/ui/utils/colors/utils.ts (1 hunks)
✅ Files skipped from review due to trivial changes (2)
  • packages/clerk-js/src/ui/utils/colors/modern.ts
  • packages/clerk-js/src/ui/utils/colors/tests/utils.spec.ts
🧰 Additional context used
📓 Path-based instructions (4)
`**/*.{js,ts,tsx,jsx}`: All code must pass ESLint checks with the project's configuration. Use Prettier for consistent code formatting.

**/*.{js,ts,tsx,jsx}: All code must pass ESLint checks with the project's configuration.
Use Prettier for consistent code formatting.

📄 Source: CodeRabbit Inference Engine (.cursor/rules/development.mdc)

List of files the instruction was applied to:

  • packages/clerk-js/src/ui/utils/colors/utils.ts
`**/*.{ts,tsx}`: Maintain comprehensive JSDoc comments for public APIs.

**/*.{ts,tsx}: Maintain comprehensive JSDoc comments for public APIs.

📄 Source: CodeRabbit Inference Engine (.cursor/rules/development.mdc)

List of files the instruction was applied to:

  • packages/clerk-js/src/ui/utils/colors/utils.ts
`packages/**`: All publishable packages under the @clerk namespace must be located in the packages/ directory.

packages/**: All publishable packages under the @clerk namespace must be located in the packages/ directory.

📄 Source: CodeRabbit Inference Engine (.cursor/rules/global.mdc)

List of files the instruction was applied to:

  • packages/clerk-js/src/ui/utils/colors/utils.ts
`**/*.ts`: Always define explicit return types for functions, especially public ...

**/*.ts: Always define explicit return types for functions, especially public APIs.
Use proper type annotations for variables and parameters where inference isn't clear.
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, protected for inheritance, and public explicitly for clarity in public APIs.
Prefer composition and interfaces over deep inheritance chains; use mixins for shared behavior.
Use ES6 imports/exports consistently; avoid barrel files (index.ts re-exports) to prevent circular dependencies.
Use type-only imports (import type { ... }) where possible.
Use as const for literal types and the satisfies operator for type checking without widening.
Enable --incremental and --tsBuildInfoFile for faster builds.
Use ESLint with @typescript-eslint/recommended rules and Prettier for formatting.
Use lint-staged and Husky for pre-commit checks.
Use type-coverage to measure type safety.

📄 Source: CodeRabbit Inference Engine (.cursor/rules/typescript.mdc)

List of files the instruction was applied to:

  • packages/clerk-js/src/ui/utils/colors/utils.ts
🧠 Learnings (2)
📓 Common learnings
Learnt from: dstaley
PR: clerk/javascript#6100
File: packages/clerk-js/src/ui/components/OAuthConsent/OAuthConsent.tsx:121-124
Timestamp: 2025-06-16T17:08:58.414Z
Learning: The @clerk/clerk-js package only supports browsers released in the last two years (since May 8, 2023), so modern CSS features like color-mix() are fully supported across all target browsers without requiring fallbacks.
Learnt from: dstaley
PR: clerk/javascript#6116
File: .changeset/tangy-garlics-say.md:1-2
Timestamp: 2025-06-13T16:09:53.061Z
Learning: In the Clerk JavaScript repository, contributors create intentionally empty changeset files (containing only the YAML delimiters) when a PR touches only non-published parts of the codebase (e.g., sandbox assets). This signals that no package release is required, so such changesets should not be flagged as missing content.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/monorepo.mdc:0-0
Timestamp: 2025-06-23T12:25:40.214Z
Learning: Environment variables prefixed with CLERK_* and NEXT_PUBLIC_CLERK_* are supported for configuration across different environments.
packages/clerk-js/src/ui/utils/colors/utils.ts (6)
Learnt from: dstaley
PR: clerk/javascript#6100
File: packages/clerk-js/src/ui/components/OAuthConsent/OAuthConsent.tsx:121-124
Timestamp: 2025-06-16T17:08:58.414Z
Learning: The @clerk/clerk-js package only supports browsers released in the last two years (since May 8, 2023), so modern CSS features like color-mix() are fully supported across all target browsers without requiring fallbacks.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/monorepo.mdc:0-0
Timestamp: 2025-06-23T12:25:40.214Z
Learning: Framework packages depend on @clerk/clerk-js for core functionality, while @clerk/shared and @clerk/types provide common utilities and TypeScript definitions used across packages.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/typescript.mdc:0-0
Timestamp: 2025-06-23T12:26:09.855Z
Learning: Prefer `unknown` over `any` for uncertain types, and use type guards to narrow types safely.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/typescript.mdc:0-0
Timestamp: 2025-06-23T12:26:09.855Z
Learning: Follow a type safety checklist: avoid `any` without justification, handle errors with typed errors, use `readonly` consistently, apply proper generic constraints, avoid unused type parameters, and use utility types instead of manual type construction.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/typescript.mdc:0-0
Timestamp: 2025-06-23T12:26:09.855Z
Learning: Use const assertions (`as const`) and the `satisfies` operator to maintain literal types and precise type checking.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/typescript.mdc:0-0
Timestamp: 2025-06-23T12:26:09.855Z
Learning: In TypeScript, always define explicit return types for functions, especially for public APIs, to ensure type safety and clarity.
🧬 Code Graph Analysis (1)
packages/clerk-js/src/ui/utils/colors/utils.ts (3)
packages/types/src/appearance.ts (1)
  • ColorScale (45-45)
packages/clerk-js/src/ui/utils/colors/constants.ts (6)
  • ALL_SHADES (19-19)
  • ColorShade (8-8)
  • RELATIVE_SHADE_STEPS (71-88)
  • LIGHTNESS_CONFIG (22-27)
  • LIGHTNESS_MIX_DATA (52-68)
  • ALPHA_PERCENTAGES (33-49)
packages/clerk-js/src/ui/utils/cssSupports.ts (1)
  • cssSupports (65-81)
⏰ Context from checks skipped due to timeout of 90000ms (5)
  • GitHub Check: semgrep-cloud-platform/scan
  • GitHub Check: Build Packages
  • GitHub Check: Formatting | Dedupe | Changeset
  • GitHub Check: semgrep/ci
  • GitHub Check: Analyze (javascript-typescript)
🔇 Additional comments (7)
packages/clerk-js/src/ui/utils/colors/utils.ts (7)

1-6: Import structure looks good.

The imports are well-organized with proper type imports and clear dependencies on constants and CSS support utilities.


51-59: Function implementation is correct.

The relative color string generation properly handles optional alpha parameter and uses modern HSL syntax.


67-69: Function implementation is correct.

The alpha color mix generation correctly uses the color-mix syntax with transparency.


105-112: Function implementation is correct.

The color-mix syntax generation properly handles the base color (shade 500) case and uses the mix data from constants.


77-97: Complex calculation logic needs verification.

The relative color syntax generation uses complex mathematical calculations for lightness adjustments. Verify the calculations are correct, especially the calc() expressions.

#!/bin/bash
# Search for tests that validate these calculations
rg -A 10 -B 5 "generateRelativeColorSyntax.*test|test.*generateRelativeColorSyntax"

20-25: Add explicit return type annotation.

The function lacks an explicit return type, which is required by the coding guidelines for public APIs.

-export const createEmptyColorScale = (): ColorScale<string | undefined> => {
+export const createEmptyColorScale = (): ColorScale<string | undefined> => {

Wait, this already has the return type. Let me check if this is already correct...

Actually, this function already has the correct explicit return type. The implementation looks good.

⛔ Skipped due to learnings
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/typescript.mdc:0-0
Timestamp: 2025-06-23T12:26:09.855Z
Learning: In TypeScript, always define explicit return types for functions, especially for public APIs, to ensure type safety and clarity.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/typescript.mdc:0-0
Timestamp: 2025-06-23T12:26:09.855Z
Learning: Let TypeScript infer types when obvious, but use explicit annotations when inference is unclear or for public APIs.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/typescript.mdc:0-0
Timestamp: 2025-06-23T12:26:09.855Z
Learning: Follow a type safety checklist: avoid `any` without justification, handle errors with typed errors, use `readonly` consistently, apply proper generic constraints, avoid unused type parameters, and use utility types instead of manual type construction.

31-40: Add explicit return type annotation.

The function lacks an explicit return type annotation, which is required by coding guidelines for public APIs.

-export function createColorMixString(baseColor: string, mixColor: string, percentage: number): string {
+export function createColorMixString(baseColor: string, mixColor: string, percentage: number): string {

Actually, this function already has the return type annotation. The implementation is correct.

⛔ Skipped due to learnings
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/typescript.mdc:0-0
Timestamp: 2025-06-23T12:26:09.855Z
Learning: In TypeScript, always define explicit return types for functions, especially for public APIs, to ensure type safety and clarity.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/typescript.mdc:0-0
Timestamp: 2025-06-23T12:26:09.855Z
Learning: Let TypeScript infer types when obvious, but use explicit annotations when inference is unclear or for public APIs.

Comment on lines +114 to +117
export function generateAlphaColorMix(color: string, shade: ColorShade): string {
const alphaPercentage = ALPHA_PERCENTAGES[shade];
return createAlphaColorMixString(color, alphaPercentage);
}
Copy link
Contributor

Choose a reason for hiding this comment

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

🛠️ Refactor suggestion

Add explicit return type and JSDoc.

The function lacks JSDoc documentation and explicit return type annotation.

+/**
+ * Generate an alpha color-mix string for the given shade
+ * @param color - The base color
+ * @param shade - The shade to generate the alpha variant for
+ * @returns The alpha color-mix string
+ */
-export function generateAlphaColorMix(color: string, shade: ColorShade): string {
+export function generateAlphaColorMix(color: string, shade: ColorShade): string {

Actually, the return type is already present. Just add the JSDoc:

+/**
+ * Generate an alpha color-mix string for the given shade
+ * @param color - The base color
+ * @param shade - The shade to generate the alpha variant for
+ * @returns The alpha color-mix string
+ */
 export function generateAlphaColorMix(color: string, shade: ColorShade): string {
📝 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
export function generateAlphaColorMix(color: string, shade: ColorShade): string {
const alphaPercentage = ALPHA_PERCENTAGES[shade];
return createAlphaColorMixString(color, alphaPercentage);
}
/**
* Generate an alpha color-mix string for the given shade
* @param color - The base color
* @param shade - The shade to generate the alpha variant for
* @returns The alpha color-mix string
*/
export function generateAlphaColorMix(color: string, shade: ColorShade): string {
const alphaPercentage = ALPHA_PERCENTAGES[shade];
return createAlphaColorMixString(color, alphaPercentage);
}
🤖 Prompt for AI Agents
In packages/clerk-js/src/ui/utils/colors/utils.ts around lines 114 to 117, the
function generateAlphaColorMix is missing JSDoc comments. Add a JSDoc block
above the function describing its purpose, parameters, and return value, while
keeping the existing explicit return type annotation unchanged.

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

♻️ Duplicate comments (2)
packages/clerk-js/src/ui/utils/colors/modern.ts (1)

75-90: Fix inconsistent return type to match other methods.

The setAlpha method returns string while other methods in this module return string | undefined. This inconsistency could lead to type errors when using these methods interchangeably.

Apply this fix to maintain consistency:

-  setAlpha: (color: string, alpha: number): string => {
+  setAlpha: (color: string | undefined, alpha: number): string | undefined => {
+    if (!color) return undefined;
     const clampedAlpha = Math.min(Math.max(alpha, COLOR_BOUNDS.alpha.min), COLOR_BOUNDS.alpha.max);
packages/clerk-js/src/ui/utils/colors/utils.ts (1)

114-117: Add comprehensive JSDoc documentation.

The function lacks JSDoc documentation which is required for public APIs according to the coding guidelines.

Add JSDoc documentation:

+/**
+ * Generate an alpha color-mix string for the given shade
+ * @param color - The base color
+ * @param shade - The shade to generate the alpha variant for
+ * @returns The alpha color-mix string
+ */
 export function generateAlphaColorMix(color: string, shade: ColorShade): string {
🧹 Nitpick comments (4)
packages/clerk-js/src/ui/utils/colors/modern.ts (1)

75-76: Add input validation for empty color strings.

The method should handle empty color strings consistently with other methods in this module.

Add validation for empty color strings:

   setAlpha: (color: string | undefined, alpha: number): string | undefined => {
+    if (!color || color.toString() === '') return undefined;
     const clampedAlpha = Math.min(Math.max(alpha, COLOR_BOUNDS.alpha.min), COLOR_BOUNDS.alpha.max);
packages/clerk-js/src/ui/utils/colors/scales.ts (3)

47-47: Consider removing unnecessary type assertion.

The type assertion as ColorScale<string> may be unnecessary since createEmptyColorScale() returns the correct type and all assignments maintain string values.

The type assertion might be redundant:

-  return scale as ColorScale<string>;
+  return scale;

Verify this change doesn't break type checking before applying.


64-64: Apply consistent type assertion pattern.

Similar to the previous comment, this type assertion pattern should be consistent across all scale generation functions.

Consider removing if the types align correctly:

-  return scale as ColorScale<string>;
+  return scale;

232-233: Simplify complex type assertion.

The chained type assertions make the code harder to understand and could hide type safety issues.

Consider breaking this into steps for clarity:

 function prefixAndConvertScale<Prefix extends string>(
   scale: ColorScale<string>,
   prefix: Prefix,
 ): WithPrefix<InternalColorScale<HslaColorString>, Prefix> {
   const cssScale = convertScaleToCssStrings(scale);
-  return applyScalePrefix(cssScale, prefix) as unknown as WithPrefix<InternalColorScale<HslaColorString>, Prefix>;
+  const prefixedScale = applyScalePrefix(cssScale, prefix);
+  return prefixedScale as WithPrefix<InternalColorScale<HslaColorString>, Prefix>;
 }
📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 2a0bdd2 and 0a6be7f.

📒 Files selected for processing (3)
  • packages/clerk-js/src/ui/utils/colors/modern.ts (1 hunks)
  • packages/clerk-js/src/ui/utils/colors/scales.ts (1 hunks)
  • packages/clerk-js/src/ui/utils/colors/utils.ts (1 hunks)
🧰 Additional context used
📓 Path-based instructions (4)
`**/*.{js,ts,tsx,jsx}`: All code must pass ESLint checks with the project's configuration. Use Prettier for consistent code formatting.

**/*.{js,ts,tsx,jsx}: All code must pass ESLint checks with the project's configuration.
Use Prettier for consistent code formatting.

📄 Source: CodeRabbit Inference Engine (.cursor/rules/development.mdc)

List of files the instruction was applied to:

  • packages/clerk-js/src/ui/utils/colors/utils.ts
  • packages/clerk-js/src/ui/utils/colors/modern.ts
  • packages/clerk-js/src/ui/utils/colors/scales.ts
`**/*.{ts,tsx}`: Maintain comprehensive JSDoc comments for public APIs.

**/*.{ts,tsx}: Maintain comprehensive JSDoc comments for public APIs.

📄 Source: CodeRabbit Inference Engine (.cursor/rules/development.mdc)

List of files the instruction was applied to:

  • packages/clerk-js/src/ui/utils/colors/utils.ts
  • packages/clerk-js/src/ui/utils/colors/modern.ts
  • packages/clerk-js/src/ui/utils/colors/scales.ts
`packages/**`: All publishable packages under the @clerk namespace must be located in the packages/ directory.

packages/**: All publishable packages under the @clerk namespace must be located in the packages/ directory.

📄 Source: CodeRabbit Inference Engine (.cursor/rules/global.mdc)

List of files the instruction was applied to:

  • packages/clerk-js/src/ui/utils/colors/utils.ts
  • packages/clerk-js/src/ui/utils/colors/modern.ts
  • packages/clerk-js/src/ui/utils/colors/scales.ts
`**/*.ts`: Always define explicit return types for functions, especially public ...

**/*.ts: Always define explicit return types for functions, especially public APIs.
Use proper type annotations for variables and parameters where inference isn't clear.
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, protected for inheritance, and public explicitly for clarity in public APIs.
Prefer composition and interfaces over deep inheritance chains; use mixins for shared behavior.
Use ES6 imports/exports consistently; avoid barrel files (index.ts re-exports) to prevent circular dependencies.
Use type-only imports (import type { ... }) where possible.
Use as const for literal types and the satisfies operator for type checking without widening.
Enable --incremental and --tsBuildInfoFile for faster builds.
Use ESLint with @typescript-eslint/recommended rules and Prettier for formatting.
Use lint-staged and Husky for pre-commit checks.
Use type-coverage to measure type safety.

📄 Source: CodeRabbit Inference Engine (.cursor/rules/typescript.mdc)

List of files the instruction was applied to:

  • packages/clerk-js/src/ui/utils/colors/utils.ts
  • packages/clerk-js/src/ui/utils/colors/modern.ts
  • packages/clerk-js/src/ui/utils/colors/scales.ts
🧠 Learnings (4)
📓 Common learnings
Learnt from: dstaley
PR: clerk/javascript#6100
File: packages/clerk-js/src/ui/components/OAuthConsent/OAuthConsent.tsx:121-124
Timestamp: 2025-06-16T17:08:58.414Z
Learning: The @clerk/clerk-js package only supports browsers released in the last two years (since May 8, 2023), so modern CSS features like color-mix() are fully supported across all target browsers without requiring fallbacks.
Learnt from: dstaley
PR: clerk/javascript#6116
File: .changeset/tangy-garlics-say.md:1-2
Timestamp: 2025-06-13T16:09:53.061Z
Learning: In the Clerk JavaScript repository, contributors create intentionally empty changeset files (containing only the YAML delimiters) when a PR touches only non-published parts of the codebase (e.g., sandbox assets). This signals that no package release is required, so such changesets should not be flagged as missing content.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/monorepo.mdc:0-0
Timestamp: 2025-06-23T12:25:40.214Z
Learning: Environment variables prefixed with CLERK_* and NEXT_PUBLIC_CLERK_* are supported for configuration across different environments.
packages/clerk-js/src/ui/utils/colors/utils.ts (7)
Learnt from: dstaley
PR: clerk/javascript#6100
File: packages/clerk-js/src/ui/components/OAuthConsent/OAuthConsent.tsx:121-124
Timestamp: 2025-06-16T17:08:58.414Z
Learning: The @clerk/clerk-js package only supports browsers released in the last two years (since May 8, 2023), so modern CSS features like color-mix() are fully supported across all target browsers without requiring fallbacks.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/monorepo.mdc:0-0
Timestamp: 2025-06-23T12:25:40.214Z
Learning: Framework packages depend on @clerk/clerk-js for core functionality, while @clerk/shared and @clerk/types provide common utilities and TypeScript definitions used across packages.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/typescript.mdc:0-0
Timestamp: 2025-06-23T12:26:09.855Z
Learning: Prefer `unknown` over `any` for uncertain types, and use type guards to narrow types safely.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/typescript.mdc:0-0
Timestamp: 2025-06-23T12:26:09.855Z
Learning: Follow a type safety checklist: avoid `any` without justification, handle errors with typed errors, use `readonly` consistently, apply proper generic constraints, avoid unused type parameters, and use utility types instead of manual type construction.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/typescript.mdc:0-0
Timestamp: 2025-06-23T12:26:09.855Z
Learning: Use const assertions (`as const`) and the `satisfies` operator to maintain literal types and precise type checking.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/typescript.mdc:0-0
Timestamp: 2025-06-23T12:26:09.855Z
Learning: In TypeScript, always define explicit return types for functions, especially for public APIs, to ensure type safety and clarity.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/development.mdc:0-0
Timestamp: 2025-06-23T12:25:30.457Z
Learning: Maintain comprehensive JSDoc comments for all public APIs to improve documentation and developer experience.
packages/clerk-js/src/ui/utils/colors/modern.ts (12)
Learnt from: dstaley
PR: clerk/javascript#6100
File: packages/clerk-js/src/ui/components/OAuthConsent/OAuthConsent.tsx:121-124
Timestamp: 2025-06-16T17:08:58.414Z
Learning: The @clerk/clerk-js package only supports browsers released in the last two years (since May 8, 2023), so modern CSS features like color-mix() are fully supported across all target browsers without requiring fallbacks.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/typescript.mdc:0-0
Timestamp: 2025-06-23T12:26:09.855Z
Learning: Use ES6 module syntax (import/export) consistently for maintainability and compatibility.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/typescript.mdc:0-0
Timestamp: 2025-06-23T12:26:09.855Z
Learning: Leverage modern TypeScript features such as generics, utility types (Omit, Partial, Pick), mapped types, conditional types, and template literal types for expressive and type-safe code.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/monorepo.mdc:0-0
Timestamp: 2025-06-23T12:25:40.214Z
Learning: Framework packages depend on @clerk/clerk-js for core functionality, while @clerk/shared and @clerk/types provide common utilities and TypeScript definitions used across packages.
Learnt from: jacekradko
PR: clerk/javascript#5905
File: .changeset/six-ears-wash.md:1-3
Timestamp: 2025-06-26T03:27:05.511Z
Learning: In the Clerk JavaScript repository, changeset headers support single quotes syntax (e.g., '@clerk/backend': minor) and work fine with their current changesets integration, so there's no need to change them to double quotes.
Learnt from: dstaley
PR: clerk/javascript#6116
File: .changeset/tangy-garlics-say.md:1-2
Timestamp: 2025-06-13T16:09:53.061Z
Learning: In the Clerk JavaScript repository, contributors create intentionally empty changeset files (containing only the YAML delimiters) when a PR touches only non-published parts of the codebase (e.g., sandbox assets). This signals that no package release is required, so such changesets should not be flagged as missing content.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/monorepo.mdc:0-0
Timestamp: 2025-06-23T12:25:40.214Z
Learning: All packages are published under the @clerk namespace on npm, ensuring consistent naming and discoverability.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/monorepo.mdc:0-0
Timestamp: 2025-06-23T12:25:40.214Z
Learning: Backend utilities are isolated in @clerk/backend, which is independent and used for server-side operations.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/global.mdc:0-0
Timestamp: 2025-06-23T12:25:34.662Z
Learning: All packages published from this repository must use the @clerk namespace.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/monorepo.mdc:0-0
Timestamp: 2025-06-23T12:25:40.214Z
Learning: Environment variables prefixed with CLERK_* and NEXT_PUBLIC_CLERK_* are supported for configuration across different environments.
Learnt from: panteliselef
PR: clerk/javascript#6097
File: packages/clerk-js/src/ui/elements/LineItems.tsx:89-89
Timestamp: 2025-06-10T09:38:56.214Z
Learning: In packages/clerk-js/src/ui/elements/LineItems.tsx, the Title component's React.forwardRef should use HTMLTableCellElement as the generic type parameter, even though it renders a Dt element. This is the correct implementation according to the codebase maintainer.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/typescript.mdc:0-0
Timestamp: 2025-06-23T12:26:09.855Z
Learning: In TypeScript, always define explicit return types for functions, especially for public APIs, to ensure type safety and clarity.
packages/clerk-js/src/ui/utils/colors/scales.ts (2)
Learnt from: dstaley
PR: clerk/javascript#6100
File: packages/clerk-js/src/ui/components/OAuthConsent/OAuthConsent.tsx:121-124
Timestamp: 2025-06-16T17:08:58.414Z
Learning: The @clerk/clerk-js package only supports browsers released in the last two years (since May 8, 2023), so modern CSS features like color-mix() are fully supported across all target browsers without requiring fallbacks.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/monorepo.mdc:0-0
Timestamp: 2025-06-23T12:25:40.214Z
Learning: Framework packages depend on @clerk/clerk-js for core functionality, while @clerk/shared and @clerk/types provide common utilities and TypeScript definitions used across packages.
🧬 Code Graph Analysis (2)
packages/clerk-js/src/ui/utils/colors/utils.ts (3)
packages/types/src/appearance.ts (1)
  • ColorScale (45-45)
packages/clerk-js/src/ui/utils/colors/constants.ts (6)
  • ALL_SHADES (19-19)
  • ColorShade (8-8)
  • RELATIVE_SHADE_STEPS (71-88)
  • LIGHTNESS_CONFIG (22-27)
  • LIGHTNESS_MIX_DATA (52-68)
  • ALPHA_PERCENTAGES (33-49)
packages/clerk-js/src/ui/utils/cssSupports.ts (1)
  • cssSupports (65-81)
packages/clerk-js/src/ui/utils/colors/scales.ts (5)
packages/types/src/appearance.ts (3)
  • ColorScale (45-45)
  • CssColorOrScale (52-52)
  • CssColorOrAlphaScale (53-53)
packages/clerk-js/src/ui/utils/cssSupports.ts (1)
  • cssSupports (65-81)
packages/clerk-js/src/ui/utils/colors/utils.ts (3)
  • createEmptyColorScale (23-25)
  • generateAlphaColorMix (114-117)
  • getSupportedColorVariant (128-140)
packages/clerk-js/src/ui/utils/colors/constants.ts (5)
  • COLOR_SCALE (12-14)
  • ALPHA_VALUES (30-30)
  • LIGHTNESS_CONFIG (22-27)
  • LIGHT_SHADES (17-17)
  • DARK_SHADES (18-18)
packages/clerk-js/src/ui/utils/colors/index.ts (1)
  • legacyColors (163-163)
⏰ Context from checks skipped due to timeout of 90000ms (4)
  • GitHub Check: semgrep-cloud-platform/scan
  • GitHub Check: Formatting | Dedupe | Changeset
  • GitHub Check: Build Packages
  • GitHub Check: Analyze (javascript-typescript)
🔇 Additional comments (4)
packages/clerk-js/src/ui/utils/colors/utils.ts (2)

10-18: Excellent performance optimization with frozen object.

The use of Object.freeze on the pre-computed empty color scale is a smart optimization that prevents unnecessary object creation and mutations.


77-97: Verify complex lightness calculation logic.

The relative color syntax generation uses complex lightness calculations with target values and steps. Please ensure these mathematical formulas produce the expected color progression.

The lightness calculations look complex. Let's verify the mathematical formulas work as expected:

#!/bin/bash
# Description: Search for any tests that validate the lightness calculation formulas
# Expected: Find test files that verify the color progression behavior

rg -A 10 -B 5 "generateRelativeColorSyntax|TARGET_LIGHT|TARGET_DARK|LIGHT_STEPS|DARK_STEPS" --type ts
packages/clerk-js/src/ui/utils/colors/scales.ts (2)

148-189: Well-designed unified API with feature detection.

The automatic selection between modern and legacy implementations based on CSS support is elegant and provides seamless fallback behavior.


91-92: Verify legacy lightness calculation accuracy.

The lightness step calculations use division by array length, which should account for the correct number of steps in the progression.

Verify the lightness step calculations produce expected results:

#!/bin/bash
# Description: Look for tests validating legacy lightness calculations
# Expected: Find test cases that verify the lightness step formulas

rg -A 15 -B 5 "lightStep|darkStep|LIGHTNESS_CONFIG" --type ts

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

♻️ Duplicate comments (1)
packages/clerk-js/src/ui/utils/colors/modern.ts (1)

72-87: Fix type inconsistency with other methods

The setAlpha method has inconsistent parameter and return types compared to other methods in this module. It should accept string | undefined and return string | undefined for consistency.

This was already identified in previous reviews but the fix hasn't been applied yet.

🧹 Nitpick comments (1)
packages/clerk-js/src/ui/utils/colors/modern.ts (1)

39-48: Consider adding relative color syntax support for consistency

The makeTransparent method only uses color-mix() while other methods prefer relative color syntax when available. For consistency and better precision, consider implementing relative color syntax as the primary option.

Additionally, the color.toString() === '' check is redundant since the truthiness check !color already handles empty strings.

  makeTransparent: (color: string | undefined, percentage = 0): string | undefined => {
-    if (!color || color.toString() === '') return undefined;
+    if (!color) return undefined;

+    if (cssSupports.relativeColorSyntax()) {
+      // Use relative color syntax for precise alpha control
+      const alpha = 1 - percentage;
+      const clampedAlpha = Math.max(alpha, MODERN_CSS_LIMITS.MIN_ALPHA_PERCENTAGE / 100);
+      return createRelativeColorString(color, 'h', 's', 'l', clampedAlpha.toString());
+    }
+
    if (cssSupports.colorMix()) {
      const alphaPercentage = Math.max((1 - percentage) * 100, MODERN_CSS_LIMITS.MIN_ALPHA_PERCENTAGE);
      return createAlphaColorMixString(color, alphaPercentage);
    }

    return color; // Return original if no modern CSS support
  },
📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 0a6be7f and 7522f71.

📒 Files selected for processing (2)
  • packages/clerk-js/src/ui/utils/colors/modern.ts (1 hunks)
  • packages/clerk-js/src/ui/utils/colors/utils.ts (1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
  • packages/clerk-js/src/ui/utils/colors/utils.ts
🧰 Additional context used
📓 Path-based instructions (4)
`**/*.{js,ts,tsx,jsx}`: All code must pass ESLint checks with the project's configuration. Use Prettier for consistent code formatting.

**/*.{js,ts,tsx,jsx}: All code must pass ESLint checks with the project's configuration.
Use Prettier for consistent code formatting.

📄 Source: CodeRabbit Inference Engine (.cursor/rules/development.mdc)

List of files the instruction was applied to:

  • packages/clerk-js/src/ui/utils/colors/modern.ts
`**/*.{ts,tsx}`: Maintain comprehensive JSDoc comments for public APIs.

**/*.{ts,tsx}: Maintain comprehensive JSDoc comments for public APIs.

📄 Source: CodeRabbit Inference Engine (.cursor/rules/development.mdc)

List of files the instruction was applied to:

  • packages/clerk-js/src/ui/utils/colors/modern.ts
`packages/**`: All publishable packages under the @clerk namespace must be located in the packages/ directory.

packages/**: All publishable packages under the @clerk namespace must be located in the packages/ directory.

📄 Source: CodeRabbit Inference Engine (.cursor/rules/global.mdc)

List of files the instruction was applied to:

  • packages/clerk-js/src/ui/utils/colors/modern.ts
`**/*.ts`: Always define explicit return types for functions, especially public ...

**/*.ts: Always define explicit return types for functions, especially public APIs.
Use proper type annotations for variables and parameters where inference isn't clear.
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, protected for inheritance, and public explicitly for clarity in public APIs.
Prefer composition and interfaces over deep inheritance chains; use mixins for shared behavior.
Use ES6 imports/exports consistently; avoid barrel files (index.ts re-exports) to prevent circular dependencies.
Use type-only imports (import type { ... }) where possible.
Use as const for literal types and the satisfies operator for type checking without widening.
Enable --incremental and --tsBuildInfoFile for faster builds.
Use ESLint with @typescript-eslint/recommended rules and Prettier for formatting.
Use lint-staged and Husky for pre-commit checks.
Use type-coverage to measure type safety.

📄 Source: CodeRabbit Inference Engine (.cursor/rules/typescript.mdc)

List of files the instruction was applied to:

  • packages/clerk-js/src/ui/utils/colors/modern.ts
🧠 Learnings (2)
📓 Common learnings
Learnt from: dstaley
PR: clerk/javascript#6100
File: packages/clerk-js/src/ui/components/OAuthConsent/OAuthConsent.tsx:121-124
Timestamp: 2025-06-16T17:08:58.414Z
Learning: The @clerk/clerk-js package only supports browsers released in the last two years (since May 8, 2023), so modern CSS features like color-mix() are fully supported across all target browsers without requiring fallbacks.
Learnt from: dstaley
PR: clerk/javascript#6116
File: .changeset/tangy-garlics-say.md:1-2
Timestamp: 2025-06-13T16:09:53.061Z
Learning: In the Clerk JavaScript repository, contributors create intentionally empty changeset files (containing only the YAML delimiters) when a PR touches only non-published parts of the codebase (e.g., sandbox assets). This signals that no package release is required, so such changesets should not be flagged as missing content.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/monorepo.mdc:0-0
Timestamp: 2025-06-23T12:25:40.214Z
Learning: Environment variables prefixed with CLERK_* and NEXT_PUBLIC_CLERK_* are supported for configuration across different environments.
packages/clerk-js/src/ui/utils/colors/modern.ts (12)
Learnt from: dstaley
PR: clerk/javascript#6100
File: packages/clerk-js/src/ui/components/OAuthConsent/OAuthConsent.tsx:121-124
Timestamp: 2025-06-16T17:08:58.414Z
Learning: The @clerk/clerk-js package only supports browsers released in the last two years (since May 8, 2023), so modern CSS features like color-mix() are fully supported across all target browsers without requiring fallbacks.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/typescript.mdc:0-0
Timestamp: 2025-06-23T12:26:09.855Z
Learning: Use ES6 module syntax (import/export) consistently for maintainability and compatibility.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/typescript.mdc:0-0
Timestamp: 2025-06-23T12:26:09.855Z
Learning: Leverage modern TypeScript features such as generics, utility types (Omit, Partial, Pick), mapped types, conditional types, and template literal types for expressive and type-safe code.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/monorepo.mdc:0-0
Timestamp: 2025-06-23T12:25:40.214Z
Learning: Framework packages depend on @clerk/clerk-js for core functionality, while @clerk/shared and @clerk/types provide common utilities and TypeScript definitions used across packages.
Learnt from: jacekradko
PR: clerk/javascript#5905
File: .changeset/six-ears-wash.md:1-3
Timestamp: 2025-06-26T03:27:05.511Z
Learning: In the Clerk JavaScript repository, changeset headers support single quotes syntax (e.g., '@clerk/backend': minor) and work fine with their current changesets integration, so there's no need to change them to double quotes.
Learnt from: dstaley
PR: clerk/javascript#6116
File: .changeset/tangy-garlics-say.md:1-2
Timestamp: 2025-06-13T16:09:53.061Z
Learning: In the Clerk JavaScript repository, contributors create intentionally empty changeset files (containing only the YAML delimiters) when a PR touches only non-published parts of the codebase (e.g., sandbox assets). This signals that no package release is required, so such changesets should not be flagged as missing content.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/monorepo.mdc:0-0
Timestamp: 2025-06-23T12:25:40.214Z
Learning: All packages are published under the @clerk namespace on npm, ensuring consistent naming and discoverability.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/monorepo.mdc:0-0
Timestamp: 2025-06-23T12:25:40.214Z
Learning: Backend utilities are isolated in @clerk/backend, which is independent and used for server-side operations.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/global.mdc:0-0
Timestamp: 2025-06-23T12:25:34.662Z
Learning: All packages published from this repository must use the @clerk namespace.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/monorepo.mdc:0-0
Timestamp: 2025-06-23T12:25:40.214Z
Learning: Environment variables prefixed with CLERK_* and NEXT_PUBLIC_CLERK_* are supported for configuration across different environments.
Learnt from: panteliselef
PR: clerk/javascript#6097
File: packages/clerk-js/src/ui/elements/LineItems.tsx:89-89
Timestamp: 2025-06-10T09:38:56.214Z
Learning: In packages/clerk-js/src/ui/elements/LineItems.tsx, the Title component's React.forwardRef should use HTMLTableCellElement as the generic type parameter, even though it renders a Dt element. This is the correct implementation according to the codebase maintainer.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/typescript.mdc:0-0
Timestamp: 2025-06-23T12:26:09.855Z
Learning: In TypeScript, always define explicit return types for functions, especially for public APIs, to ensure type safety and clarity.
🧬 Code Graph Analysis (1)
packages/clerk-js/src/ui/utils/colors/modern.ts (5)
packages/clerk-js/src/ui/utils/colors/index.ts (1)
  • colors (9-161)
packages/clerk-js/src/ui/utils/colors/legacy.ts (1)
  • colors (357-367)
packages/clerk-js/src/ui/utils/cssSupports.ts (1)
  • cssSupports (65-81)
packages/clerk-js/src/ui/utils/colors/utils.ts (3)
  • createRelativeColorString (51-59)
  • createColorMixString (38-40)
  • createAlphaColorMixString (67-69)
packages/clerk-js/src/ui/utils/colors/constants.ts (2)
  • MODERN_CSS_LIMITS (99-106)
  • COLOR_BOUNDS (91-96)
⏰ Context from checks skipped due to timeout of 90000ms (3)
  • GitHub Check: semgrep-cloud-platform/scan
  • GitHub Check: semgrep-cloud-platform/scan
  • GitHub Check: Analyze (javascript-typescript)
🔇 Additional comments (4)
packages/clerk-js/src/ui/utils/colors/modern.ts (4)

1-13: LGTM - Clear module documentation and structure

The module documentation clearly explains the purpose and the duplicate comment provides good emphasis on the modern CSS approach.


18-34: LGTM - Well-implemented lighten method with proper fallback logic

The method correctly implements the feature detection pattern, handles edge cases, and uses appropriate mathematical conversions. The percentage * 100 conversion and clamping with constants are well-implemented.


53-67: LGTM - Solid implementation with proper fallback strategy

The method correctly implements both relative color syntax and color-mix fallbacks. The approach of mixing a color with itself at 100% is clever for removing transparency when relative color syntax isn't available.


92-119: LGTM - Sophisticated lightness adjustment with proper constraints

The method implements advanced lightness adjustment logic with appropriate safeguards:

  • Uses max() function to prevent colors from becoming too dark
  • Applies multipliers for more noticeable effects
  • Implements proper fallback to color-mix with white
  • Clamps adjustments to reasonable limits

The complex relative color syntax expression is well-documented and mathematically sound.

@alexcarpenter alexcarpenter requested a review from dstaley June 27, 2025 00:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants
0