Emphasis with extra whitespace inside is parsed when it should not be

[mariechatfield]

According to the GitHub Flavored Markdown Spec, emphasis and strong emphasis should only be parsed when opened by a left-flanking delimiter run and closed by a right-flanking delimiter run, where:

• a left-flanking delimiter run is not followed by Unicode whitespace
• a right-flanking delimiter run is not preceded by Unicode whitespace

In Example 361, they show that a * foo bar* should not be parsed as emphasis since there is white-space between the opening asterisk and the text.

react-markdown is incorrectly parsing emphasis and strong emphasis with white space before and after the text.

react-markdown

| Sample                   | Should it parse? | Correct Behavior? |
|--------------------------|------------------|-------------------|
| __bold__                 | yes              | ✅                |
| __ starting space bold__ | no               | ❌                |
| __ending space bold __   | no               | ❌                |
| _italic_                 | yes              | ✅                |
| _ starting space italic_ | no               | ❌                |
| _ending space italic _   | no               | ❌                |

GitHub

| Sample                   | Should it parse? | Correct Behavior? |
|--------------------------|------------------|-------------------|
| __bold__                 | yes              | ✅                |
| __ starting space bold__ | no               | ✅                |
| __ending space bold __   | no               | ✅                |
| _italic_                 | yes              | ✅                |
| _ starting space italic_ | no               | ✅                |
| _ending space italic _   | no               | ✅                |

Workaround

It looks like setting parserOptions.pedantic prevents this behavior:

<ReactMarkdown parserOptions={{ pedantic: true }} />

But I'm fairly certain that React Markdown is meant to support GFM out of the box, so I think this is still a bug.

[ChristianMurphy]

this is an upstream issue being tracked at remarkjs/remark#306 and will be resolved by remarkjs/remark#439