Replace go-yaml/yaml with goccy/go-yaml

[neiser]

Please describe your feature request. yq increasingly suffers from the fact that the underlying go-yaml/yaml library is rather unmaintained and lacks some important functionality for some yq use cases.

Describe the solution you'd like yq could migrate to a new kid in town, the goccy/go-yaml. According to its README, the library aims to replace the go-yaml/yaml library and has some really nice additional features, such as:

Reversible transformation without using the AST for YAML that includes Anchors, Aliases, and Comments

This feature is in particular interesting for yq -i use cases, which unfortunately might modify whitespace due to limitations in the go-yaml/yaml library.

[mikefarah]

Totally agree, I actually started doing this late 2023 but hit some snags on their repo. I can see That this was closed recently..worth trying again when I get free time

[neiser]

@mikefarah Thanks for your effort! Really appreciate your effort!

[goccy]

@mikefarah Please let me know if the migration is being hindered by an issue with my library. I will prioritize addressing it.

[Mivr]

Hey @mikefarah, will you have time for this soon?

And if not, can you offer some general guidance in case I or anyone else finds the time to work on this?

[yesudeep]

@mikefarah https://github.com/go-yaml/yaml has been deprecated and archived. Can we please update to using https://github.com/goccy/go-yaml

[ccoVeille]

I would say it's urgent to wait for the fork that the YAML organization is now officially supporting

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

[yesudeep]

I believe the existing code for go-yaml can stick around but we should migrate to an implementation fixes issues such as https://github.com/mikefarah/yq/issues/2294. Why not go ahead with the goccy parser and revisit if they bring the implementation up to speed? It would unblock the rest of us that are waiting for this to be fixed in the meantime.

[mikefarah]

Def keeping my eyes on https://github.com/yaml/go-yaml - they haven't actually made any changes or releases afaik. I've just raised an issue against the repo, lets see how it goes.

Re goccy; I'm going to dedicate some time to that in June/July; I've been raising some issues here and there on goccy they are getting fixed which is great :) ; just have to keep going through the tests and make sure it's not going to cause issues.

[neiser]

Thank you all, in particular @mikefarah and @goccy, for keeping up with this and appreciating my initial request!

I just wanted to add a thought which could drive adoption of @goccy's lib: What if goccy/go-yaml offered a package adapter/yamlv3 which provides drop-in replacements for types such as yamlv3.Node and functions like yamlv3.Marshal and yamlv3.Unmarshal. The actual work would be done by goccy/go-yaml internally, of course, but the outer interface would stay as much compatible as possible.

This way tools like yq (and by chance, also my own stuff) would be much easier to migrate piece by piece, I suppose. One could then simply start by replacing all imports like

import (
  yamlv3 "github.com/go-yaml/yaml/v3"
)

to

import (
  yamlv3 "github.com/goccy/go-yaml/adapter/yamlv3"
)

Bonus points could be earned if @goccy's new yamlv3.Node had some extra (maybe private?) fields which track whitespace upon unmarshaling, and use that extra information when marshaling to recover original formatting of the document as much as possible.

[mikefarah]

Yeah that would def make the switch over easier, depending on how closely matched goccy populates and processes the ast w.r.t go-yaml. Other thing to keep in mind is that the official YAML org had taken up go-yaml, which hopefully means official long term support.

On Sat, 21 June 2025, 7:37 pm Andreas Grub, @.***> wrote:

neiser left a comment (mikefarah/yq#2298) https://github.com/mikefarah/yq/issues/2298#issuecomment-2993715667

Thank you all, in particular @mikefarah https://github.com/mikefarah and @goccy https://github.com/goccy, for keeping up with this and appreciating my initial request!

I just wanted to add a thought which could drive adoption of @goccy https://github.com/goccy's lib: What if goccy/go-yaml offered a package adapter/yamlv3 which provides drop-in replacements for types such as yamlv3.Node and functions like yamlv3.Marshal and yamlv3.Unmarshal. The actual work would be done by goccy/go-yaml internally, of course, but the outer interface would stay as much compatible as possible.

This way tools like yq (and by chance, also my own stuff) would be much easier to migrate piece by piece, I suppose. One could then simply start by replacing all imports like

import ( yamlv3 "github.com/go-yaml/yaml" )

to

import ( yamlv3 "githum.com/goccy/go-yaml/adapter/yamlv3" )

Bonus points could be earned if @goccy https://github.com/goccy's new yamlv3.Node had some extra (maybe private?) fields which track whitespace upon unmarshaling, and use that extra information when marshaling to recover original formatting of the document as much as possible.

— Reply to this email directly, view it on GitHub https://github.com/mikefarah/yq/issues/2298#issuecomment-2993715667, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIZHNIWLT4BCNDIKM6Y5X33EWQ6ZAVCNFSM6AAAAABXSTMJSGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDSOJTG4YTKNRWG4 . You are receiving this because you were mentioned.Message ID: @.***>

[mikefarah]

Update: the newly YAML org backed go-yaml has got some good activity (https://github.com/yaml/go-yaml); they've already fixed one bug (https://github.com/yaml/go-yaml/issues/36) which I'm eagerly awaiting the release of!

[mikefarah]

Had a good discussion with Ingy; yq will stick with go-yaml now that it has official support. Should be some nice fixes and features coming soon!