gopls/v0.5.4
Features
Opening a project that contains a module in a subdirectory
Previously, gopls
required that you open your editor exactly at or below the module root (the directory containing the go.mod
). Now, you can open a directory that contains exactly one module in a subdirectory, and gopls
will work as expected. For details on multi-module workspaces, see below.
Removal of the granular go.mod
upgrade codelenses
Previously, we offered a code lens to suggest upgrades for each require
in a go.mod
file. In anticipation of changes that limit the amount that gopls
accesses the network, we have decided to remove and reevaluate this feature. Users had mentioned that the code lenses cluttered their go.mod
files, especially if they didn't actually want to upgrade. golang/go#38339 tracks the work to revamp this feature. An "Upgrade all dependencies" code lens should still appear at the top of your go.mod
file.
Improved error message reports
Previously, critical error messages were reported as message pop-up that would re-trigger as you type. Many users would find this annoying. We have changed the approach to show error messages as progress reports, which should be less intrusive and appear more like status bars.
Improved memory usage for workspaces with multiple folders
We are now using a coarser cache key for package type information. If you use the gopls daemon, this may reduce your total memory usage.
Experimental
Multi-module workspace support
The proposal described in golang/go#32394 is still in development and off by default. See our progress by tracking the multi-module workspace milestone and project.
Enable multi-module workspace support by adding the following to your settings:
"gopls": {
"experimentalWorkspaceModule": true,
}
With this setting, you will be able to open a directory that contains multiple modules or a directory that contains nested modules.
Give this a try if you're interested in this new feature, but please note that it is still very experimental. Please file issues if you encounter bugs.
Fixes
File corruption with CRLF line endings and /**/
-style comments
Previously, when you organized the imports in a file with CRLF line endings and multi-line comments, the formatter might output incorrect content for the file, rendering it invalid Go code. This issue has popped up a number of times, but we believe it has finally been fixed for good. If you are using Windows with CRLF line ending, please report any regressions. For full details, see golang/go#42646.
A full list of all issues fixed can be found in the gopls/v0.5.4 milestone. To report a new problem, please file a new issue at https://golang.org/issues/new.
Thank you to our contributors!
@findleyr @heschik @pjweinb @leitzler @yangwenmai @matloob @golopot @muirdm