Go Modules 三兩事. 介紹Go Modules 的緣由以及使用方式

在Go 1.11 中(於2018 年8 月釋出)，官方加入了實驗性的package management tool，稱為Modules。

這一項舉動有幾個重要的目的. GetstartedOpeninappEvenChangSigninGetstarted168FollowersAboutGetstartedOpeninappGoModules三兩事EvenChangJan5,2019·6minread介紹在Go1.11中(於2018年8月釋出)，官方加入了實驗性的packagemanagementtool，稱為Modules。

這一項舉動有幾個重要的目的統一既有的第三方套件管理工具（glide,govendor等等）在不久的將來移除自Go1.5時引入的vendor在不久的將來移除$GOPATH相信對於第一點，大多數使用Go一定時間的人都不需要太多解釋便能理解。

社群上有著好幾套看似成熟，實則各有個自的坑的第三方套件管理工具。

以glide來說，每次想要增加一個dependency都要等上好幾分鐘，因為它固定會去更新所有存在的dependencies。

至於第二跟第三點，就得先了解當時為何會出現vendor以及$GOPATH。

我們可以將$GOPATH底下看成一個巨大的Repository，如果以傳聞中Google是實踐MonoRepo來說的話，似乎就能明白為何Go一開始的設計會是如，因為各個team維護的專案都能放在同一個Repo底下。

然而並不是每個公司或是社群都是走MonoRepo的路線，更常見的是，底下有好幾個projects擁有相同的dependency卻要不同的version因此在Go1.5時，在每個專案底下都加入了vendor來管理各自的依賴，從此開始，各個project終於可以擁有不同版本相同的dependency了，然而vendor底下的package其實也只是clone當時dependency的樣子，至於後續的升級又得仰賴各個第三方套件實踐。

於是GoModules就這樣誕生了（當然中間還經過了vgo,dep等等討論，這邊就不詳述了）GoModules指令介紹Usage:gomod[arguments]Thecommandsare:download//將依賴全部下載到本機中，位置為$GOPATH/pkg/mod/cacheedit//編輯go.mod例如鎖定某個依賴的版本graph//列出專案中哪一個部分使用了某個依賴init//建立go.modtidy//增加遺失的依賴，移除未使用的依賴vendor//將既有的go.mod依賴全部存在/vendor底下verify//驗證本地依賴依然符合go.sumwhy//解釋某個依賴為何存在在go.mod中，誰使用了它如何在一個新的專案使用GoModules？以下以OSX為例//先確認Go的版本已經在1.11以上$brewupgradego$mkdirgomod-test//請確定當前位置在$GOPATH以外的地方$cdgomod-test其實不一定要在$GOPATH以外的地方，只是當前GoModules還在實驗階段，如果是在$GOPATH的專案，預設依然會照舊有的vendor機制，除非將環境變數GO111MODULE該為on來強制開啟，但既然GoModules一個重要的性質是去除$GOPATH，就讓我們試試看在其他地方開專案吧！接著初始化GoModules$gomodinitgithub.com/hieven/gomod-test便會看到專案底下出現go.mod的檔案，而這也是最重要的檔案，之後會紀錄每一個dependency以及版本。

現在應該長得像這樣//go.modmodulegithub.com/hieven/gomod-test最後讓我們做一個簡單的helloworld//main.gopackagemainimport"fmt"funcmain(){fmt.Println("helloworld")}此時還沒有任何改變，但接著我們嘗試加入一個dependencypackagemainimport"fmt"import"github.com/gofrs/uuid"funcmain(){uuid,_:=uuid.NewV4()fmt.Println("helloworld",uuid)}接著運行程式$gorunmain.go會發現程式神奇的運作了$helloworld3f99abff-8404-42ec-b9f6-5fa165e5d447再來檢查go.mod，會發現已經多了一個dependencymodulegithub.com/hieven/gomod-testrequire(github.com/gofrs/uuidv3.1.0+incompatible)原因是GoModules不僅僅是一個gomodxxx的工具而已，同時也整合了既有的goget、gorun、gobuild、gotest，每當這些指令運行時，都會去檢查整個project底下新的dependency並自動更新到go.mod底下既有的專案如何遷移至GoModules？剛好在既有的project中分別有用glide以及govendor，所以剛好都試過這兩個的遷移方法，其實非常簡單。

只要到project底下執行$gomodinit便自動會去讀glide.yaml或是vendor/vendor.json並產生一個go.mod。

個人目前還沒有遇到問題如果有興趣的人可以參考我在go-instagram中的一個PR，便是把glide轉移成GoModules此外，可以試試看執行$gomodtidy來移除沒使用的依賴，我自己的私人專案在使用tidy之後，成功移除了好幾個呢！如何讓Travis能使用GoModules？基本上現在的Travis也有支援Go1.11了，所以GoModules自然而然就有了。

唯一要特別注意的是，Travis底下預設把project放在$GOPATH底下，所以要在env中把GoModules打開才行具體設定就是要注意這兩行//.travis.ymlgo:-"1.11"env:-GO111MODULE=onEvenChang台灣人🇹🇼/SeniorBackendEngineeratDAZN,AmsterdamFollow7676 76GoGolangBackendEngineeringMorefromEvenChangFollow台灣人🇹🇼/SeniorBackendEngineeratDAZN,Amsterdam