But a lockfile is not like "any generated file", because for typical generated artifacts they should always be generated the same, for the same commit.
This is not true for a lockfile, where the whole point is to capture the specific versions at the point in time that the generation is done.
The benefit of the contributor committing the lockfile is that it encodes the exact combo of dependencies that worked at the time the related code changes were made (in the same PR).
This means other project maintainers aren't left scratching their heads trying to figure out why a PR worked on your machine but fails in CI.
Code smells if a change works with one lockfile but not another generated around the same time. The utility of a lockfile increases with the age of the file.
We expect lockfiles to change when we update it add dependencies. If a pull request cannot build with a lockfile generated when it is merged then that change should not be merged.
> Code smells if a change works with one lockfile but not another generated around the same time.
This isn't true at all. You can't predict when a new, potentially breaking, version of a dependency might get published. It could happen a second after you generate your lockfile, or create your PR.
At time of PR creation we could have versions 1, 2, 3 and 4 of our transitive dependencies.
At time of merge we could have versions 1.1, 2.2, 3.3 and 4.x available.
Dependencies are outside of your control, so always "smell", that's why it's crazy to do anything other than pin the heck out of them.
This. Just reset package.json and yarn.lock to master state and then re-apply the changes yourself (via yarn). Should be possible most of the time as package.json changes are usually small.
