Upgrading to pnpm 11

[00:00 - 00:09] When I started recording this video course, the current version of pnpm was version 9. Since then, versions 10 and 11 have come out.

[00:10 - 00:32] Version 10 is a fully backwards compatible version, with the only change being that you can disable lifecycle scripts, which means Post-install scripts by selecting which dependencies can be built after install. Upgrading to this version is trivial. We don't need to change almost anything in our setup.

[00:33 - 00:55] I can do "pnpm view pnpm@10" so we can grab what the current latest version 10.x.x is, and at the time of recording, it's 10.34.3. I'm just going to copy this, open my package.json, go to my "packageManager" and change the version to 10.34.3.

[00:56 - 01:35] Then when I exit and do "pnpm -v" corepack is going to automatically recognize that they changed the version in "packageManager" and asked me to install that version, which I am going to say yes to. Okay, so "pnpm -v" is version 10, and then if I remove all node_modules folders in my repository with "git clean -Xfd; git clean -fd" This means remove all files in the repository that are either get ignored or not get ignored, but not added to the register.

[01:36 - 01:49] It's an easy way to delete all node_modules. After that I can do "pnpm install" and if I run my dev scripts, everything is going to work fine.

[01:50 - 02:04] Yeah, the Vite app works, the Next.js app works, everything just continues working. We don't need to do any actual changes to our repository for things to continue working.

[02:05 - 02:25] The only possible change that you might need to do is if you need to specify builtDependencies. However, pnpm version 11 is an actual major change that has breaking changes. It makes the minimal version of Node.js 22, which happily, we already do in our course.

[02:26 - 02:35] It changes us "onlyBuiltDependencies" which were added in version 10 into "allowBuilds". It's a simpler config.

[02:36 - 02:48] It does better global isolation when you add packages to a global store and it has more commands, but none of those are something that affects us. Those are about publishing flow.

[02:49 - 02:59] The major change that does affect us is this line over here. So we used to have our configuration for pnpm in our .npmrc file.

[03:00 - 03:12] But now all settings must live in pnpm-workspace.yaml instead of .npmrc. The easiest way to do that is to use the provided codemod for pnpm.

[03:13 - 03:27] We can use "pnpx", which is the counterpart to "npx", to run the codemod. And that's what I'm going to do. Let me clear my shell and do "pnpx codemod run pnpm-v10-to-v11".

[03:28 - 03:50] Now we can look at our diff. So what the codemod did is it grabbed our .npmrc configs for "auto-install-peers=false", and for "public-hoist-pattern [] =*eslint*" and removed those from .npmrc.

[03:51 - 04:00] It changed our "packageManager" setup to version 11. It was version 10 in the previous short update.

[04:01 - 04:33] It removed the package.json pnpm config key, which specified that we can build all dependencies and allowed deprecated version ESLint 8 and it moved this config into pnpm-workspace.yaml. So now a "allowDeprecatedVersions" ESLint: 8 is here. "autoInstallPeers: false" is here, and publicHoistPattern eslint is also moved here. The part that didn't get moved is anything about what's allowed to build on pnpm.

[04:34 - 04:48] So what post install scripts are allowed to run. If I do "pnpm -v" Corepack is going to again ask me to install the newer version because we didn't have pnpm version 11 installed for it yet.

[04:49 - 05:03] So let me do that first. I'm again going to delete all my node_modules just because when you change pnpm versions, that's a good practice, like getting rid of old node_modules because you don't want something to mess up when you're switching between pnpm versions.

[05:04 - 05:19] So I'm just going to do "git clean -Xfd; git clean -fd", and then pnpm install. Now we get a new error: "Ignored build scripts for @swc/core, esbuild and Lefthook".

[05:20 - 05:57] In pnpm 11, you must specify which packages can run build scripts with the idea that this protects you against supply chain attacks that leverage build scripts in order to execute code on your machine, and usually steal authentication tokens. So let me do "pnpm approve-builds", and I get asked which one I want to approve, and I'm just going to approve all of them because I know ahead of time that these are packages that I expect to build and that I know will be behaving correctly.

[05:58 - 06:18] Approve the build. And finally, if we look at our diff, we have a new section added in our pnpm-workspace.yaml that adds the "allowBuilds" key. And this completes the migration from pnpm 9 or 10 to pnpm 11.