go.mod の go directive を上げた モジュールを特定する

go.mod の go directive を上げた モジュールを特定する 市川恭佑(@ebi-yade) 2024年12月13日 @ kamakura.go

Who is 市川恭佑 󰳕 IT エンジニアをやっています ● カヤック SRE 新卒3年目 ● オブザーバビリティとかコンテナとか 🚶 Go は5年目ぐらい ● 学生の頃から ● 最近は使い捨てスクリプトも Go

とは言っても約5年間、 テキトーに Go と向き合ってきた

POV: Dependabot 等が仕込まれていない プロジェクトの依存を更新するとき

$ go get -u ./...

だいたい動くから OK! ちょっと突いたら顔真っ赤にして gyp ERR! ってキレてくる アイツとは大違いだぜ！

依存に引っ張られて Go バージョンが上がっても割と問題ない！

依存に引っ張られて Go バージョンが上がっても割と問題ない！ 厳密には go ディレクティブ （Go 1.21 で色々あった）

Go 1.21 以降の go ディレクティブは 「ビルド可能な最小の Go バージョン」 → インストールされている Go のバージョン が追いつけばいいだけじゃん

- FROM golang:1.22.x + FROM golang:1.23.y

どんな環境でも最新 バージョンで良いとは 限らない

$ go get -u で go ディレクティブが 更新されるとき、現場では...

↓ go ディレクティブの更新 ↑更新された依存モジュールがズラズラ並ぶ 何が原因で go ディレクティブが上がったか、 という情報はない

ebi-yade/why-go-over つくりました！ なんで 1.22.4 から上がったんや？！ うちの環境で 1.23 は使えんよ！！！

注意 🧪 RC には対応していません ● バージョン比較は semver パッケージで雑に実装したため ● $ why-go-over 1.23rc1 とかは無理 ● 依存モジュール側が要求した場合は warn が出る 󰠅 あくまで参考です ● ● ● ● 間接依存も対象としている（これは良いこと） $ go mod why -m は、ひとつのパスを見つけた時点で切り上げる ひとつの依存モジュールはひとつのバージョン パッケージ特定→ $ go mod why にバージョンごと渡して解決？？

お役立ち資料 ご紹介コーナー

お役立ち資料① go mod why のソースコード internal 関数利用 が多いのでコピペ は無意味 シンプルに理解の きっかけになるし AIに食わせても👍

• https://github.com/golang/go/blob/master/src/cmd/go/internal/modcmd/why.go

お役立ち資料② ChatGPT さん x/tools/go/packages に 詳しい人になってもらう のがポイント

今すぐ ebi-yade/why-go-over をチェック！