Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Yarn – A new package manager for JavaScript

code.facebook.com

Post reply on HN
Print view View original

401–410 of 486 posts

Re: Yarn – A new package manager for JavaScript

#401

Post by brandonbloom »

Benjamin_Dobell wrote: post #396
brandonbloom wrote: post #395

Earlier quoted context omitted.

> > ways that could not be fixed without braking changes > Examples, please. The first and foremost: Version pinning should be the only way it works. Obviously _requiring_ shrink-wrap would be a breaking change. > > Shrinkwrap is still a usability nightmare > Again, examples, please. Having to explicitly call shrink-wrap is just silly. Devs on every time I've used shrink-wrap with frequently forget to do it and it ca…

> The first and foremost: Version pinning should be the only way it works. Obviously _requiring_ shrink-wrap would be a breaking change. > Having to explicitly call shrink-wrap is just silly. Devs on every time I've used shrink-wrap with frequently forget to do it and it causes all sorts of "works for me" problems later. Really? An entirely new tool because you didn't like typing "npm shrinkwrap" once, just once per…

> An entirely new tool because you didn't like typing "npm shrinkwrap" once, just once per project?

I don't know what kind of projects you work on, but new dependencies get added with some regularity on any large node project, requiring a shrink-wrap every time.

If you've never experienced the forgetting-to-shrinkwrap problem and its interplay with team dynamics, then I envy you. But I also must give up trying to explain to you, since this drives to the heart of the problem and I must conclude that we simply do not have enough common experiences for you to ever understand. The developers of Yarn et al clearly have lived this nightmare.

> Do you mean in the past

Where the past was > This is an all too common attitude in the JavaScript community.

An equally big problem in the JavaScript community is that core pieces of infrastructure have been "claimed" by people who have absolutely no idea what they are doing, but are happy to community-coordinate their way to some kind of idealistic open source victory.

> weren't co-operative

Again, I don't care if they were willing to co-operate. I have zero confidence in them.

> I'd rather humanity not waste the man-hours duplicating effort.

Give up on this dream. People are going to re-invent everything from now until the end-of-time, and rightly so.

Re: Yarn – A new package manager for JavaScript

#402

Post by Benjamin_Dobell »

brandonbloom wrote: post #401
Benjamin_Dobell wrote: post #396

Earlier quoted context omitted.

> The first and foremost: Version pinning should be the only way it works. Obviously _requiring_ shrink-wrap would be a breaking change. > Having to explicitly call shrink-wrap is just silly. Devs on every time I've used shrink-wrap with frequently forget to do it and it causes all sorts of "works for me" problems later. Really? An entirely new tool because you didn't like typing "npm shrinkwrap" once, just once per…

> An entirely new tool because you didn't like typing "npm shrinkwrap" once, just once per project? I don't know what kind of projects you work on, but new dependencies get added with some regularity on any large node project, requiring a shrink-wrap every time. If you've never experienced the forgetting-to-shrinkwrap problem and its interplay with team dynamics, then I envy you. But I also must give up trying to exp…

Clearly you haven't been using the default settings in the latest version of NPM ;)

I can only hope the Yarn developers knew about the changes, and had a real justification for their work.

Again, I'm not saying the Yarn developers didn't have justification, I just haven't seen any yet. Love to be shown otherwise.

Re: Yarn – A new package manager for JavaScript

#404

Post by k3n »

jlongster wrote: post #191
emerongi wrote: post #96

Earlier quoted context omitted.

> Yarn pulls packages from registry.yarnpkg.com, which allows them to run experiments with the Yarn client. This is a proxy that pulls packages from the official npm registry, much like npmjs.cf.[0] Time will tell whether they only want to be proxying NPM or will allow direct pushing to their own registry. If they do, JS ecosystem might see another big shift. [0] http://blog.npmjs.org/post/151660845210/hello-yarn

That big shift will have to happen first. I don't see them ever making their own registry unless 99.99% of people are using yarn and are having a lot of problems with the current npm registry. While I see a lot of people using yarn, I'm not sure about 99.99% and I think npm's registry itself is pretty good. So I don't think interests will ever align to create a new registry. Nobody wants to do that. That would have s…

> So I don't think interests will ever align to create a new registry.

Possibly not soon, at least from a technical perspective, but I could definitely see a PR fiasco (security, bias, etc.) causing a loss of confidence in its stewardship.

And I don't think it'd be that big of a disruption if it were to happen; for the hypothetical case of Facebook+Yarn, they're already proxying to NPM, so they could easily continue to do so while also accepting packages that are Yarn-only.

Re: Yarn – A new package manager for JavaScript

#405

Post by theanswerer »

substack wrote: post #229

One of the features for yarn mentioned is better offline support, but you can also do this with vanilla npm: npm install --cache-min Infinity I have this aliased to `npmi` on my system and use it all the time.

For unknown reasons it will still try to contact the npm servers once in a hundred runs even though none of the package versions changed.

Re: Yarn – A new package manager for JavaScript

#407

Post by neandrake »

gakada wrote: post #300
prodigal_erik wrote: post #287

Earlier quoted context omitted.

I'm arguing for choosing dependency versions that don't require you to break the highlander rule. "a is updated to 2.0" doesn't mean you should start using that version of a right now.

Right but what I'm saying is that two versions of the same library will live quite happily together, because node.js absolutely abhors global scope. The two versions have their own module-level scope to store functions and data. So go crazy and install every version of lodash! Nothing will break.

I'm not a large JS developer but with my other experiences managing dependencies, it doesn't always allow this as a possibility. A bug in your system is tracked down to the library b using x@1.0 but the fix is to upgrade to b with x@2.0 however a using x@1.0 doesn't have an upgrade path. Waiting for another company or organization to release with an update is not an option. Our projects have several cases of requiring different versions of the same library -- we try to avoid this using the same logic you suggest but it's not a possibility in all cases so we have to work with it.

It's placing your own release cycle at the whims of your dependencies' release cycles. In the corporate world that would not be a viable solution.

Re: Yarn – A new package manager for JavaScript

#408

Post by mvindahl »

_ea1k wrote: post #258
rubber_duck wrote: post #148

Earlier quoted context omitted.

The fun of kicking off a CI build after the weekend with no commits and see stuff randomly break because some dependency of a dependency got updated and broke things in a minor version is something I've only experienced in JS - beautiful.

In fairness to the language and tools, this seems to be more of a cultural problem than anything. You can do the same kind of version range tricks in typical Java builds, for example (Maven), but most people hardcode the values to keep builds as deterministic as possible. For some reason, the JS community seems to prefer just trusting that new versions won't break anything. Its either very brave of them really (or ma…

But can yarn fix this?

Say that I use yarn to depend upon some module X, specifying a fixed version number like the good boy scout that I am. Module X resides on npmjs and in turn depends upon the bleeding edge version of module Y. And then one day module Y goes all Galaxy Note and bursts into flames.

Can yarn shield my app from that?

Re: Yarn – A new package manager for JavaScript

#409

Post by alessioalex »

deckard1 wrote: post #394
kzahel wrote: post #40

"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.

To make matters worse, each package gets its own node_modules directory. Do a grep for 'async' in your node_modules. Mine contains ~20 instances of it. Some of those, probably, are the exact same version. Going further down shit creek, each project I work on has its own node_modules. Which duplicates all of this crap, ad nauseam. Do I really need React and Babel and jQuery and Webpack installed for every goddamn repo…

> To make matters worse, each package gets its own node_modules directory. Do a grep for 'async' in your node_modules. Mine contains ~20 instances of it. Some of those, probably, are the exact same version.

Upgrade to npm v3, that should these problems.

Re: Yarn – A new package manager for JavaScript

#410

Post by foo101 »

davidascher wrote: post #381
evv wrote: post #249

Earlier 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

Somewhat funny to have an FB employee complaining about overly centralized systems.

I used to find such comments funny until I began working for Big Name Corps myself and I realized how much one's personal philosophy could be inconsistent or sometimes even contradictory to the employer's philosophy. I make money by selling my skills to an employer despite inconsistent philosophies. I think it's like a chef that can cook meat for his/her guests although the chef has decided to refrain from consuming meat himself/herself.
Post reply on HN