Lockfile is not respected when a newer version of the dependency exists in the tree about pnpm

[KSXGitHub]

pnpm decides to change the lockfile because it detects that the specification from your package.json does not match the specification that the lockfile remembered.

To workaround this, you can either:

1. Manually edit importers or dependencies and devDependencies in the lockfile.
2. Run pnpm add resolve@^1.20.0 (with a caret).

Regarding the desired behavior, I am not sure if this is a bug. If I relax the version range, I would expect pnpm to update my dependencies to be latest of that range.

[neongreen]

I’ll check the workarounds later, thanks!

re/ this:

I would expect pnpm to update my dependencies to be latest of that range.

Perhaps we use lockfiles for different purposes? Mine is both a) “no surprises during deploy” and b) “no version bumps ever unless I explicitly ask for them”. I suppose you might just have (a) in mind.

[KSXGitHub]

Perhaps we use lockfiles for different purposes? Mine is both a) “no surprises during deploy” and b) “no version bumps ever unless I explicitly ask for them”.

I only use lockfile for purpose a as well as reproducibility. If I don't ever change the specification, the dependencies will remain the same. For purpose b, I think relaxing the specification is pretty much "asking for them".

[KSXGitHub]

Actually, this is a bug. It doesn't change with only resolve. What changes is the transitive dependency of eslint-import-resolver-node.

[KSXGitHub]

I double checked again and noticed that my pnpm why gives a different result than yours:

dependencies:
eslint-import-resolver-node 0.3.9
└── resolve 1.22.8
resolve 1.22.8

(both resolve are 1.22.8)

Can you try again with pnpm v1.14.0?

[neongreen]

Hm, I get 1.22.8 for both resolves even with pnpm 8.13.1 now. (And with pnpm 8.14 as well.) Not sure what happened back then — maybe I copied the wrong output somehow? (I remember trying to choose the second dependency to reproduce the issue.)

[KSXGitHub]

If you can reproduce the case where resolve versions are inconsistent, then we'd have a bug.

Anyway, do you have any .npmrc or configuration then?

[neongreen]

Even without inconsistent resolve versions --

• If we just have resolve: 1.20.0, then after updating package.json to say resolve: ^1.20.0, pnpm i doesn't do anything.
• On the other hand, if we have both resolve and eslint-import-resolver-node, then after updating package.json to say resolve: ^1.20.0, pnpm i upgrades resolve.

If this is the intended behavior, then I don't understand the semantics of pnpm i with prefer-frozen-lockfile (which is supposed to be on by default).

Anyway, do you have any .npmrc or configuration then?

No configuration.

[KSXGitHub]

@neongreen Good point, pnpm should either change in both cases or not change in both cases.

@zkochan Which one should be the correct behavior?

[zkochan]

I don't have objections to change pnpm's behaviour in this case. If the existing resolved version satisfies the new range, we can update the range in the lockfile and consider it up-to-date.

[KSXGitHub]

@neongreen I did a bit more digging and found that pnpm only upgrades resolve because eslint-import-resolver-node requires a newer version of resolve (^1.22.4 is what [email protected] requires), and pnpm seeks to minimize duplication and bundle size. If we remove eslint-import-resolver-node, pnpm would not upgrade resolve. I think this behavior is what most people desire, and I personally like it too. If you don't want pnpm to optimize the dependency tree, you should keep it explicitly pinned. Do you agree?