[lexical-markdown] Bug Fix: Fix nested fenced code blocks parsing and export#8116
Merged
etrepum merged 7 commits intofacebook:mainfrom Feb 8, 2026
Merged
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
etrepum
reviewed
Feb 6, 2026
Collaborator
etrepum
left a comment
There was a problem hiding this comment.
Overall this looks like a good direction but I think it can handle a few more edge cases
Comment on lines
+226
to
+228
| if (typeof val === 'string' && val.startsWith('`')) { | ||
| return val; | ||
| } |
Collaborator
There was a problem hiding this comment.
Might as well guarantee that it's a valid fence
Suggested change
| if (typeof val === 'string' && val.startsWith('`')) { | |
| return val; | |
| } | |
| if (typeof val === 'string' && /^`{3,}$/.test(val) { | |
| return val; | |
| } |
etrepum
reviewed
Feb 6, 2026
Collaborator
etrepum
left a comment
There was a problem hiding this comment.
The only thing left here is to test that the computed fence works
etrepum
reviewed
Feb 6, 2026
Collaborator
etrepum
left a comment
There was a problem hiding this comment.
There should be a test that the computed fence works. Right now it is only testing round-trips where the fence is not computed.
Contributor
Author
|
@etrepum I've added the test case ( this PR now addresses all feedback (redundant fallback removed + new test). |
etrepum
reviewed
Feb 8, 2026
packages/lexical-markdown/src/__tests__/unit/LexicalMarkdown.test.ts
Outdated
Show resolved
Hide resolved
etrepum
approved these changes
Feb 8, 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
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.
[lexical-markdown] Bug Fix: Fix nested fenced code blocks parsing and export
Description
Current behavior:
Nested fenced code blocks (e.g., using 4 backticks to wrap 3 backticks) are corrupted during the Markdown round-trip. The parser prematurely closes the code block at the first encounter of a 3-backtick sequence, causing the remaining content and the original closing fence to leak into the editor as plain text.
Changes added by this PR:
State Preservation: Introduced
codeFenceStateusingcreateStateto store the specific fence length (3, 4, 5+ backticks) used during import, ensuring the same length is used during export.Dynamic Fence Detection: Implemented
handleImportAfterStartMatchwith a dynamic Regex to ensure a code block only closes when it finds a fence with a length matching the opening fence.Edge Case Fixes:
Improved single-line code block detection to prevent content (like in
```Single line```) from being incorrectly parsed as a language attribute.Added EOF (End of File) handling for unclosed code blocks to ensure they are correctly captured as code nodes instead of standard paragraphs.
Refined the
CODEtransformer Regex to properly separate the fence and language capture groups.Closes #8109
Test plan
Before
Markdown content with nested fences would be rendered incorrectly in the Lexical editor. For example, a 4-backtick block would "break" at the inner 3-backtick block, leading to malformed output and extra escaped backticks (
\````) on export.After
Automated Tests:
Added new unit tests in
LexicalMarkdown.test.ts:can round-trip nested fenced code blocks (4 backticks wrapping 3 backticks)can round-trip deeply nested fenced code blocks (5 backticks wrapping 4 backticks)Verified that single-line blocks and incomplete/unclosed tags still pass and render correctly as per CommonMark expectations.
Manual Verification:
Tested in the playground by switching between Markdown and Rich Text views with nested code examples. The structure and backtick count are now perfectly preserved.