Roundtrip loss: trailing break node in paragraph serializes but doesn't parse back

[gkubisa]

Subject

remark-stringify serializes a trailing break node in a paragraph as \ + newline, but remark-parse does not parse it back as a break — it produces a literal \ in the text instead. This means MDAST trees with trailing breaks in paragraphs don't survive a serialize → parse roundtrip.

Steps to reproduce

import remarkParse from 'remark-parse';
import remarkStringify from 'remark-stringify';
import { unified } from 'unified';

// An MDAST with a trailing break in a paragraph
const tree = {
  type: 'root',
  children: [{
    type: 'paragraph',
    children: [
      { type: 'text', value: 'test' },
      { type: 'break' },
    ],
  }],
};

// Serialize: produces "test\\\n" (backslash + newline)
const md = unified().use(remarkStringify).stringify(tree);
console.log('Serialized:', JSON.stringify(md)); // "test\\\n"

// Parse back: the trailing \ becomes a literal backslash, not a break
const parsed = unified().use(remarkParse).parse(md);
const children = parsed.children[0].children;
console.log('Parsed children:', JSON.stringify(children.map(c => ({ type: c.type, value: c.value }))));
// [{ type: "text", value: "test\\" }] — literal backslash, no break node

Expected behavior

A break node at the end of a paragraph should survive a remark-stringify → remark-parse roundtrip. Either:

1. remark-stringify should not emit \ + newline for a trailing break (since it won't be parsed back), or
2. remark-parse should recognize \ at end-of-paragraph as a hard break

Actual behavior

remark-stringify emits \ + newline, but remark-parse treats \ at end of a block as a literal backslash (per CommonMark spec). The break node is lost and replaced with a literal \ character in the text.

Context

This issue surfaces when converting HTML → Markdown → HTML. A trailing <br> inside <p> (e.g. from a WYSIWYG editor's Shift+Enter) gets converted to a break node in MDAST, serialized as \ + newline, and then parsed back as a literal \ character — showing a visible backslash to the user instead of preserving the line break.

[remcohaszing]

The provided AST is invalid. A break can’t be at the end of a paragraph. So this is garbage in, garbage out.

I agree the current behaviour is a bit confusing. I like proposed option 1: don’t stringify trailing breaks.

I think it’s the responsibility of the user to make sure their AST is valid. The user can remove trailing breaks. Still, we do handle this on some way, and I like option 1 better than the current behaviour.

[gkubisa]

Thank you for the quick reply. Yes, I fully agree that I should provide valid AST. Feel free to close this issue. 👍

[wooorm]

Yeah, I am not aware of a way to create a break, whether in ATX headings or in paragraphs, without anything after it.

Such things are possible with HTML, which is why hast-util-to-mdast has stuff like https://github.com/syntax-tree/hast-util-to-mdast/blob/caab47b64da47d38792e43f4f4c18b439eeb5233/lib/util/drop-surrounding-breaks.js#L19-L20.
But like, there’s only so much that can be done here, this does seem a bit too far to me? How far do you go? Tables in headings? Users can also make html nodes with arbitrary text (that is actually markdown)!

Solution 2 is not possible, that breaks CM.
There is another alternative to 1: result in a\\n . But I am not really advocating for this 1b.

I’d softly lean to not doing anything and closing.
Greg, perhaps you can share, why not use hast-util-to-mdast?
Remco, how strong do you feel about having logic like hast-util-to-mdast and solution 1 (or my 1b), instead of garbage-in/out and closing this?

[remcohaszing]

I feel like 1b might be slightly worse. The trailing space may be more unexpected than the trailing slash.

Another option would be to throw errors when trying to serialize invalid ASTs. Although maybe some people won’t like that either.

There’s no technically correct solution. I really don’t feel strongly about keeping the current behaviour or changing it.