Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

yarn.lock's differences from npm-shrinkwrap.json aren't clear #509

strugee opened this issue May 22, 2017 · 2 comments


Copy link

commented May 22, 2017 states that yarn.lock "not lossy and it creates reproducible results." It's not clear to me exactly what this means on a technical level. What is meant by "reproducible"? And what is lost with shrinkwrap files?


This comment has been minimized.

Copy link

commented Oct 2, 2017

I'm wondering if this answer is incorrect and potentially harmful. I assume many people have switched to Yarn for it's lockfiles, but it sounds like that's no longer necessary if we use npm lock files.

@Haroenv Haroenv added the needs docs label Oct 2, 2017


This comment has been minimized.

Copy link

commented Jan 20, 2018

This thread and the SO link above by @johntron both dead-end when ppl ask how npm shrinkwrap is less reliable than yarn. I prefer to use 'native' tools whenever possible, so if this is a case of a community solution that was better but has now pushed npm to improve shrinkwrapping to the point that the later is now sufficient, i'd love to know. from my own experience, I have yet to encounter a case where shinkwrapping didn't sufficiently lock down dependencies but with so much attention paid to Yarn lately, I assumed that there are some cases where shinkwrapping could fail. Yarn continues to have advantages in performance, but honestly, i mostly just care that my deps are correct... not as concerned about shaving seconds off deployment times.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
4 participants
You can’t perform that action at this time.