[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 28, 2025 10:29pm
lexical-playground	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Jan 28, 2025 10:29pm

[github-actions]

size-limit report 📦

Path	Size
lexical - cjs	29.07 KB (0%)
lexical - esm	28.86 KB (0%)
@lexical/rich-text - cjs	38.04 KB (0%)
@lexical/rich-text - esm	30.92 KB (0%)
@lexical/plain-text - cjs	36.55 KB (0%)
@lexical/plain-text - esm	28.22 KB (0%)
@lexical/react - cjs	39.85 KB (0%)
@lexical/react - esm	32.28 KB (0%)

[etrepum]

I didn't do a very careful read of all the logic but this seems like a reasonable approach, has new tests, and passes existing tests. @potatowagon what do you think?

[potatowagon]

I didn't do a very careful read of all the logic but this seems like a reasonable approach, has new tests, and passes existing tests. @potatowagon what do you think?

lgtm! a very useful feature, thankyou