Next Generation Package Management

What if installs were so fast they could happen in the background, just by using Node? What if every file in your dependencies could be guaranteed to be bit-by-bit identical to what’s on the registry? What if working on a new project was as simple as clone and run? What if your build tools got out of your way?

Introducing tink, a proof of concept implementation of an install-less installer.

tink acts as a replacement for Node.js itself, working from your existing package-lock.json. Try it out on a project without a node_modules and you’ll find that you can still require any of your dependencies even though you never ran an install. The first run will take a few seconds while it downloads and extracts the package tarballs, but subsequent runs are nearly instantaneous even though it’s still verifying that everything in your package-lock.json is on your system.

The first thing you’ll notice is that none of those modules are put into your node_modules folder — in fact, the only thing you’ll find there is a .package-map.json file. This contains hashes of all of the files in every package you have installed. These are verified before they’re loaded, so you can have confidence that you’re getting what you asked for (if a verification fails then the file is fetched from its original source, all transparently).

We’re not throwing the baby out with the bathwater though. You can still install things in your node_modules folder and those versions will be used in preference to the cached version. This opens a path to live-editing of dependencies (sometimes a necessary debugging technique) and support for things like postinstall scripts that mutate the package distribution.

tink is an opportunity to change how we relate to our Node.js projects and the npm Registry. Should using require or import on a module not in your package.json just add it to your package.json? Should extremely popular features like babel-compatible esm, typescript, or jsx be available by default? These are the questions we’ve been asking ourselves and we’d love to hear what you would want from a next generation experience. Come by npm.community and let us know!