This is not going to be changed, sorry,
gopls specifically falls into the "need to resolve import paths relative to the current directory" category.
It never tries to guess a working directory based on the input files, you have to be explicit.

server mode is not supported at all, it is a pure debugging aid, but when it does work we will only support the command line adding a new view to the server based on its current working directory, which means where you launch the server from will not matter, but where you launch the client from still will.

I understand that gopls needs to have an explicit working directory, and I'm not proposing to remove that expectation. In the case when a package has no relative imports and neither has an explicit go.mod nor is in GOPATH, allowing editors to rely on gopls to provide users' the experience they expect (especially given that go build, go list, etc. work) would be valuable for editors that provide features using gopls. This typically comes up when a user has a go runnable package that they want to edit using vim-go, vscode, et al.

Sorry, I didn't mean literally the server mode of gopls that's used for debugging; I just meant the usual mode used by editors as opposed to gopls query.

No worries if the answer is still never, but I wanted to make sure I laid out the use case better.

I didn't have any idea that go. mod is a required file in order for gopls to work.
I think we should at least have it stated in the gopls docs.

@bhcleek Thanks for pointing that out!

gopls does not require a go.mod file to work. If you do not have a go.mod file, you will need to be in a directory in your $GOPATH.

Yea, I'm aware of that, but I wanted to edit files in a directory that is not in $GOPATH.
I'm a Vim user, and I wanted to edit some random test.go file in home directory, and I'm seeing the error but I don't understand what the problem is.
All other plugins I came across work perfectly without $GOPATH directory and go.mod file.

gopls relies on the behavior of go list to understand how to type-check the package correctly. If go list fails in a given directory, we avoid making guesses for the sake of correctness. This could potentially be a nice feature, but I don't think it's something we will consider supporting in the near future.

Sure, I'm not saying you have to. It would just be helpful if that's written in the docs.

@stamblerre what is it about go list that gopls needs but isn't provided in this case (it exits 0 and provides info about the package)?

#! /bin/bash

cd $(mktemp -d)

cat <<EOF > main.go
package main

import "fmt"

func main() {
	fmt.Println("Go, please")
}
EOF

go list -json .