refactor(lint): remove the head_leaked_text rule - #3385
Merged
Conversation
The rule fired on legitimate content and blocked check. A prose CSS comment naming a tag, such as "the <body> rule below sets the base font", was enough: HEAD_CONTENT_PATTERN ends the head at the first <body> in raw source, so the token inside the comment truncated the capture mid-<style>. The unclosed style tag then defeated the strip-ignorable-blocks pass, and the stylesheet's own rules reached the orphan-CSS matcher, which reported a valid nearby rule as the leak. Removed rather than repaired. Across all 643 shipped registry files it fires zero times, so it has never caught anything real here, while producing at least one confirmed false positive that blocked a working cloud render. It is an error, not a warning, so the cost of a false positive is a blocked pipeline. Leaked text of this kind is also visible in the very first preview frame, which is a faster and more reliable signal than a regex over raw source. Takes its seven helpers and eight now-dead patterns with it, plus four orphaned test fixtures. VISIBLE_MARKUP_COMMENT_PATTERN is kept; it belongs to visible_markup_comment. Refs #3384
Merged
This was referenced Aug 21, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Remove the
head_leaked_textlint rule, its seven helpers, its eight now-dead patterns andits test fixtures. Net -478 lines.
Refs #3384.
Why
Telemetry, over 30 days of real usage:
A streak is a finding that was still there after the user edited and re-linted. Rules whose
findings are genuinely actionable get fixed once and vanish:
font_family_without_font_faceinvalid_parent_traversal_in_asset_pathmedia_missing_idgsap_non_transform_motionhead_leaked_textThis one averages nearly three failed attempts, and one person fought it through eleven
edits. It is also the only high-streak rule that is an
error— the other two rules withcomparable streaks are warnings, where a stubborn finding is annoying rather than blocking.
So it is rare and punishing: 0.22% of runs, and when it hits, people cannot get past it.
That is what you would expect from the defect in #3384, where the reported snippet points at
an innocent CSS rule rather than at the text that actually caused it.
The triggering case
A prose CSS comment naming a tag was enough:
HEAD_CONTENT_PATTERNends the head at the first<bodyin raw source, so that tokeninside a comment truncated the capture mid-
<style>. The unclosed style tag then defeatedHEAD_BLOCKS_TO_IGNORE_PATTERN, which requires a matching close, and the stylesheet's realrules reached
ORPHAN_CSS_RULE_PATTERN. One mechanism produced both symptoms: the falsepositive, and the misleading snippet.
Why removed rather than repaired
I wrote the repair first — mask
<style>/<script>/comment regions with same-lengthwhitespace before finding the boundary, so offsets stay valid for snippets. It worked, with
three regression tests. I discarded it because repairing the detector does not address what
the telemetry shows: even when this rule is right, people cannot act on it.
The rule has been in place since 2026-06-25 (#1727), moved into
@hyperframes/linton06-27 (#1756), and was hardened twice since, including a false-positive fix in July (#2413)
that added a regression test for a
<g>-shaped CSS comment. So the fragility was known andhad already been patched once at exactly this seam;
<body>and</head>were simply thetokens that test did not cover. This would have been the third patch of the same shape.
If this failure mode is worth catching later, the right place is a rendered-pixel check
rather than a regex over raw HTML.
Test plan
Before / after on the reported case
Nothing else moved
Same audit over the 643 shipped registry files, lint untouched vs this branch:
Identical. The 614 are pre-existing findings from other rules. Note this corpus is curated
content and was never strong evidence on its own — the telemetry above is the real argument.
Other checks
vitest packages/lint— 495 passed, 14 filesoxlint+oxfmton both touched files — clean, including four test fixtures that becameorphaned and were removed with it
Kept deliberately
VISIBLE_MARKUP_COMMENT_PATTERNstays: it belongs tovisible_markup_comment, a differentrule, and is untouched.