Include yarn and node versions in yarn.lock

[christopherstott]

Sometimes it is helpful for automated tooling to know the version of
yarn and nodejs that was used in the environment that last modified the
yarn.lock file.

For example, this allows CI platforms to automatically ensure the
same versions of yarn and node are used in CI as locally.

This functionality can be disabled by adding to .yarnrc
yarn-disable-lockfile-versions true

Summary

Test plan

[christopherstott]

Looks like AppVeyor failed in an potentially unrelated way. Could this be a flakey test? Otherwise I can track down a windows machine to try this out on.

[christopherstott]

Also - I'd love any suggestions for how to add tests for the .yarnrc behaviour

[SimenB]

Can this please be disabled by default? I can see for some projects it might be sorta useful, but the churn in PRs to make everybody disable it (or forced to add yet another dotfile to all my repos, this time to disable some weird behaviour I don't want) makes me a sad panda.

[SimenB]

Does this also in practice makes using --pure-lockfile and testing on multiple versions of node impossible, or does pure lockfile compare just the dependency part?

[bestander]

Thanks for raising this @SimenB, I had similar reservations.

Anyone has an idea how to make this a better experience?
I think this will totally be a problem for merging PRs for popular OSS projects.

Maybe don't downgrade version in yarn.lock?
I.e. if this lockfile worked on 0.25.0 then if someone sends an updated generated in 0.24.0 then there is no need to update the version?

[SimenB]

I'm more concerned about the node version. I like to use just the LTS version of node, but lots of people use node 7 because of async functions (and just running brew install node or whatever) which will be quite noisy. Also, lots of different minors and patch versions out there. The same thing is probably an issue for yarn versions.

What about never changing any of them without an explicit flag for it? So add it first time, then don't touch it without the user being explicit

[raido]

This is not cool. In my team we have PR based workflow and this just is a lot of churn. This should be opt-in only instead of opt-out. I would like to revert the configuration name and logic that handles it to be opt-in.

Basically all the larger projects that upgrade to Yarn 0.25 will have this churn.

Workaround is to disable it but if you have many projects that's another churn, because it seems obvious that default patterns should not require configuration.

[bestander]

Thanks for submitting this feedback. We are open to reconsider. Any idea of some compromise? The idea behind this change is reasonable.

…

On Fri, 26 May 2017 at 18:56, Raido Kuli ***@***.***> wrote: This is not cool. In my team we have PR based workflow and this just is a lot of churn. This should be *opt-in only* instead of opt-out. I would like to revert the configuration name and logic that handles it to be opt-in. Basically all the larger projects that upgrade to Yarn 0.25 will have this churn. — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#3265 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACBdWJhEBNSvQQJuaYVpJhPvfmNqHQ4-ks5r9xI8gaJpZM4NJtnu> .

[raido]

I am not sure what type of compromise there could be. Having dynamic data as Yarn and Node versions in lockfile which will differ on each developer machine is not possible. It just causes merge conflicts and noise in commits as unrelated changes.

[bestander]

@christopherstott and everyone, I've merged the reverse of logic where this feature is now opt-in.

I understand that this feature would help CI systems to match Yarn version to lockfile but side effects, i.e. merge conflicts make developer experience with Yarn noticeably worse.

Open to find some compromise that would work for both.