TIL: go fix Reaches Into Third-Party Code Too

I’ve been running go fix on every Go project of mine, since the Go team rewrote it into a real modernizer. It helps me stay up-to-date with changes inside of the standard library, as well as new idioms and language upgrades. This is a very good practice when using AI agents to write code for you, because they are not always up-to-date on those changes. I was susprised to find out that go fix can even poke into, and introduce changes suggested by third-party dependencies, too..

Here’s how I found out:

In my Go projects, I use a library called tint, which brings color to slog-style dev logs. Usually, I would write tint.NewHandler to instantiate it. However, this time, after I ran go fix ./..., it automatically changed it to tint.NewTextHandler. I reverted and tried again, and the result was the same.

I poked into tint’s code, and this turned up:

// Deprecated: Use [NewTextHandler] instead.
//go:fix inline
func NewHandler(w io.Writer, opts *Options) slog.Handler {
	return NewTextHandler(w, opts)
}

With that //go:fix inline directive, added alongside the new go fix, any package author can attach a machine-executable migration to their own deprecation notice. go fix would read it and rewrite every call site across the dependency graph.

Now that I saw that, I think I’d read something about it from the Go team, regarding refactorign one’w onw code. Yet, I never thought as far as to assume that it applies to third-party code as well. Makes sense.