You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
https://yarnpkg.com/lang/en/docs/yarn-lock/ 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?
The text was updated successfully, but these errors were encountered:
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.
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.
https://yarnpkg.com/lang/en/docs/yarn-lock/ 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?
The text was updated successfully, but these errors were encountered: