Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Yarn – A new package manager for JavaScript

code.facebook.com

Post reply on HN
Print view View original

391–400 of 486 posts

Re: Yarn – A new package manager for JavaScript

#391

Post by toefraz »

jay_kyburz wrote: post #344
mschuster91 wrote: post #158

Earlier quoted context omitted.

> That, to me, is what is wrong with npm. The problem stems from node.js not coming with "batteries included" so there is a proliferation of tiny libraries that do the most trivial things. This is in no way a fault of node.js but of the whole JS standard. People these days use npm modules to run in a browser and ship stuff bundled together with webpack (or other bundlers), so even if nodejs had a proper stdlib, you'd…

Yeah, but we could have a big, standard library polyfill, and it would quickly find its way into everybody cache, just like jQuery.

We do. It's called Lodash.

Re: Yarn – A new package manager for JavaScript

#392

Post by Benjamin_Dobell »

brandonbloom wrote: post #385
Benjamin_Dobell wrote: post #383

Hmm, NIH Syndrome? The justification for Yarn starts by ignoring the existence NPM Shrinkwrap. It then proceeds to mention Shrinkwrap and refer to its supposed short-comings. Whilst there absolutely were issues with Shrinkwrap in the past, they've already been addressed by NPM. NPM is slow, perhaps Yarn is faster and has some extra features. But why these couldn't be contributions to NPM seems like a serious case of…

> 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, every one of the dozen-or-so Node-using projects I've worked on have shared. > Whilst there absolutely were issues with Shrinkwrap in the past, they've already been addressed by NPM. This isn't even remotely true. Shrinkwrap is still a usability nightmare and doesn…

> 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).

Re: Yarn – A new package manager for JavaScript

#393

Post by Benjamin_Dobell »

gjolund wrote: post #390
Benjamin_Dobell wrote: post #383

Hmm, NIH Syndrome? The justification for Yarn starts by ignoring the existence NPM Shrinkwrap. It then proceeds to mention Shrinkwrap and refer to its supposed short-comings. Whilst there absolutely were issues with Shrinkwrap in the past, they've already been addressed by NPM. NPM is slow, perhaps Yarn is faster and has some extra features. But why these couldn't be contributions to NPM seems like a serious case of…

The short comings of npm are very real. I would go so far as to say that npm is the single biggest problem with the node community at the moment.

> The short comings of npm are very real.

NPM seems to be continually addressing their short-comings, as you would expect from any software project. It's come a long way.

Specifically, what are the existing short-comings of NPM, and why couldn't they have been addressed via pull requests?

Re: Yarn – A new package manager for JavaScript

#394

Post by deckard1 »

kzahel wrote: post #40

"The React Native package.json currently lists just 68 dependencies, but after running npm install the node_modules directory contains 121,358 files." That, to me, is what is wrong with npm. The problem stems from node.js not coming with "batteries included" so there is a proliferation of tiny libraries that do the most trivial things.

To make matters worse, each package gets its own node_modules directory. Do a grep for 'async' in your node_modules. Mine contains ~20 instances of it. Some of those, probably, are the exact same version.

Going further down shit creek, each project I work on has its own node_modules. Which duplicates all of this crap, ad nauseam.

Do I really need React and Babel and jQuery and Webpack installed for every goddamn repo? You're not a package manager if you're not managing packages!! You're a glorified wget.

Re: Yarn – A new package manager for JavaScript

#395

Post by brandonbloom »

Benjamin_Dobell wrote: post #392
brandonbloom wrote: post #385

Earlier quoted context omitted.

> 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, every one of the dozen-or-so Node-using projects I've worked on have shared. > Whilst there absolutely were issues with Shrinkwrap in the past, they've already been addressed by NPM. This isn't even remotely true. Shrinkwrap is still a usability nightmare and doesn…

> 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 dependenc…

> > 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.

Re: Yarn – A new package manager for JavaScript

#396

Post by Benjamin_Dobell »

brandonbloom wrote: post #395
Benjamin_Dobell wrote: post #392

Earlier quoted context omitted.

> 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 dependenc…

> > 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 ca…

> 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.

Re: Yarn – A new package manager for JavaScript

#397

Post by twhb »

lucian1900 wrote: post #48
tomdale wrote: post #22

This is a huge leap forward for the JavaScript community—probably more than many people will realize right away. I loved Bundler's deterministic builds but chafed against the Ruby limitation of only having a single version of a dependency at once. npm solved this problem elegantly, but still struggles with non-determinism. I had resigned myself to thinking that maybe these were just fundamental tradeoffs in package m…

Multiple versions may sound like it's useful, but it's almost always a bad idea. Cargo doesn't allow it either. The problem isn't really fundamental. Bundler makes almost all the right choices already. Its major disadvantage is that it only works for Ruby.

You've got to take the ecosystem into account. There are a lot of very depended-upon modules that are 1 KB of code and bump their major version as a morning habit. Forcing people to reconcile all 8 ways they indirectly depend on the module would drive them nuts, but including 4 copies of the module doesn't hurt much.

Re: Yarn – A new package manager for JavaScript

#398

Post by shados »

bandrami wrote: post #131

This may come off as a troll, but it's an honest question. I'm not a javascript guy. It's not a language I deal with at all. Why on God's green earth does it need as much tooling as it seems to have? Are people really making projects with dozens (hundreds? more?) of dependent libraries? Are there aspects of the language or runtime that reward multiple layers of configuration management? In short, what the hell is up…

Handling dependencies is hard. Handling dependencies for a platform you don't control is harder. Handling dependencies for a platform you don't control, where every single kilobytes count, is insane.

Add those together, and you get the need for real complex tooling.

With that said, tooling is nowhere as complex as it is for languages like C++ or Java. People are just used to it on those platforms, and the tooling is more mature/understood because it already went through the countless iterations, 15-20 years ago or more.

Re: Yarn – A new package manager for JavaScript

#399

Post by shados »

tigershark wrote: post #340
l1ambda wrote: post #330

Earlier quoted context omitted.

In this case, I would argue it is not better. Many JS devs have moved onto simpler, greener pastures. https://github.com/substack/tape is what I prefer. Small little library. Its API has everything I need and nothing I don't. Those other test libraries listed are pretty much overkill. Similar with http://mithril.js.org/ over React, Angular and Ember. A single drop-in library with 13 functions in it's API. The library…

From the readme I can't really see how to write extensive unit tests with that thing.. If I need to test something I want only one tool that works perfectly and does all the Stubbing, Mocking, verification, data driven test and behaviour driven test. I still haven't found in any language/ecosystem anything comparable to Spock in completeness, readability and ease of use. Honestly I can't really see how to do BDD with…

its not that hard. That being said, the current all in one turnkey testing framework for javascript is Jest, and that will pretty much do it all in one tool.

Re: Yarn – A new package manager for JavaScript

#400

Post by shados »

jrs235 wrote: post #78

Here is npm's response: http://blog.npmjs.org/post/151660845210/hello-yarn

That's pretty well written, though you can see slight hints of bitterness in the tone (though its subtle). Or maybe I'm a little biased, because I've seen some of the non-public reactions, and they were more than a little bitter...
Post reply on HN