Earlier this year, Go Team presented golang.org/x/tools/go/packages as build system-agnostic interface for tooling authors. At the moment GopherJS uses go/build as a main way to load packages, which lacks Go Modules support and is strongly tied to the go tool.

In theory, switch to go/packages should offer several advantages:

• Transparent build system integration, lesser chance to be affected by changes in go build tooling. As a corollary, this should provide Go Module support "for free".
• An avenue for integrating GopherJS with other build systems (bazel.io and friends).
• A possibility to remove a lot of custom code from the gopherjs/build package, which is handling loading packages in different ways.

How much of that proves to be true, is yet to be seen, but I'll start an experiment.