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

281–290 of 486 posts

Re: Yarn – A new package manager for JavaScript

#281

Post by gakada »

prodigal_erik wrote: post #253
hbhakhra wrote: post #219

Earlier quoted context omitted.

Just imagine two packages you depend on (a and b) that both have a shared dependency (x). Both start off depending on x version 1.0 but then later a is updated to 2.0 while b isn't. Now you have two packages depending on different versions of the same package and hence the need for duplication. You have a that needs x@2.0 and b that needs x@1.0, so both copies are kept.

Don't upgrade a when it wants a half-baked x. Choose versions of a and b that agree on a known-good version of x. If there aren't any, it's not sane to use a and b together unless x is written very carefully to accommodate data from past and future versions of itself.

That's not how it works. There will be two copies of x in the require cache. They don't know of each other's existence.

Re: Yarn – A new package manager for JavaScript

#282

Post by fryguy »

_greim_ wrote: post #174
lucian1900 wrote: post #48

Earlier quoted context omitted.

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.

> Multiple versions [...] almost always a bad idea If so, different major versions of the same dep should be considered different libraries, for the sake of flattening. Consider lodash for example.

That can cause some serious problems in at least some portion of times. I've dealt with the subtle errors that have been caused by this problem in c++, and don't really know javascript libraries that well so I can't give a more concrete example. But imagine that there are the following libraries:

* LA: handles linear algebra and defines a matrix object.

* A: reads in a csv file and generates a matrix object using LA

* B: takes in a matrix object from LA, and does some operations on it

In this case, if B depends on version 5 of LA and the new version of A depends on version 6 of LA, then there's going to be a problem passing an object that A generated from version 6 and passing it to B which depends on version 5.

Re: Yarn – A new package manager for JavaScript

#285

Post by KayL »

bcherny wrote: post #168

I use JS+Node+NPM for my day job and many side projects. Initial thoughts: - Why didn't Facebook contribute the updates to NPM directly? - They are coupling a package manager and registry proxy; the latter has many existing implementations already - The differenced between Yarn and NPM+Shrinkwrap do not seem substantive; NPM made the design decision to use a sometimes non-deterministic install algo in NPM3 to speed u…

When you're game changer, it's hard to make current projects maintainers nod their head for you!!! I think io.js was a good example.

Re: Yarn – A new package manager for JavaScript

#286

Post by baq »

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…

funny (and great!) how cargo became a gold standard for package management without any advertising. well done, rustaceans.

Re: Yarn – A new package manager for JavaScript

#287

Post by prodigal_erik »

gakada wrote: post #281
prodigal_erik wrote: post #253

Earlier quoted context omitted.

Don't upgrade a when it wants a half-baked x. Choose versions of a and b that agree on a known-good version of x. If there aren't any, it's not sane to use a and b together unless x is written very carefully to accommodate data from past and future versions of itself.

That's not how it works. There will be two copies of x in the require cache. They don't know of each other's existence.

I'm arguing for choosing dependency versions that don't require you to break the highlander rule. "a is updated to 2.0" doesn't mean you should start using that version of a right now.

Re: Yarn – A new package manager for JavaScript

#288

Post by tigershark »

erikpukinskis wrote: post #250
grayrest wrote: post #207

Earlier quoted context omitted.

> Are people really making projects with dozens (hundreds? more?) of dependent libraries? Yes. > Are there aspects of the language or runtime that reward multiple layers of configuration management? A significant fraction of the node community likes to split their project into really, really small packages and treat them as if they're independent even if they come from the same source repo and tend to get used togeth…

What do you find maddening about micro packages? I hate depending on a giant stack of frameworks (slowing installs, builds, adding behavior surface area) when I just need a function or two, so micro packages are a joy for me.

Reading the article it seems to me that this micro packages approach is what slows down everything. I never, ever have seen all these problems in even not-so-state-of-the-art dependency managers like maven or nuget. Seriously up to now it was impossible to have a build server isolated from the internet if you didn't want to check-in all the dependencies??? Simply crazy. I really can't understand how people can even think to use a dependency manager system that doesn't satisfy the essential requirement of having your CI server sandboxed.

Re: Yarn – A new package manager for JavaScript

#289

Post by swang »

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

1. any left-pad issue has been "eliminated" with the new rules npm (the company) has enforced.

2. you can already have your own version of thirdparty/left-pad by maintaining your own npm repository. i think what your parent post is referring to is facebook saying we're going to make our own public node/javascript package registry and you should publish to our registry.

doing this at the moment does nothing for the community other causing a lot of pain points. ex) now npm authors will have to publish to both registries so developers don't have to dig to find where it was published to, then they also have to hope that someone else didn't register the module name in one of the registries..

there is just too much splintering if facebook decided to become a competing registry rather than just using npm's registry and building on top of it.

Re: Yarn – A new package manager for JavaScript

#290

Post by stincity »

I get NPM for backend development but I don't understand why frontend developers require NodeJS just to utilize it's package management. It really does not make any sense to me considering that NodeJS is server side javascript. If my backend is Python or Go or .NET or Java or whatever, now I'll need NodeJS for the frontend and only for NPM (and now this). It's a reason why I don't enjoy dealing with "modern" frontend technologies.
Post reply on HN