Install yarn

[strarsis]

yarn is an alternative package manager (like npm).
It would be great if nvm also installs yarn as it does with npm.
A switch to decide whether to install yarn or npm or even both of them would be a great addition.

[ljharb]

1. yarn is not yet a full alternative to npm.
2. nvm installs node. npm comes with node - nvm doesn't install npm.

If node ships with yarn, then nvm will bring yarn along with it. Until then, npm install -g yarn works just fine.

[rgbkrk]

As an nvm true believer and a lover of yarn, I'm disheartened by the stance of yarn to prefer a system wide installation.

[nathansobo]

I'm disheartened by the stance of yarn to prefer a system wide installation.

Agreed. I wonder how nvm and yarn will interact once npm install -g doesn't work anymore. It's currently deprecated.

[gsklee]

@rgbkrk @nathansobo No they don't. The installation instruction you referred to needs to be there to make global installations work, but that doesn't mean they endorse the usage; it's more like for compatibility's sake. If you refrain from doing global installations, you can completely omit the Path Setup section and things will still work fine.

[seangates]

I believe I would rather have all packages (global or otherwise) be installed by yarn. It fixes many NPM issues, and significantly speeds up development. Could this be built in as an option? A flag? Perhaps something like --package-manager=yarn?

[kane-thornwyrd]

@seangates which issues specifically ?

[ljharb]

@seangates that's up to node, not nvm, since nvm manages node, not npm. However, I'd discourage ever installing anything globally - everything should be project-local.

[seangates]

@ljharb Even yarn? yarn is a global wrapper for npm. Anywhere you'd use NPM, you'd use yarn as a replacement.

@kane-thornwyrd http://stackoverflow.com/questions/40027819/when-to-use-yarn-over-npm-what-are-the-differences#40028313

[seangates]

Also, as a testament to this, multi-billion-dollar companies have quickly and with purpose adopted yarn as a replacement for the sake of their code quality, and deployment speed and stability. I will not use npm again until it's fixed. Hence, the need for me to always have yarn available globally.

[seangates]

Do you folks not use yarn on every project you have going right now? npm is woefully unpredictable.

[kane-thornwyrd]

@seangates use npm shrinkwrap

[ljharb]

@seangates i have yet to see a single concrete problem scenario where npm shrinkwrap is less predictable than yarn - including from the yarn team.

[ljharb]

@seangates and yes, even yarn. The yarn team actually recommends installing yarn separately from npm, so if you follow their recommendation, it wouldn't be at all relevant to this thread.

Separately, I don't yet believe yarn is production-ready, since it does not yet have feature parity with npm.

[seangates]

npm shrinkwrap does not work properly for private repositories, nor is it consistent between developers who run (seemingly) the exact same environment. I have concrete scenarios, first hand, where shrinkwrap failed to properly handle nested dependency trees while using a private repository.

I mean, why else would Facebook have created yarn in the first place?

I guess what I'm hearing is that you folks are simply installing the vanilla node version, but keeping out of packages altogether? But ... yet you still will allow the install global packages as part of that process?

What I want to know is: would you then be amenable to let someone implement a flag to use yarn as the package tool to do the package installation?

[seangates]

A great explanation: https://code.facebook.com/posts/1840075619545360

Attempts at scaling the npm client
Initially, following the prescribed best practices, we only checked in package.json and asked engineers to manually run npm install. This worked well enough for engineers, but broke down in our continuous integration environments, which need to be sandboxed and cut off from the internet for security and reliability reasons.

The next solution we implemented was to check all of node_modules into the repository. While this worked, it made some simple operations quite difficult. For example, updating a minor version of babel generated an 800,000-line commit that was difficult to land and triggered lint rules for invalid utf8 byte sequences, windows line endings, non png-crushed images, and more. Merging changes to node_modules would often take engineers an entire day. Our source control team also pointed out that our checked-in node_modules folder was responsible for a tremendous amount of metadata. The React Native package.json currently lists just 68 dependencies, but after running npm install the node_modules directory contains 121,358 files.

We made one final attempt to scale the npm client to work with the number of engineers at Facebook and the amount of code that we need to install. We decided to zip the entire node_modules folder and upload it to an internal CDN so that both engineers and our continuous integration systems could download and extract the files consistently. This enabled us to remove hundreds of thousands of files from source control, but made it so engineers needed internet access not just to pull new code, but also to build it.

We also had to work around issues with npm's shrinkwrap feature, which we used to lock down dependency versions. Shrinkwrap files aren't generated by default and will fall out of sync if engineers forget to generate them, so we wrote a tool to verify that the contents of the shrinkwrap file matches what's in node_modules. These files are huge JSON blobs with unsorted keys, though, so changes to them would generate massive, difficult-to-review commits. To mitigate this, we needed to add an additional script to sort all the entries.

Finally, updating a single dependency with npm also updates many unrelated ones based on semantic versioning rules. This makes every change much larger than anticipated, and having to do things like committing node_modules or uploading it to a CDN made the process less than ideal for engineers.

[seangates]

@ljharb It's production ready, and has been for quite a while. And it's been prod ready at Facebook for even longer than that, too. eBay has now adopted it as their package management for Node, which is hundreds of clusters and thousands of deployments. eBay (where I work) has been working closely with the Facebook teams to ensure continuity and stability in our infrastructure relating to yarn.

[ljharb]

@seangates no, i wouldn't be amenable, because nvm has nothing to do with package installation - it manages node. You can npm install -g yarn and then use yarn all you like, or you can install it systemwide (as they recommend) and use it regardless which node version you're using.

I would love to see one of your concrete scenarios where yarn's determinism prevents a problem that npm's lack of determinism causes - I've had many conversations with the yarn team, in person, and nobody has been able to provide a single one yet.

(it's a bit gauche to thumb-up your own posts, btw)

[seangates]

Well, I still stand by my comments about yarn solving issues for my team, and others, where npm and npm shrinkwrap did not properly pull the right dependencies.

Also, I also stand by my comment that yarn is production ready.

[seangates]

Also, I still don't understand this:

nvm has nothing to do with package installation

You supply a way to migrate packages, yet not to pick the way those packages will be installed.

[ljharb]

Yes, that's a good point. As soon as node ships with yarn, nvm will support yarn.

I'm happy that yarn solves issues for whoever it solves them for - in no way does that provide a single concrete repro case that justifies any claims that yarn avoids bugs by more deterministic than npm. I'm still very interested in seeing yours, since nobody at Facebook has yet been able to provide me one.

[seangates]

Let me hunt down the conversations (and scrub them for security). I hope to provide something first thing in the morning.

Also, I think I may be bundling my comments more around how npm works with how npm shrinkwrap works, because they are two different things. I just now prefer yarn for installing all packages, even if they are global (mainly for the speed improvement). So, your comment about nvm not having anything to do with projects (e.g. packages within a package.json) is correct.

[ljharb]

Thanks; please feel free to email them to me directly if you prefer.

Regardless, nvm's repo isn't the correct place to vent complaints about npm, or share preferences for alternatives.

[seangates]

@ljharb Yeah, apologies on getting off track a little. I am interested in how the tools I use everyday can be improved to help me speed up my engineering efforts.

[andrewhavens]

Just an update for anyone who comes across this issue via Google search...Yarn documentation now says that Yarn can be installed without node like this:

brew install yarn --without-node