Paragraph starting with a decimal number is moved into preceding list (MDX)

[TrevorBurnham]

Prettier 2.3.2
Playground link

--parser mdx
--arrow-parens avoid
--trailing-comma none

Input:

- A list item.

1.x Some text below the list that starts with "1.x"

Output:

- A list item.

  1.x Some text below the list that starts with "1.x"

Expected behavior:

The text below the list should not be indented. In addition to being aesthetically unpleasant, the indentation actually changes the meaning of the code, as you can confirm in the MDX Playground:

• Without the indentation, the text starting with "1.x" is a separate paragraph outside of the list.
• With the indentation, the text starting with "1.x" is a paragraph within the list item above it.

AFAICT this bug occurs whenever a line of text after a paragraph starts with a string of the form \d\.\S+.

[TrevorBurnham]

It looks like this is an issue with remark-parse when the commonmark flag is enabled. With commonmark: false, remark-parse correctly treats the paragraph after the list as a paragraph:

$ parsers.remark.parse('* List\n\n1.0')
{
  type: 'root',
  children: [
    {
      type: 'list',
      ordered: false,
      start: null,
      spread: false,
      children: [Array],
      position: [Position]
    },
    { type: 'paragraph', children: [Array], position: [Position] }
  ],
  position: {
    start: { line: 1, column: 1, offset: 0 },
    end: { line: 3, column: 4, offset: 11 }
  }
}

But with commonmark: true, as used by prettier, the paragraph is incorrectly treated as a list entry:

$ parsers.remark.parse('* List\n\n1.0')
{
  type: 'root',
  children: [
    {
      type: 'list',
      ordered: false,
      start: null,
      spread: false,
      children: [Array],
      position: [Position],
      loose: true
    }
  ],
  position: {
    start: { line: 1, column: 1, offset: 0 },
    end: { line: 3, column: 4, offset: 11 }
  }
}

I'll see if I can put together a test case for the remark-parse folks.

[TrevorBurnham]

I looked into this on the remark-parse side and found that the issue was addressed in remark-parse@9, when they made the switch to micromark. (As of this writing, Prettier is on remark-parse@8, and the latest version is remark-parse@10.)

[TrevorBurnham]

It looks like upgrading to remark-parse@9 is non-trivial because it breaks the API used by Prettier's front-matter plugin. Here's the relevant commit that updated the official remark-frontmatter plugin for the new remark-parse API: remarkjs/remark-frontmatter@fb1357b#diff-e727e4bdf3657fd1d798edcd6b099d6e092f8573cba266154583a746bba0f346

[TrevorBurnham]

Another complication: The micromark-extension-frontmatter dependency that remark-frontmatter now uses is ESM-only, which Prettier isn't set up for. And it looks like this is really only the tip of the iceberg in terms of micromark compatibility issues… 😬

[TrevorBurnham]

I've created an issue to track the task of upgrading Prettier to remark-parse@9: #11828