postcss-calc emits spurious warnings for relative color syntax and color-mix() channel keywords (SPFx 1.23)

[StfBauer]

Target SharePoint environment

SharePoint Online

What SharePoint development model, framework, SDK or API is this about?

💥 SharePoint Framework

Developer environment

macOS

What browser(s) / client(s) have you tested

• not applicable

Additional environment details

• SPFx version: 1.23.0
• postcss-calc version: 8.2.4 (bundled with SPFx 1.23 toolchain)
• Node.js version: v22.22.0

Describe the bug / error

When using Relative Color Syntax or color-mix(), postcss-calc (v8.2.4, shipped with SPFx 1.23) fails to parse calc() expressions that contain color channel identifiers (h, s, l, c, r, g, b, a, etc.) and emits a lexical error warning, even though the CSS is fully valid and has been supported across all major browsers for years.

The CSS value is not modified (the catch block returns the original value), so this is a false-positive warning only — but it pollutes build output and may be mistaken for a real error.

Warning produced:

from "postcss-calc" plugin: Lexical error on line 1: Unrecognized text.

  Erroneous area:
1: h + 116
   ^..^

The exact identifier in the erroneous area varies (h, s, l, c, etc.) but it is always the same class of failure.

Root cause: postcss-calc 8.2.4 (released February 2022) uses a Jison-generated grammar that has no token rule for bare channel-name identifiers. Both color-mix() with nested relative color expressions and standalone relative color syntax trigger the issue. The upstream postcss-calc repository addressed this in the 9.x / 10.x series (current latest: 10.1.1).

Steps to reproduce

1. Create an SPFx 1.23 web part with a .module.scss file.
2. Add any of the following declarations:

/* Relative Color Syntax — hue shift */
background-color: hsl(from var(--themePrimary, #1059ff) calc(h + 116) 100% 41%);

/* Relative Color Syntax — lightness reduction */
background-color: hsl(from var(--box-color-resolved) h s calc(l - 11));

/* color-mix() with nested relative color + calc */
background: color-mix(in hsl, hsl(from var(--color) calc(h + 30) s l), transparent);

/* color-mix() with oklch channel calc */
border-color: color-mix(in oklch, oklch(from var(--accent) l calc(c * 0.5) h), white 20%);

3. Run gulp build or gulp serve.
4. Observe the postcss-calc lexical error warning in the build output.

Expected behavior

No warning is emitted. Channel keywords (h, s, l, c, etc.) are valid tokens inside calc() expressions in a relative color context. The CSS should pass through unmodified and silently.

---

Browser support reference

Both features have been production-safe for modern SharePoint environments for years.

Relative Color Syntax — Baseline widely available since July 2024:

Browser	Version	Released
Safari	16.4	March 2023
Chrome	119	October 2023
Edge	119	October 2023
Firefox	128	July 2024

color-mix() — Baseline widely available since May 2023:

Browser	Version	Released
Safari	16.2	December 2022
Chrome	111	March 2023
Edge	111	March 2023
Firefox	113	May 2023

---

Suggested fix

Update the postcss-calc dependency in the SPFx build toolchain from 8.2.4 → 10.1.1. If a major-version bump is not feasible for 1.23, a patch that silences warnings for unrecognised text inside from-prefixed color functions would also resolve the issue.

Workaround

No developer-side workaround is available without ejecting from the SPFx toolchain or patching node_modules.

[Ashlesha-MSFT]

Hello @StfBauer,
Thank you for bringing this issue to our attention. We will look into it and get back to you shortly.

[Ashlesha-MSFT]

Hello @StfBauer,

Thank you for the detailed report and repro details.

We were able to reproduce this behavior in our validation environment with SPFx 1.23.x, including the postcss-calc lexical warnings for relative color syntax / color-mix() channel expressions inside calc() (for example h + 116, l - 11, h + 30, c * 0.5).

Our verification also confirms this is warning-only behavior: build and packaging continue successfully, which indicates a false-positive parsing warning in the current toolchain dependency path.

We have logged this as a bug and will raise it with the engineering team for further investigation and fix planning.

Thank you again for reporting this. We will update this issue as we have progress.