go.work: create a go.work automatically for a workspace with multiple modules

[hyangah]

Go1.18 provides go.work that helps when working with multiple modules. Still that requires knowledge and one more thing users need to configure.

An idea is to create a temporary go.work file that includes all the modules found from the workspace automatically unless there is already an affecting go.work. (i.e. go env GOWORK is empty) That covers:

• Multiple modules
• Single module in subdirectory

This should be configurable through a setting.

• Should it be done in gopls? That will maybe help other editors?

  My answer is no. The point is to make go build, go test, dlv, and other analysis tools wired by vscode-go work, too.

• Problems to investigate:

  • users of older versions of go are stuck.
  • go.mod won't be updated until go work sync is called. That can cause confusion.
  • handling of failure caused by conflicting dependencies.
  • handling of mono-repo (maybe disable this feature and ask users to write go.work if the number of modules are more than N?
  • go.work is still new and there could be some surprise.
  • what to do to the integrated terminal? ...

If that is possible, we can also consider redesigning our test & debug features. Currently they run go test and dlv from the package directory which caused many issues and confusion. With go.work, in theory, we can always run those commands from the workspace root + relative path to the target package.

• File paths in error messages are relative to cwd of go test or dlv which prevented vscode from using the paths info correctly. https://github.com/golang/go/issues/47399
• Various issues related to the choice of defaults in debugging and test flags. Relative to workspace or package?

cc @matloob @findleyr @golang/tools-team

[hyangah]

From off-line discussion with @golang/tools-team:

• Automatic creation of go.work can cause confusion.

• Given that go.work is just launched and it needs time to sock, it can be risky.

• Instead, gopls may suggest users create a go.work when it finds the workspace is outside of any module, nor there is no go.work. How gopls should show this recommendation still needs investigation.

• An idea

  • gopls sends a prompt or diagnostic message with a quick fix that may create a go.wok in the current directory with go work use -r.
  • editors like vscode may also intercept the disagnostic or quickfix message and provide richer UI options, instead of letting gopls do the default go.work creation.

[gedw99]

+1 on this :)