npm v7 Series - Introduction

Quite a lot has happened in npm since our last update way back in 2019. We’re overdue for a status update on npm v7.

Despite some massive distracting changes (some unfortunate, some very fortunate), development work has been proceeding steadily.

Yesterday, Edward Thomson presented a demo of a few of the features coming in npm v7 at GitHub Satellite. The Q&A session was awesome, and it was clear that a lot of you are excited for this update to the npm CLI, and have a lot of questions that unfortunately couldn’t be adequately answered in such a short time.

This post started as a brief update on what we’ve been doing, intended to go live along with the talk, but it got long. So, instead, this is the first post, with more to come, where I take you all through some of the major changes coming in npm v7, the thinking and motivation behind them, and how they might affect you and your work.

Vision

npm v7 is based on a handful of technical and user experience principles, and each post in this series will tie back to one or more of these in some way.

Reduce noise that is not actionable. Or, in other words “make npm yell at you less”. We’ve gone through the entire project from the data management to the presentation layers, stripping output that doesn’t provide worthwhile information.
Manage your packages for you. There are a handful of places in npm where v6 and earlier versions sort of throw up their hands and make you fix stuff by yourself. But npm is a package manager! It shouldn’t make you manage packages, that’s its job!
Strict separation of concerns. Moving forward, the npm CLI itself is becoming strictly the user-interface layer, and we’ve moved out all complex tree management and registry interactions to @npmcli/arborist, pacote, and the various libnpm* modules.
Be as fast as possible while behaving correctly. The key to fast software is to do as little as possible, including doing as little waiting as possible. From the refactor to use Minipass streams to refactoring out a decade’s worth of compatibility fixes for long-dead Node.js versions, npm v7 is leaner and faster because it’s lazier.

If we know the right thing to do, let’s not yell at you to do it. Let’s just do it for you, and do it all the way the first time. That’s what npm loves you means. It means taking care of you and your project like a good and faithful assistant, only troubling you to get involved when absolutely necessary.

Coming Attractions

In the coming npm v7 posts, we’ll cover:

A deep dive on Arborist, the tree management and analysis utility that does a lot of heavy lifting in npm v7.
Updates and impacts from some of the major refactoring that’s happened in the npm CLI dependency stack over the last year.
Automatically installing peerDependencies: why, how, and what you might want to be aware of.
Improvements to the performance, effectiveness, and UI of npm audit.
Updates to the package-lock.json format, added handling for yarn.lock files, and why we are going to keep using package-lock.json.
Support for acceptDependencies
Changes to how npm handles install scripts (RFC0021 RFC0022 and RFC0024)
Fixing the “noisy chokidar/fsevents” problem, and how this is related to npm fund.
Updates to permission handling while running as root.
Dropping the --depth config in npm update and npm outdated.
Changes to config options (especially, config options that determine what gets installed).
Improvements to the handling of "files" in package.json.
Workspaces
Overrides
Staged publishes
And, presumably, updates about the beta and eventual GA releases, because this is going to take a minute :)

RFC Process

The npm CLI team has been running an open RFC process for the last several months now, and the impact on our development process has been great.

Usually, writing the code is the easy part. The hard part is all the thinking and talking that goes into making sure we’re writing code for a feature that users will benefit from, and that we’ve explored the edge cases well enough to be confident we’re not overlooking something important.

If you’re interested in getting involved with npm’s design process, we want you to participate! Building something like this is a team effort, and we all benefit from getting a broad range of perspectives from our community.

Is there something that you really wish npm would do, or do differently, or stop doing? Head over to npm/rfcs and give us a proposal. Obviously the more engaged and thorough you can be, the more easy it’ll be for us to get it done, but every great idea has to start somewhere, so don’t feel like you have to have all the answers before you begin :)

Thanks!

If there’s something you’d like to see covered around npm v7, you can post an issue on the npm/npm-v7-blog repo.

Stay tuned for more from us, and I hope these posts prove to be fun and informative!

>> Arborist Deep Dive