bundle with yarn and allow which package manager during build.

[joshmanders]

Now that Yarn has made it's debut and seems to be going swimmingly, it'd be great if we can specify which package manager is used during build. I know there's --without-npm so I'd like to see --with-npm and --with-yarn as options.

Thoughts?

[vkurchatkin]

Why yarn? There are other, much older alternative npm clients

[joshmanders]

Because it's the most viable option being as it's backed by Google, Facebook, Exponent, Tilde, and is gaining more momentum in the week since it's release than any alternative has in it's whole lifetime. Not to mention npm, Inc themselves are cooperating and helping with yarn. It's just a no-brainer that it should be a choice. Adding others is fine too, but my main concern is that we'd have 600 choices and 598 of them are all abandoned.

[joepie91]

Because it's the most viable option being as it's backed by Google, Facebook, Exponent, Tilde

I don't think that's necessarily a good reason, or even a good situation. The io.js fork happened for a reason.

I'm skeptical about adding any other package managers at this stage. The --without-npm flag has a good reason for being there, as it can be used for eg. distributions that want to decouple the Node.js and NPM packages, but I can't really see the same argument for eg. --with-yarn.

Adding such a flag also runs the risk of different distributors deciding to build with different package managers, which would add fragmentation and confusion for new users, for no clear benefits (given that it's already relatively easy to install Yarn anyway).

This is something that should probably be revisited later, after careful consideration of the consequences (and after perhaps considering the option of not shipping a package manager at all), but for now, I think this would not be a good idea. It would add complexity without a clear benefit.

[pluma]

As another +1 for Yarn I would like to point out that Google, FB and Tilde represent the three major web frameworks (Angular, React and Ember). Yarn is definitely not an experiment.

I also think it's also important to stress that Yarn was explicitly created with an open governance model in mind while the npm client is necessarily an npm, Inc project.

See Yehuda's excellent rationale for supporting yarn as a community alternative to npm: http://yehudakatz.com/2016/10/11/im-excited-to-work-on-yarn-the-new-js-package-manager-2/

No other alternative client comes close to yarn in terms of political and actual support and like Josh has said, no other client has seen an adoption anywhere as rapid as yarn's. Additionally the yarn maintainers have a proven track record in the JS ecosystem (e.g. Babel) regardless of the commercial entities involved.

[jasnell]

Changing the npm client that ships with core by default is not out of the question in the future but it needs to be done carefully and we would need to make sure that the client is production stable. Yarn has a ton of great things going for it but it does need to mature a bit before we could even consider adopting it. @joshmanders ... the way forward for this would be to open a proposal in https://github.com/nodejs/node-eps describing the roadmap for this kind of change. Following that, a PR that adds the necessary bits to make it happen would be required. There's no guarantee that it would land any time soon (or at all) but that would be the way to get the ball rolling if you feel strongly enough about it.

[joshmanders]

Thank you @jasnell. I personally cannot accommodate the requirements to write a formal proposal, but I'd love to see one.

[pluma]

WRT to maturity I would like to remind people that the official npm client node.js is bundling has over 2300 open issues (and over 10,000 closed). One of the open issues results in corrupted bundles being pushed to the registry (meaning the bundle has to be re-published with an incremented version) and was originally filed in 2014 and only addressed earlier this year.

The npm client is definitely older than yarn by far but that doesn't make it stable. Also, yarn's development started in January and has seen some internal use before it went public.

However I agree in principle with @jasnell -- it may be a bit early to throw the weight of nodejs behind yarn. I do however think that it's a good time to start the work on how yarn could be adopted by nodejs if it survives the honeymoon and would love to see an EP being developed and taken serious.

[jasnell]

There are quite a few people (including myself) who love to see continued innovation, competition and collaboration around things like package management in Node.js so I have little doubt that we'll see an EP emerge on this in the not too distant future.

Some things to keep in mind for this: For me, it falls along the same lines as encouraging support for multiple VMs in Core. Chakra is not something that core will be shipping a supported build for in the near future, but it is a project that core fully embraces and provides a home for. The concerns that apply to that work, however, apply to this: core will only support alternatives if those do not break/fragment the ecosystem and if those can be supported in a way that is largely transparent to the majority of users. We do not want to end up in a situation where one subset of ecosystem stuff works in one combination of Node.js+Stuff-Node-Uses but not in another.

[joshgav]

Perhaps tools like nvm and nvs could add support for installing and managing package managers along with runtimes. After all, something has to bootstrap and install the package manager itself. If that is successful, perhaps Node could stop shipping npm and work cooperatively with all these package managers.

[cjihrig]

There is also the new installer repo that could manage the package managers.

[joshmanders]

I use homebrew to install node, and they support --without-npm flag, as they do not install node with npm, but install node and npm separately. They also support installing yarn, so that's how I am setup, but a lot of people do not use managers such as homebrew, nvm, etc, and just install node directly with npm, which gives the clear advantage to npm.

[vkurchatkin]

which gives the clear advantage to npm

It's possible to install yarn with npm, so no problem here

[joshmanders]

Valid point.