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

371–380 of 486 posts

Re: Yarn – A new package manager for JavaScript

#371

Post by dacjames »

cpojer wrote: post #368
beefsack wrote: post #360

Is it just me, or does Facebook seem to create new competing tools and technologies more often than the other majors? My inner-cynic makes me feel like everyone at Facebook is really young, as I've noticed a trait of inexperienced developers is to try to create new things over finding and improving existing tools. In reality it could be something as simple as Facebook releasing more FOSS software than others, or mayb…

We don't think this way. We needed to solve this problem for Facebook, explored alternatives and made the case to build Yarn. We work at Facebook to solve Facebook's engineering challenges; when we can collaborate with other companies and the open source community, that's an added bonus.

That mindset would seem to explain why Facebook creates more competing technologies than other players.

Re: Yarn – A new package manager for JavaScript

#372

Post by daveidol »

iamleppert wrote: post #203

This is not a problem with the package manager. This is a problem with complexity. When did it start becoming reasonable for a front-end only part of the MVCC pattern to have 68 dependencies? Or for a transpiler like Babel to add 100k+ files? I'm sorry I just find it ridiculous that instead of taking a look at the disease (unbounded complexity), we are looking to engineer our way out of the problem by creating a pack…

Have you seen some of the things we are building for the web these days? Full applications, with multiple "pages", server-side rendering above the fold content, minified builds that load not only content--but code as well--on demand from the server, etc.

Absolutely: this is overkill for your blog or portfolio website, but part of the rising complexity with the tooling and dependency system is due to the rising complexity of the applications themselves.

Re: Yarn – A new package manager for JavaScript

#373

Post by dacjames »

wtetzner wrote: post #303
thoughtpalette wrote: post #109

Earlier quoted context omitted.

Well, it seems like it could be according to the article. What would you still need to use NPM (the cli) for, other than package hosting? According to http://blog.npmjs.org/post/151660845210/hello-yarn , it seems it doesn't work with private packages yet, which may or may not be an issue for your project. But it seems this is a complete CLI replacement for NPM.

Yes, it replaces the client, but it uses the same package repository and package format.

And thus could have been implemented as part of the existing client.

Re: Yarn – A new package manager for JavaScript

#376

Post by markus2012 »

steveklabnik wrote: post #169
markus2012 wrote: post #157

Earlier quoted context omitted.

Well, now you can do that in Cargo as well :-) What we do currently is we lock everything to an explicit version - even libraries. At least it's possible to get deterministic builds if you are willing to do a bit of work carefully / manually updating all of your dependencies at once.

You shouldn't have that happen with Cargo, given that we have a lockfile. Even when you specify version ranges, you're locked to a single, specific version.

If you follow the best practices for using Cargo you don't have a Cargo.lock file for libraries.

This means your library tests will not be deterministic.

Using the Cargo.lock file for libraries does solve this, but then every binary package you build that references your library will have to be specifically tied to the versions in the library.

We do this internally because it's the only way to provide deterministic builds over time.

Over time I suspect it will get harder and harder to keep this rigid web of dependencies working.

One thing we might try is to enforce the rule 'no library will contain any tests'. At first glance this kinda makes my skin crawl, but maybe if we could find a way where every project that used a library could somehow share the tests for that library it could actually work.

git submodules might actually be able to provide these tests for each binary package. If only git submodules would stop corrupting our git repos... :-(

Re: Yarn – A new package manager for JavaScript

#377

Post by FLGMwt »

nailer wrote: post #33
michaelsbradley wrote: post #6

I think the write-up should specify `npm install -g yarnpkg` not `npm install -g yarn`.

Could be worth finding the author of 'yarn' on npm and asking them for the name - it's been unmaintained for 4 years: https://github.com/samholmes/yarn

He's since donated it : )

Re: Yarn – A new package manager for JavaScript

#378

Post by steveklabnik »

markus2012 wrote: post #376
steveklabnik wrote: post #169

Earlier quoted context omitted.

You shouldn't have that happen with Cargo, given that we have a lockfile. Even when you specify version ranges, you're locked to a single, specific version.

If you follow the best practices for using Cargo you don't have a Cargo.lock file for libraries. This means your library tests will not be deterministic. Using the Cargo.lock file for libraries does solve this, but then every binary package you build that references your library will have to be specifically tied to the versions in the library. We do this internally because it's the only way to provide deterministic b…

Hmmm, I feel like there's some kind of disconnect here; could you open an issue on users or the Cargo repo? Thanks!

Re: Yarn – A new package manager for JavaScript

#379

Post by jessaustin »

hyperpape wrote: post #361
gakada wrote: post #300

Earlier quoted context omitted.

Right but what I'm saying is that two versions of the same library will live quite happily together, because node.js absolutely abhors global scope. The two versions have their own module-level scope to store functions and data. So go crazy and install every version of lodash! Nothing will break.

That will work for lodash, because it's just a bag of functions. But anything that creates objects that are passed outside of a single module could have problems. There was actually a high profile bug when someone ended up with two versions of react included in the same page: https://github.com/facebook/react/issues/1939 .

That seems to be a slightly different situation? As the issue poster described, a single page had invoked two copies of React, both of which assumed ownership of a particular "global" variable. (Not really global, but a particular member of a global.)

I'm not a React expert, but I don't see why that situation would only affect multiple React copies with different versions?

Re: Yarn – A new package manager for JavaScript

#380

Post by _greim_ »

fryguy wrote: post #282
_greim_ wrote: post #174

Earlier quoted context omitted.

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

If an API expects the outside world to hand it an instance of a specific library, all bets are off. Maybe it gets `null` or the `window` object, who knows? But a library can at least declare what dependencies it wants. If you take that away, it ratchets up the uncertainty factor that much more.
Post reply on HN