https://github.com/stevenacoffman/monotidy
go mod tidy, but for multi-module monorepos via mad science
https://github.com/stevenacoffman/monotidy
Last synced: about 1 year ago
JSON representation
go mod tidy, but for multi-module monorepos via mad science
- Host: GitHub
- URL: https://github.com/stevenacoffman/monotidy
- Owner: StevenACoffman
- License: mit
- Created: 2021-08-07T20:04:15.000Z (almost 5 years ago)
- Default Branch: main
- Last Pushed: 2021-09-13T20:56:46.000Z (over 4 years ago)
- Last Synced: 2025-04-10T16:23:20.737Z (about 1 year ago)
- Language: Go
- Homepage:
- Size: 16.6 KB
- Stars: 5
- Watchers: 2
- Forks: 1
- Open Issues: 1
-
Metadata Files:
- Readme: README.md
- License: LICENSE
Awesome Lists containing this project
README
### 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:
```shell
#!/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_