[lexical-markdown] Bug Fix: support link and inline code text formats

[AlessioGr]

Fixes #5148. Additionally, it fixes an issue where formatted code blocks (e.g.

**`code`**

are not exported to markdown correctly after they have been imported.

This PR refactors the logic for applying text match and text format transformers to enable support for nested text formats within text match transformers, such as link nodes.

Unlike the previous attempt to fix it, this change does not include any node-specific logic. It fixes the root cause of the issue by ensuring that nested combinations of textmatch and textformat transformers are applied in optimal order.

Before

CleanShot.2024-12-30.at.11.56.42.mp4

After

CleanShot.2024-12-30.at.11.56.03.mp4

The Problem

Previously, the import process for text transformers roughly followed this sequence:

ElementTransformers ($importBlocks) => TextFormatTransformers =if not found> TextMatchTransformers

For link nodes containing formatted text, the process failed as follows:

1. Executed $importBlocks
2. Found code markdown within link => Run code text format transformer => create code textnode
3. The input text is split into 3 nodes: normal text, code text, and normal text. However, this fragmented structure prevents the link text match transformer from recognizing and creating a link node.

Initially, I attempted to solve this issue by adjusting the sequence to prioritize text match transformers:

ElementTransformers ($importBlocks) => TextMatchTransformers => TextFormatTransformers

While this resolved the issue with nested formats, it introduced a new problem in scenarios where links were wrapped by text format markdown, like this:

Text **boldstart [text](https://lexical.dev) boldend** text

Now, the link is created first and we get normal text, link, normal text. However, the bold text transformer could no longer identify and apply formatting to the entire outer bold range.

The Solution

Text format transformers already include logic to identify the outermost match, allowing them to handle scenarios like:

One **two __three__ four**

In this case, the bold transformer runs first, followed by the italic transformer, ensuring proper formatting.

However, text match transformers currently lack similar logic. Consider this example:

Text **boldstart [`text`](https://lexical.dev) boldend** text

The existing sequence processes it as:

1. Bold text
2. Code text
3. Link

However, to achieve correct results, the sequence should be:

1. Bold text
2. Link
3. Code text

To address this, the PR introduces logic for identifying the outermost match across both text match and text format transformers.

With this change, text match and text format transformers are treated as equals in priority, allowing their results to be compared directly. This ensures that the outermost match—whether from a text match or a text format transformer—is correctly identified and then applied, enabling seamless handling of nested text transformations.

Implementation details

1. Find (not apply) outermost text match
2. Find (not apply) outermost text format
3. Determine if found text match or text format is the outermost match
4. Apply said text match or text format
5. Repeat this for the matched node, and the node before / afterwards if text was split, until no more text matches and text formats are found

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
lexical	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Jan 21, 2025 6:43am
lexical-playground	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Jan 21, 2025 6:43am

[github-actions]

size-limit report 📦

Path	Size
lexical - cjs	29.07 KB (0%)
lexical - esm	28.89 KB (0%)
@lexical/rich-text - cjs	38.04 KB (0%)
@lexical/rich-text - esm	30.98 KB (0%)
@lexical/plain-text - cjs	36.57 KB (0%)
@lexical/plain-text - esm	28.26 KB (0%)
@lexical/react - cjs	39.84 KB (0%)
@lexical/react - esm	32.34 KB (0%)

[AlessioGr]

Just squeezed in another fix for formatted inline code markdown, e.g.

**`code`**

Didn't want to open a separate PR, as this one is a relatively large refactor and I wanted to make sure this fix is compatible

[etrepum]

I didn't look too carefully at the logic in the while loop other than to confirm that it should still terminate, I think the unit test coverage is probably sufficient to show that it's not more wrong than the status quo

[etrepum]

Presumably this title should be escaped because there could be embedded " and/or )?

[AlessioGr]

Done - I escaped this with some simple regex.

Should we consider a library like dompurify to protect against XSS attacks here? While it's just markdown, XSS could still be an issue if (and depending on how) this is rendered to HTML.

[AlessioGr]

I have reverted the escaping change. This broke a unit test and did not work when the markdown was re-imported to lexical.

The latter is a separate issue I have experienced, where escaped markdown is not un-escaped properly when imported. E.g. \*text\* is imported as<span> \*text\*</span> instead of <span>*text*</span>

I think fixing this properly may not be trivial and is out of scope for this PR anyways, since this PR did not introduce this unescaped title being outputted

[etrepum]

With how often this expression is repeated it's probably worth making a function to cover $isTextNode(node) && !node.hasFormat('code'). Checking for non-null/undefined is redundant because $isTextNode already does that

[AlessioGr]

done! I went for canContainTransformableMarkdown as that conveys the intent and makes the code where it's used more readable

[AlessioGr]

While doing this, found another area that I was able to optimize:

I think we can move the remaining logic up to the $transform call out of the editor.update() call as well - what do you think?