Fix --frozen-lockfile not preventing lockfile changes

[gpoole]

Summary

Fixes an issue where Yarn would rewrite yarn.lock instead of failing when --frozen-lockfile was used.

Fixes #3313.

Test plan

Added a test which checks the expected behaviour.

[bestander]

Unfortunately that is not the fix.
integrityError can just mean that node_modules was corrupted.

[bestander]

Thanks for the attempt, @gpoole.
The issue is deeper, since 0.23 Yarn started optimizing the lockfile during installs and this causes the changes.
We need to make sure lockfile does not change when install runs if it satisfies the package.json.
The issue is somewhere in the resolver.

[gpoole]

That makes sense @bestander, it did seem like that's what was happening for me. I am seeing a lockfile error (LOCKFILE_DONT_MATCH) in when I run it against real projects that have this problem, but looks like the test is failing here so that's obviously not it. Is the integrity checker not comparing the newly generated structure with the original one read from the file?

[bestander]

Integrity checker checks the integrity of previous installation in node_modules folder and compares it to current lockfile and package.json and CLI arguments. It is not directly related to the issue with lockfiles changing but there is a relation.

…

On 26 May 2017 at 01:52, Greg Poole ***@***.***> wrote: That makes sense @bestander <https://github.com/bestander>, it did seem like that's what was happening for me. I am seeing a lockfile error ( LOCKFILE_DONT_MATCH) in when I run it against real projects that have this problem, but looks like the test is failing here so that's obviously not it. Is the integrity checker not comparing the newly generated structure with the original one read from the file? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3497 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACBdWMHNDv5CGr7Bfi6znsErvPv2R4-1ks5r9iJQgaJpZM4Nl6b-> .