[Bug?]: Yarn generates invalid yaml with keys longer than 1024 chars

[elado]

Self-service

• I'd be willing to implement a fix fix(parsers): correctly stringify keys longer than 1024 chars #4275

Describe the bug

I have a large monorepo, and frequently run dedupe on some packages. Recently yarn dedupe resolve led to a key longer than 1024 chars, making the yaml invalid according to the yaml 1.2 spec, and failing to parse with other libraries (even js-yaml).

Example:

"resolve@patch:resolve@^1.0.0#~builtin<compat/resolve>, resolve@patch:resolve@^1.1.10#~builtin<compat/resolve>, resolve@patch:resolve@^1.1.4#~builtin<compat/resolve>, resolve@patch:resolve@^1.1.5#~builtin<compat/resolve>, resolve@patch:resolve@^1.1.6#~builtin<compat/resolve>, resolve@patch:resolve@^1.10.0#~builtin<compat/resolve>, resolve@patch:resolve@^1.12.0#~builtin<compat/resolve>, resolve@patch:resolve@^1.13.1#~builtin<compat/resolve>, resolve@patch:resolve@^1.14.2#~builtin<compat/resolve>, resolve@patch:resolve@^1.15.1#~builtin<compat/resolve>, resolve@patch:resolve@^1.17.0#~builtin<compat/resolve>, resolve@patch:resolve@^1.19.0#~builtin<compat/resolve>, resolve@patch:resolve@^1.2.0#~builtin<compat/resolve>, resolve@patch:resolve@^1.20.0#~builtin<compat/resolve>, resolve@patch:resolve@^1.3.2#~builtin<compat/resolve>, resolve@patch:resolve@^1.3.3#~builtin<compat/resolve>, resolve@patch:resolve@^1.4.0#~builtin<compat/resolve>, resolve@patch:resolve@^1.8.1#~builtin<compat/resolve>, resolve@patch:resolve@^1.9.0#~builtin<compat/resolve>":
  version: 1.21.0
  resolution: "resolve@patch:resolve@npm%3A1.21.0#~builtin<compat/resolve>::version=1.21.0&hash=07638b"
  dependencies:
    is-core-module: ^2.8.0
    path-parse: ^1.0.7
    supports-preserve-symlinks-flag: ^1.0.0
  bin:
    resolve: bin/resolve
  checksum: a0a4d1f7409e73190f31f901f8a619960bb3bd4ae38ba3a54c7ea7e1c87758d28a73256bb8d6a35996a903d1bf14f53883f0dcac6c571c063cb8162d813ad26e
  languageName: node
  linkType: hard

The working way is to use ? as a prefix and : in a new line, and the key can be any length.

? long key
: foo: bar

E.g.

? resolve@patch:resolve@^1.0.0#~builtin<compat/resolve>, resolve@patch:resolve@^1.1.10#~builtin<compat/resolve>, resolve@patch:resolve@^1.1.4#~builtin<compat/resolve>, resolve@patch:resolve@^1.1.5#~builtin<compat/resolve>, resolve@patch:resolve@^1.1.6#~builtin<compat/resolve>, resolve@patch:resolve@^1.10.0#~builtin<compat/resolve>, resolve@patch:resolve@^1.12.0#~builtin<compat/resolve>, resolve@patch:resolve@^1.13.1#~builtin<compat/resolve>, resolve@patch:resolve@^1.14.2#~builtin<compat/resolve>, resolve@patch:resolve@^1.15.1#~builtin<compat/resolve>, resolve@patch:resolve@^1.17.0#~builtin<compat/resolve>, resolve@patch:resolve@^1.19.0#~builtin<compat/resolve>, resolve@patch:resolve@^1.2.0#~builtin<compat/resolve>, resolve@patch:resolve@^1.20.0#~builtin<compat/resolve>, resolve@patch:resolve@^1.3.2#~builtin<compat/resolve>, resolve@patch:resolve@^1.3.3#~builtin<compat/resolve>, resolve@patch:resolve@^1.4.0#~builtin<compat/resolve>, resolve@patch:resolve@^1.8.1#~builtin<compat/resolve>, resolve@patch:resolve@^1.9.0#~builtin<compat/resolve>
: version: 1.21.0
  resolution: "resolve@patch:resolve@npm%3A1.21.0#~builtin<compat/resolve>::version=1.21.0&hash=07638b"
  # ...

Yaml seems to implement its own yaml parser, syml, that isn't spec compliant. Dumping the object with js-yaml generates proper yaml. Is there anything special about syml that js-yaml can't do?

Example of parse error

Example with proper long key

To reproduce

Links above.

Environment

System:
    OS: macOS 12.2.1
    CPU: (10) arm64 Apple M1 Max
  Binaries:
    Node: 16.13.1 - /private/var/folders/8r/75v81kkd78x69n_wmwh_1c2h0000gp/T/xfs-4f26fda1/node
    Yarn: 3.1.1 - /private/var/folders/8r/75v81kkd78x69n_wmwh_1c2h0000gp/T/xfs-4f26fda1/yarn
    npm: 8.1.2 - ~/.nvm/version/npm

Additional context

No response

[merceyz]

Is there anything special about syml that js-yaml can't do?

It was implemented for performance but that might have changed in the four years after it was implemented.

[arcanis]

It was implemented for performance but that might have changed in the four years after it was implemented.

Also to have a consistent formatting in all the file, and to handle "arrays as keys" (comma-separated ranges).

[merceyz]

The fix has been backported and released in v3.2.1