Beyond npm@6: The future of the npm cli

This week npm@6 is going to be promoted to latest and so now is an excellent time to look forward. If you dig into it you’ll find that it doesn’t have much in the way of breaking changes. Later this year we’ll be releasing npm@7. First there are a few new features, these will initially ship as npm@6 minor releases:

• We will be introducing package aliases as described in #5499 for use with assets, to support conflict resolution.
• As an optimization, npm install will be updated to be an alias for npm ci when they would produce the same result, that is, that your package-lock is compatible with your package.json and you’re starting with no node_modules.
• Combine bundling and the v8 compile cache to reduce latency when running the npm cli.

The breaking changes in npm@7 should not be disruptive but are important:

• npm login and npm adduser will finally be split apart. Up till now they’ve been the same command, which is why npm login prompted for an email address.
• npm init will be getting an overhaul, both with allowing easy third-party init templates and with some new one’s from us, to help you configure your CI and git environments.
• Changes to how npm runs under sudo and how it handles permissions as root to make it less surprising. Look for a new RFC soon!
• The npm link rewrite as described in its associated RFC.
• Output from preinstall, install and postinstall scripts when running for a dependency will have their output captured and it will only be displayed if there’s an error. They will run with stdin closed. This means that install lifecycle scripts in projects installed as dependencies will not be able to be interactive. For all other lifecycle scripts, output will be captured and routed to the log and also outputted to stdout.
• Allow package aliases to be used for any dependency type.

After npm@7, in the late summer and fall of 2018, our plans are somewhat more tentative, but we have a few things we’d like to get out to you all:

• npx has been a huge success, but it can mean that you’re running untrusted code from the registry. We have a number of thoughts about how to improve its security, from looking for known vulnerabilities to catching typo-squatting.
• Integrating the functionality of shrinkpack into npm directly. This would allow for entirely offline deploys even without a cache. It will also let you deploy with git dependencies without having git installed on your production machines.
• We have two installation engines with different tradeoffs in npm install and npm ci. If one fails due to certain classes of error then we should try the other.
• Workspaces, as seen in Yarn, for management of certain kinds of monorepos.
• An option to run npm in low memory environments, this would disable in-memory caching of data at the cost of speed.
• Begin exploring updating dependencies in your package.json from your source code… (npm init auto?)

As we work our way through the year we will likely be rewriting a number of other components in npm, either as we need them or as the community provides them.

• Stand alone libraries to generate a “logical tree”, that is, one that represents the relationships between modules but not their locations on disk.
• New, faster, on-disk tree readers that produce trees like the above from an existing node_modules.
• Two-pass installer where resolution of the logical tree is distinct from computing the physical tree. With this we may be able to, at long last, end the pain around peerDependencies.
• Many years ago, npm’s configuration was extracted as a stand alone module, but it was so tightly coupled with the rest of npm that we ultimately brought it back in. We’ve been slowly working on extracting it again, carefully decoupling it from the rest of the code base.
• npm outdated could use with a rewrite as it has the hackiest of shims to make it work at all. It was originally designed to run off of read-installed output which is what npm@1 and npm@2 used to read node_modules. A version that was designed to run off of modern npm data structures would be much easier to understand.
• Similarly, npm ls would benefit a great deal from being updated to work off of modern data structures.
• We’ve nearly eliminated npm-registry-client (and in turn request) from the npm code base. With the advent of npm-registry-fetch (which is based off make-fetch-happen and in turn node-fetch) we can finally complete this.
• Once we have support for Workspaces, npm itself could benefit from bringing a bunch of its closely related modules together into a monorepo.

For more…

Watch this blog, follow @npmjs on Twitter and subscribe to our newsletter!

If you want to follow development as it happens the best place to go is #js-npm on the package.commmunity discord.