js-yaml is tagged as obsolete by ban-dependencies / module-replacements

[jandppw]

js-yaml is used as the preferred YAML parser in parser.js Parser.yamlParser, line 142, with the argument in comments that it is "the better js-yaml module".

js-yaml is flagged as obsolete by the eslint plugin ban-dependencies, based on es-tooling/module-replacements.

I suggest reversing the preference.

Note 1

The reasoning is that users should include a dependency on their favorite parser as a "peer dependency" in their project. However, with the code as it is in parser.js Parser.yamlParser, this doesn't work like that. In this case, e.g., take a project that does not have js-yaml as direct production dependency. If it is a devDependency, or an indirect dependency of any of the direct dependencies in the project, js-yaml will be found first and be used nevertheless.

Note 2

The cause of us finding this out is "amusingly" complex. Readers should be aware that js-yaml and yaml do not behave exactly the same.

In our case, we got caught by the fact that yaml, out of the box, does not put quotes around strings in output when they are not needed, while js-yaml does. The YAML output of

{
    …
    committedAt: new Date(Number.parseInt(gitData.committedOn) * 1000).toISOString(),
    …
}

with yaml is (1)

  …
  committedAt: 2025-08-05T15:14:10.000Z
  …

while with js-yaml it is (2)

  …
  committedAt: '2025-08-05T15:14:10.000Z'
  …

When reading with js-yaml (2) returns a JavaScript string. When reading with js-yaml (1) returns a JavaScript Date.

[jdmarshall]

so you're suggesting the 'yaml' package instead?

@markstos 405k + 172k -> 683k for the conversion. Opinions?

[jandppw]

I suggest reversing the preference.

That is probably the safer option? Removing support for js-yaml altogether might make life more difficult for some people.

It is still a stopgap. A real solution might be to explicitly first look for direct dependencies in package.json, and decide on that if possible, with the current decision mechanism as fallback.

[markstos]

I would go with yaml because it is very popular, highly depended on and recently updated.