I think the use case here goes beyond go/packages - it extends to any use case where one may want to import/build the package in question as part of the generation process. Be it go/packages, go list, go build, or any other means.

Also, if there's a way to accomplish this already, please bring it up. Paul and myself weren't able to come up with a way, other than adding something like GOBUILDTAGS.

I am skeptical of introducing a new GOBUILDTAGS environment variable that generate writes but that nothing else reads.

(The others that are unique to generate are GOFILE, GOLINE, GOPACKAGE, and DOLLAR, which are all easier to understand as not-read-by-the-go-command.)

In the case in the original report, it's clear that the relevant file is specific to wasm+js+constraint. Why not just say that on the command line of the generator: -tags 'wasm js constraint'?

Stepping back a bit just in case I'm jumping rather too quickly to a solution before properly articulating the problem.

go/packages defines a Config type. Taking the Env field first:

...
    // Env is the environment to use when invoking the build system's query tool.
    // If Env is nil, the current environment is used.
    // As in os/exec's Cmd, only the last value in the slice for
    // each environment key is used. To specify the setting of only
    // a few variables, append to the current environment, as in:
    //
    //	opt.Env = append(os.Environ(), "GOOS=plan9", "GOARCH=386")
    //
    Env []string
...

Hence we can use the current environment's GOOS and GOARCH, or override. In many situations, the GOOS and GOARCH of the current environment will suffice. Hence the GOOS and GOARCH used to invoke go generate will probably suffice. So nothing to override in most cases.

Config also defines .BuildFlags:

    // BuildFlags is a list of command-line flags to be passed through to
    // the build system's query tool.
    BuildFlags []string

This is where there is currently a gap, because these would need to be explicitly set: if I pass -tags constraint to go generate, I don't have a way to automatically pass these through the generator to go/packages.

If, however, the -tags flag is set via GOFLAGS then that value is automatically available to go/packages via the generator's environment:

$ cd $(mktemp -d)
$ go mod init example.com/hello
go: creating new go.mod: module example.com/hello
$ cat <<EOD >hello.go
package hello
EOD
$ cat <<"EOD" >hello_js_wasm.go
// +build constraint

package hello

//go:generate echo "GOARCH: $GOARCH; GOOS: $GOOS; GOFILE: $GOFILE; GOLINE: $GOLINE; GOPACKAGE: $GOPACKAGE; GOFLAGS: $GOFLAGS"
EOD
$ GOFLAGS=-mod=vendor GOOS=js GOARCH=wasm go generate -tags constraint
GOARCH: wasm; GOOS: js; GOFILE: hello_js_wasm.go; GOLINE: 5; GOPACKAGE: hello; GOFLAGS: -mod=vendor

So if instead of setting GOBUILDTAGS we have go generate set the effective GOFLAGS (i.e. the combined result of the GOFLAGS it was passed plus any command line flags it was passed) in the environment for the generator, then I think we have all bases covered.

Why not just say that on the command line of the generator: -tags 'wasm js constraint'?

Absolutely, this would work. But then these constraints would need to be maintained at the site of every go:generate directive (probably by setting GOFLAGS so that each generator doesn't also need to grow another flag just for the purpose of accepting tags/other).

I am skeptical of introducing a new GOBUILDTAGS environment variable that generate writes but that nothing else reads.

Have re-read what's written above, I can quite agree now. I don't know how we didn't come up with the effective-GOFLAGS option earlier. Would that work to your mind?