[clean99]

The docs list OKLCH as a supported theme.colors format, and the docs theme itself uses an oklch-blue ramp. lighten and darken send every non-var() color through toRgba, which parses hex, rgb and hsl and returns { r: 0, g: 0, b: 0, a: 1 } for anything else, so an oklch() value is treated as black.

That shows up in the generated variables. In dark color scheme --mantine-color-<name>-light and -light-hover are darken(theme.colors[color][9], 0.5) and darken(..., 0.3) (get-css-color-variables.ts:65-66), so an OKLCH color's light variant background came out rgba(0, 0, 0, 1). With <Button color="oklch-blue" variant="light" /> in dark mode the button is black rather than a tint of the color. The filled variant has the same problem for a raw oklch() color prop, because its hover is darken(color!, 0.1) (default-variant-colors-resolver.ts:81).

// before
darken('oklch(49.72% 0.1888 251.59)', 0.5)  // rgba(0, 0, 0, 1)
// after
darken('oklch(49.72% 0.1888 251.59)', 0.5)  // color-mix(in srgb, oklch(49.72% 0.1888 251.59), black 50%)

The fix is the branch rgba() already has (rgba.ts:13): OKLCH is passed through to a CSS color-mix instead of being converted to numeric channels, so the browser does the mixing and toRgba does not have to carry an OKLab conversion. var() colors are unaffected and hex/rgb/hsl still take the numeric path.

Tests were added next to the existing supports css variables cases in both test files; they fail with only the two source lines reverted. corepack yarn jest packages/@mantine/core passes (354 suites, 10746 tests), along with oxlint and oxfmt.