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

471–480 of 486 posts

Re: Yarn – A new package manager for JavaScript

#471

Post by ohitsdom »

Kiro wrote: post #198
ohitsdom wrote: post #150

Earlier quoted context omitted.

You don't? Consistent and reliable dependency versioning across all machines, and speed: https://yarnpkg.com/en/compare

Sure, not saying there aren't any benefits but as a casual user they don't feel big enough to justify a switch. I may be wrong though (hence why I'm asking).

It took less than 20 minutes for me to change over a decently large project. The builds on the CI server increased by about 25 seconds by switching from npm install to yarn install. It was definitely worth it for me.

Re: Yarn – A new package manager for JavaScript

#472

Post by skrebbel »

akhatri_aus wrote: post #465
skrebbel wrote: post #464

Earlier quoted context omitted.

You don't. If you want to be able to do stuff like that (and inevitably run into "hmm, works on my machine"-type bugs once you start sharing your code with others), you need to keep using npm. This kind of liberty is the sort of stuff npm was designed for. It is also why npm has been causing trouble in many cases.

I was under the impression that this was about speed. There are many use cases for this functionality, the design of a software package shouldn't instill dogma into its users. Users use software for their needs, not to sign up to a religion.

No, speed is bonus. Yarn is about reproducible dev/test/build setups. Same yarn.lock - same node_modules content. That's the primary goal.

If you think consistency across computers is a religion then I don't think we're going to find a lot of common ground here though.

Finally, yarn is not intended to replace the npm client. It is intended to replace it for a certain use case, which happens to be one many companies have. Unlike Yarn, Npm is highly flexible and obviously you like it like that. I strongly doubt it's going to stop being developed all of a sudden because some other people made Yarn. So what, exactly, is the problem?

Re: Yarn – A new package manager for JavaScript

#473

Post by PudgePacket »

jameside wrote: post #162
mvdanj wrote: post #126

Earlier quoted context omitted.

You say "decent performance" and "predictability". What is the basis of this claim? I've heard these all before, but unless you've actually shipped a product using this tool I don't know how you can back this up.

As for performance, Yarn is about 3-5x faster installing all of the dependencies and devDependencies of react-native. The benchmarks are here: https://yarnpkg.com/en/compare . It's much faster in most scenarios, especially the ones that used to take minutes.

Only if those dependencies are in the cache, otherwise it takes the same time.

Re: Yarn – A new package manager for JavaScript

#474

Post by seandavidfisher »

ohitsdom wrote: post #471
Kiro wrote: post #198

Earlier quoted context omitted.

Sure, not saying there aren't any benefits but as a casual user they don't feel big enough to justify a switch. I may be wrong though (hence why I'm asking).

It took less than 20 minutes for me to change over a decently large project. The builds on the CI server increased by about 25 seconds by switching from npm install to yarn install. It was definitely worth it for me.

Wait, your build times increased on the CI server? What makes that worth it?

Re: Yarn – A new package manager for JavaScript

#475

Post by Ericson2314 »

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…

Ideally for libraries you would try to test with different combos of transitive deps, but it's a large space.

Anyways you can put a lockfile with your library, and it shouldn't affect downstream.

Re: Yarn – A new package manager for JavaScript

#476

Post by vroombaprime »

Cthulhu_ wrote: post #420
dlandis wrote: post #183

Earlier quoted context omitted.

It is quite a congenial response and no disrespect to npm inc, but yarn will be technically far superior (if it's not already), and I can't help but interpret this as the beginning of the end for npm....It was only a matter of time though since there are a number of systemic problems with npm and (in my opinion) it is at the center of the dysfunctional world of modern JavaScript tooling. It did move the ecosystem for…

NPM can evolve; Gradle and SBT also didn't turn out to be the end of Maven, which evolved to being more of a repository and dependency management tool with multiple clients.

This would make a lot of sense. I would /never/ make a build using maven again, but having maven central around is a huge plus for the jvm ecosystem and I'm happy it survives. (plus lots of people continue to make new builds with maven and legacy maven builds will be around basically forever)

Re: Yarn – A new package manager for JavaScript

#477

Post by akhatri_aus »

skrebbel wrote: post #472
akhatri_aus wrote: post #465

Earlier quoted context omitted.

I was under the impression that this was about speed. There are many use cases for this functionality, the design of a software package shouldn't instill dogma into its users. Users use software for their needs, not to sign up to a religion.

No, speed is bonus. Yarn is about reproducible dev/test/build setups. Same yarn.lock - same node_modules content. That's the primary goal. If you think consistency across computers is a religion then I don't think we're going to find a lot of common ground here though. Finally, yarn is not intended to replace the npm client. It is intended to replace it for a certain use case , which happens to be one many companies…

> So what, exactly, is the problem?

Follow users needs, not your idea of what they are or the problems with npm are.

Re: Yarn – A new package manager for JavaScript

#478

Post by mfornasa »

niix wrote: post #436

Awesome! So far this is working great with a Dockerized Node application I have. Great job Facebook and the rest who contribute!

It could finally solve the major pain in using Node over Docker for CI and local development.

https://medium.com/@mfornasa/using-yarn-with-docker-c116ad28...

Re: Yarn – A new package manager for JavaScript

#479

Post by ef4 »

theanswerer wrote: post #215
ef4 wrote: post #32

Earlier quoted context omitted.

Yeah, that would be much better. But unfortunately the node_modules structure (which yarn is attempting to be fully compatible with) makes that impossible. The reason is that each package only finds its dependencies relative to its own location. So your second level dependencies cannot vary from project to project unless you do copying. (Example: AppA and AppB depend on LibX. LibX depends on LibY. Through their deter…

You can make it work with `node --preserve-symlinks`

Thanks, I was not aware of that option.

Looks like it's new in Node 6. Yarn supports Node LTS.

Re: Yarn – A new package manager for JavaScript

#480

Post by spasquali »

remi wrote: post #470
spasquali wrote: post #469

Or just use shrinkpack: https://github.com/JamieMason/shrinkpack But that would be too easy...

Did you read the article paragraph about shrinkwrap?

Not `shrinkwrap` -> `shrinkpack`.

Not sure why Facebook spent so much time and money to create a more complicated "solution", or why so many people don't realize that.

Post reply on HN