Vim-go: Features that rely on gopls will not work correctly outside of GOPATH or a module.

[desdic]

https://github.com/fatih/vim-go/blob/8651442f279d8862556d0e25b83105ca5ec7ef7d/autoload/go/lsp.vim#L179

For some reason I get this warning even if my project is setup as a module. vim-go works fine but I have to press enter to continue every time I open a file

[saschagrunert]

The main issue on my side is that the go list command fails because the root directory of my go projcet does not contain any go files:
https://github.com/fatih/vim-go/blob/2d04dc6a99ad822725dcd68a684a5dc1a3ca8776/autoload/go/package.vim#L153-L157

[peterhellberg]

I'm also seeing this issue. (The project does not have any go file in its root directory)

Should go list ./... be called instead?

let [l:out, l:err] = go#util#Exec(['go', 'list', './...'])

[saschagrunert]

I'm also seeing this issue. (The project does not have any go file in its root directory)

Should go list ./... be called instead?

let [l:out, l:err] = go#util#Exec(['go', 'list', './...'])

I'm not sure if this is the right solution. I mean it now matches the first package, does everything works as intended after this change?

Ah I see it has been fixed with another fix. So I assume this is fine now.

[rbcrwd]

Not to reopen this, but to perhaps save someone else some steps.

Vim's getcwd() call _always_ returns the _physical_ directory, and I can't find a way to override this. That means for those random few of us that have made GOPATH/src (or subdirectories thereof) a symlink get this message as well as other subtly broken behavior in vim-go features that use getcwd().

[bhcleek]

symlinks in GOPATH are not supported by vim-go, because it's not supported by Go: https://github.com/golang/go/issues/15507#issuecomment-241581036

[rbcrwd]

Please note, I'm not asking vim-go to support it, I'm simply leaving breadcrumbs for the next person that runs up against this.

That said, this isn't the same problem space. Your linked bug and its siblings are about Go explicitly supporting symlinks. This is about vim (and therefore vim-go) behaving differently than Go does by invariably resolving symlinks rather than just ignoring them and following whatever path you use. Whether by design or not, Go is perfectly happy with GOPATH/src being a symlink, whereas vim will resolve it to its physical location and produce different behavior than the canonical Go command-line tooling.

[silas]

Is there a way to disable this feature completely? I couldn't find anything obvious in the documentation or autoload config file.

This warning adds a forced 1 second delay and prompt if you're just editing a lonely go file.

Example

$ cd $( mktemp -d )
$ cat << EOF > hello.go
package main
func main() { println("hello world") }
EOF
$ vim hello.go

Output

"hello.go" 5L, 52C
vim-go: Features that rely on gopls will not work correctly outside of GOPATH or
 a module.
Press ENTER or type command to continue

[santosh]

I'm in similar condition as @silas. Sometimes I want to edit standalone .go file, which of course is not inside GOPATH.

How can we disable this warning? Or at least prevent it from opening the file.

A warning shown on statusline after opening the file would also serve the purpose of warning the user.

[vkorchagin]

The warning can be disabled with this line in .vimrc:

let g:go_null_module_warning = 0

[weienjun]

I have a similar question ：vim-go :Features that rely on gopls will not work correctly in a null module
who can help me ,thanks

[HelperInCa]

I have a similar question ：vim-go :Features that rely on gopls will not work correctly in a null module
who can help me ,thanks

same problem!

[pierDipi]

I have a similar question ：vim-go :Features that rely on gopls will not work correctly in a null module
who can help me ,thanks

Same problem!

[raymonlai]

Same problem!

[stamblerre]

The latest version of gopls does support null modules. To get the latest version, run go get -u golang.org/x/tools/gopls@master.