cmd/go,x/tools/gopls: confusing behavior of go mod when go.work is in play

[frankli0324]

What version of Go are you using (go version)?

$ go version
go version go1.20.4 darwin/amd64

What did you do?

with a go workspace https://github.com/frankli0324/workspace_demo (I committed the go.work file for demonstration purposes)

go.work // uses module_a and module_b
module_a
  - go.mod // that *doesn't* require module_b
  - main.go // imports module_b
module_b
  - go.mod
  - lib.go

module_a can be compiled

now remove go.work, compilation fails with:

main.go:6:2: no required module provides package github.com/frankli0324/workspace_demo/module_b; to add it:
	go get github.com/frankli0324/workspace_demo/module_b

also note that go install github.com/frankli0324/workspace_demo/module_a succeeds, and go install github.com/frankli0324/workspace_demo/module_b@remove-go-work also succeeds.
the remove-go-work branch doesn't have a go.work file and module_a doesn't require module_b

What did you expect to see?/What did you see instead?

I expect either gopls to stop complaining about missing modules in go.mod and "you must go mod tidy" or go build/install fail to build the module if go.mod is incorrectly constructed (missing require)

Conclusion

From what I observe, I believe the essence of go work is forcing submodules to build as if there's an replace $declared_module_name => ./$local_path in each of the used go.mods:

in persudo-code:

used = use_directives_from(go.work)
replacements = []
for mod in used:
    mod_name = get_module_name_from(path.join(mod, go.mod))
    replacements.append(mod, mod_name)
for mod in used:
    for m, mod_name in replacements:
        set_replacement_for(mod, mod_name => m)

However, normally if module_a doesn't require module_b, if module_b is replaced anyway, go build still fails:

main.go:6:2: module github.com/frankli0324/workspace_demo/module_b provides package github.com/frankli0324/workspace_demo/module_b and is replaced but not required; to add it:
	go get github.com/frankli0324/workspace_demo/module_b

this is where I think is inconsistent and erroneous.

I'm aware that #52962 raised the issue already, but I believe it's not a duplicate. Also the issue seems wasted since no one is getting anywhere closer to an answer.

[frankli0324]

actually this also raises a question: how should versions be managed if we could build the module_a without requiring module_b? or is this "undefined behavior"? Is this some legacy from the GOPATH era?

[frankli0324]

also related: #53502

[findleyr]

Slotted this for gopls@v0.13.0, when we are revisiting UX of modules/workspaces/etc.