Tuesday, 24 April, 2018 UTC
Summary
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 installwill be updated to be an alias fornpm ciwhen they would produce the same result, that is, that your package-lock is compatible with your package.json and you’re starting with nonode_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 loginandnpm adduserwill finally be split apart. Up till now they’ve been the same command, which is whynpm loginprompted for an email address.npm initwill 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
sudoand how it handles permissions as root to make it less surprising. Look for a new RFC soon! - The
npm linkrewrite as described in its associated RFC. - Output from
preinstall,installandpostinstallscripts when running for a dependency will have their output captured and it will only be displayed if there’s an error. They will run withstdinclosed. 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 tostdout. - 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:npxhas 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
shrinkpackinto 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 installandnpm 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 outdatedcould use with a rewrite as it has the hackiest of shims to make it work at all. It was originally designed to run off ofread-installedoutput which is whatnpm@1andnpm@2used 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 lswould benefit a great deal from being updated to work off of modern data structures. - We’ve nearly eliminated
npm-registry-client(and in turnrequest) from thenpmcode base. With the advent ofnpm-registry-fetch(which is based offmake-fetch-happenand in turnnode-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.