Migrate to a maintained yaml package

[xqqp]

Testify uses the yaml package provided by https://github.com/go-yaml/yaml. After no development for a long period, a few days ago it finally got archived.
Testify should migrate to another yaml package which is actively maintained. There are some forks of go-yaml which could be considered. There is also https://github.com/goccy/go-yaml, which is not a fork but largely API compatible.

[dolmen]

Note that the default YAML library is still gopkg.in/yaml.v3, that libraray is already user-pluggable (replaceable) in your own test suite by using build tags. See assert/yaml/yaml_custom.go and #1579.

So anyone using testify v1.10.0 can already switch to use any other YAML library right now and this is documented here: https://pkg.go.dev/github.com/stretchr/testify/assert/yaml

[dolmen]

At this point I would prefer to go further and deprecate assert.YAMLEq and assert.YAMLEqf than to deal with compatibility issues between two YAML libraries.

I can't imagine that the two libraries work exactly the same and that the replacement will not raise issues. Instead removing one dependency would make maintenance of the core easier: one less problem to deal with.

[founderio]

To make that happen, an option would be to remove the dependency completely and make testify_yaml_fail or testify_yaml_custom the default behaviour.

Tehnically, testify_yaml_custom without a configured unmarshaller is not that functionally different from testify_yaml_fail, it would just need a default implementation which fails. This would do away with the build tags as well.

For anyone who needs the original behaviour, a code snippet could be provided in the documentation.

[brackendawson]

My first priority here as with all testify issues is to not break existing users or require them to do extra work. Deprecating the function without replacement or removing the implementation of the assertion will cause some people to have to do a non-trivial amount of work.

Continuing to use the archived yaml implementation requires some to do no work, but there will be people who can't use archived transient dependencies due to company policies.

Switching to goccy/go-yaml would require upgrading the minimum version of Go we require to 1.21. I don't think that would cause a lot of work because someone insisting on using the latest testify but also insisting on using an unsupported Go toolchain is quite a contradiction. I have had a play with #1725 and couldn't find a way the libraries behave differently. There may of course be ways and the fuzzer would be an excellent way to find any. I created a fuzz test here: brackendawson@f3aa8e6 but it fails immediately because of goccy/go-yaml#718. So we can already say goccy/go-yaml isn't ready for us to use.

I think my preference would be to move to goccy/go-yaml and increase our minimum Go version. But only once the bug I found in goccy/go-yaml and any other blocking bugs are fixed. There's no rush to do this but a vulnerability in gopkg.in/yaml.v3 would change this.

[founderio]

An option would be to publish that package as a separate module.
This incurs a bit of overhead when publishing versions, as this would be a separate go.mod within the same repository. During update, affected users will need to add another line to their go.mod when updating testify, but everyone who does not need the yaml dependency can just remove it/leave it out.

Not exactly clean, but it would incur minimum effort on user side. And the minimum Go version on the main module could remain the same.

[Victor-Elkins]

I've been reading through some of the documentation for this and I'm trying to figure out how to replace the yaml v3 in such a way that allows me to remove the dependency from my go mod all together. I've read through the documentation and the existing approaches but I'm struggling with understanding some of it. I may just have a knowledge gap with how build tags work, but it seems like even if I were to finish and succeed in this approach I would still have yaml v3 in my go mod. I don't actually require any of the functions that do use yaml v3 either so keeping it isn't really necessary I'm just trying to figure how I can manage to remove it and switch to something else. My main priority here is to just get the yaml.v3 off my go mod if that's at all possible, but I'm thinking it may not be.

[brackendawson]

I've been reading through some of the documentation for this and I'm trying to figure out how to replace the yaml v3 in such a way that allows me to remove the dependency from my go mod all together.

You can't, that's a limitation of the swappable yaml unmarshaller feature. You can prove that you don't use it, even if you do use YAMLEq, but you can't remove it from your go.mod file.

[brackendawson]

goccy/go-yaml#718 was fixed very quickly and I re-ran my fuzz test. It quickly found that the string "�" (go: "\xff") is considered invalid yaml by gopkg.in/yaml.v3 but is considered valid yaml for that string value by github.com/goccy/go-yaml. I think this is valid yaml. This shows that there will be differences in behaviour if we switch the yaml provider, in this case it fixes a bug but there may be regressions too. I'm not going to run the fuzzer any further because it will just find more instances of the same bug in gopkg.in/yaml.v3.

[brackendawson]

Curiosity got the better of me, I wondered if there was a case that both considered to be valid yaml but had different interpretations and there is. "!!0" is considered to be "" by gopkg.in/yaml.v3 but nil by github.com/goccy/go-yaml. I don't know who's right here.