feat: Add --merge option to CLI tool

[danielbayley]

# test.yaml
a: &a
  a: 2
b:
  <<: *a

yaml --single --merge --json < test.yaml

{
  "a": {
    "a": 2
  },
  "b": {
    "a": 2
  }
}

[eemeli]

Do you have a use case for this that isn't solved by --yaml 1.1? As in, are you actually working with documents that extend the YAML 1.2 schema with support for << merge keys, or are you working with YAML 1.1 documents?

[danielbayley]

are you working with YAML 1.1 documents?

Well I'm not currently using old documents which I have no control over, if that's what you mean?

But I don't want to be stuck on the 1.1 spec to be able to retain the use of << merge keys going forward…

This PR simply enables the existing merge option. Is the rationale different between the underlying API, and the CLI?

Also, out of curiosity, why was the << merge key removed in the 1.2 spec? @eemeli

[eemeli]

This PR simply enables the existing merge option. Is the rationale different between the underlying API, and the CLI?

Yeah, a bit. I'd prefer to keep the CLI pretty minimal, rather than presuming that all the options it could have would have actual use.

Regarding --merge my concern is that in other tools supporting << tends to correlate with presuming YAML 1.1 values in general, where e.g. infamously the plain sclarar no parses as a boolean. So if you're using the yaml CLI to emit YAML without --yaml 1.1 but still reading the output elsewhere with a YAML 1.1 parser, you could get surprised by the results.

Are there other parses than yaml that you're using to work with your documents?

Also, out of curiosity, why was the << merge key removed in the 1.2 spec?

I'm afraid I wasn't around during that transition, so can't speak authoritatively. But as an implementer, it works very differently from anything else in the language and isn't really well defined.

[danielbayley]

I'd prefer to keep the CLI pretty minimal

Not an ureasonable sentiment, but this is a single option, for a substantial feature—substantial in it's ability to cut down on a lot of duplicate config at least…

infamously the plain scalar no parses as a boolean.

Which is exactly the kind of thing I'm getting at… I definitely don't want plain scalar yes/no to ever be parsed as boolean, but do want to retain << merge ability… So if the CLI is arbitrarily restricted to --yaml 1.1 as the only way to enable the latter, I'm kind of screwed.

Are there other parses than yaml that you're using to work with your documents?

YAMLScript, and sometimes js-yaml, but I am trying to migrate everything possible over to this superior package, including replacing js-yaml in pnpm with this.

[eemeli]

I definitely don't want plain scalar yes/no to ever be parsed as boolean, but do want to retain << merge ability… So if the CLI is arbitrarily restricted to --yaml 1.1 as the only way to enable the latter, I'm kind of screwed.

Ok, that makes sense. I added a couple more tests just to make sure the option was working as intended, but the code itself looks good.