Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
x/pkgsite: redesign - the pkg.go.dev/<path> page #41586
We'll be redesigning pkg.go.dev based on feedback received over the last year. This is the first in a series of issues about plans for the pkgsite/design-2020 milestone. Comment below with any feedback or suggestions related to this issue!
We will redesign the pkg.go.dev/<path> page such that information is organized around a path. A path represents a directory in a particular version of a module. A path may be a package, the root of a module, and/or contain subdirectories.
Currently, the landing page for a given path differs for each of these cases, even when a path fits into more than one case. For example, golang.org/x/tools (a module) has two landing pages - pkg.go.dev/mod/golang.org/x/tools shows the overview tab and pkg.go.dev/golang.org/x/tools shows the subdirectories tab. golang.org/x/tools/go (a subdirectory) shows the subdirectories tab and golang.org/x/tools/go/packages (a package) shows the doc tab.
These different pages will become a single page in the new design.
The changes to the pkg.go.dev/<path> page described below are motivated by wanting to make the page consistently useful and predictable. Here's a preview of what that page will look like:
Note: The images shown in this issue are mocks, so the data may not accurately represent the exact contents of a given package.
1. Single URL for all paths
Each pkg.go.dev/<path> page will display information for that path, regardless of its type.
The existing “/mod” namespace will be deprecated. Requests to
The default page will not have a tab query param.
2. Consistent landing page
To create a consistent landing page, content on the doc, overview and subdirectories tabs will be consolidated into a single page. A pkg.go.dev/<path> page will always display at least one of the following:
If a path does not have content for one of these sections, that section will be omitted from the page.
3. README section
Currently, the overview tab only shows the README if present at the module root. By organizing information around a path, we plan to display the README section, only if a README is present at that path.
On the other hand,
4. Documentation section
The documentation section will be described in more detail in #41587.
5. Source Files and Directories sections
The UI for source files and directories will be similar to the existing layout. The Directories section will display both subdirectories and nested modules relative to the current path.
We are also exploring using a tree structure in the directories section, since some pages have lots of subdirectories (example: subdirectories tab for cloud.google.com/go). This will be discussed in a later issue.
If a path is also the root of a module, could you clarify how the UI would look for that case? What if it's both the root of a module and the package - which information would show up by default?
Also, I assume you're using the term "directory" to mean either "package" or "module". I think that might be confusing to users, because
Regardless of whether the path is a package or a module, we'll be displaying the contents as described under
To give a few examples:
Thanks for the suggestion! Edited the issue above to use "path" instead of "directory" where applicable.