gopls version
$ gopls -v version
Build info
golang.org/x/tools/gopls v0.20.0 golang.org/x/tools/gopls@v0.20.0 h1:fxOYZXKl6IsOTKIh6IgjDbIDHlr5btOtOUkrGOgFDB4= github.com/BurntSushi/toml@v1.5.0 h1:W5quZX/G/csjUnuI8SUYlsHs9M38FC7znL0lIO+DvMg= github.com/fatih/camelcase@v1.0.0 h1:hxNvNX/xYBp0ovncs8WyWZrOrpBNub/JfaMvbURyft8= github.com/fatih/gomodifytags@v1.17.1-0.20250423142747-f3939df9aa3c h1:dDSgAjoOMp8da3egfz0t2S+t8RGOpEmEXZubcGuc0Bg= github.com/fatih/structtag@v1.2.0 h1:/OdNE99OxoI/PqaW/SuSK9uxxT3f/tcSZgon/ssNSx4= github.com/fsnotify/fsnotify@v1.9.0 h1:2Ml+OJNzbYCTzsxtv8vKSFD9PbJjmhYF14k/jKC7S9k= github.com/google/go-cmp@v0.7.0 h1:wk8382ETsv4JYUZwIsn6YpYiWiBsYLSJiTsyBybVuN8= golang.org/x/exp/typeparams@v0.0.0-20250620022241-b7579e27df2b h1:KdrhdYPDUvJTvrDK9gdjfFd6JTk8vA1WJoldYSi0kHo= golang.org/x/mod@v0.26.0 h1:EGMPT//Ezu+ylkCijjPc+f4Aih7sZvaAr+O3EHBxvZg= golang.org/x/sync@v0.16.0 h1:ycBJEhp9p4vXvUZNszeOq0kGTPghopOL8q0fq3vstxw= golang.org/x/sys@v0.34.0 h1:H5Y5sJ2L2JRdyv7ROF1he/lPdvFsd0mJHFw2ThKHxLA= golang.org/x/telemetry@v0.0.0-20250710130107-8d8967aff50b h1:DU+gwOBXU+6bO0sEyO7o/NeMlxZxCZEvI7v+J4a1zRQ= golang.org/x/text@v0.27.0 h1:4fGWRpyh641NLlecmyl4LOe6yDdfaYNrGb2zdfo4JV4= golang.org/x/tools@v0.35.1-0.20250728180453-01a3475a31bc h1:ZRKyKRJl/YEWl9ScZwd6Ua6xSt7DE6tHp1I3ucMroGM= golang.org/x/vuln@v1.1.4 h1:Ju8QsuyhX3Hk8ma3CesTbO8vfJD9EvUBgHvkxHBzj0I= honnef.co/go/tools@v0.7.0-0.dev.0.20250523013057-bbc2f4dd71ea h1:fj8r9irJSpolAGUdZBxJIRY3lLc4jH2Dt4lwnWyWwpw= mvdan.cc/gofumpt@v0.8.0 h1:nZUCeC2ViFaerTcYKstMmfysj6uhQrA2vJe+2vwGU6k= mvdan.cc/xurls/v2@v2.6.0 h1:3NTZpeTxYVWNSokW3MKeyVkz/j7uYXYiMtXRUfmjbgI= go: go1.24.5
go env
$ go env
GO111MODULE=''
GOARCH='amd64'
GOBIN='/home/claudio_onoue/.asdf/installs/golang/1.23.11/bin'
GOCACHE='/home/claudio_onoue/.cache/go-build'
GOENV='/home/claudio_onoue/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOINSECURE=''
GOMODCACHE='/home/claudio_onoue/.asdf/installs/golang/1.23.11/packages/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='linux'
GOPATH='/home/claudio_onoue/.asdf/installs/golang/1.23.11/packages'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/home/claudio_onoue/.asdf/installs/golang/1.23.11/go'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/home/claudio_onoue/.asdf/installs/golang/1.23.11/go/pkg/tool/linux_amd64'
GOVCS=''
GOVERSION='go1.23.11'
GODEBUG=''
GOTELEMETRY='local'
GOTELEMETRYDIR='/home/claudio_onoue/.config/go/telemetry'
GCCGO='gccgo'
GOAMD64='v1'
AR='ar'
CC='gcc'
CXX='g++'
CGO_ENABLED='1'
GOMOD='/dev/null'
GOWORK=''
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build3938872359=/tmp/go-build -gno-record-gcc-switches'
What did you do?
I created a new Go file in my editor, and I noticed that gopls automatically inserted the package clause at the top of the file. I was trying to start with a blank file and add everything manually, but this behavior was triggered automatically.
What did you see happen?
As soon as I created a new Go file, gopls automatically inserted a package clause at the top of the file without any prompt or interaction.
What did you expect to see?
I expected the new Go file to be completely empty, so I could manually write the package clause myself when I was ready.
Editor and settings
No response
Logs
No response
Comment From: claudioonoue
Hi,
Since gopls version v0.19.0, a new feature was introduced under Editing features:
Completion: auto-complete package clause for new Go files Gopls now automatically adds the appropriate package clause to newly created Go files, so that you can immediately get started writing the interesting part. (It requires client support for workspace/didCreateFiles)
I was wondering if there's currently a way to disable this behavior.
If not, would it be possible to add a configuration flag (e.g., experimentalDisablePackageClauseCompletion) or any other opt-out mechanism to turn it off?
I appreciate the motivation behind the feature, but in my setup I prefer starting with completely empty files and adding the package clause manually.
Thanks in advance!
Comment From: adonovan
It would be possible to add a flag, but I'm curious to know why the feature is unhelpful to you. Does it guess wrong, so that you have to amend its guessed name? Do your fingers habitually type the command for a new file then start spelling "package..."? Are the copyright and other comments wrong? Perhaps there's some way we could improve the feature so that it saves you time.
Comment From: claudioonoue
Sorry for the delayed response, and thanks for getting back to me!
In my case, it's mostly about personal workflow preference. I often create new Go files as placeholders or drafts, and I prefer starting with an entirely blank file. Having gopls insert the package clause automatically sometimes feels intrusive — especially when I'm not yet sure what the package name should be, or if the file will remain at that location.
I completely understand that this feature can save a lot of time for most users, and I don’t mean to be nitpicky — I know this might come across as a small thing. But for my setup, having control over when and how that clause is added would improve my experience.
A flag to disable it would be the ideal solution from my point of view, even if the default remains enabled.
Thanks again!
Comment From: skewb1k
Author's intentions seem reasonable to me, and I can see why one would want to keep the action as simple as 'Create .go file' doing exactly what it says without overloading it with additional behavior.
I think adding a option completion.disablePackageClauseCompletion would solve the issue. May I take it?
Comment From: claudioonoue
Yes, that option sounds excellent to me — it would address the issue perfectly while keeping the default behavior intact for those who want it.
Thanks a lot for the suggestion!
Comment From: adonovan
Since this is a superficial feature an option is acceptable. (We really don't like options that change to core functionality.) The best name I can come up with so far is newGoFileHeader=true (the default), with false to disable. (It's not really an LSP completion feature, even though the Go logic lives in that package.)
Thanks for the offer of fix, @skewb1k .
Comment From: skewb1k
I think we should also consider future extensibility - for now, gopls auto-completes only the package clause, but that could change (I don’t know how exactly, but I also know I can't foresee the future). So, the option we add should toggle any autocompletion on file creation. We already know this kind of option will be needed, since users may dislike not just what gets inserted, but the fact that anything is inserted at all.
That's why I'm questioning whether the name newGoFileHeader is appropriate. I'm not sure about the 'Header' part. Also, maybe the setting shouldn't be only for Go files in that case?
Comment From: adonovan
I think we should also consider future extensibility - for now, gopls auto-completes only the package clause, but that could change (I don’t know how exactly, but I also know I can't foresee the future).
That's funny, @findleyr said the same thing and suggested using a template whose default was {{.Copyright}}\n{{.PackageClause}} or somesuch, and could be disabled with "" or altered to one's taste. I argued against on grounds that there really isn't much variation in what the header looks like, and we don't have evidence of a third position between "on" and "off" yet.
(I've taken the template route prematurely in the past and regretted it, since approximately zero people ever use it.)
I'm questioning whether the name newGoFileHeader is appropriate. I'm not sure about the 'Header' part.
Feel free to propose a better name. We considered a bunch here but none was epic.
Also, maybe the setting shouldn't be only for Go files in that case?
The only non-Go files for which gopls will receive DidCreate notifications are templates, go.mod, and assembly, and I don't think there's much we can usefully do for them; they often don't even have a copyright header.
Comment From: gopherbot
Change https://go.dev/cl/694275 mentions this issue: gopls/internal/settings: add ui.newGoFileHeader option
Comment From: skewb1k
I think we should also consider future extensibility - for now, gopls auto-completes only the package clause, but that could change (I don’t know how exactly, but I also know I can't foresee the future).
That's funny, @findleyr said the same thing and suggested using a template whose default was
{{.Copyright}}\n{{.PackageClause}}or somesuch, and could be disabled with""or altered to one's taste. I argued against on grounds that there really isn't much variation in what the header looks like, and we don't have evidence of a third position between "on" and "off" yet.
I was thinking not about extending the current feature itself, but about expanding the capability to insert code for new files based on context - for example, auto-import the "testing" package for _test.go files, or something in that fashion. I don’t have concrete ideas yet, but they may arise in the future.
That said, I might be overthinking it, and I don't have a better name proposal for the option anyway.
Comment From: adonovan
I was thinking not about extending the current feature itself, but about expanding the capability to insert code for new files based on context - for example, auto-import the "testing" package for _test.go files, or something in that fashion.
We already have a mechanism to import testing when it is needed, so we needn't duplicate it here.
I don’t have concrete ideas yet, but they may arise in the future. That said, I might be overthinking it, and I don't have a better name proposal for the option anyway.
Exactly; let's solve the problems we know actually exist.