fix(lint-mdx): stop flagging closing code fences as missing a language - #1805
Open
bayrakdarerdem wants to merge 1 commit into
Open
fix(lint-mdx): stop flagging closing code fences as missing a language#1805bayrakdarerdem wants to merge 1 commit into
bayrakdarerdem wants to merge 1 commit into
Conversation
checkCodeBlocks() matched every line starting with ``` the same way, opening and closing fences alike. Closing fences never carry a language, so every single fenced code block in the docs -- thousands of them -- was reported as "Code block missing language specifier" on its closing line. Running `node scripts/lint-mdx.js all` before this change: 349 files checked, 1246 errors, 75 warnings After: 349 files checked, 100 errors, 74 warnings The function now tracks the length of the currently-open fence and only treats a ``` line as a new opening fence when not already inside a block. This also fixes a related edge case surfaced while writing the fix: two files (agents/plugins/custom-plugins.mdx and base-account/guides/authenticate-users.mdx) use a 4-backtick fence to show a literal 3-backtick code sample as content. A plain boolean would have treated that inner 3-backtick line as a real closing fence and gotten out of sync for the rest of the file, so the fix tracks fence length and only closes a block on a fence at least as long as the one that opened it (matching CommonMark's nested-fence rule). The CodeGroup label check is unchanged in behavior; it's simplified now that the surrounding opening/closing logic no longer needs it to compensate. Verified the ~100 remaining reported issues are real (genuine language-less code blocks, missing frontmatter, multiple H1s, etc.) by spot-checking several files directly. Assisted by Claude (Anthropic).
Collaborator
🟡 Heimdall Review Status
|
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
2 participants
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.
Summary
checkCodeBlocks()inscripts/lint-mdx.jsmatched every line starting with ``` the same way, opening and closing fences alike. Closing fences never carry a language, so every single fenced code block in the docs —thousands of them was reported as "Code block missing language specifier" on its closing line.
Before / after
Running
node scripts/lint-mdx.js all:349 files checked, 1246 errors, 75 warnings349 files checked, 100 errors, 74 warningsFix
The function now tracks the length of the currently-open fence and only treats a ``` line as a new opening fence when not already inside a block.
This also fixes a related edge case surfaced while writing the fix: two files (
agents/plugins/custom-plugins.mdxandbase-account/guides/authenticate-users.mdx) use a 4-backtick fence to show a literal 3-backtick code sample as content. A plain boolean would have treated that inner 3-backtick line as a real closing fence and gotten out of sync for the rest of the file, so the fix tracks fence length and only closes a block on a fence at least as long as the one that opened it(matching CommonMark's nested-fence rule).
The
<CodeGroup>label check is unchanged in behavior; it's simplified now that the surrounding opening/closing logic no longer needs it to compensate.Verification
Spot-checked several of the ~100 remaining reported issues directly in the source files to confirm they're real (genuine language-less code blocks, missing frontmatter, multiple H1s, etc.) no false positives
left in the sample I checked.