Include unravel transformation into `remark-mdx`

[fuma-nama]

Initial checklist

• I read the support docs
• I read the contributing guide
• I agree to follow the code of conduct
• I searched issues and discussions and couldn’t find anything (or linked relevant results below)

Problem

Since @mdx-js/mdx is more high-level, I usually use remark-mdx for unit tests for my own remark mdx plugins.

I noticed an inconsistency when parsing MDX inline content, like:

<Comp>Text</Comp>

<Comp>

Text

</Comp>

In remark-mdx, the former one is a flow text element, while latter one is a JSX flow element.

But when using @mdx-jd/mdx, where my remark plugins run, they became both JSX flow element.

I would have expected it's a parse-level behaviour as it's about how JSX syntax being handled, but after checking, the work is done by an internal remark plugin to unravel JSX text elements.

Current solutions

Copy the remark unravel plugin from this repository, or using another existing plugins.

But they're not parser, which causes processor.parse to handle syntax like:

<Comp>Text</Comp>

as inline elements, and created inconsistency when I use remark().use(remarkMdx) instead.

The result is a bit unintuitive because it's enabled by default by MDX.js, and cannot be disabled at all.

Proposed solutions

An option to remarkMdx to specify how to handle those JSX syntax. (or consider enabling it by default)

[wooorm]

This is missing context: what is the inconsistency? What did you notice? What are you doing?

[fuma-nama]

I think they’re answered in the Problem section. I’m running the same plugin on unit test environment using remark MDX, and on production using MDX.js, but they gave different results due to the inconsistency mentioned above.

[remcohaszing]

Why do you use remark-mdx in your unit tests instead of @mdx-js/mdx? For typical plugins, @mdx-js/mdx is closer to what your users would use. I would recommend remark-mdx for cases where you only need the mdast, such as linting. For testing transformations I strongly suggest @mdx-js/mdx.

[fuma-nama]

from what I know, @mdx-js/mdx gives a unified processor of remark -> rehype -> estree while I only want to capture the result of MDAST using processor.run(), not sure which is the best path

[fuma-nama]

and on a side note, on @mdx-js/mdx, the original issue will also cause processor.parse() to treat

<Comp>Text</Comp>

as JSX text element, while during processor.run() it becomes JSX flow element. I think the unravel step is more related to the parser part, especially when the transformation already enforced by default.

[remcohaszing]

Why do you need to capture the result of the mdast after the unmark and unravel? To me it looks like you’re testing internals.

[fuma-nama]

Why do you need to capture the result of the mdast after the unmark and unravel?

As said it's mainly for unit testing some of my remark plugins, so I'm doing markdown -> remark-parse -> remark-mdx -> my-plugin, and snapshot/compare the output MDAST. Using stringify would lose the tree info, and it's too much if I capture the result of rehype/estree instead.