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

Fixed bug affecting npm package and organization maintainers

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: https://www.npmjs.com/support.

See more

Explore the content of your npm packages with the new code explorer

You can now view the content of a package with the updated code explorer directly on the npmjs.com 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

Limit scope of npm tokens with the new granular access tokens

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

npm CLI v9 is now generally available

npm-v9

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 CHANGELOG.md.

See more

High-impact package maintainers now require 2FA

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

Improved account recovery flow in case of a lost 2FA device

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.

recover_accounts

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

npm v9.0.0 released

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

Installation

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

Download data stored in your npm account by placing an export request

You can now place a support request for an export of your npm data.

  • Navigate to npm support page.
  • Select "I have an account and billing issue".
  • Select "Data export" as the subtype
  • Provide the requested details and submit the form

Once a request is placed, our support team will review it and initiate an export. You will get an email with a link to download the archive which is valid for 7 days. You must login to your account to download the archive.

Read more in our documentation

See more

Introducing the new npm Dependency Selector Syntax

npm query is a new top-level command as of npm v8.16.0 which accepts a Dependency Selector (as defined in the Dependency Selector Syntax Specification) & returns a filtered JSON Array/NodeList of dependencies from your project. We believe this capability has been a missing piece of the package management ecosystem; With its introduction we hope to unlock the potential for developers to self-serve in asking new, complex questions about their dependencies, their relationships & associative metadata.

For many JavaScript developers, the Dependency Selector Syntax will look very familiar as it is actually an adapted form of CSS. We leveraged this existing, known language & its operators to make disparate package information broadly accessible.

Example Uses:

If I wanted to list all of my dependencies (similar to npm list --all) I can run:

npm query "*"

If I wanted to find every version of react & lodash in my project I can run:

npm query "#react, #lodash"

If I wanted to find all react versions not-defined as a peer dependency I can run:

npm query "#react:not(.peer)"

If I wanted to find all the dependencies in my project that used an MIT license I'd change that query to be:

npm query "[license=MIT]"

If I wanted to find all the git dependencies in my project I can run:

npm query ":type(git)"

If I wanted to find out which of my transitive dependencies used a postinstall script I could run:

npm query ":attr(scripts, [postinstall]):not(:root > *)"

Programmatic Usage

We know many developers in the ecosystem will also want to leverage this new syntax themselves, so we've built it right into the programmatic brain of the CLI. Under the hood, we’ve added a new .querySelectorAll() method to the existing Node Class we use in the @npmcli/arborist library. Tooling authors can now load up & query their dependencies just like we do.

// index.js
const Arborist = require('@npmcli/arborist')
const arb = new Arborist({})

arb.loadActual((tree) => {
  // query all workspaces
  const results = await tree.querySelectorAll('.workspace')
  console.log(results)
})

You can learn more about the syntax & usage in our documentation here: https://docs.npmjs.org/cli/v8/using-npm/dependency-selectors

What's next?

Looking ahead we’ve got work planned to add new pseudo states & selectors based on registry metadata that should unlock another host of capabilities aimed at auditing (examples include: :outdated :deprecated :vulnerable :cve() & :cwe()). As documented in the original RFC proposal we will also consider supporting a query flag or reading from stdin to existing commands.

See more

General Availability of improved 2FA experience in npm

Enhanced Two-Factor Authentication (2FA) experience is now Generally Available. Previously, we had announced a set of improvements in our public beta. Further to this we have made the following new changes to streamline the CLI login experience.

  • As of npm 8.15.0 Login and Publish authentication from CLI can now be managed by the browser with the --auth-type=web flag.
  • Login can use an existing web session, only prompting for your second factor or email verification OTP to create a new CLI session.
  • Publish now supports “remember me for 5 minutes” and allows for subsequent publishes from the same IP + access token to avoid the 2FA prompt for a 5-minute period.
  • You can now use 2FA for re-verification requests while performing high privilege operations on npmjs.com.

Read more about two-factor authentication
 from our documentation.

See more

A new npm `audit signatures` command to verify npm package integrity

The public npm registry is migrating away from the existing PGP signatures to ECDSA signatures that are more compact and can be verified without extra dependencies in the npm CLI.

Ensure the integrity of packages you download from the public npm registry, or any registry that supports signatures, by verifying the registry signatures of downloaded packages using the following npm CLI command:

npm audit signatures

The CLI will error if some packages have missing or invalid signatures. This could indicate that those packages might have been tampered with.

Read more about this feature from our documentation: about registry signatures.

See more
View more changes