npm Blog (Archive)

The npm blog has been discontinued.

Updates from the npm team are now published on the GitHub Blog and the GitHub Changelog.

npm v7 Series - Beta Release! And: SemVer-Major Changes in npm v7

<< Why keep package-lock.json?

A new beta version of npm appears!

tl;dr - Run npm i -g npm@next-7 right now, and tell us about any problems you encounter with it.

This is a big one, you’re going to want to check it out. As with any beta software, it’s likely to still have a few rough edges, but we’re confident that those will be polished down very quickly. Your help finding them will make that process go much faster.

This post outlines the major-version updates (aka “Breaking Changes” in SemVer lingo) in this release. If you’re going to start using npm v7, it would be good to take a look over this list and make sure nothing is going to ruin your day.

Despite a massive overhaul of most of npm’s functionality, we are endeavoring to make npm v7 as low-risk and low-effort as possible, for as many users of npm as we possibly can. Nevertheless, this list is fairly long, because we endeavor to call out a change even if we think the impact is likely minor.

For the massive majority of npm users, where your experience is “install my stuff, do the right thing, let me get back to work”, we are confident this update will be entirely an improvement to your development experience.

On the “Breaking” in “Breaking Changes”

The Semantic Versioning specification precisely defines what constitutes a “breaking” change. In a nutshell, it’s any change that causes a you to change your code in order to start using our code. We hasten to point this out, because a “breaking change” does not mean that something about the update is “broken”, necessarily.

We’re sure that some things likely are broken in this beta, because it’s best to be pessimistic about beta software. But nothing is “broken” on purpose here, and if you find a bug, we’d love for you to let us know so we can get it fixed before the beta tag falls off.

Peer Dependencies

We have identified automatic peerDependencies installation as a potentially disruptive change for many users (albeit one that we are confident is the correct behavior for a package manager), we have some tools to minimize this disruption, based on the feedback we get.

We are confident that resolving package trees such that peerDependencies are properly accounted for is the right thing to do. After all, an error here can result in a production issue that’s very difficult to debug later, especially if it occurs deep in a node_modules tree. However, years of not resolving peerDependencies has allowed many projects to fail to notice these problems.

In order to get unblocked and install your project in spite of peerDependencies conflicts, you can use the --legacy-peer-deps flag at install time. It may be that the disruption is too great to take all at once, and we have to have this flag enabled by default for a while as projects gradually update their conflicting dependencies. Our intent is to let the beta give us some more data points to help make that decision carefully.

Regardless of where we land on installs, the npm ls command will always run with --legacy-peer-deps set to false, so that missing peer dependencies will be highlighted when looking at the package tree. We hope that this will be useful encouragement to get projects to update out of a broken state (or worse, a “works by accident” state).

Beta Schedule

Beta versions of v7 will go out weekly on Tuesdays until everything looks good. We’ll decide to cut a GA release based on stability and getting the last bits of housecleaning done.

What’s Missing From This Beta (Why Not GA?)

We have not yet gotten to 100% test coverage of the npm CLI codebase. As such, there are almost certainly bugs lying in wait. We do have 100% test coverage of most of the commands, and all recently-updated dependencies in the npm stack, so it’s certainly more well-tested than any version of npm before.

There’s still lots of work we need to do in updating the documentation. Prior to a GA release, we’ll be going through all of our documentation with a fine-toothed comb to make sure it’s as accurate and helpful as possible.

That’s about it! It’s ready to use for most purposes, and you should try it out.

Now on to the list of changes.

Programmatic Usage

All Registry Interactions

The following affect all commands that contact the npm registry.

All Lifecycle Scripts

The environment for lifecycle scripts (eg, build scripts, npm test, etc.) has changed.


The npx binary was rewritten in npm v7, and the standalone npx package deprecated when v7.0.0 hits GA. npx uses the new npm exec command instead of a separate argument parser and install process, with some affordances to maintain backwards compatibility with the arguments it accepted in previous versions.

This resulted in some shifts in its functionality:

We do intend to continue supporting the npx that npm ships; just not the npm install -g npx library that is out in the wild today.

Files On Disk

Dependency Resolution

These changes affect install, ci, install-test, install-ci-test, update, prune, dedupe, uninstall, link, and audit fix.


npm update

npm outdated

npm adduser, npm login

npm audit

npm dedupe

npm fund

npm ls

npm pack, npm publish

npm rebuild

npm build, npm unbuild

npm test


Huge thanks to the people who wrote code for this update, as well as our group of dedicated Open RFC call participants. Your participation has contributed immeasurably to the quality and design of npm.

<< Why keep package-lock.json?