Repository navigation
bundle with yarn and allow which package manager during build. #9161
Description
Activity
Why yarn? There are other, much older alternative npm clients
Reacted by Nicolas ChambrierReacted by Matthew Evans, Alan Plum, Peter Petrov, Kilian von Pflugk, Dwayne, Daniel Lo Nigro, Denis Bardadym, Jason Kurian, Giovanni Tirloni, Kevin Poirot and 1 moreReacted by Sergey Rubanov and Kilian von PflugkBecause 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.
Reacted by Alan Plum, Matthew Evans, Peter Petrov, Dwayne, nmccready, Constantine Antonakos, Daniel Lo Nigro, zanets, Mikael Finstad, Sindre Sorhus and 7 moreBecause 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-npmflag 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.
Reacted by Anna Henningsen, Vladimir Kurchatkin, Sergey Rubanov, Evan Lucas, Vse Mozhe Buty, Alberto Varela, Sean Vieira, Josh Gavant, Joran Dirk Greef, Nicolas Chambrier and 13 moreAs 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.
Reacted by Josh Manders, Peter Petrov, Constantine Antonakos, Patrick Camacho, Kyle Stevenson, matteocng and Jason KurianChanging 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.
Reacted by Sergey Rubanov, Vladimir Kurchatkin, Alan Plum, Joe McCann, Joe Doyle, Peter Petrov, Josh Manders, Bryan Hughes, Gibson Fahnestock, S.Y. Lee and 11 moreThank you @jasnell. I personally cannot accommodate the requirements to write a formal proposal, but I'd love to see one.
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.
Reacted by Josh Manders, Sindre Sorhus and Jason KurianThere 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.
Reacted by Marc Udoff and Sean VieiraPerhaps 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.
Reacted by Nicolas Chambrier and Andreas LindI use homebrew to install node, and they support
--without-npmflag, 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.which gives the clear advantage to npm
It's possible to install yarn with npm, so no problem here
Reacted by Sergey Rubanov, Joran Dirk Greef and Denis BardadymValid point.
2 remaining items
I'm not advocating it being done right now. Just starting a discussion on it being done, so when yarn is ready to go, we have steps to begin the process and not spend 6 months after the fact debating it.
And yes, @bnoordhuis you are correct in what I was trying to convey.
Reacted by Alan Plum and Simon KnittelMicrosoft ships Windows with Internet Explorer too 📦 which most People use to download Chrome or others..
npm is like Internet Explorer
Reacted by Nicolas Chambrier, Hongbo LU, nmccready, Thomas Grainger, Johannes Schickling, (Rew) Andrew McLagan and Thomas BrianReacted by Yazan Medanat, Jason Kurian, Ingvar Stepanyan, Nelson, Giovanni Tirloni, John-David Dalton, Sergey Rubanov, Jordan Harband, Alan Plum, Jonathan Cardoso and 1 moreReacted by nmccready, Yuri Pereira Constante, Denis Bardadym, zanets, Jonatan Männchen, Martin Hochel, Guilherme Meireles, Anthony Ciccarello, (Rew) Andrew McLagan, Chawye Hsu and 5 moreReacted by nmccready and (Rew) Andrew McLaganReacted by (Rew) Andrew McLaganI like to propose the idea of choosing which package manager to use. something like
node --install-package-manager yarnornode --install-package-manager npmandnode --use yarnornode --use npm. This way, the user has to make the decision and not bundle a package manager into the default install.@jumoog The difference is that Microsoft owns MSIE. This is more like Windows shipping with Chrome. Except Chrome is not tied to any commercial services and Windows is owned by a corporate entity. So it's really more like Linux shipping with the Opera browser (back when Opera was freemium).
I think both should be integrated as default.
npm for back compatibility and yarn for new package management.
it time for us to reject semver, which is totally a false practice on version management and a very harmful misleading to software development.
Reacted by Sergey Rubanov, Simon Knittel, Oleksii Orlenko, Nikita Skovoroda, Jordan Harband, Ruben Bridgewater and Kat MarchánThere'll be alternatives that crop up from time to time, but npm is defacto and a constant in the ecosystem. I don't think it's worth the time and support investment to include every so-hot-right-now package manager. –PS semver is p rad and so is npm5
Reacted by Jordan Harband, Ruben Bridgewater and Kat Marchán@calidion: What are you going on about? Semantic versioning is a critical part of good dependency management.
If you feel there's something wrong with it, then describe what you think is wrong with it. Don't just throw in a few superficial negative remarks - at best it's non-constructive, at worst it's misleading towards other readers of the thread.
Reacted by Nikita SkovorodaI think with npm5 landing with Node 8 there is very little incentive to integrate yarn, as virtually all objections raised here have been addressed. Can we close this thread now?
Reacted by Saad QuadriYeah, there's little to no reason to keep this thread open. The right way to pursue anything along these lines would be to make a node-eps proposal.
Reacted by Benjamin Gruenbaum, Jordan Harband, Kat Marchán, Rich Trott and Nikita SkovorodaSo we're just going to ignore the exact governance and ownership concerns raised in this discussion that are the reason the Node Foundation was created in the first place and accept the conflict of interest because it npm Inc was grandfathered into a monopoly position within the ecosystem?
Fine. I've officially stopped having any hope in the Foundation taking its responsibility seriously.
Reacted by EricReacted by Benjamin Gruenbaum@pluma this isn't a foundation thing. For what it is worth there is a complete separation between the foundation and the technical decisions of the project.
There has yet to be someone who has practically shown how we can begin to ship with yarn.
Putting aside stability and political concern... the project would need to:
- begin a relationship with the facebook tooling team and work out a process in which we could expect updates to yarn
- decide if we are going to ship yarn in the tree or not
- figure out how we plan to ship it
- update our .pkg installer
- update our msi
- update our tarballs and makefiles
I'll focus on a single one.. updating our .pkg installer. Did you know that our .pkg installer is being held together by very thin wires because Apple no longer actively supports the format. I've tried for many hours on multiple occasions to fix the install scripts for the package installer to try and solve issues like this to no avail.
To allow for the "pick a package manager" functionality we would need to completely replace our .pkg. We have begun some experiments in making an electron installer, but that comes with it's own sacrifices (such as a 100MB download).
This is not a governance decision, this is a technical one. Not only do we need to find the time and resources to figure out the technical challenges that are unearthed by moving from one to two package managers in a release, we also need support from the teams that are building it.
I talked with @cpojer at JSConf EU, and I believe that he can attest to the fact that individuals from the project have given this serious thought. We are even willing to try and see if there is a path forward, it just takes time + resources that not everyone has at the moment.
To @pluma, @calidion, and to others watching this repo. Node.js is maintained by a group of people, most of whom are doing this out of the kindness of their hearts in their free time. If you don't see something being done, and you don't have the time to fix it yourself... perhaps assume other people are also pretty busy and don't have time to do it either. The current way you are engaging in this conversation is unproductive and disingenuous.
Reacted by Jan Olaf Martin, Kat Marchán, Renée, Anna Henningsen, Jordan Harband, Rich Trott, Bryan Hughes, ashley williams, Refael Ackermann, Benjamin Gruenbaum and 1 moreReacted by Anna Henningsen, Jordan Harband, Rich Trott, Bryan Hughes, Kat Marchán, Nikita Skovoroda, ashley williams, Refael Ackermann, Benjamin Gruenbaum and Daijiro Wachisemver is the root for the unstability that npm has now. and I have pointed out here:
that is why yarn is far better options than npm.
just because semver is the evil root.
if semver is good, then npm needs no updates.
since semver is evil and false, npm updates again and again with out any improvement.
I have pointed out the problem years ago, and yarn has implemented my idea, but npm has not.
and npm is not fit for stable release, every updates can lead to project breaking which i have encouter just days ago.
why can't i say semver is evil?
semver and npm is totally misleading on how to version a software and keep packages stable and safe.
yarn is more practical and theoretically correct.
npm makes packages unstable and keep programmers wasting time finding problems.
semver is theoretically wrong and npm is the sequential result which is unstable and problem causing!
yarn keeps exact versions instead of assuming such false compatibility from semver that keeps projects or packages stable and peace.
through years of practice and being proven wrong, I think it is time to embrace other package management such as yarn.
npm is good at easy publishing but bad at keeping package stability .
yarn makes that up.
As i have discussed with npm maintainers, they will continue semver rules.
And I think some of us may need an alternative pm tool to keep their package stable and safe.
not with npm promises no stability.
Reacted by Jordan Harband@calidion ... This is not the place to debate the merits of semver, nor is your comment useful in any particular manner. @MylesBorins spelled out the issues rather clearly.
Given that this issue has been closed and the conversation is not advancing things forward at all, I'm locking the issue. Collaborators, please refrain from posting further on this thread. If any other CTC members have concerns about locking the thread, let me know.
- locked and limited conversation to collaborators
on May 28, 2017
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-npmso I'd like to see--with-npmand--with-yarnas options.Thoughts?