Pkg.go.dev groups modules and adds symbol search

A search page can return relevant packages and still make the useful choice difficult to see. Several packages from one module can occupy separate results, while older major versions of the same dependency compete for attention. Pkg.go.dev's new search experience changes how those related results appear and adds a separate way to find symbols.

Julie Qiu's November 9 announcement describes grouping by module and major version. The redesign tracking issue, opened in July, records the problems that motivated the work. Its list includes noisy package results and confusing presentations of the latest version. The change concerns how developers interpret search output, alongside what the search can find.

I value being able to enter an unfamiliar Go package and understand its public declarations. Finding the right package is an earlier part of that same task. A result page that distinguishes a module family from its individual packages reduces ambiguity before the documentation even opens.

Packages share their module's result

The search now groups packages belonging to the same module. Within that group, the package most relevant to the query receives the highlight. Other packages remain available through a row identifying additional packages in the module. The announcement uses a search for markdown as an example.

This preserves two kinds of information. The highlighted package answers the immediate query, while the group indicates that related results belong to the same dependency. Without that organization, several related packages can look like several independent alternatives. Their presence may be justified individually while their combined presentation consumes attention disproportionate to the number of choices.

Grouping does not establish that all packages in a module do the same job. A module can contain packages with different purposes. The result page still needs a relevant representative and access to the alternatives. The announced behavior supplies both, so the grouping changes presentation without requiring readers to infer a module's contents from its name alone.

The tracking issue puts this in context by linking earlier complaints about top-level package results and the lack of module-oriented search. These are problems in the unit presented to a reader. Someone choosing a dependency may need to compare modules, while someone following an import needs a particular package. A result page can support both tasks if it makes their relationship visible.

Major versions form another group

Different major versions of the same module now appear together too. The highlighted result is the highest major version containing a tagged release. The announcement's github query example highlights the v39 module and lists older versions as other major versions.

The tagged-release qualification matters. The policy is more specific than choosing whichever version-like name sorts highest. It gives a reader an explicit account of why one major version is prominent. Older versions remain accessible, which matters when documentation needs to match an existing dependency rather than a new selection.

This also distinguishes discoverability from an upgrade recommendation. A highlighted major version identifies what the search presents first under its rule. It does not establish compatibility with an application's current use. The grouping helps a reader locate the alternatives needed to answer that separate question.

Imports, versions, and license information also have a revised layout with direct links to their tabs. These are useful next steps from a search result. A reader can move toward the information relevant to evaluating or locating a package without treating the search ranking as sufficient evidence about it.

Identifiers get a distinct search path

The release adds search for symbols in Go packages. When the site identifies a query as a symbol search, it opens a new tab of symbol results. The announcement points to homepage examples and search help for the supported forms. This creates another route into documentation when the reader knows an identifier instead of a package's role.

That route complements package search. Searching for a capability and searching for a known declaration begin with different evidence. A package description may contain the useful term for the first task. A symbol name may be the only precise clue available for the second. Presenting the latter as its own result type makes the match easier to interpret.

The announcement places symbol search beside earlier documentation work. Pkg.go.dev already shows package API history and marks deprecated symbols in the index while hiding them by default in package documentation. Discovery therefore leads into documentation that also describes changes and deprecation state.

I find that combination useful because locating an identifier is only the start of understanding it. A symbol result can establish where to read next. Its package documentation and history then supply context for deciding whether that declaration is appropriate for the code being maintained.

The rollout has a visible history

The tracking issue records the redesign becoming available on beta.pkg.go.dev in August and reaching pkg.go.dev on November 9. That sequence gives the launch a specific public history. The announcement invites feedback through the site's issue-reporting control and identifies the project as open source.

The practical change is a more informative result structure. Module grouping reduces repeated alternatives, major-version grouping explains the prominent tagged version, and symbol results support identifier-based lookup. A reader can then use the linked documentation to examine the package or declaration that the search has located.