`gopkg.in/yaml.v3` is unmaintained, consider migrating to `https://github.com/yaml/go-yaml`

[andreynering]

Description

gopkg.in/yaml.v3 is now unmaintained: https://github.com/go-yaml/yaml?tab=readme-ov-file#this-project-is-unmaintained

We should consider migrating to https://github.com/goccy/go-yaml

I think we considered this migration in the past, but I don't remember why we didn't switch over. I may be tricky because our use is quite advanced.

Good thing gopkg.in/yaml.v3 is very stable, so we don't need to hurry into this.

---

Edit by @pd93: Consider using https://github.com/yaml/go-yaml instead as its being supported by the YAML org.

[pd93]

I think we considered this migration in the past, but I don't remember why we didn't switch over. I may be tricky because our use is quite advanced.

I attempted this when we implemented our fancy YAML error snippets as goccy/go-yaml does something similar for free. However, I had trouble with the interface provided by their package as at the time it only offered a InterfaceUnmarshaler which looks similar to the gopkg.in/yaml.v2 interface and doesn't expose the Node like gopkg.in/yaml.v3. This made handling custom types like we do very difficult.

It looks like very recently, a new NodeUnmarshaler type was added that may unblock this. I'm happy to take a look again in the coming days.

[pd93]

Very quick initial look. I don't think it's not going to be particularly easy to switch without further changes upstream or major changes to the way we unmarshal YAML. Their ast.Node does not have any kind of Decode or Contents methods which makes it pretty useless to us. As far as I can tell, the only way we could implement our current design would be to attempt to unmarshal to each type one at a time until we find one that doesn't error. This is less than ideal.

I also find their list of projects using their parser to be quite disingenuous at best. I took a look at some of them for examples of how it was being used. Out of the top 5:

• etcd (48K) - Indirect dependency via github.com/mikefarah/yq/v4 which is no longer used. Actually uses gopkg.in/yaml.v3
• LazyDocker (39K) - Uses Goccy in 1 file but mostly github.com/jesseduffield/yaml
• GraphQL Engine (31K) - Uses Goccy, but falls back on gopkg.in/yaml.v3 in the only place UnmarshalYAML is called.
• Trviy (24K) - Indirect dependency. Actually uses gopkg.in/yaml.v3
• Tailscale (20K) - Indirect dependency. Actually uses sigs.k8s.io/yaml

And this pattern continues down the list.

[andreynering]

Thanks for taking a look!

This is for sure not prioritary, as we are not facing any particular issues or limitations with gopkg.in/yaml.v3. We can decide to keep things as is for now, if we want.

I'm sure that are other things that are more worth our time at the moment.

[digitive]

YAML organization is now officially supporting

https://github.com/yaml/go-yaml

[pd93]

@digitive Thanks for linking. I hadn't seen that it was being adopted by the YAML org. That's great news! In that case, I think this issue can be used to track the migration to the new official YAML fork. However, it seems that it's not quite ready to be used in production yet. Let's wait until the YAML team are happy to announce it officially and then we can move forwards with this. In the meantime, using the old gopkg.in/yaml.v3 package isn't doing any harm.

[andreynering]

This is news for me as well. I’m happy to know!

[andreynering]

I just opened:

• refactor: migrate to the official yaml package #2434