The last note took a long time on the GoModule. I still don’t know anything about it. This is due to a lack of history: GoModule is not an old concept, but a relatively new version of Go. Previously, Go managed packages through GoPath.

1. GoPath pit

When using Go Get < Package >, GoPath installs third-party packages on the GoPath path (an environment variable). And in Go, your code must be in GOPATH to run. There are two options:

  1. Different projects use different $GOPATH: This is obvious because, just like node_modules in javascript, different projects have their own set of dependencies. The disadvantages are also obvious, one is to download the same dependence repeatedly, take up large space; Second, GoPath is so crappy that any third-party packages you download will go directly to your SRC folder, which means they will be placed alongside your own code, resulting in a very confusing directory structure that makes no sense.
  2. Using the same $GOPATH for different projects: Eliminates the problem of repeated dependencies taking up space, but the project structure can be extremely messy, with not only different project files mixed up, but also third-party packages.

2. GoModule

Shockingly, Go didn’t fix this until version 1.11. Good for you, Go. The solution is the GoModule. The problem GoModule solves is as simple as creating a GoModule directory (the same directory as go Mod Init) in addition to GoPath so that your own code is installed in the GoModule directory and the third party is installed in the GoPath directory. I don’t know why this stuff has to wait for 1.11, but this is GO.

Advantages of GoModule:

  1. As mentioned above, your own code and third-party packages split into two paths, and the problem of project structure is solved.
  2. This allows you to set up only one GoPath, which is shared by all projects, and eliminates the dependency duplication problem.
  3. The GoModule finally has dependency management, it finally has version management, and version conflicts are under control. (But some posts on the Internet say it is still rubbish, I will mention this when I encounter it)

In the GoPath era, code could only run on GoPath. With GoModule, you can run code in the GoModule directory. GoPath serves only as a repository for third-party packages.

3. The go plugin pit on vscode

Shockingly, the go plugin on vscode also has bugs. Multiple Module management is not supported. If you have multiple modules in the same directory, you can only open multiple modules in a single module if you want vscode dependency imports to work properly.

  • Then I looked at the developer of the go plugin on vscode. Well, it’s the go team at Google.

However, the official said that later versions will be supported, wait.