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.