x/tools/gopls: change behavior of dependency upgrade suggestions #38339
Comments
gopherbot
added
Tools
|
Or is there any way to disable some of the code lenses? |
There is a |
|
We now have per-code lens configuration. While I would like to eventually make improvements to the behavior of the upgrade code lenses, I don't think it's necessary for v1.0. |
|
https://golang.org/cl/271297 removed the per-require upgrade code lenses, so we should prioritize adding the upgrades as diagnostics paired with suggested fixes. I think they should be treated similarly to how fillstruct works in Go files--we don't want to use a visible underlined diagnostic since it may bother the user visually (if they specifically chose a lower version), but when they click on the require, they should be prompted to upgrade it. /cc @heschik |
|
It's not a good idea to drop per-dependency update notification when the alternative method not ready. I also have to stay on gopls v0.5.3. |
|
The "Upgrade all dependencies" code lens still appears at the top of the |
|
Change https://golang.org/cl/275432 mentions this issue: |
|
@stamblerre Can we have a code lens like "Check for upgrade" to trigger upgrade suggestions for each require in a go.mod file as before. |
0.5.5 This is a patch release to fix two bugs in gopls/v0.5.4. Fixes Excessive reloading of packages outside of GOPATH or a module File corruption with CRLF line endings and //-style comments golang/go#42646 was supposed to have been fixed in gopls/v0.5.4, but it was not. golang/go#42923 was reported and fixed. 0.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.
|
Thanks for the suggestion--we will consider that option. Would the "upgrade all direct dependencies" code lens work for you? |
|
@stamblerre Not really. I want to keep my dependencies up to date. But there are some reasons I can't upgrade all of them. For example, some dependencies have a breaking change and it needs some time to handle, which is not the top priority. |
`go get -u all` can have unexpected behavior for some users, since upgrades all transitive dependencies as well as direct ones. Offer users the ability to upgrade only direct dependencies via a code lens. Also, change the placement of the upgrade code lenses. The module declaration was getting cluttered, and they make more sense above the requires anyway. Updates golang/go#38339 Change-Id: I6790a02f2a334f3f4d1d89934b2c4dc4f11845ce Reviewed-on: https://go-review.googlesource.com/c/tools/+/275432 Trust: Rebecca Stambler <rstambler@golang.org> Run-TryBot: Rebecca Stambler <rstambler@golang.org> gopls-CI: kokoro <noreply+kokoro@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Heschi Kreinick <heschi@google.com>
|
That's fair, but it should still make it a little simpler to upgrade all dependencies and then revert the ones you don't want to upgrade. I think the per-require code action will work well for most cases, because it will allow us to offer multiple versions, but I do also like the idea of a "check for updates" command that we could expose as a code lens. |
|
I would like to add a user experience report. I don't find the per line code lenses invasive. In fact, it's the most useful feature. I only goto the go.mod file to check for potential upgrades. I work on some projects that suffer from upstream breaking Semitic Versioning, but if go tooling makes keeping certain versions back easier, more developers will feel freer to break SV. This will end up making the development experience worth. "but it should still make it a little simpler to upgrade all dependencies and then revert the ones you don't want to upgrade. " If "Upgrade direct dependencies" is a useful workflow, that should be added to the command line tooling first instead as a gopls only feature. |
`go get -u all` can have unexpected behavior for some users, since upgrades all transitive dependencies as well as direct ones. Offer users the ability to upgrade only direct dependencies via a code lens. Also, change the placement of the upgrade code lenses. The module declaration was getting cluttered, and they make more sense above the requires anyway. Updates golang/go#38339 Change-Id: I6790a02f2a334f3f4d1d89934b2c4dc4f11845ce Reviewed-on: https://go-review.googlesource.com/c/tools/+/275432 Trust: Rebecca Stambler <rstambler@golang.org> Run-TryBot: Rebecca Stambler <rstambler@golang.org> gopls-CI: kokoro <noreply+kokoro@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Heschi Kreinick <heschi@google.com>
|
We reworked the user experience in gopls/v0.6.5, and you can see an explanation of the new workflow in the release notes. Closing this issue as a result. |
Some users have mentioned that the upgrade code lenses are a little invasive because they are shown per-line. Here are some general thoughts / ideas for how to handle this:
The text was updated successfully, but these errors were encountered: