Project repo restructuring

[hyangah]

VS Code Go extension will install a new helper go binary (#3121) for VS Code Go extension specific tasks. Its source code is in github.com/golang/vscode-go and colocated with the extension code, and the Go extension installs a specific version with the go install command.¹ The tool must be small and has little extra 3rd party dependencies.

Currently, the vscgo package is in a separate module to avoid pulling in large files (TS/JS and media files) and dependencies of github.com/golang/vscode-go repo that are not needed by vscgo.

Two modules should be released together but require separate tags. For example, the release process for v0.41.0 in the current layout involves:

1. Tag vscgo/v0.41.0

• Extension 0.41.0 runs go install [email protected]
• This tagging must be done before the other tagging.

1. Tag v0.41.0

• Triggers CI for publishing
• Serves as the extension version tag
• Watched by downstream

Given that tagging is a manual process, requiring two tags for every release and prerelease will be tedious and more error prone. And, the github.com/golang/vscode-go module is not actually a Go module meant for publishing.

We propose to move the extension code to a separate module in a subdirectory, and move the vscgo package to github.com/golang/vscode-go. That will allow us to require one version tag for extension release.

The single tag serves both for vscgo and the extension.

The extension module references the github.com/golang/vscode-go module, and it is replaced. This module is meant for local development, so use of this replace directive and invalid version will prevent unexpected dependency on this module, too.

The docs module is a module that contains documentation files, and will include supporting tools.

The build directory remains in the top level for now, but can be punched to a separate module when it grows big.

Risk

• Will affect contributors with pending changes. Good, but sad news - there are not many contributors with pending changes.
• NPM scripts should run from the extension directory, which will confuse users. Good contributor guidelines will mitigate confusion.

Tasks

• Move code (draft cl 554316)
  • Move the extension code to extension/ directory
  • Adjust build scripts and configuration to work with this new setup
  • github.com/golang/vscode-go/go.mod
  • github.com/golang/vscode-go/extension/go.mod
  • The replace directive allows testing and dev extension to build vscgo from the source. (See vscgo: sidecar of the vscode go extension #3121)
• Update the contributor guideline
• Update (internal) release process

Footnotes

1. That means the tool source code can be fetched from Go module proxies and the source code and its dependencies can be verified with sum.golang.org. ↩

[gopherbot]

Change https://go.dev/cl/554316 mentions this issue: extension: move extension code to a separate module

[gopherbot]

Change https://go.dev/cl/556536 mentions this issue: extension/tools/release: uncomment vsce package and fix README handling

[gopherbot]

Change https://go.dev/cl/556855 mentions this issue: docs: update contribution instruction

[gopherbot]

Change https://go.dev/cl/556857 mentions this issue: .github/workflows: fix wiki.yml