We recently released the ability to use web based authentication for the npm login and npm publish commands with the --auth-type=web flag. Now we are extending this feature to all the other commands that require authentication or OTP verification.
This feature is available from CLI version 8.19.1
You can now place a support request for an export of your npm data.
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
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.
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 > *)"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
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.
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.
--auth-type=web flag.Read more about two-factor authentication
from our documentation.
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.
Two-Factored Authentication (2FA) is now enforced for maintainers of the top-500 packages, by dependents, on the npm registry.
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.
A variety of improvements to the npm 2FA experience are now in public beta, including:
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.
The npm Public Roadmap is being deprecated in favor of using the GitHub Public Roadmap to track feature launches for the npm Registry, CLI, and website.
Launched in October of 2020, the original npm roadmap process worked well for the team. As time has passed, the benefits of using a shared roadmap for GitHub and npm now outweigh the flexibility of managing separate ones. From now on, all large launches will be tracked via the GitHub Public Roadmap.
All npm accounts that do not have two-factor authentication (2FA) enabled will now receive an email with a one-time password (OTP) when authenticating through either the npmjs.com website or the npm CLI. The emailed OTP must be provided, in addition to a user’s password, before authenticating. This extra layer of authentication helps prevent common account takeover attacks, such as credential stuffing, which utilize a user’s compromised and reused password. It is worth noting that enhanced login verification is intended to be an additional baseline protection for all publishers. It is not a replacement for 2FA, such as time-based one-time passwords (TOTP), WebAuthn, or other methods described by NIST 800-63B. We encourage maintainers to opt-in to 2FA authentication. In doing so, you will not need to perform enhanced login verification.
You can read more about enhanced login verification in our documentation and blog.
As part of our ongoing commitment to npm ecosystem security, and in advance of enforcing two-factor authentication for top packages maintainers, the npm team has been hard at work improving the experience of using 2FA and managing 2FA for organizations.
Customers who have enabled 2FA are likely to use automation tokens in their CI/CD infrastructure when automating tasks such as publishing a package. To make managing multiple tokens clearer, we now support naming tokens.
Similar to GitHub, it is now possible to enforce 2FA at the organization level on npm. On the members page of an organization, you can now click "Enable 2FA Enforcement" to enforce 2FA for all members of the organization. If current members do not have 2FA enabled, they will be removed when you confirm removal.
We have made it easier to audit adoption of 2FA in organizations as well. You can now see exactly which organization members have 2FA enabled already and filter the list to audit and prepare for enforcing 2FA in your org.
Finally, we've improved how members are added to organizations. Previously all members would be automatically added to the developers team. Now you can select a different team to add members to when you send them the invitation.
On February 16, 2022, all non-audit-related npm Advisory APIs will be deprecated. Historically these undocumented APIs have been used to programmatically access advisory data. If you don’t use these APIs, you don’t need to take any action at this time.
Earlier this year, all npm advisory APIs were updated to be powered by the GitHub Advisory Database. As part of this work, we have created a service that converts the GitHub Advisory entries into a format that is compatible with the npm CLI and other tools that rely on our audit APIs that manage POST requests.
All non-audit-related npm Advisory APIs will be deprecated as the data being served from them has been modified from the original source, the GitHub Advisory Database.
We recommend customers who wish to continue utilizing advisory data should switch to the GitHub Security Advisory GraphQL API.
Today, we are releasing version 8 of the npm CLI. A Semver-Major release of the CLI allows us to drop support for Node.js 10, making it easier for us to maintain npm through the LTS life cycle of Node.js 16.
With this change, most customers will automatically get the update when updating Node.js, and version 8 will be the default version installed when you run npm i -g npm. If you’re interested in reading more about this change, check out this breaking changes issue.
As previously announced, the npm registry now requires TLS 1.2 or higher for all requests, including package installation.
The npm security advisory database is now part of the GitHub Advisory Database. As a result, npm audit will now return URLs to the GitHub Advisory Database and the advisories on the npmjs.com will redirect to GitHub.
npm access tokens will now follow the established format of GitHub authentication tokens as part of our work to create a more secure supply chain.
Previously, the npm access tokens were created as a UUID pattern of 36 characters, which has limitations such as inaccurate detection of compromised npm tokens in packages and GitHub repositories.
With the new pattern, access tokens now start with an identifiable prefix: npm so it is easier to be indexed by features like secret scanning and npm’s internal secret scanners. Moreover, the delimiter following after is no longer a - but an underscore _ meaning a full token can be selected when double clicked.
The last six characters of the tokens consist of CRC32 checksum, which is encoded in Base62 to further eliminate false positives when scanning for leaked tokens.
We strongly encourage you to make the move towards the new format by resetting your existing access tokens to help mitigate any risk to compromised tokens as well as make our secret scanning detection more precise. You can reset your personal access tokens by clicking on Access tokens under your Profile, deleting all of your old tokens and creating new ones.
The npm registry will upgrade its public CouchDB instance on September 15, 2021. As part of this upgrade, we will promote a new CouchDB replica to become our new public CouchDB instance, https://replicate.npmjs.com. This upgrade will reset the CouchDB sequence number.
If you are not familiar with CouchDB replication, then you will not be impacted by this change. In particular, users running npm install or running other commands using the npm CLI will not be affected by this change.
If you replicate our public CouchDB or have an application that is following it, then you may be impacted:
If you are replicating the npm database using CouchDB then you may see a replication delay while your follower re-synchronizes, but you do not need to take any other action.
If you have custom tools that query npm's databases using the CouchDB Replication Protocol then you should ensure that you do not assume that sequence numbers are monotonically increasing, and that your custom replica correctly treats the sequence number as an opaque blob.
The Packages npm registry no longer returns a time value in metadata responses. This was done to allow for substantial performance improvements. We continue to have all the data necessary to return a time value as part of the metadata response and will resume returning this value in the future once we have solved the existing performance issues.
Learn more about the Packages npm registry
For questions, visit the GitHub Packages community
To see what's next for Packages, visit our public roadmap
Note: This post originally inaccurately referred to time as not being returned in the “official npm specification”. While an “official npm specification” does not exist, time is referred to in the registry package-metadata documentation and used for some commands.