Update dependency yaml to v2 #145

renovate · 2022-09-29T10:30:33Z

This PR contains the following updates:

Package	Change	Age	Adoption	Passing	Confidence
yaml (source)	`1.10.2` -> `2.3.1`

Release Notes

eemeli/yaml (yaml)

`v2.3.1`

Compare Source

Drop npm from package.json "engines" config (#476)

`v2.3.0`

Compare Source

This release corresponds with the release of yaml-types v0.2.0, an expanding library of custom tags or types for use with yaml.

This release contains no changes from v2.3.0-5, and the notes below include all changes from the v2.3.0-x prereleases.

Custom Tag Improvements

Add export of createNode() & createPair() to 'yaml/util' (#457)
Add static from() methods to simplify tag development, and otherwise make extending custom collections easier (#467)

TypeScript Improvements

Add a second optional generic type argument Strict to Document instances. (#441)
Add types exports for TypeScript (#463)
Export StringifyContext type from 'yaml/util' (#464)

Other New Features

Add a toJS(doc, options?) method to nodes (#451, #458)
Set explicit tag during createNode() for non-default tags (#464)

Bugfixes

Use correct argument order when stringifying flow collection comments (#443)
Improve first-line folding for block scalars (#422)

`v2.2.2`

Compare Source

This patch release includes a fix for an error that could be thrown in parseDocument for degenerate input. Otherwise, it's a patch release uplifting a few fixes from the ongoing v2.3 work to v2.2:

Corner case failure in error pretty-printer (CVE-2023-2251)
Use correct argument order when stringifying flow collection comments (#443)
First-line folding for block scalars (#422)

`v2.2.1`

Compare Source

Quote top-level map keys containing document markers (#431)

`v2.2.0`

Compare Source

New Features

Add flowCollectionPadding toString option (#420)
Use indicator line for props on block collection values of mappings (#425)

Bugfixes

Minor relaxation of types for custom tags (#429)

`v2.1.3`

Compare Source

Set correct node-end position for block collections with comments (#413)

`v2.1.2`

Compare Source

Set correct node-end position for empty values with comments (#413)

`v2.1.1`

Compare Source

No changes in executable code, only TS types.

Revert "Use TS named tuple for range (#385)" -- see #393
Fix types for compatibility with TS 4.2 and 4.7
Add CI workflow for testing published type in a range of TS versions

`v2.1.0`

Compare Source

Fixes for TypeScript users. Arguably this could've been a patch release as well.

Improve/specify/fix TS types for Document & collection access methods (#383)
Use TS named tuple for range (#385)
Rename internal Document option as _directives to resolve type conflict with ToString options (#389)
Update tsc target to ES2020 to match Node.js support
Update dev dependencies, including jest 28

`v2.0.1`

Compare Source

Fix tags and anchors on map keys (#378)

`v2.0.0`

Compare Source

This update has been in the works for the last year and a half. Its prerelease versions have been thoroughly tested by a wide number of users, and I think it's finally ready for "actual" release, for use in the mythical "production".

The breaking changes introduced here are mostly originating from the v1 CST parser having become a rather difficult beast to work with. So it's here rewritten pretty much completely, now with a lexer as a first stage. Along the way, the whole project was rewritten in TypeScript and the export paths and options refactored pretty deeply.

If you've been using the library just via its parse(), parseDocument() and stringify() functions, then it's quite likely that none of the changes affect your experience in any way. However, if you've been doing something more involved, then I would strongly recommend that you review the library's documentation site for the v2 docs.

Going forward, it's finally time to start experimenting with new YAML spec features that may eventually be included in YAML 1.3 and later. Those will be made available by specifying the version: 'next' option. However, beware! Any features available this way may be removed or have their API broken by any minor release of this library, and no compatibility guarantees with other libraries are given. In general, semver compatibility is guaranteed for features that are explicitly included in the documentation; everything else should be considered as internal implementation details.

The following is an overview of the breaking changes and new features introduced in each of the prerelease steps leading up to this release; the individual releases' notes and the PRs will contain more detail, along with specific migration guides.