pnpm version 2 is out!
Last week v2.0 of pnpm was released. It’s been almost a year since version 1.0 came out and we were busy implementing new features (v1 had 43 minor versions). So let’s see what awesome new features were added to pnpm since v1.0 and what are the breaking changes of v2.
So what’s new in pnpm since v1.0?
The store server
We added the store server to pnpm in v1.30. The store server is an app that can run in a separate process and handle all the store manipulations, reducing the number of tasks that pnpm install should do. With a store server, installations are faster and concurrent installations may run using the same store.
To start a store server, open a new tab in your console and run: pnpm server start. Or run installation with the --use-store-server flag: pnpm install --use-store-server. Or set the use-store-server config to true: pnpm set use-store-server true.
In the future, we plan to make installation with a running store server the default behavior. An always running store server will allow us to make really interesting features, like supporting a decentralized registry or keeping the store always hot.
The recursive commands
Everyone seems to like multi-package repositories lately but managing a multi-package repo is hard. In v1.24 of pnpm, we implemented our first recursive commands: pnpm recursive install and pnpm recursive update.
`pnpm recursive link`The pnpm recursive commands are implementations of the traditional pnpm commands for multi-package repositories. So for instance, the recursive install command is installing dependencies of every project in every subdirectory of the current working directory. Installation is performed concurrently by a single run of pnpm, so it is a lot faster than separate executions of pnpm for each package in the repo.
For a performance comparison of pnpm recursive with npm, you can read: Trying pnpm on the JustAnswer multi-package repository
As of now, there are 4 recursive commands: install/update/link/unlink. But soon there will be more because we converted the pnpm repo into a monorepo and we are actively dogfooding these commands.
The ability to create flat node_modules
As you may know, one of the great features of pnpm is that it creates a non-flat node_modules (you can read more about why this is a great feature in this article). However, we discovered that many packages in the ecosystem are broken, they use dependencies that are not declared in their package.json. When we see such packages, we try to submit pull requests and fix them. It takes time though, to discipline the ecosystem, that is why
If your tooling has issues with pnpm, you can create a .npmrc file in the root of your project and set shamefully-flatten = true. But be aware that this is a hack and the right solution is to find the issue and fix it.
Headless installation
The most complex part of the installation is the resolution stage. After the resolution stage pnpm knows what should be installed where. But when a project already has a shrinkwrap.yaml, there is no need to repeat the resolution stage. That’s why we created a dedicated package (@pnpm/headless) that can install really fast but only using information from a shrinkwrap.yaml.
This is basically what the npm team did with the npm ci command but we did it with the regular install command. No actions are required to enjoy the speed improvement, headless installation will be used instead of regular installation when the shrinkwrap file is up-to-date with the package.json (for better results, you should always commit your shrinkwrap.yaml file).
Pro tip. You can use the --frozen-shrinkwrap flag to force a headless install. This flag is good for CI usage. But be aware, if you run pnpm install --frozen-shrinkwrap then an out-of-date lockfile will cause an installation failure.
And many more…
TBH, there were so many new features and improvements that I didn’t even mention them all, like side effects caching, better console reporting and new ways to import packages from the store. So just open our docs and read the descriptions of all the different commands… or just give pnpm a try on your project! (how to install pnpm)
Breaking changes
Node.js 4 is not supported anymore
End of life of Node.js 4 was on April 30th. This was the main reason we needed to make a major version bump. A lot of our dependencies started to drop Node.js 4 support months before its end of life, so we had to make the same as soon as possible.
Non-deprecated versions are preferred during resolution
This is a breaking change that npm v6 did as well. If a semver range can be resolved by a deprecated and non-deprecated version of a package, then the non-deprecated version is used even if it is a smaller version than the deprecated one.
Example. If a package depends on rimraf@2 and rimraf@2.0.1 is deprecated then rimraf@2.0.0 is going to be installed (if v2.0.0 is not deprecated).
`pnpm unlink` is an alias of `pnpm dislink`
In version 1, pnpm unlink was an alias of the pnpm uninstall command. However, we wanted a command that would remove a linked package created by pnpm link and install it from the registry, so we create pnpm dislink. In order to avoid confusion, now we’ve made pnpm unlink an alias of pnpm dislink.
Try it
Just install pnpm via npm: npm install -g pnpm. And use it instead of npm whenever you want to install something: pnpm i foo.
Also, you can read more info at the pnpm GitHub repo. You can follow pnpm on Twitter or ask for help at the pnpm Gitter Chat Room.
If you were afraid to use pnpm in the past because it was not used by big teams/projects then it is not the case anymore. Check out who’s using pnpm.
