Closed hyangah closed 6 months ago
Change https://go.dev/cl/554316 mentions this issue: extension: move extension code to a separate module
Change https://go.dev/cl/556536 mentions this issue: extension/tools/release: uncomment vsce package and fix README handling
Change https://go.dev/cl/556855 mentions this issue: docs: update contribution instruction
Change https://go.dev/cl/556857 mentions this issue: .github/workflows: fix wiki.yml
VS Code Go extension will install a new helper go binary (https://github.com/golang/vscode-go/issues/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.[^1] 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:
vscgo/v0.41.0
go install vscgo@v0.41.0
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
Tasks
[^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.