Simplify Golang definition once gopls is 1.0 #375
Description
Golang has moved toward using gopls for nearly all language features. Most of the tooling installed in the current template is no longer needed and adds bloat to the container.
Would it be alright to push another golang container and have two, one using the go language server and the other one using the existing setup?
With gopls the install drops to the following, with a few additional settings. I've also done in these examples is to pin the versions to avoid breaking changes, this feels like the right thing to do to preview breaking changes, for example #173 affecting users, but I understand this would incur more effort to maintain the template.
RUN \
# --> Delve for debugging
go get github.com/go-delve/delve/cmd/[email protected] \
# --> Go language server
&& go get golang.org/x/tools/[email protected] \
# --> Go symbols and outline for go to symbol support and test support
&& go get github.com/acroca/[email protected] && go get github.com/ramya-rao-a/go-outline@7182a932836a71948db4a81991a494751eccfe77
"settings": {
"terminal.integrated.shell.linux": "/bin/bash",
"go.gopath": "/go",
"go.useLanguageServer": true,
"[go]": {
"editor.snippetSuggestions": "none",
"editor.formatOnSave": true,
"editor.codeActionsOnSave": {
"source.organizeImports": true,
}
},
"gopls": {
"usePlaceholders": true, // add parameter placeholders when completing a function
// Experimental settings
"completeUnimported": true, // autocomplete unimported packages
"watchFileChanges": true, // watch file changes outside of the editor
"deepCompletion": true, // enable deep completion
},
"files.eol": "\n", // formatting only supports LF line endings
},
The repository container I pushed in this PR is an example of how much this can be slimmed down. #374
Or similar in the azbrowse devcontainer.