eemeli
Breaking changes for `yaml` v3
I'm considering releasing a new major release of the library once an even-numbered version of Node.js becomes available with require(esm) support, probably at latest sometime around April or May when Node.js 24 is expected to be released.
The major breaking change here would be dropping the separate CJS and ESM builds, and only releasing an ESM bundle, and relying on require(esm) to keep the library usable in CJS environments.
It should be relatively easy to keep the current (v2) version updated with backports, with any security issues getting fixes at least until Node.js 22 goes out of support (or if changes are backported to v22, until Node.js v20 goes out of support).
Are there other changes you'd like to see? Are there config options that you think should have different defaults? Are there API endpoints that you think should work differently? Other breaking changes to consider?
One that comes to my mind is reducing the current flexibility of accepting non-Node contents within the Document. Being more strict about it would clarify the types of values within Document contents quite a bit.
Changing the return type of parse to unknown or a better narrowed type than any could be a good improvement.
Another schema option would be very useful when parsing documents, this could be a good time to dig up the old idea Consider adding JSON Schema support.
Yeah, pretty much the biggest blocker regrading v3 is that I would really like to make it so that you could parse a YAML doc like
a: true
b: true
with an attached JSON schema
{
"type": "object",
"properties": {
"a": { "type": "string" },
"b": { "type": "boolean" }
}
}
and end up with
{ a: 'true', b: true }
but I've not been able to find a sensible way of making that happen.
I would much rather not write yet another JSON schema library, but the few times I've looked, I've found that all of them iterate on the schema rules in order to find any errors in the input data. That doesn't really work well here, as some process is needed that can take the above data and figure out that a: true should result in a string, while b: true should result in a boolean.
For simple examples like this that's of course pretty easy, but JSON schema is pretty powerful, and gets complex rather fast, with multiple rules affecting a single node.
