Skip to content

chore: migrate yaml to go.yaml.in/yaml/v3#362

Open
andreynering wants to merge 1 commit intomasterfrom
yaml-pkg
Open

chore: migrate yaml to go.yaml.in/yaml/v3#362
andreynering wants to merge 1 commit intomasterfrom
yaml-pkg

Conversation

@andreynering
Copy link
Contributor

@andreynering andreynering commented Feb 1, 2026

go.yaml.in/yaml/v3 is the new official YAML package maintained by the YAML org. This is a fork from the old gopkg.in/yaml.v3 has been unmaintained for a while.

@andreynering andreynering requested a review from slsyy February 1, 2026 21:38
@andreynering andreynering self-assigned this Feb 1, 2026
Comment on lines +784 to +793
var buf bytes.Buffer
encoder := yaml.NewEncoder(&buf)
if err := encoder.Encode(valueNode); err != nil {
return nil, fmt.Errorf("testfixtures: could not encode value: %w", err)
}

var records any
if err := yaml.Unmarshal(buf.Bytes(), &records); err != nil {
return nil, fmt.Errorf("testfixtures: could not unmarshal value: %w", err)
}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It might be a good idea to have a custom type to avoid this marshal/unmarshall process here.

@ccoVeille
Copy link

Hi

I'm one of the yaml/go-yaml maintainer

I would like to suggest you to use the v3.0.4 version

The main branch from where we created an -rc is moving fast, and we should have named it an alpha.

@andreynering
Copy link
Contributor Author

@ccoVeille Good to know. I've been using the 4 RC version on many projects.

"Release Candidate" usually means it practically the final version, so yes it's a bit confusing.

@ccoVeille
Copy link

I know 😅

We introduced something about new error struct around 4.0.0-rc2 that didn't meet or expectations.

We have just found out it would be problem with the latest PR when we released the -rc4

It's not a big thing. But enough to question us about our choices.

So here we are actively defining the best option.

But if you are not relying on yaml error struct s you are safe to use the -rc4

@slsyy
Copy link
Contributor

slsyy commented Feb 2, 2026

@andreynering any reason to migrate from github.com/goccy/go-yaml? I remember we migrated from gopkg.in/yaml.v3 to github.com/goccy/go-yaml due to:

  • better features (for spanner ordered map semantic)
  • yaml.v3 was unmaintained

@ccoVeille pls share your feedback, I guess you know both libraries

Comment on lines +766 to +768
if node.Kind == yaml.DocumentNode && len(node.Content) > 0 {
node = *node.Content[0]
}

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this would be unnecessary when this will be merged and released

@andreynering
Copy link
Contributor Author

gopkg.in/yaml.v3 was unmaintained, indeed, but go.yaml.in/yaml/v4 is its fork now maintained officially by the YAML org. This will be the default YAML package in the Go community from now on.

As an anedotic story, we do advanced usage of YAML on Task and were never able to migrate to goccy/go-yaml because it didn't fit our needs. Only once we had the official fork we managed to migrate.

All that said, this is far from urgent. If v4 is alpha, we can hold this PR until that's more stable if we decide to.

@andreynering andreynering changed the title chore: migrate yaml to go.yaml.in/yaml/v4 chore: migrate yaml to go.yaml.in/yaml/v3 Feb 17, 2026
andreynering added a commit to go-task/task that referenced this pull request Feb 17, 2026
According to one of the maintainers, `go.yaml.in/yaml/v4` is still alpha
and they called it "rc" by mistake.

In fact, our dependency update PRs are failing because they're still
pushing breaking changes to v4.

* go-testfixtures/testfixtures#362 (comment)
* #2661
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants