-
Notifications
You must be signed in to change notification settings - Fork 18k
x/tools/gopls: deprecate the "allowModfileModifications" setting #56570
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Thanks, I was able to reproduce, but only using Disabling that setting should fix your problem, but this is a bug and will be prioritized for the next gopls patch release. |
Thanks for the fast response! I tried to remove the option as well, but just realize I only removed it from my workspace config in VS Code, not from my user config. So, it was still active from gopls' point-of-view. |
It was easy to find the bug thanks to your detailed report! Unfortunately, this is a case where the 'allowModfileModifications' flag has deep implications into the behavior of gopls, and therefore should really be tested against the entire gopls test suite (but isn't). AFAIK very few people use this setting, and I'd love to deprecate it in favor of go.mod code-lens. Can you share why you have it enabled? |
I did some digging and I believe we enabled it when we did bump Go to 1.16. Without this flag, we got following error in VS Code:
Based on your comment, our in-house workflow might not be following best practices. If that's the case, fine for me to remove the flag in our config and move to best practices instead. I assume above issue could be resolved by doing a |
Thanks for explaining. Yes, that indicates that your workspace is not tidy. |
Having the go.mod to auto-update is not a best practice and can lead to weird bugs. See golang/go#56570 for more info.
I think the action to take here is to deprecate the 'allowModfileModifications' setting. Generally speaking, this setting means "whatever the go command does to your go.mod file is OK". That's not a coherent mode of operation for gopls to support, which is why it has no test coverage. Additionally, the documentation says "this option will eventually be removed". We should surface the deprecation notice in [email protected], and remove in [email protected]. |
Change https://go.dev/cl/561975 mentions this issue: |
What version of Go, VS Code & VS Code Go extension are you using?
Version Information
go version
to get version of Go from the VS Code integrated terminal.gopls -v version
to get version of Gopls from the VS Code integrated terminal.code -v
orcode-insiders -v
to get version of VS Code or VS Code Insiders.Go: Locate Configured Go Tools
command.Share the Go related settings you have added/edited
Run
Preferences: Open Settings (JSON)
command to open your settings.json file.Share all the settings with the
go.
or["go"]
orgopls
prefixes.Describe the bug
I faced the issue in a large project, but was able to reproduce minimally following: https://go.dev/doc/tutorial/workspaces
Once you add a Golang Workspace by creating a

go.work
file, everygo.mod
file returns error:no go.mod file found in /home/skipr/Dev/workspace go list
. Where/home/skipr/Dev/workspace
is the root of the workspace.Steps to reproduce the behavior:
hello
go mod init example.com/hello
(run insidehello
directory)hello/main.go
containinggo work init ./hello
(run inside root/workspace directory)hello/go.mod
Adding a


go.mod
to the root doesn't solve the issue. Nor adding.
to thego.work
. When doing the latter, you even get the same error in the rootgo.mod
:Screenshots or recordings
See above
The text was updated successfully, but these errors were encountered: