If PNPM cannot correctly install a lockfile version, it should fail rather than malfunctioning

[octogonz]

In #1876 (comment) @zkochan said:

We can only promise full determinism in scope of one pnpm version + lockfile. So if you have a lockfile and you use the same version of pnpm, it should be deterministic.

Deterministic build outcomes are very important when shipping a product in a professional environment. The entire purpose of a lockfile is to ensure that installations are deterministic.

Expected behavior: PNPM should report an error if it cannot ensure a deterministic installation for a certain lockfile (e.g. because the lockfile was created using a different version of PNPM). For all practical purposes, the lockfile is incompatible and not supported by that version of PNPM.

An error will call attention to this incompatibility, so that the developer can mitigate the problem by either:

1. Regenerating the lockfile, if possible; or
2. Reverting the upgrade of the PNPM tool

Note that regenerating the lockfile is not feasible in some cases. For example, consider an old release branch that may only ever receive critical security patches. In this situation, regenerating the lockfile would require an expensive QA test pass to ensure that no regressions were introduced due to a package that got upgraded. In that case #2 is the only option.

Actual behavior: If I understand correctly, PNPM handles an incompatible lockfile by making a "best effort" to follow the installation plan, but does not produce an accurate or even deterministic result. In other words, it silently malfunctions, in a way that is very confusing and led to difficult investigations such as microsoft/rushstack#1142.

We have an open issue to allow specifying the wanted pnpm version (#1383)

For Rush repos, #1383 is not a good solution. The PNPM version is already constrained by the pnpmVersion setting in rush.json. Repo maintainers want to carefully manage which version of PNPM is used by different repos at their company. They don't want it to be magically inferred based on an obscure field in the generated lockfile.

[zkochan]

fixed by #1886

[zkochan]

🚢 3.5.3

[octogonz]

Wow, that was fast! Thanks @zkochan!