Yarn shouldn't be installed from the package repository.The inconsistency between the version of nodejs which yarn is running on and the version of nodejs which npm is running on brings significant effects.
https://github.com/yarnpkg/rfcs/issues/9
Any idea how to reach out to one of the authors?
Yarn – A new package manager for JavaScript
481–486 of 486 posts
Re: Yarn – A new package manager for JavaScript
#482This may come off as a troll, but it's an honest question. I'm not a javascript guy. It's not a language I deal with at all. Why on God's green earth does it need as much tooling as it seems to have? Are people really making projects with dozens (hundreds? more?) of dependent libraries? Are there aspects of the language or runtime that reward multiple layers of configuration management? In short, what the hell is up…
Because JS is open source and it's not controlled by an Oracle / Microsoft / Apple / XXX foundation. Everybody is free to do stuff - and does. In the end there aren't actually as many tools as people think, a lot of hobbyists projects who die quite quickly
Re: Yarn – A new package manager for JavaScript
#483Earlier quoted context omitted.
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.
The benchmarks test both the hot cache and cold cache scenarios for npm and Yarn. Except in the scenario when node_modules is already populated and there is no yarn.lock file, which is uncommon if you're using Yarn, Yarn is faster than npm in all of the benchmarked scenarios where there is a cold cache.
Re: Yarn – A new package manager for JavaScript
#484neat
Re: Yarn – A new package manager for JavaScript
#485Earlier quoted context omitted.
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 t…
Javascript is very easy to work with if you just stick to micro packages. What slows it down is that the language has been forked to an incompatible spec (ES6) so there is essentially a hard fork in pool of libraries. To deal with this—and calm anxieties around lack of inheritance, trauma over having to type function over and over, etc—layers of pre-processing have been added: JSX, SASS, asset compilation, compatibility layers, framework booting. This pipeline distances developers from the DOM and other low-level protocols, increases the surface area of the build process, and frequently disables debugging and introspection tools. In addition megaframeworks like Angular, Ember, and React add mandatory layers of indirection and runtime dependencies between each snippet of code, introducing behavioral complexity and confusion from non-deterministic builds.
All of this is why people are excited about Yarn, but to me it's a band-aid on several architectural mistakes.
Just say no to frameworks. Just say no to ES6 and transcompilation. Just say no to asset pipelines. Viva la JavaScript. Viva la Netscape. Viva la Node.
Re: Yarn – A new package manager for JavaScript
#486Earlier quoted context omitted.
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 co…
> any left-pad issue has been "eliminated" with the new rules npm (the company) has enforced.
Only to resurface again: http://status.npmjs.org/incidents/dw8cr1lwxkcr
And it will, no doubt, resurface again and again and again