How to prevent remark-stringify from trimming trailing newlines from handler return values?

[NickSto]

Hi, I'm trying to customize remark-stringify, so I recently tried to define my own handler for a particular node type:

  .use(remarkStringify, {handlers: {break: _ => '  \n'}})

But then the resulting output seems to lack the newline returned by the handler. I ended up having to use a workaround where I inserted an empty text node right after the break, which seems to prevent this.

But now I'm running into this again, when making a custom text node handler. It seems trimming newlines is a general rule for this compiler?

I'm wondering why, in what situations, or at least how to prevent it?

Update

I guess I've found part of the answer to "why": syntax-tree/mdast-util-to-markdown#15
So this only happens when the node following the newline is html?
For reference, this is where the trimming is done: https://github.com/syntax-tree/mdast-util-to-markdown/blob/main/lib/util/container-phrasing.js#L28

I'm still not sure how to achieve my real goal, which is to represent breaks as ' ​ \n', even when followed by an html node. The other problem I was trying to solve is round-tripping joining two separate lines like:

any text
<span>inline element</span>

into a single one like:

any text <span>inline element</span>

I was trying to preserve such input as two separate lines. But the newline gets trimmed off the end of any text\n (a text node) before stringifying.

[wooorm]

• Why do you want the legacy break format (two trailing spaces, then a line ending)?
  It’s something that many users have found complex, and tools have often trimmed away
• Why is this exact roundtripping important? remark does roundtrip in meaning, but can’t always exactly match the input

[NickSto]

I personally prefer the double-space break, and I have the impression it's more widely known and backward compatible, but I could be wrong. I found the backslash notation confusing because in most languages a backslash at the end of a line is meant to escape the newline, removing a line break instead of adding one.

As for exact roundtripping, I cared about it because I was trying to use the remark parser to make automatic changes across a codebase of Markdown content. So I didn't want to make a lot of changes aside from the specific cases I wanted to alter. I was only using remark because the changes I wanted to make were beyond regex hacks (and it's nice use an actual parser instead of regex hacks).

But at this point I think it's clear I should abandon that approach and instead do on-the-fly changes on display and keep the codebase the same.

[wooorm]

If you have a lot of content, you could do one big refactor where remark formats things, and then do on-the-fly changes afterwards? That formatting will help streamline all content. And you might also use remark-lint to integrate a bunch of checks to ensure markdown is otherwise uniform.

remark also exposes positional information. If you want to edit small parts of the source, without touching the rest, location info can be used?

[NickSto]

Yeah, I realized in order to do the small, targeted changes I wanted, I'd probably need a different library that has a specific focus on preserving all the original formatting, not just the logical structure.

Or I could get into using the positional information remark gives. Perhaps I could even build a library for small, targeted changes on top of it! Sounds like a fun project, but realistically I won't have the time. Maybe I'll give it a shot if the on-the-fly plan doesn't work out.

[wooorm]

magic-string (https://github.com/Rich-Harris/magic-string) might help there. With the positions, and that project, you should have most things to do what you want to do!