4 ms·

> NIH Syndrome No. NPM is awful in ways that could not be fixed without braking changes. They have a need, so they satisfied it. A need which, by the way, ever

• Benjamin_Dobell 10y ago
  > No. NPM is awful in ways that could not be fixed without braking changes. They have a need, so they satisfied it. A need which, by the way, every one of the dozen-or-so Node-using projects I've worked on have shared. Examples, please. > This isn't even remotely true. Shrinkwrap is still a usability nightmare and doesn't begin to address the non-deterministic install behavior that crops up when you add new dependencies. Again, examples, please. > There's no way that they could have got these changes in to NPM in anywhere near the time it will take for Yarn to become popular; if at all! Politics (or the avoidance thereof) are practically _the_ perfectly valid reason to justify NIH. Did the Yarn developers make any attempt to contribute to NPM at all? If they did and were turned back, then sure, I understand. However, everything I've read about Yarn thus-far is just vague finger-pointing at NPM. I'm by no means suggesting NPM is perfect, for one I find it incredibly slow. However, surely that can be optimised. However, regarding dependency version locking, which is the problem Yarn is trumpeting, what are the actual issues with Shrinkwrap? I'd like something specific. Since Shrinkwrap was updated to keep a flat sorted structure (a while ago) I've been using it no fuss at all. What are the specific issues people are running into now? I've seen comparisons with Bundler, and how Yarn will be more like Bundler's Gemfile.lock files. However, the thing is the current version of Shrinkwrap works almost identically to Bundler's lockfile e.g. When I update a dependency the shrinkwrap file automatically updates (at least that's the default behaviour).
  • brandonbloom 10y ago
    > > 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.
    • Benjamin_Dobell 10y ago
      > 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.
      • brandonbloom 10y ago
        > 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.