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

381–390 of 486 posts

Re: Yarn – A new package manager for JavaScript

#381

Post by davidascher »

evv wrote: post #249
jlongster wrote: post #191

Earlier quoted context omitted.

That big shift will have to happen first. I don't see them ever making their own registry unless 99.99% of people are using yarn and are having a lot of problems with the current npm registry. While I see a lot of people using yarn, I'm not sure about 99.99% and I think npm's registry itself is pretty good. So I don't think interests will ever align to create a new registry. Nobody wants to do that. That would have s…

Why would it be a bad thing to support additional repositories? Personally, I don't like how centralized the JS ecosystem is. For example, if I refer to 'left-pad', it would default to 'npmjs.org/left-pad'. If the author goes rougue, I think it would be great to enable people to publish and consume 'thirdparty.com/left-pad' Disclosure: I'm a FB employee with no knowledge of our plans in this regard

Somewhat funny to have an FB employee complaining about overly centralized systems.

Re: Yarn – A new package manager for JavaScript

#382

Post by rickhanlonii »

tigershark wrote: post #325
pcsanwald wrote: post #181

Earlier quoted context omitted.

I have no idea if you're familiar with the java ecosystem, but I am, so I'll use that as an example: Node libraries are typically several orders of magnitude smaller and more single purpose than java libraries. Java libraries like Guava and Spring are typically quite large. A practical example is from unit testing: In Java, you might use JUnit+Mockito for your test dependencies. In Node, to get similar functionality,…

Why is that? In the Java ecosystem there is Spock framework that gives you everything required for testing, you don't even need junit+mockito. In which scenario would be better to use 11 different libraries for doing the same thing as a well written framework?

The benefit of what's happening in JS is that a lot of libraries are reasonably compartmentalized for a specific purpose.

As an example: you _could_ have one SpockJS framework that gives you React + Redux + ReactRedux, but instead each of these libraries are separate so you can use them without each other. This allows you to, say, move from React to Angular without changing the state of your application.

With everything moving so quickly in JS, this separation turns out to be valuable enough to tolerate a lot of packages and dependencies. It also makes it easier for communities to exist for solutions to specific problems, which at least in theory results in better solutions.

It's not necessarily better, just a different approach.

Re: Yarn – A new package manager for JavaScript

#383

Post by Benjamin_Dobell »

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

Re: Yarn – A new package manager for JavaScript

#385

Post by brandonbloom »

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't begin to address the non-deterministic install behavior that crops up when you add new dependencies.

> why these couldn't be contributions to NPM seems like a serious case of NIH

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.

I'll wait a while for Yarn to bake, but personally, I hope NPM dies a swift and total death.

Re: Yarn – A new package manager for JavaScript

#386

Post by gjolund »

wycats wrote: post #16

I wrote a post explaining why I'm psyched to be working on it: TLDR: - open, community governance that will support long-term evolution - the technical details get a lot right out of the gate (decent performance, predictability, and security)

When do you expect ember to transition to yarn?

Are there any branches of ember-cli implementing yarn?

Re: Yarn – A new package manager for JavaScript

#387

Post by deckard1 »

_ea1k wrote: post #258
rubber_duck wrote: post #148

Earlier quoted context omitted.

The fun of kicking off a CI build after the weekend with no commits and see stuff randomly break because some dependency of a dependency got updated and broke things in a minor version is something I've only experienced in JS - beautiful.

In fairness to the language and tools, this seems to be more of a cultural problem than anything. You can do the same kind of version range tricks in typical Java builds, for example (Maven), but most people hardcode the values to keep builds as deterministic as possible. For some reason, the JS community seems to prefer just trusting that new versions won't break anything. Its either very brave of them really (or ma…

> the JS community seems to prefer just trusting that new versions won't break anything. Its either very brave of them really (or maybe just foolish).

Let's not pretend that we aren't all blindly tossing in random libs of dubious quality and origin we find on github into our package.json and hoping for the best anyway. My company talks a mean talk about "best practices", but, my god, the dependencies we use are a true horror show.

Re: Yarn – A new package manager for JavaScript

#389

Post by blubbi2 »

ag_dubs wrote: post #50
k__ wrote: post #20

Earlier quoted context omitted.

It's not the first one addressing these problems. Nix and ied (which borrowed from Nix) got these problems pretty much solved. I don't understand what spoke against these approaches? I mean okay, nix has its own language, which is probably a turnoff for JS devs, but ied?

ied didn't work on windows because of the linking strategy. many people who need to use npm use windows.

That's not 100 % accurate. Arguably symlinks are kinda weird under Windows, but that doesn't mean symlinking node_modules doesn't work (you just need admin privileges).

(Disclaimer: I'm the author of ied.)

Re: Yarn – A new package manager for JavaScript

#390

Post by gjolund »

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.

Post reply on HN