npm

Subscribe to all “npm” posts via RSS or follow GitHub Changelog on Twitter to stay updated on everything we ship.

→ ~ cd github-changelog
→ ~/github-changelog|main git log main
showing all changes successfully

Easily distinguish between direct and transitive dependencies for npm packages

npm’s massive ecosystem of open source packages is one of its greatest strengths. But as a security-conscious developer, it can be tough to keep up with vulnerability reporting and updates once your project has more than a handful of dependencies, each of which has its own set of dependent packages. Dependabot notifies you of vulnerabilities and their fixes as they come in. Unfortunately, it’s hard to distinguish actionable alerts about direct dependencies you’ve added to your manifests from those transitive dependencies that were pulled in along the way… until now, that is.

GitHub’s dependency graph now tracks direct and transitive dependencies for npm packages. This helps you triage, prioritize, and remediate your Dependabot alerts. This capability shows up in user-facing features across the site:

  • Dependabot alerts will now contain a direct label if they are associated with a package you’ve directly included in a manifest. You can filter the list of alerts down to only these direct ones with the relationship:direct filter in the search bar.
  • Alerts for transitive dependencies now show transitive path information – the chain of packages which led from your direct dependency to the transitive one which has the vulnerability.
  • A repository’s dependency graph now distinguishes between direct and transitive relationships. Direct dependencies will have a label in the table UI, whereas indirect dependencies have a disclosure menu that shows the transitive path which led to their inclusion.
  • A repository’s SBOM will contain a relationships section that uses the SPDX relationshipType: DEPENDS_ON field to express the tree of package dependencies. Tools like guac.sh can help explore and visualize this tree.
  • The GraphQL API will now return a relationship field with direct, transitive, or unknown values in the DependencyGraphDependency object. See the API documentation for details.

A table of Dependabot alerts can now be filtered to show only direct dependencies

We started with npm because it’s the most popular package ecosystem in the known universe, but it’s just the beginning. Over the next few months, package types for other programming languages will also get the transitivity treatment. Up next: Maven packages for Java.

To try this out, you’ll need to make sure the dependency graph is enabled. To see the Dependabot labels, you’ll also need to enable Dependabot alerts. If the “Direct” labels aren’t showing up for you immediately, push a commit that updates one of your manifest files, which will trigger an update of the dependency graph.

Join the discussion within GitHub Community.

See more

Changes and deprecation notice for npm replication APIs

We are making changes to npm replication APIs to optimize performance and availability. As part of this update, certain endpoints will be deprecated as of Thursday, May 29, 2025.

To facilitate a seamless transition, the new endpoints will be available starting Tuesday, March 18, 2025, operating in parallel with the existing endpoints. The existing endpoints will be fully deprecated on Thursday, May 29, 2025.

During the transition period, you may access the new endpoints by including the npm-replication-opt-in header with the value true in your requests. This option will be available from Tuesday, March 18, 2025 until the deprecation date, after which only the new endpoints will be available. Effective Thursday, May 29, 2025, the header will be ignored, and all requests will be directed to the new endpoints by default.

This notice is provided to ensure adequate time for necessary updates to replication implementations. We strongly encourage developers to migrate to the new endpoints as early as possible.

How to migrate?

To assist with migration, we have detailed documentation in our replication API migration community discussion, outlining alternative approaches for deprecated endpoints when available. This is the go-to place for questions and discussions.

Additional support for migration

If you have further questions or need additional assistance, please reach out to our support team.

See more

Announcing npm’s New Simplified Search Experience [GA]

Today, we’re excited to introduce a new, streamlined search experience on npmjs.com! This update provides clear, objective sorting options that make finding the right packages easier.

The new search helps you quickly discover packages that are widely used, relied on by other projects, or recently updated. By removing vague options – i.e. popularity, quality, maintenance – each sorting option is now straightforward and transparent.

Try it out on npmjs.com, and share your feedback in our GitHub Community discussions.

Happy searching!

See more

Sunset Notice – npm Hooks API Endpoints

Starting today, we are deprecating npm hooks services and they might no longer be functional, including current hooks subscriptions. This deprecation includes npm hooks API Endpoints and its related cli npm hook command. Users should expect the API Endpoints to respond with a deprecation message. The npm cli will no longer be able to add new hooks using the npm registry.

The npm hooks services were launched as Beta in 2016 so users could use the endpoints to be notified of changes in the npm packages, owners, or scopes. The service never achieved a full GA maturity. We are sunsetting the hooks services in favor of our ongoing investments for the npm platform, including high quality standards on the maintenance of our other existing services.

See more

npm feedback is now available on GitHub Community

npm feedback is now available on GitHub Community. Previously feedback for npm took place on the npm feedback channel, which is going to be sunset as we migrate unresolved discussions.

External users should utilize the new npm category on GitHub Community to make suggestions to any part of npm, the cli, the registry, and the website. Users can vote and rank topics to voice their opinions and give support to existing items.

Please join us on GitHub Community to share your feedback on npm!

See more

Block npm package publishes when names and versions don’t match between manifest and tarball package.json

On September 27, 2023, we began blocking npm package publishes with differing name or version fields between the manifest and tarball package.json. This blocking protects against obfuscation. The different fields in the manifests have been assessed from a risk-based perspective. We will continue to analyze for other mismatches that can be blocked that won’t have adverse effects on the ecosystem. If a package is blocked, a user may receive an error message similar to “Package ‘version’ is “1.0.4”. It should match “1.0.3” from “package.json” in packaged tarball. Make all changes to package.json before packaging a tarball to publish.” In addition, a new tool, npm pkg fix, can help users fix any validation errors from the registry when they attempt to publish a package.

See more

npm provenance general availability

npm provenance is now generally available.

npm packages built on a supported cloud CI/CD system can publish with provenance. Today this includes GitHub Actions and GitLab CI/CD.

Publishing with provenance verifiably links the package back to its source repository and build instructions. Provenance is restricted to public packages and public source repositories only.

npm will check the linked source commit and repository when you view a package's provenance information on npmjs.com. If the linked source commit or repository cannot be found, an error displays at the top of the page and alongside the provenance information to let you know that provenance for this package can no longer be established. This can happen when a repository is deleted or made private.

Once published, packages display provenance on the registry website:

Provenance displayed on the registry website

For more information, see generating provenance.

See more

Publishing with npm provenance from private source repositories is no longer supported

Starting today, publishing with provenance is restricted to public source repositories only. Private source repositories are no longer supported for use with provenance for public packages.

As announced on July 11, 2023: npm will verify the linked source commit and repository when users view a package's provenance information on npmjs.com. If the linked source commit or repository cannot be found, an error will be displayed. This can occur if a repository is deleted or if it is made private.

Read more about viewing npm provenance and publishing with provenance.

See more

Warn when the npm provenance source commit or repository cannot be found

npm will now check the linked source commit and repository when you view a package's provenance information on npmjs.com. If the linked source commit or repository cannot be found, an error displays at the top of the page and alongside the provenance information to let you know that provenance for this package can no longer be established. This can happen when a repository is deleted or made private.

Note: In future releases, publishing a public package with provenance from a private source repository will not be allowed.

Read more about viewing npm provenance and publishing with provenance.

See more

Improvements to granular access tokens on npm

Today we are making further improvements to granular access tokens in npm.

Highlights of this update are

  • Custom Expiration Times: You can now create granular access tokens with custom expiration times, allowing for durations that span multiple years.
  • Increased Token Limit: We have expanded the maximum limit for granular access tokens creation to 1000. This enables maintainers with a large amount of packages to secure their publishing workflows more efficiently.

We recommend using granular access tokens with least privileges (for example one token per package) for automating your publishing and org management activities.

Read more about creating a granular access tokens here.

See more

Accessibility improvements for npmjs.com

Many accessibility improvements have been deployed to npmjs.com. Highlights include:

  • Site-wide improvements to color contrast, text resize, and support for users with low vision.
  • Improvements that enable keyboard-only access including visual tracking of the focus indicator.
  • Improved support for assistive technologies including screen readers.

Your feedback is welcome! Please share feedback on the accessibility community discussions page and learn more about GitHub accessibility at accessibility.github.com.

See more

Dependabot alerts now automatically dismiss false positives for npm (public beta)

Starting today, Dependabot will be able to auto-dismiss npm alerts that have limited impact (e.g. long-running tests) or are unlikely to be exploitable. With this ship, Dependabot will cut false positives and reduce alert fatigue substantially.

On-by-default for public repositories, and opt-in for private repositories, this feature will result in 15% of low impact npm alerts being auto-dismissed moving forward – so you can focus on the alerts that matter, without worrying about the ones that don’t.

What’s changing?

When the feature is enabled, Dependabot will auto-dismiss certain types of vulnerabilities that are found in npm dependencies used in development (npm devDependency alerts with scope:development). This feature will help you proactively filter out false positives on development-scoped (non-production or runtime) alerts without compromising on high risk devDependency alerts.

Dependabot alerts auto-dismissal list view

Frequently asked questions

Why is GitHub making this change?

At GitHub, we’ve been thinking deeply about how to responsibly address long-running issues around alert fatigue and false positives. Rather than over-indexing on one criterion like reachability or dependency scope, we believe that a responsibly-designed solution should be able to detect and reason on a rich set of complex, contextual alert metadata.

That’s why, moving forward, we’re releasing a series of ships powered by an underlying, all-new, flexible and powerful alert rules engine. Today’s ship, our first application, leverages GitHub-curated vulnerability patterns to help proactively filter out false positive alerts.

Why auto-dismissal, rather than purely suppressing these alerts?

Auto-dismissing ensures any ignored alerts are 1) able to be reintroduced if alert metadata changes, 2) caught by existing reporting systems and workflows, and 3) extensible as a whole to future rules-based actions, where Dependabot can decision on subsets of alerts and do things like reopen for patch, open a Dependabot pull request, or even auto-merge if very risky.

How does GitHub identify and detect low impact alerts?

Auto-dismissed alerts match GitHub-curated vulnerability patterns. These patterns take into account contextual information about how you’re using the dependency and the level of risk they may pose to your repository. To learn more, see our documentation on covered classes of vulnerabilities.

How will this activity be reported?

Auto-dismissal activity is supported across webhooks, REST, GraphQL, and the audit log for Dependabot alerts. In addition, you can review your closed alert list with the resolution:auto-dismissed filter.

How will this experience look and feel?

Alerts identified as false positives will be automatically dismissed without a notification or new pull request, and appear as special timeline event. As these alerts are closed, you’ll still be able to review any auto-dismissed alerts with the resolution:auto-dismissed filter.

How do I reopen an automatically dismissed alert?

Like any manually dismissed alert, you can reopen an auto-dismissed alert from the alert list view or details page. This specific alert won’t be auto-dismissed again.

What happens if alert metadata changes or advisory information is withdrawn?

Dependabot recognizes and immediately responds to any changes to metadata which void auto-dismissal logic. For example, if you change the dependency scope and the alert no longer meets the criteria to be auto-dismissed, the alert will automatically reopen.

How can I enable or disable the feature?

This feature is on-by-default for public repositories and opt-in for private repositories. Repository admins can opt in or out from your Dependabot alerts settings in the Code Security page.

Is this feature available for enterprise?

Yes! In addition to all free repositories, this feature will ship immediately to GHEC and to GHES in version 3.10.

What’s next?

Next, we’ll expose our underlying engine – which enables Dependabot to perform actions based on a rich set of contextual alert metadata – so you can write your own custom rules to better manage your alerts, too.

How do I learn more?

How do I provide feedback?

Let us know what you think by providing feedback — we’re listening!

See more

npm provenance public beta

npm packages built on a cloud CI/CD system (like GitHub Actions) can now publish with provenance, meaning the package has verifiable links back to its source code and build instructions.

The cloud CI/CD system securely communicates this information by sending provenance information in a signed OIDC JWT to Sigstore's public-good servers, which returns a signing certificate that is sent to the registry along with your built package.

Here's an example of how to do a build with provenance in a GitHub Actions workflow:

name: Publish Package to npmjs
on:
 release:
   types: [created]
jobs:
 build:
   runs-on: ubuntu-latest
   permissions:
     contents: read
     id-token: write
   steps:
     - uses: actions/checkout@v3
     - uses: actions/setup-node@v3
       with:
         node-version: '18.x'
         registry-url: 'https://registry.npmjs.org'
     - run: npm install -g npm
     - run: npm ci
     - run: npm publish --provenance --access public
       env:
         NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}

Once published, packages display provenance on the registry website:

Provenance displayed on the registry website

Dependencies with provenance can also be verified from the command line with npm audit signatures.

For more information, see generating provenance.

See more
View more changes