mirror of
https://github.com/heygen-com/hyperframes.git
synced 2026-09-03 04:38:33 +00:00
* fix(compiler): skip CSS var() in font resolver — fixes FONT_FETCH_FAILED on distributed renders The font scanner treated `var(--ui-font)` as a literal font family name, causing fail-closed distributed renders to throw FONT_FETCH_FAILED for any composition using CSS custom properties in font-family declarations. CSS var() expressions resolve at browser paint time, not at compile time. The regex-based font scanner cannot resolve them statically — skip them and let headless Chrome handle variable substitution during render. Closes #1654 — Miga * test(regression): add distributed css-var-fonts fixture Regression test for compositions that use CSS custom properties in font-family declarations. Exercises the var() skip guard in extractRequestedFontFamilies() under the distributed renderer's fail-closed font resolution path. Baseline needs to be generated on first CI run with --update. — Miga * fix(compiler): address review feedback — mixed declaration test + validator TODO Add unit test verifying concrete fonts alongside var() in mixed declarations still get resolved (non-aggression pin). Add TODO(#1654) in validateNoSystemFonts for the var()-as-primary gap flagged by both reviewers. — Miga * fix(test): correct stale 4xx fail-closed test expectations The 4xx tests expected no throw, but that was the contract before #1255 added the system font capture path (Path 3). Post-#1255, a font that gets 4xx from Google Fonts AND isn't a bundled alias AND has no system font IS genuinely unresolvable — fail-closed mode should throw. The 4xx distinction still matters at the fetch level (no retry, treated as deterministic "not served"), but at the final unresolved check, a completely unresolvable font must throw regardless of the HTTP status that caused the Google Fonts path to return empty. Updated tests to match the actual contract: 4xx + unresolvable = throw. Also set allowSystemFontCapture: false to match how distributed renders (plan.ts:799) actually call the function. — Miga --------- Co-authored-by: Miguel Ángel <miguel.sierra@heygen.com>