はじめに

Go1.12からModulesが標準でサポートされ、
いよいよ言語標準機能で依存関係管理とバージョニングが可能となりました。

これにより、

という利点が生まれます。

というわけで、depで依存管理していたレポジトリを、Modulesによる依存管理に移行してみました。

手順

今回は、github.com/n-someya/lambda-gittrendというレポジトリを脱depさせ、Modules対応させてみました。
lambda-gittrendの直下には、Gopkg.lockがある状態です

まずは、$GOPATH以外のパスにレポジトリを移動します。

cd $GOPATH
cp -r src/github.com/n-someya/lambda-gittrend ~/lambda-gittrend

cd ~/lambda-gittrend
go mod init

以下のような出力がされて、コマンドが完了します。

go: creating new go.mod: module github.com/n-someya/lambda-gittrend
go: copying requirements from Gopkg.lock

え、これだけ？と思いましたが、dep対応のレポジトリならGopkg.lockを読みこんで勝手に移行してくれます。
コマンドが完了すると、go.modというファイルができています。

ちなみに、1からレポジトリ作る時は、
go mod initの後にレポジトリパスを書きます。 go mod init github.com/n-someya/fooみたいな感じです。

今までありがとう、、、

rm Gopkg.lock Gopkg.toml
rm -r vendor

これだけで go build 出来るようになりました。
Gitのレポジトリから、大量のvendorディレクトリも消えて満足です！

移行終了時にはビルド出来る状態になっていると思いますが、
実際のリリース時には以下のようなコマンドで、レポジトリの状態をチェックするのが良いみたいです。

依存モジュールを整理し、不必要なものはpruneされます。
また、全てのビルドタグ、OSの組み合わせでビルド可能か？などが精査されます。

go mod tidy

タイトルの通りです。
依存パッケージ含めて、全てのテストをします。

go test all

※私のレポジトリでは残念なことに通らず。。。aws lambdaのSDKとかテストこけてるんだがどういうこと

ダウンロードされている依存パッケージが、本当に正しいかを検証します。

go mod verify

思ったより簡単でした。
なお、ビルド環境とかで、どうしてもGOPATH配下でModulesを使わなければいけない場合は
GO111MODULE環境変数をonに設定しておくとModulesが使えるはずです。