Hello, I’m fried fish.

Go dependency management, also known as the Go Module. From the launch to now, it has been a certain year, teasing has been a lot, the official is constantly improving.

Go1.18 will introduce a new feature: Multi-Module Workspaces, which supports multiple Module Workspaces and solves a number of previous problems.

Today we are going to learn more about fish fry.

background

In the daily use of Go project, there are always two classic problems, which are particularly troublesome.

As follows:

  1. Rely on the local Replace Module.
  2. Rely on locally unpublished Modules.

replace module

The first scenario: like in the normal Go project, we need to solve some local dependencies, or customize the code. Replace is used in the go.mod file.

The following code:

replace golang.org/x/net => /Users/eddycjy/go/awesomeProject
Copy the code

In this way, the accuracy of local development can be achieved.

Here’s the problem:

  • Local path: The set of replace essentially transforms the local path, meaning that everyone is different.
  • Repository dependencies: File changes are uploaded to Git repositories, accidentally uploaded, affecting other developers, or have to be changed back every time they are uploaded.

The user experience is very poor and very frustrating.

Unpublished Modules

Scenario 2: When doing local Go project development, it is possible to develop multiple libraries (project libraries, tool libraries, third-party libraries) locally at the same time.

The following code:

package main

import (
    "github.com/eddycjy/pkgutil"
)

func main(a) {
    pkgutil.PrintFish()
}
Copy the code

If YOU run Go Run or Go Mod Tidy at this point, it won’t work, it will fail.

Error similar to the following:

fatal: repository 'https://github.com/eddycjy/pkgutil/' not found
Copy the code

This error is because github.com/eddycjy/pkgutil this library, is not in making, nature also can’t pull.

Solution: Prior to Go1.18, we would either use Replace (which had background 1 issues) or upload directly to Github, which would naturally be pulled by the Go tool chain.

Many of you will ask the soul question: Do Go dependencies have to be uploaded to GitHub?

Very unfriendly to new students, very deadly.

Workspace mode

After several rounds of feedback from the community, Michael Matloob put forward his Proposal “Proposal: Multi-Module Workspaces in CMD/Go”, which was discussed and implemented in a large amount and officially landed in Go1.18.

A core concept of the new proposal is to add the concept of the Go Work workspace, which is aimed at the dependency management mode of the Go Module.

It can set a series of dependent module local paths in the local project go.work file, and then the modules under the path to form a current workspace, it has the highest read priority.

We can check it by going help as follows:

$ go1.18beta1 help work
Usage:

	go work <command> [arguments]

The commands are:

	edit        edit go.work from tools or scripts
	init        initialize workspace file
	sync        sync workspace build list to modules
	use         add modules to workspace file

Use "go help work <command>" for more information about a command.
Copy the code

To initialize a new workspace, simply execute Go Work Init, followed by the specific submodule mod to be generated.

The command is as follows:

go work init ./mod ./tools
Copy the code

The project catalog is as follows:

├── ├─ ├─ all exercises, exercises, exercises, exercises, exercises, exercises, exercises, exercisesCopy the code

The content of the generated go.work file:

Go 1.18 use (./mod./tools)Copy the code

The new go.work has the same syntax as go.mod, and can also use replace syntax:

1.18 use the go (...). Replace golang.org/x/net => example.com/fork/net v1.4.5Copy the code

The go.work file supports three commands:

  • Go: Declare the GO version number, which is mainly used for subsequent version control of new semantics.
  • Use: specifies the file path of the module on which the application depends. The path can be an absolute path or a relative path outside the application directory.
  • Replace: Specifies the import path that a module depends on to replace the replace directive in advanced go.mod.

If you want to disable workspace mode, you can specify it with the -workfile=off directive.

The following command is executed at runtime:

go run -workfile=off main.go

go build -workfile=off
Copy the code

The go.work file does not need to be committed to a Git repository, otherwise it would be a hassle.

As soon as you set up the go.work file in the Go project, it will enter workspace mode at runtime and compile time, taking priority over the workspace configuration to suit local development needs.

This concludes the core knowledge of the workspace.

conclusion

Today I introduced a new feature of Go1.18: the multi-module workspace mode. It is essentially to address the appeal of local development.

Because go.mod files are strongly associated with your project and are almost always uploaded to a Git repository, it’s hard to hack them. Directly created a go. Work out, pure local use, convenient and fast.

With the new go.work, you can tinker with files that are completely local, with no impact on other member development.

What do you think? 🙂

If you have any questions, welcome feedback and communication in the comments section. The best relationship is mutual achievement. Your praise is the biggest motivation for the creation of fried fish, thank you for your support.

This article is constantly updated. You can read it on wechat by searching “Brain into fried fish”. GitHub github.com/eddycjy/blo… Already included, learning Go language can see Go learning map and route, welcome Star urged more.