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

361–370 of 486 posts

Re: Yarn – A new package manager for JavaScript

#361

Post by hyperpape »

gakada wrote: post #300
prodigal_erik wrote: post #287

Earlier quoted context omitted.

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.

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.

Re: Yarn – A new package manager for JavaScript

#362

Post by steveklabnik »

gell_mann wrote: post #358

This is a somewhat unrelated question. I'm a systems programmer (I spend most of my days in the land of C and Go). I do understand the basic concepts of web apps and how you develop one. I have even built a few websites using Rails. Can somebody please explain to me: 1) How does npm fit in in the process of developing a web app. How does it manage the js files / libraries and where does it place them? 2) How is yarn…

1. npm == bundler. One difference: it puts the source of your dependencies into a node_modules folder in the project itself, rather than in some global spot

2. npm doesn't have bundler's lockfile, but this does. It's also faster.

Re: Yarn – A new package manager for JavaScript

#363

Post by nmblackburn »

joepie91_ wrote: post #197
steveklabnik wrote: post #147

Earlier quoted context omitted.

How is this throwing away semver?

As I understand it, it automatically locks in the (exact) version of everything you install, rather than having this as a separate, optional feature (like shrinkwrap does, despite it not working well - but that's an implementation problem). The big deal about semver and how it's implemented in NPM is that there is a choice of how to deal with it - either you automatically allow compatible updates and risk an occasion…

"Facebook also needs to take into account their influence over the ecosystem. The reality is that whatever project Facebook puts out is immediately seen as gospel and "naturally, a well-engineered thing and a good choice to use!" - this is literally a daily argument in #Node.js when somebody is trying to argue why a poorly-fitting tool is somehow appropriate for their usecase. "Well, Facebook uses it!""

Absolutely agree with this statement, it drives me insane listening to the hype before anyone has really even had chance to form an opinion on it.

Re: Yarn – A new package manager for JavaScript

#364

Post by nmblackburn »

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…

They absolutely do, it's all a big game to see who can get the biggest market share.

Re: Yarn – A new package manager for JavaScript

#365

Post by gell_mann »

steveklabnik wrote: post #362
gell_mann wrote: post #358

This is a somewhat unrelated question. I'm a systems programmer (I spend most of my days in the land of C and Go). I do understand the basic concepts of web apps and how you develop one. I have even built a few websites using Rails. Can somebody please explain to me: 1) How does npm fit in in the process of developing a web app. How does it manage the js files / libraries and where does it place them? 2) How is yarn…

1. npm == bundler. One difference: it puts the source of your dependencies into a node_modules folder in the project itself, rather than in some global spot 2. npm doesn't have bundler's lockfile, but this does. It's also faster.

I never guessed building a package manager / dependency tracker could be such a complex problem.

Re: Yarn – A new package manager for JavaScript

#367

Post by steveklabnik »

gell_mann wrote: post #365
steveklabnik wrote: post #362

Earlier quoted context omitted.

1. npm == bundler. One difference: it puts the source of your dependencies into a node_modules folder in the project itself, rather than in some global spot 2. npm doesn't have bundler's lockfile, but this does. It's also faster.

I never guessed building a package manager / dependency tracker could be such a complex problem.

It's really tough! I like this post, if you want to learn more: https://medium.com/@sdboyer/so-you-want-to-write-a-package-m...

Re: Yarn – A new package manager for JavaScript

#368

Post by cpojer »

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.

Re: Yarn – A new package manager for JavaScript

#369

Post by dclowd9901 »

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

It's not a cultural problem. People make mistakes. People don't know what a non-breaking change is, especially those not well versed in refactor work.

I don't think Yarn solves any of these problems, tbh. It seems like what we really need is a package manager that tests the api of each package update to make sure nothing in it has broken expectation in accordance with Semver.

Re: Yarn – A new package manager for JavaScript

#370

Post by cpojer »

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…

Hey, I work on Yarn and Jest. Let me respond to why we built Jest: It solves a ton of problems no other test runner solves and it works well at Facebook's scale. We open sourced it more than two years ago but only recently started to promote the project in open source more actively because it is working so well at FB.

If you are curious to find out more about why we built it, please read our blog posts, beginning with one about testing performance and our unique constraints at FB: http://facebook.github.io/jest/blog/2016/03/11/javascript-un...

Finally, test runners tend to get stale. Any large organization will run into trouble with any kind of tooling as companies scale up engineers or codebases. Testing is no different and we aimed to solve those problems for Facebook; getting to open source our solutions is an added bonus and we are excited to work with the JS community to build the best tooling we can possibly build.

Post reply on HN