@thorn0 Can you review this, when you got time? This is actually quite big change, because it called unsafe normalizeDoc on "Root", and I removed it. But maybe normalizeDoc was safe before we extract to doc-utils.js

Ooops, I keep forgetting about this one...

The doc for #9503 still doesn't look right:

[
  fill([
    conditionalGroup([
      group([/*...*/]),
      group([/*...*/]),
    ]),
    " ", // <--- should be `line`
    "is",
    line,
// ...

Yes, this is a big one. My research plan so far:

MDX: line break inserted between elements and text in JSX blocks

<asdf/>zxcv

• Prettier 2.2.1 parses it all as JSX (not Markdown) and prints line breaks the way it normally does for JSX.
• That's probably not the expected output. That's why MDX: line break inserted between elements and text in JSX blocks #6961 was opened.
• Also there is a fill bug that causes v2.2.1 to print <Hello></Hello><Hello></Hello>123 without that break.

  [
    fill([
      group(["<Hello", indent([]), ">"]),
      "</Hello>", // <--- Problem! Odd-indexed elements must be line breaks.
      hardlineWithoutBreakParent,
      breakParent,
      group(["<Hello", indent([]), ">"]),
      "</Hello>",
      softline,
      "123"
    ]),
    hardline,
  ]

• Things to look into:
  1. The fill bug
     1. Is the bug in Inline React components in MDX cause line lengths to exceed print-width #9503 same or different?
     2. How did it work in older versions?
     3. Was normalizeDoc safe before it got extracted to doc-utils?
     4. Manipulations with normalizeDoc and cleanDoc (in particular, PR Refactor markdown paragraph print #9847) look like they might affect more things in Markdown than just MDX. What else can be affected?
  2. What actually is the expected output?
     1. Is the whitespace between the tag and the text significant?
     2. Should the text be parsed as JSX or as Markdown?