Go tooling has to load the same packages as the build

A compiler accepting a module does not automatically give an editor enough information to understand it. The editor still has to find the selected dependency versions and determine which files belong to the package being edited. Paul Jolly's September 11 tooling discussion proposal makes that gap visible. Its agenda includes module-compatible tools and a package-loading update, alongside editor context and language-server discussion.

This is a meeting proposal, with a session suggested for September 18. It is not an announcement that the participating editors have completed module support. Reading the agenda as evidence of finished integration would miss the reason coordination is needed. The tools have to agree with a dependency model that Go 1.11 has only just introduced experimentally.

I care about that agreement because a readable language is less useful when the editor describes a different program from the one being built. Navigation and diagnostics should follow the same dependencies as the go command. Otherwise, a programmer has to reconstruct why two tools disagree before addressing the actual source change.

Package discovery has become a build question

The Go 1.11 release notes identify golang.org/x/tools/go/packages as a new package-loading API. They explain that go/build cannot fully support modules. That limitation matters because an analysis tool needs more than the ability to parse a single Go file.

A source file identifies its imports, but the import strings alone do not specify where the chosen versions live on disk. Modules add version selection and a download cache to that lookup. An editor that assumes the unversioned GOPATH layout can find an available copy of a dependency without finding the copy selected for the build.

The release notes describe a different division of responsibility. The package-loading API runs a query command such as go list to obtain package information. Build-system knowledge can therefore remain with the mechanism that understands the build. The same approach can support alternative build systems rather than requiring every source-analysis tool to reproduce their rules internally.

That design changes what a tool author needs to maintain. The tool can focus on analyzing the resulting packages while relying on a loader to locate them. The benefit depends on supplying the right context to that loader. Asking the correct question from the wrong directory can still describe the wrong package tree.

Editor context becomes part of correctness

The released go command help defines Go 1.11's module-mode rules. In automatic mode, the command considers whether it runs outside GOPATH/src and whether a go.mod exists in the current directory or an ancestor. The selected environment can force module mode on or off.

These are concrete reasons for the agenda's editor-context discussion. An editor invokes tools on behalf of a user, and those invocations need a working directory and environment. If the editor supplies different values from the terminal, the same package name can produce different loading behavior. That is a consequence of the documented mode rules, rather than evidence of a defect in a named editor.

An explicit package query illustrates what information the command can expose in module mode.

go list -m all

The command reports the build list, including the selected module versions. It helps explain a dependency choice that is not apparent from a single file. An editor integration needs equivalent agreement about the selected program before more elaborate navigation or analysis can be reliable.

Coordination concerns performance as well

Jolly's agenda includes the speed of cmd/go list. That is a significant item when package discovery moves behind a command query. Correct dependency information can still be frustrating if every interaction requires expensive repeated work. The agenda establishes that query performance is among the issues proposed for discussion, without promising a particular optimization.

The proposed language-server discussion addresses another possible place to share work. A common service could give editors a shared implementation of language operations. The invitation does not select a final architecture or establish that one implementation already handles every module case. It records a topic for participants to examine together.

I prefer this kind of explicit coordination to each editor quietly inventing its own dependency interpretation. There can be different user interfaces while the underlying package identity remains consistent. Sharing that understanding reduces the number of unrelated explanations a programmer needs for one build.

The invitation is open to interested participants and follows sessions begun at GopherCon. Its immediate contribution is a common agenda for people maintaining interdependent tools. Package loading and editor context have to fit the same module rules, while query performance determines whether the integration remains usable during editing. The planned discussion gives those concerns a place to be considered together before individual tools make incompatible assumptions.