Hacker News Reader

Comment by brandonbloom | Hacker News Reader

> > ways that could not be fixed without braking changes

> Examples, please.

The first and foremost: Version pinning should be the only way it works. Obviously _requiring_ shrink-wrap would be a breaking change.

> > Shrinkwrap is still a usability nightmare

> Again, examples, please.

Having to explicitly call shrink-wrap is just silly. Devs on every time I've used shrink-wrap with frequently forget to do it and it causes all sorts of "works for me" problems later. My team has also experienced all kinds of brokenness related to private NPM repositories and shrink-wrap non-determinism.

> Did the Yarn developers make any attempt to contribute to NPM at all

I don't care about this at all. Just because you got there first doesn't mean you should have some kind of special claim to solving the problem.

View on HN

> The first and foremost: Version pinning should be the only way it works. Obviously _requiring_ shrink-wrap would be a breaking change.

> Having to explicitly call shrink-wrap is just silly. Devs on every time I've used shrink-wrap with frequently forget to do it and it causes all sorts of "works for me" problems later.

Really? An entirely new tool because you didn't like typing "npm shrinkwrap" once, just once per project? I... I don't even know how to respond to that...

> My team has also experienced all kinds of brokenness related to private NPM repositories and shrink-wrap non-determinism.

I'm unclear on what you mean? Do you mean in the past? Cause if so, sure... but hasn't this already been addressed?

> I don't care about this at all. Just because you got there first doesn't mean you should have some kind of special claim to solving the problem.

This is an all too common attitude in the JavaScript community. Hence the plethora of poorly maintained, duplicated NPM packages.

I'd rather humanity not waste the man-hours duplicating effort. Do something productive with the time you saved.

As mentioned, if for some reason the NPM guys weren't co-operative, then I understand, however that doesn't at all seem to be the case.

> An entirely new tool because you didn't like typing "npm shrinkwrap" once, just once per project?

I don't know what kind of projects you work on, but new dependencies get added with some regularity on any large node project, requiring a shrink-wrap every time.

If you've never experienced the forgetting-to-shrinkwrap problem and its interplay with team dynamics, then I envy you. But I also must give up trying to explain to you, since this drives to the heart of the problem and I must conclude that we simply do not have enough common experiences for you to ever understand. The developers of Yarn et al clearly have lived this nightmare.

> Do you mean in the past

Where the past was < 4 months ago. If it has been fixed since that, I don't care: too little, too late.

> This is an all too common attitude in the JavaScript community.

An equally big problem in the JavaScript community is that core pieces of infrastructure have been "claimed" by people who have absolutely no idea what they are doing, but are happy to community-coordinate their way to some kind of idealistic open source victory.

> weren't co-operative

Again, I don't care if they were willing to co-operate. I have zero confidence in them.

> I'd rather humanity not waste the man-hours duplicating effort.

Give up on this dream. People are going to re-invent everything from now until the end-of-time, and rightly so.

Clearly you haven't been using the default settings in the latest version of NPM ;)

I can only hope the Yarn developers knew about the changes, and had a real justification for their work.

Again, I'm not saying the Yarn developers didn't have justification, I just haven't seen any yet. Love to be shown otherwise.

Reply on news.ycombinator.com