This is the documentation for https://docs.npmjs.com/. Do you want to contribute a change? Great!
npm installto download Gatsby and all the dependenciesnpm run develop: starts the test server athttp://localhost:8000.- Update the content - it's MDX, which is like Markdown - in the
contentdirectory. - Review your content at
http://localhost:8000. (Gatsby watches the filesystem and will reload your content changes immediately.) - Once you're happy, commit it and open a pull request at https://github.com/npm/documentation.
- A CI workflow run will publish your PR to a GitHub Preview Page.
- Once the content is reviewed, merge the pull request. That will deploy the site.
First, npm install the dependencies. This will install Gatsby, et al.
Next, npm run develop to start the test server to view your changes. The Gatsby server will be started on port 8000. You can navigate to http://localhost:8000 to view the site live.
In order to cut down on the time it takes npm run develop to complete, you can use the environment variables GATSBY_CONTENT_ALLOW and GATSBY_CONTENT_IGNORE to only build some pages.
For example, if the only pages you need to test locally are in /cli/v10/commands, then you can run the the following to build the cli/v10/commands pages:
GATSBY_CONTENT_ALLOW=cli/v10/commands npm run developThe content/cli directory has the most pages so it tends to be most helpful to ignore older CLI versions unless you need to explicitly test those pages:
GATSBY_CONTENT_IGNORE=cli/v6,cli/v7,cli/v8,cli/v9 npm run developFor best results use Node 18 and npm 9+
Gatsby will watch your filesystem looking for updates. Any content changes you make should be reflected in the site immediately.
We use Conventional Commits.
When opening a pull request please be sure that either the pull request title, or each commit in the pull request, has one of the following prefixes:
feat: For when introducing a new feature.fix: For bug fixes.docs: For documentation updates. This specifically means the documentation in and this repo, NOT the contents of the documentation site itself.chore: For changes that do not affect the published site. Often these are changes to tests. The result will be no change to the website when it is next published.
The documentation content lives in the content directory, and is Markdown. (Actually, MDX, a sort of reactive Markdown.)
Static content lives in the static directory. Since most of the static content is screenshots, you can use the Screenshot component to reference them, which is an extension of the Img component that is configured for the docs site. For example, an image living as static/organizations/managing-teams/team-members.png would be referenced as:
<Screenshot src="/organizations/managing-teams/team-members.png" alt="Screenshot of the team members button" />
(Note the alt tag, it is mandatory.)
There are various places where we want to share content between pages, to prevent copy-pasta. For example, we display a screenshot of the user login dialog repeatedly. Therefore this shared content is defined in src/shared.js, and includes a literal MDX snippet.
For example, user-login is defined with text and image properties:
'user-login': {
'text': (<><Link href="https://www.npmjs.com/login">Log in</Link> to npm
with your user account.</>),
'image': (<Screenshot src="/shared/user-login.png" alt="Screenshot of np
m login dialog" />)
},Since MDX is reactive, you can import the shared data at the top of the file, just beneath your frontmatter. It uses the special path ~/shared.js so it can be imported the same way from any nested file without needing to figure out the appropriate relative path:
---
title: Using shared content
---
import shared form '~/shared.js'
And then reference the shared content within <>:
To login, <>{shared['user-login'].text}</>
Note that for backward compatibility reasons, the on-disk paths are not precisely identical to the URLs for the documentation. To keep URLs expressive but still short, intermediate directories are removed from a page's URL.
You can see this navigating through the documentation hierarchy: if you visit the "Packages and modules" page, you'll navigate to https://docs.npmjs.com/packages-and-modules.
There's then a folder beneath that, "Contributing packages to the registry", which is (sensibly) at https://docs.npmjs.com/packages-and-modules/contributing-packages-to-the-registry.
You might (understandably) expect the page "Creating Node.js modules" to be URL-wise beneath contributing-packages-to-the-registry, but unfortunately, you would be wrong. To keep URLs short, the intermediate folder paths are removed from pages, so "Creating Node.js modules" becomes https://docs.npmjs.com/creating-node-js-modules.
If you have only a URL and want to find where it lives on disk, you can consult the left-hand navigation on the site.
You can also use find from within the content directory. For example:
find . -iname creating-node-js-modules\* -print
The content pages should include frontmatter.
title: the page's title (string); requiredredirect_from: any URLs on the site that will be redirected to this page (array of strings)
The site's navigation (on the left-hand sidebar of the site) is controlled by content/nav.yml. If you add or remove a page from the site, you'll also want to add or remove it from the navigation configuration.
The documentation for the npm cli is not modified in this repository. Instead, the canonical location for it is in the npm/cli repository. Modifications to those files are automatically included here for completeness.
Pull requests to CLI documentation in this repository will be closed.
Since the CLI documentation content lives in the npm/cli repo, there is a GitHub Actions workflow that pulls documentation updates from the CLI into this repository. This is done nightly.
This process can, of course, be done manually. This may be useful for editing its behavior or debugging, and it should be done when you're adding a new major version to the site.
-
Review the configuration
Thecli/releases.jsonconfigures how the CLI documentation is included. It is an array of documentation versions, each having the following configuration:id: A short identifier for the documentation version, egv6orv7. This corresponds to a directory containing a version of the CLI repository (using a submodule). This will also be used as the output folder in the content.branch: The branch name for the version. This will be used to fetch the latest version of the documentation from GitHub.spec: The registry spec for the version. This will be used to fetch the latest version in that range from the registry.resolved: This should not be edited manually. This is a reference to the last fetched version of the content for this release. If a future fetch is done and this field matches what is returned from the registry, then no updates will be made. To force an update (which can be useful when making changes to thebin/build.jsscript) it can be run with the argument--force.
-
Fetch and import the latest content for each CLI release
Runnpm run build -w clito download the latest version for each release and import its content into thecontentdirectory. This will take the content in each submodule'sdocs/contentdirectory, perform any necessary translations (like adding historical redirects) and putting it in this repository'scontentdirectory. In addition, it will take thedocs/nav.ymland include it in this repository's navigation.
When a pull request is opened or updated the GitHub Actions workflow will deploy a preview to the github-pages environment. The URL will be reported to the pull request and the status can be checked by looking at the workflows for the pull_request_target event.
The docs site (https://docs.npmjs.com/) is published from a GitHub Actions workflow on any push into the main branch. That means that the workflow for updating the site is:
- Make your changes locally, review them, commit them.
- Open a pull request for review
- Merge that pull request
On step three, your changes will be published live! 🎉