Scenario: I need to update a third party Go Module to a new major version across a repository.
Example: github.com/google/go-github/v20
to github.
A good automated solution is https://github.com/marwan-at-work/mod, which can automatically add, remove, or change the required /vN
in your *.go
code and your go.mod
.
Using your example, it should be able to update your code from using github.com/google/go-github/v20
to instead use github.com/google/go-github/v24
.
From the repository:
Motivation
There are two good use cases to do this:
If you own a library and you want to introduce a breaking change, then you have to go around all your Go files and sub-pacakges and update the import paths to include v2, v3, etc. This tool just does it automatically with one command.
If you own a library that is already tagged v2 or above but is incompatible with Semantic Import Versioning, then this tool can solve the problem for you with one command as well. Introduce a go.mod file with the correct import path, and just run mod upgrade once or mod -t=X upgrade (where x is the latest tag major) to update the import paths of your go files to match whatever tag you're at.
In addition to those two use cases, this utility also relatively recently added support for automatically upgrading clients to use a different major version of a module by changing the /vN
in the client's *.go
code and the client's go.mod
.
In other words, this utility can be used if you are the author of a module going from v2
to v3
, and it can also be used if you are the consumer of a module going from v2
to v3
.
It uses packages such as golang.org/x/tools/go/ast/astutil
to manipulate the AST of *.go
source in order to update import paths, and hence should not be susceptible to the types of concerns you expressed about using sed
.
As a new major version indicates breaking compatibility you will have to fix your code manually anyway: Updating the import path in case of a new major version is your least concern to automate.