So this is not a Hadoop thing?
Yarn – A new package manager for JavaScript
101–110 of 486 posts
Re: Yarn – A new package manager for JavaScript
#102Earlier quoted context omitted.
Sorry about that, there are very likely still some bugs out there we weren't able to catch in all our testing which will be ironed out by the community in the next few days. Can you open an issue with details about which package failed to install? https://github.com/yarnpkg/yarn/issues/new
Thank you. Done. The issue is reproducible with an entirely new project.
A fun side effect of reproducible builds: recreating bugs for bug reports is easier.
Re: Yarn – A new package manager for JavaScript
#103"The React Native package.json currently lists just 68 dependencies, but after running npm install the node_modules directory contains 121,358 files." That, to me, is what is wrong with npm. The problem stems from node.js not coming with "batteries included" so there is a proliferation of tiny libraries that do the most trivial things.
As I understand it, the related problem is the poor support in build tools for dead code elimination which encourages people to publish libraries that contain a single function like left-pad.
Re: Yarn – A new package manager for JavaScript
#104Overall looks good, but it's a shame that flat mode is opt-in instead of the default - this is the sane way of doing package management. Would have been nice to flip the options over so you have to explicitly allow multiple versions of the same package - which you could automatically enable if you're converting from npm.
Elsewhere in this thread, they said that its because it doesn't work well with enough of the ecosystem yet.
Re: Yarn – A new package manager for JavaScript
#105Re: Yarn – A new package manager for JavaScript
#106What does this mean for NPM Inc the company?
Is a replacement / mirror / rethink of the NPM infrastructure coming next?
If I was NPM Inc I would think about adopting yarn if possible.
Re: Yarn – A new package manager for JavaScript
#107Should you commit the yarn lockfile to version control?
I don't know about yarn specifically, but for all the systems it's modeled after, the answer is "yes for binaries, no for libraries".
Re: Yarn – A new package manager for JavaScript
#108"The React Native package.json currently lists just 68 dependencies, but after running npm install the node_modules directory contains 121,358 files." That, to me, is what is wrong with npm. The problem stems from node.js not coming with "batteries included" so there is a proliferation of tiny libraries that do the most trivial things.
Yeah. Inspecting the node_modules folder for pretty much any front-end project is depressing. Still, I prefer npm to no package manager at all.
One problem is that packages often bundle everything, rather than including an npmignore. I'm guilty of this myself.
Do you think that the problem of over-dependence is reversible, and if so, how?
Re: Yarn – A new package manager for JavaScript
#109Earlier quoted context omitted.
I find it strange that the time isn't invested in already existing projects. But at least it's a move away from NPM. I think the most problems I had with JavaScript develompent in the last 2 years came from NPM.
Yarn isn't a replacement for npm itself. It's a client that can read/write to npm, and other registries such as Bower.
Well, it seems like it could be according to the article. What would you still need to use NPM (the cli) for, other than package hosting?
According to http://blog.npmjs.org/post/151660845210/hello-yarn, it seems it doesn't work with private packages yet, which may or may not be an issue for your project. But it seems this is a complete CLI replacement for NPM.
Re: Yarn – A new package manager for JavaScript
#110This is a huge leap forward for the JavaScript community—probably more than many people will realize right away. I loved Bundler's deterministic builds but chafed against the Ruby limitation of only having a single version of a dependency at once. npm solved this problem elegantly, but still struggles with non-determinism. I had resigned myself to thinking that maybe these were just fundamental tradeoffs in package m…
> I loved Bundler's deterministic builds but chafed against the Ruby limitation of only having a single version of a dependency at once
This is due to the way that Ruby includes code, where it's available globally, vs Node where code is scoped to the including module. I'm not sure how Ruby could support multiple versions with changes to the language and/or RubyGems