Values ending in space or newline get odd treatment by bundle and join

[steve-nay-sage]

Describe the bug I have some multiline descriptions in my OpenAPI schemas. Here's an example of a tag description:

tags:
  - name: Contacts
    description: |
      You can think of contacts as a common, shared address book that's used across a company by many people for a variety of purposes. Contacts hold all the information needed to contact an individual or business, including name, email address, phone number, mailing address, and more. 

      Contacts are almost always used with other Sage Intacct objects, such as vendors, customers, or locations. For example, you specify a contact in Order Entry and Purchasing transactions to set a ship-to, bill-to, pay-to, or return-to addresses, and to determine tax on transactions.

servers:
  - url: 'http://localhost:3000'

Notice the empty line at the end of the description. That--or if the last character is a space instead of new line--results in strange output from the bundle and join operations. Here is the result after bundle:

tags:
  - name: Contacts
    description: "You can think of contacts as a common, shared address book that's used\nacross a company by many people for a variety of purposes. Contacts hold\nall the information needed to contact an individual or business, including\nname, email address, phone number, mailing address, and more. \n\n\nContacts are almost always used with other Sage Intacct objects, such as\nvendors, customers, or locations. For example, you specify a contact in\nOrder Entry and Purchasing transactions to set a ship-to, bill-to, pay-to,\nor return-to addresses, and to determine tax on transactions.\n"
servers:
  - url: http://localhost:3000

Notice that it's no longer a multi-line text field, is wrapped in quotes, and \n has been inserted where it thinks there need to be line breaks (which may be based on a max line length setting?) .

In one sense this is just an aesthetic issue, as the display of the field looks the same in Redocly. But it looks pretty odd when I go in and look at the file after bundling. I'd call it a minor bug.

To Reproduce Steps to reproduce the behavior:

1. Create an OpenAPI file with a multi-line description field. Put a space or a newline at the end of the field.
2. Run redocly bundle on the file. I think redocly merge does the same thing, but you need multiple files to test that.
3. Look at the description field in the bundled file.

Expected behavior The description field should still be a multi-line text field, without inserted newlines. It's fine to trim any extra white space off the end.

Redocly Version(s) 1.0.0-beta.102

Node.js Version(s) v18.7.0

[adamaltman]

This is not a bug. \n means line break.

In YAML, try the block literal "strip" behavior:

description: |-

https://redocly.com/docs/yaml/blocks-and-flows/#ending-line-breaks-for-blocks

[steve-nay-sage]

Okay, perhaps this isn't a bug, but the design might be open to question. My source file is using literal blocks with clip endings, and it gets converted to a string that is not a block, with newlines inserted where there were none before. Is there a reason why it has to be changed at all? Sometimes the bundle and join operations change a pipe character that marks a block literal to a > to make it a folded block, and my expectation is that the tool would not change my files like that.

Strange changes are also made if the multi-line block ends in a space character. The block clip/strip/keep setting shouldn't care about spaces, just newlines.

[adamaltman]

I think the issue relates to an external library related to yaml parsing and we don't have any plans to replace that. It may be a configuration issue, so I'll leave this open for investigation.

[lornajane]

Seems related to #649

[RomanHotsiy]

It's not directly related.

We use yaml parser for working with yaml files. There is no reliable yaml parser for node that works based on AST. All yaml parsers parse yaml into the JS object.

When we serialialize it back yaml parser has no idea which form of string you used, all it knows is the string contents so the parser uses some rules to decide if use string in quotes or block literal. So we don't have a way to preserve the original format.

My source file is using literal blocks with clip endings, and it gets converted to a string that is not a block, with newlines inserted where there were none before.

I checked your example in more details and it seems weird indeed.

This newline should not be there indeed.

@tatomyr we need to take a look at it. I think there may be some double-encoding leading to this.