monotidy

monotidy

go mod tidy, but for multi-module monorepos

Why?

In a multi-module monorepo, when dependabot updates a shared lib's go.mod, this also invalidates the go.sum of all the dependent applications in the same repo (if they use a replace directive for the local relative path), so then go mod verify will fail for those dependents, breaking the build without manual intervention.

Ideally, when we update a shared library directory, we would then run go mod tidy on all the dependent (e.g. application) modules, and commit back the changed go.sum files.

This can be done with a dumb little bash script:

 #!/bin/bash

 # uncommenting below will update all the go modules, and show you if the go.mod is targetting
 # old go versions. Requires go-mod-upgrade

function is_bin_in_path {
  builtin type -P "$1" &> /dev/null
}

function modupdate {
    for D in */; do
        if [ -f "${D}go.mod" ]; then
            echo -e "\033[32m\xE2\x9c\x93 Updating modules for ${D}\n\n\033[0m"
            rm "./${D}go.sum"
            # cat "./${D}go.mod" | grep 'go 1.' # list go version
            cd "${D}"
            #go get -u all
            # ! is_bin_in_path go-mod-upgrade && go get -u github.com/oligot/go-mod-upgrade
            #is_bin_in_path go-mod-upgrade && go-mod-upgrade
            go mod tidy
            # go mod download
            # go mod verify
            # go vet ./...
            cd ..
        fi
    done
}

However, that assumes we have a whole unix environment and Golang dev tools, which bloats the size of any CI container and slows down the whole process.

I want juuuuuust go mod tidy, but from a root directory on all go.mod file containing subdirectories, so I can make a static binary to shove in a scratch container.

Luckily, github's dependabot helpfully scrapes and copies the go tools internal packages and renames them so they are re-usable, so I can reuse them!

Then, I can just hook dependabot up to THIS repo, and it will maintain itself. Muhahahahaha!

insert further mad science here