How to update the pnpm-lock.yaml without run pnpm update

[g-chao]

Hi everyone,
I have a problem when upgrading pnpm version for a Monorepo project, and want to see if the community has a better idea.

Here is the background, our Monorepo (based on Rush) is huge and has ~1000 projects. And, due to historical reasons, there is no common pnpm-lock.yaml for them, which means there are ~1000 pnpm-lock.yaml inside our Monorepo. We used pnpm 6.x now, and want to upgrade to pnpm 8.x.

It's very time consuming if we regenerate pnpm-lock.yaml using pnpm update for all projects. So I wrote a custom script to convert the lockfile version from v5 to v6

Here is link to the script

In the script:

1. I called readWantedLockfile, writeWantedLockfile, convertToInlineSpecifiersFormat functions from @pnpm/lockfile-file to help me convert lockfile version from v5 to v6.
2. However, after these functions, the converted pnpm-lock.yaml version is 5-inlineSpecifiers, also, the version format is still old ones, which means, if you run pnpm install for these pnpm-lock.yaml, it will complain about format error.
3. So, I add some custom logic to change the pnpm-lock.yaml, like change 5-inlineSpecifiers to 6.0, change version format (eg, 3.0.9_react-dom@17.0.2+react@17.0.2 => 3.0.9(react-dom@17.0.2)(react@17.0.2)), and other fixes to make sure pnpm install does not complain the format error.
4. It looks good after I done these fixes, and pnpm install can install the dependencies

Ok, that's all I did to solve the problem. Here, want to see if you guys have a better idea here.

1. Do we already have this kind of tool which convert the pnpm-lock.yaml between different versions? I am not supper confident on the script I wrote, cause they are many edge cases. So if there are exiting tools, I am very happy to try it.
2. Can pnpm provide a option let you dry-run a pnpm update command? Which is pnpm update --dry-run will only regenerate the pnpm-lock.yaml for you, but don't do the installation, post-install scripting, etc. So It will save huge amount of time when working a pnpm upgrade in a Monorepo situation.

[octogonz]

@zkochan is there no official solution for migrating to a newer lockfile version?

(In our use case, it is very important that adopting a new release of PNPM does not force lockfile dependencies to get upgraded, since that would be potentially disruptive for app teams and validation can be time consuming. In other words, we'd like for lockfile upgrades and dependency upgrades to be separate steps that can be validated in isolation.)

[zkochan]

If you run pnpm install, it will change the lockfile format to the new one. Dependencies will not be updated.

[HexiangLiu-Galxe]

@zkochan It does update dependencies when we upgrade pnpm 8.9.0 to pnpm 10.3.0

[zkochan]

Update to v9 then to v10.

[alanbaldwin]

I’m currently working in a situation where we’re maintaining a very old application, and running into the same problem. Company policy won’t let me install v9 on my machine, and it came with v10 on it.

[zkochan]

The lockfile format is the same in pnpm v6 and v7. pnpm v8 automatically converts the older lockfile format to the newer one without updating dependencies. You should be able just to run pnpm install and commit the new lockfile.

[g-chao]

Thanks @zkochan for detailed reply.
I did some testing in our Monorepo, yeah, pnpm install does automatically convert the older lockfile format to the newer one without updating dependencies.
However, it also touches the package.json, one example, it changes workspace: protocol to link: protocol. We just want to convert the lockfile format, all others shall remain same.

Also, in our case, since we don't need the installation and scripts happening during pnpm install, so I passed --lockfile-only. But, it still download packages from registry, still costs us a lot of time.

So, wondering if you can point to me which function or lib used to convert older lockfile format to the newer one? So, I can just write a script directly call these functions to do the conversion.