Skip to content


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

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 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 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

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 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

npm will now check the linked source commit and repository when you view a package's provenance information on 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

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

Many accessibility improvements have been deployed to 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

See more

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 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
   types: [created]
   runs-on: ubuntu-latest
     contents: read
     id-token: write
     - uses: actions/checkout@v3
     - uses: actions/setup-node@v3
         node-version: '18.x'
         registry-url: ''
     - run: npm install -g npm
     - run: npm ci
     - run: npm publish --provenance --access public
         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

Today we are making the granular access token feature on npm generally available.

Granular access token, allows you to:

  • Restrict token access to specific packages and/or scopes
  • Grant tokens access to specific organizations for org and user management
  • Set a token expiration date
  • Limit token access based on IP address ranges
  • Select between read and/or write access for the token

We recommend using granular access tokens with least privileges for automating your publishing and org management activities. You can allow your package to be published without 2FA using granular access tokens from your trusted CI/CD systems. Additionally, you can also configure your package to require 2FA when publishing from a local machine to defend against account hijacking.

Read more about creating a granular access token here.

See more

GitHub Security was recently notified about a caching issue affecting npm. This bug had been present since 2016 and sporadically caused npm maintainers to be re-invited upon removal from packages or organizations. Our Security team investigated potential instances of the issue and believe this bug only occurred if a user was removed, followed shortly by the addition of a different member. This bug affected npm-cli version 6 and above, and was fixed in version 7+.

Out of an abundance of caution, we are recommending all npm users review the maintainers of their projects and organizations for any discrepancies that may be a result of this bug and remove any unexpected members. Please feel free to reach out to us with any additional questions or concerns through the following contact form:

See more

You can now view the content of a package with the updated code explorer directly on the portal. We have improved the reliability, performance and have now made this feature available for free. You no more need to download a package to view its content. With this feature, you can easily scrutinise packages to make sure it is safe for use in your application. The code explorer provides syntax highlighting for .js, .ts, .md, .json and other commonly used file types in npm packages. You can also view the content of any previous version of a package.

Start by exploring the npm package.

See more

You can now create access tokens with limited scope using the new granular access tokens functionality in npm. With granular access tokens, you can:

  • Restrict which packages and/or scopes a token has access to
  • Grant tokens access to specific organizations for user management
  • Set a token expiration date
  • Limit token access based on IP address ranges
  • Select between read and/or write access

Tokens with least privileges protects your npm packages from accidental or malicious misuse of your token. These tokens also allow you to manage your npm org and teams from a CI/CD pipeline. Granular access tokens are specifically built for automation and do not require 2FA. We recommend using granular access tokens with least privileges while you automate publishing and org management activities.

See more


The npm CLI v9 is now generally available! As of today, running npm i -g npm will install the latest version (v9.1.1). Details on the major breaking changes, features and bug fixes of v9 can be found in our last changelog post.

A huge shout out to all of the contributors who helped make this release possible and who continue to make npm awesome.

Learn more about v9.1.1 in the release notes. You can also find references to previous releases in the project's

See more

Starting today, two-factor authentication (2FA) will be enforced for maintainers of all high-impact npm packages. A package is marked as a high impact package when they have more than 1 million weekly downloads or have more than 500 dependents. Maintainers of such packages will be notified 15 days in advance to enroll for 2FA.

To learn more about configuring 2FA, see Configuring two-factor authentication.
To learn more about 2FA in general, see About two-factor authentication.
For questions and comments, open a discussion in our feedback repository.

See more

We have streamlined our account recovery flow to help us verify your identity in the instance you lose access to your two-factor authentication (2FA) device and get locked out of your npm account.

If you lose access to your 2FA device and your recovery codes, you can now sign in to your npm account using your username and password and then request an account recovery. You will be asked to fill the form as shown below. We recommend you provide as much information as possible when requesting an account recovery.


Read more about how you can recover your 2FA enabled accounts here.

For accounts with 2FA, linking your GitHub account and Twitter account in your profile settings will help verify your identity quicker.

Note: The new account recovery flow tries to gather and map information about your identity such that our support team can address your request sooner. Since there is a manual review in place, this recovery process will take few days to complete. We recommend our users generate and keep a copy of their recovery code to be used as the primary recovery option and avoid getting locked out of your account for a prolonged period of time.

See more

The npm CLI team has been working hard over the past few months and are happy to announce the release of the next major version – v9.0.0


You can start using npm v9.0.0 today by running:

$ npm i -g npm@9

About this release

Our goal with this major release was to standardize appropriate defaults and clean up legacy configurations where possible. We believe the changes made lay the ground-work for future improvements to the default npm experience long-term. Notably, Docker users should find this release to to be beneficial as we simplifie file permissions (ref. #5703 & #5704).

Timeline to GA

Although we have published v9.0.0, we are not immediately setting this release to latest in the npm registry or considering this “Generally Available.” Our team has been coordinating with the Node.js Release WG on a phased approach to making v9 the next major version of the CLI available to the widest audience; this means ensuring v9 can be safely backported to as many Node.js LTS versions as possible. With that in mind, we’ve put together a phased roll-out plan outlined below:

  • Wednesday Oct. 19th
    • npm@9.0.0 was released & set to the next-9 dist-tag (previously used for pre-releases)
    • The CLI team will continue to cut minor & patch versions of v9.x, addressing any feedback or unexpected issues arising from the breaking changes (outlined below)
  • Wednesday Nov. 9th (General Availability)
    • To ensure npm@9.x is considered "non-breaking" for Node.js LTS we will codify a set of exit criteria in collaboration with the Release WG
    • npm@9.x will be set to the latest dist-tag (becoming the latest, maintained version of npm)
    • A PR will be opened to land npm@9.x in nodejs/node's main branch (exposing experimental/nightly users to this latest version)
  • Wednesday Dec. 7th (~4 weeks after GA)
    • A PR will be opened to backport npm@9.x in node@19
  • Wednesday Jan. 18th (~6 weeks after node@19 backport)
    • A PR will be opened to backport npm@9.x in node@18

⚠️ Notable Breaking Changes

  • the compatible semver ranges of node have been updated to: ^14.17.0 || ^16.13.0 || >=18.0.0
  • npm will no longer attempt to modify ownership of files it creates
  • the presence of auth related settings that are not scoped to a specific registry found in a config file is no longer supported and will throw errors
  • login, adduser, and auth-type changes
    • legacy auth types sso, saml & legacy have been consolidated into "legacy"
    • auth-type defaults to "web"
    • login and adduser are now separate commands that send different data to
      the registry.
  • npm pack now follows a strict order of operations when applying ignore rules. If a files array is present in the package.json, then rules in .gitignore and .npmignore files from the root will be ignored.
  • links generated from git urls will now use HEAD instead of master as the default ref
  • timing and loglevel changes
    • timing has been removed as a value for --loglevel
    • --timing will show timing information regardless of
      --loglevel, except when --silent
  • --timing file changes:
    • When run with the --timing flag, npm now writes timing data to a
      file alongside the debug log data, respecting the logs-dir option and
      falling back to <CACHE>/_logs/ dir, instead of directly inside the
      cache directory.
    • The timing file data is no longer newline delimited JSON, and instead
      each run will create a uniquely named <ID>-timing.json file, with the
      <ID> portion being the same as the debug log.
    • Finally, the data inside the file now has three top level keys,
      metadata, timers, and unfinishedTimers instead of everything being
      a top level key.
  • npm now outputs some json errors on stdout. Previously npm would output all json formatted errors on stderr, making it difficult to parse as the stderr stream usually has logs already written to it.
  • deprecated boolean install flags in favor of --install-strategy
    • deprecated --global-style, --global now sets --install-strategy=shallow
    • deprecated --legacy-bundling, now sets --install-strategy=nested
  • npm config set will no longer accept deprecated or invalid config options
  • install-links config defaults to "true"
  • node-version config has been removed
  • npm-version config has been removed
  • npm access subcommands have been renamed
  • npm birthday has been removed
  • npm set-script has been removed
  • npm bin has been removed (use npx or npm exec to execute binaries)

Notable Features

  • a09e19d #5696 new npm config fix command (@nlf)
  • 3445da0 npm timings are now written alongside debug log files (@lukekarrys)
  • 6ee5b32 query: now displays queryContext in results (@nlf)
  • 314311c #5550 separated login/adduser (@wraithgar)
  • de2d33f add --install-strategy=hoisted|nested|shallow (#5709) (@fritzy)

For more information about this release, check out the GitHub release notes.

See more