[AksharP5]

What

Add focused regression coverage for valid @font-face blocks whose final, unquoted font-family descriptor has no semicolon. Document that syntax alongside the lint rule.

Why

The original report, #6083, reproduced with the regex extractor on this PR's earlier base. Main now reads font declarations with PostCSS through #5221, which also fixes this case. The rebase retains that parser unchanged; the remaining diff is two regression cases and the documentation clarification.

Final descriptor	Original regex extractor	Current main and this PR
font-family: ProjectFont }	Missing-font error	Accepted
font-family: Project Font }	Missing-font error	Accepted

The new cases call the real HTML linter and cover both single-word and multiword family names.

Related work

Refs #6083. The production correction is already on main through #5221. This PR preserves the targeted regression coverage and documents valid syntax.

How

Keep packages/lint/src/rules/fonts.ts byte-for-byte identical to main. Retain the two semicolon-free final-descriptor cases and the two-line docs clarification from the approved revision.

Test plan

• Rebased commit is signed and verified by GitHub.
• 129 font-rule and project-lint tests pass on the rebased branch.
• Parsers/lint builds and lint typecheck pass.
• Lint, formatting, comment checks, package-cycle check and workspace contracts pass.
• Independent GPT-6.1 Sol xhigh verification: no blockers; all 129 font/project tests and 10 direct linter controls pass. The reviewer confirmed that production code equals main and the new cases add distinct coverage.
• Documentation describes the accepted syntax.

Rebased onto 3d45d1b03. Full workspace builds were attempted; missing installed inspector/AWS dependencies prevent a complete local build. Mintlify validation awaits CI because mint is unavailable locally. No packages were installed.

CI follow-up

The integration job on 17daae9 could not find Puppeteer's Chrome binary. Its aggregate Test check failed for that reason. All 101 affected browser tests pass locally with Chrome available. The same workflow and dependency lock passed the producer integration lane on #5528. A fresh CI run is requested on the unchanged commit.

[mintlify]

Preview approval required

This pull request comes from a fork, so Mintlify won't build a preview until someone with write access approves commit 17daae9.

Approve preview

[miguel-heygen]

Nice first contribution. I ran both the old and the new pattern over the real block matcher and the defect reproduces exactly as described: font-family:ProjectFont} yielded projectfont} before and yields projectfont now, with quoted names, multiword names and the trailing semicolon case all unchanged. The three other font family extractors in the repo already exclude the closing brace, so this brings the one outlier in line, and the new tests fail on base.

One housekeeping item: the docs validation job is cancelled at this head while the PR edits the lint rules page, so please get that one green before merge.

[AksharP5]

@miguel-heygen Refreshed this branch onto current main at 2cad3c9 to trigger fresh docs validation after the old run was cancelled. git range-diff confirms the font fix, tests and docs patch are unchanged. Parsers/lint builds, all 100 font/project-lint tests, lint typecheck, formatting and comment checks pass. The new commit is signed and verified. Ready for another look once CI finishes.

[miguel-heygen]

Thanks for the fix, and welcome. This is a nicely contained one.

The housekeeping item from the earlier look is now closed: docs validation is green at this head along with the rest of the suite, so the approval stands here.

I re-ran the old and the new pattern side by side over the real block matcher to try to break it. The reported case goes from projectfont} to projectfont, the trailing semicolon case, the quoted case and the multiword case are all unchanged, and a declaration with trailing space before the brace actually comes out cleaner now. I could not build an input where the old pattern extracts a correct family and the new one does not. A quoted name containing a brace fails under both, but the outer @font-face block matcher already truncates there, so that is not something you introduced.

One thing I liked: the other family extractor in this file already excludes the closing brace, so this brings the one outlier in line rather than adding a new rule. The two new cases fail on base, which is what makes them worth keeping.

[jrusso1020]

Approving, agreeing with Miguel's approval at this head.

The bug is real on main. extractFontFaceFamilies in packages/lint/src/rules/fonts.ts matches [^;'"]+, and since the @font-face block match ends at }, a final unquoted descriptor with no semicolon captures ProjectFont }. After trim that is projectfont }, which never equals the used family, so font_family_without_font_face fires as a blocking error on valid CSS. Both new test cases hit exactly that path, so they fail on main and pass here.

The fix also brings this regex in line with its siblings. The used-font matcher a few lines down in the same file, htmlParityContract.ts in core, and the capture downloader in cli all already stop at }. This was the one extractor that didn't.

Need: yes, valid CSS hard-fails lint (#6083) · Size: ok · Reuse: matches the existing [^;}] pattern used by the other font-family extractors · Simpler: already minimal, one character class

— Rames

[jrusso1020]

Thanks, @AksharP5. This was approved and in the merge queue, but another PR that merged ahead of it touched the same lines, so GitHub took it out of the queue with a merge conflict. Could you rebase onto the latest main? If it's a clean rebase with no code changes, we'll requeue it right away.

— Rames

[miguel-heygen]

Thanks for the rebase. Re-checked at this head: since main now reads font declarations with PostCSS, fonts.ts here is identical to main and the PR is the two regression cases plus the docs line, which the new title says. The cases go through lintHyperframeHtml, cover single-word and multi-word names with no trailing semicolon on either side, and they fail against the old regex extractor, so they will catch a slide back to it. Nothing on main already covered this shape. CI is green at this head.

Verdict: APPROVE
Reasoning: Test-and-docs-only change on top of main's fix; the cases are real coverage through the linter entry point and all required checks are green.