最近在整理组里的旧项目的时候,发现原来一些不太标准的操作,举个例子。最下面是一个叫 A 项目的 go.mod,两个 common 模块是需要指向本地的文件夹中的,这就意味着,换了其他环节编译这个 A 项目的时候,你必须在上层文件夹目录提前下载好两个 common 项目,这就不太标准了,比较好的做法就是直接将依赖指向内部仓库的这两个 common 项目。
查看一下原因,原来这两个 common 项目的 module path 竟然是一个不存在的仓库名,因此以前老做法是把这两个 common 包 git clone
下来到 A 项目的父目录,然后通过 go.mod 的 replace
重新指向的。
关于 module path 是啥,其实就是 go.mod 文件的第一行,如果项目是通过 go mod init
创建的,可以看看 Go 的官方文档,指个路。
当然了,一些历史原因,以及这两个既然叫做 common,那么修改 module path 是有风险的,万一忘记修改依赖 common 的其他项目的 go.mod,那么就会编译失败了。
所以这里要做一些 trick,去改造一下,首先把 common 包的 module path 改成内部仓库的地址,然后修改 A 项目的 go.mod 文件,把 replace
部分去掉,然后将 require
部分重新写成 common 的内部仓库地址即可。
通过上面的改造,下次编译 A 项目的时候,就会去远程仓库下载对应版本的 common 依赖了,否则不管是编译还是构建镜像,这都会很麻烦。