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

171–180 of 486 posts

Re: Yarn – A new package manager for JavaScript

#171

Post by pags »

rubber_duck wrote: post #148
k__ wrote: post #93

Earlier quoted context omitted.

The whole version range stuff got me many times. I went to use fixed versions on my own package.json files, but the deps of my deps could still be dynamic, which is even worse, since they sit deeper in my dependency graph AND there are more indirect deps than direct deps. (~50 direct, >200 indirect) Also, npm isn't deterministic and it got even worse with v3. Sometimes you get a flat list of libs, if a lib is used wi…

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.

npm shrinkwrap

Re: Yarn – A new package manager for JavaScript

#172

Post by lukeschlather »

mschuster91 wrote: post #158
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.

> 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. This is in no way a fault of node.js but of the whole JS standard. People these days use npm modules to run in a browser and ship stuff bundled together with webpack (or other bundlers), so even if nodejs had a proper stdlib, you'd…

That's kind of a red herring when it comes to NodeJS. Webpack and the 50 other tools you need to run it are in a completely controlled environment. Most of the build tooling is working around issues with NodeJS, and NodeJS doesn't need to wait for anyone to come up with improved APIs around filesystem interactions and build tooling. This is purely build-time stuff.

Re: Yarn – A new package manager for JavaScript

#173

Post by Klathmon »

mambodog wrote: post #153
bandrami wrote: post #131

This may come off as a troll, but it's an honest question. I'm not a javascript guy. It's not a language I deal with at all. Why on God's green earth does it need as much tooling as it seems to have? Are people really making projects with dozens (hundreds? more?) of dependent libraries? Are there aspects of the language or runtime that reward multiple layers of configuration management? In short, what the hell is up…

Basically I think it comes down to: 1. In the browser we have less control over the environment the code runs in, requiring tooling to achieve a stable, normalised environment which we can improve at our own pace, rather than the rate at which browsers are updated. 2. JS has become very widely used very quickly, which means that there have been lots of hastily built things, which have been replaced by better things (…

Your number 3 is the one that really drives it home for me. It's the unix philosophy taken to the extreme, and (at least in my experience) it's working very well.

It does take some getting used to, but when you stop looking for one big tool that can solve 5 semi-related problems, and start looking for 5 little tools that each solve one of the problems, things get much more clear.

And yes, I know that this kind of reliance on dependencies can cause issues, but from my experience, those issues don't seem to bite that often, and many of them can be resolved with even more tooling.

Re: Yarn – A new package manager for JavaScript

#174

Post by _greim_ »

lucian1900 wrote: post #48
tomdale wrote: post #22

This 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…

Multiple versions may sound like it's useful, but it's almost always a bad idea. Cargo doesn't allow it either. The problem isn't really fundamental. Bundler makes almost all the right choices already. Its major disadvantage is that it only works for Ruby.

> Multiple versions [...] almost always a bad idea

If so, different major versions of the same dep should be considered different libraries, for the sake of flattening. Consider lodash for example.

Re: Yarn – A new package manager for JavaScript

#175

Post by sotojuan »

BinaryIdiot wrote: post #167
jrs235 wrote: post #78

Here is npm's response: http://blog.npmjs.org/post/151660845210/hello-yarn

I'm glad they're okay with it but then again what else would they post? npm has some major, major issues with it and it has barely moved in years . This Yarn looks like it solves quite a few issues with npm and it took another company to build it. That's insane. It wouldn't surprise me if yarn becomes popular and its proxy to npm slowly turns off and boom, everyone would be migrated and npm would be left with little…

Does anyone know why npm moves so slowly?

Re: Yarn – A new package manager for JavaScript

#176

Post by Vinnl »

Kiro wrote: post #132

So, as a casual user of node... Should I switch? I don't see any immediate benefits.

Depends on how casual :P But probably not.

(Edit: Note: I mean you don't _have_ to. You might like the performance increase, but if you only use it casually, even that might not be worth the trouble.)

Re: Yarn – A new package manager for JavaScript

#177

Post by STRML »

This is a really big deal. We have a very large/complex web application & API with a large number of dependencies, and not a single npm alternative (pnpm, ied, npm-install) could figure out the tree properly.

It has been working well with our npm proxy and is basically a faster, better-deduped drop-in replacement that removes our need for npm-cache, npm-check-updates, and all of our shrinkwrap hacks.

This is finally the npm rewrite we've been waiting for.

In looking at the yarn repository, it's nice to see a clean, modern build, ES6 + async/await, Flow typing, and so on. This is what a well-maintained JS project looks like in 2016 that's built for production use.

npm, for all its flaws, was a revolution when it was first written. But since then, it has been large, unruly, difficult to maintain, and has largely unaddressed many important production use cases. It is nice to see a group of companies using Node in production take the lead on addressing problems that really matter to production JS apps.

Re: Yarn – A new package manager for JavaScript

#178

Post by pluma »

ag_dubs wrote: post #125
pluma wrote: post #114

Earlier quoted context omitted.

Because the npm client is a hot mess? The official npm cli is quite old and evolved along with all the different coding styles and architecture choices of the node and JS ecosystems. It's also full of dependencies on originally purpose-built modules that suffer from the same problems. This compounds various issues, resulting in long-standing bugs like `npm publish` sometimes not actually including all files in the ta…

a few points! fwiw, only 2 of those humans work on the CLI, (3 if you count their manager, who spends a lot of time managing). other people work in sales, marketing, engineering on the website, engineering the registry, community + docs, etc. wombat is not a tool for managing our other commercial services! it's a way to manage our webhooks product, one of many products we have, though very certainly the smallest. yar…

> only 2 of those humans work on the CLI

Thanks for clarifying. But that does show that having a company fund two full-time developers to work on the CLI wouldn't have been sufficient. Yarn was mostly built by Seb (403 commits) starting in late January and Konstantin Raev (121 commits) with contributions from several others (This most likely includes collaboration with the other people supporting the project (both Seb and Konstantin work for FB) and a lot of architectural planning -- aspects, which likely would have required an even greater investment of time if building on the legacy codebase of the official npm client (not to mention having to negotiate all changes with npm Inc directly).

> wombat is not a tool for managing our other commercial services!

Sorry about the misunderstanding. When wombat came out a lot of people wondered why wombat was a standalone tool when practically every other aspect is part of the npm cli and from what I gathered from npm devs at the time the decision was more of a technical one (different people working on different tools for different things) than a managerial one (different products deserving different tools).

> yarn depends on the npm registry, which depends on npm, Inc making money to keep it running.

Yarn currently uses a downstream mirror of npm as the direct source of truth, with support for private registries being actively worked on to support the private parts of the npm registry and products like npm enterprise or free alternatives like sinopia.

However that is obviously an implementation detail. Decoupling yarn from the npm registry by going through an intermediary allows experimentation (as the npm blog post points out) and ultimately allows avoiding a hard dependency on npm Inc as a company.

If npm Inc were to shut down right now, yarn would still have a read-only mirror. I'm sure Facebook and Google have enough experience solving problems at scale that they could build a public registry alternative if necessary (such as if npm Inc went out of business tomorrow).

I'm not saying yarn will kill npm Inc. But yarn can kill the npm client and replace it with a community-supported alternative (under an open governance model similar to Ember), which in turn makes it a lot easier to fade out the reliance on the public npm registry maintained by npm Inc -- benefiting both the community (by eliminating a single point of commercial failure in the node ecosystem -- exactly like joyent was to the node project) as well as npm Inc (by eliminating a major drag on development resources and cost center).

The only drawback from such a move to npm Inc would be the loss of its privileged position in the ecosystem, the "first mover" advantage of being the place to go if you want private packages (because it's more frictionless than any of the alternatives -- exactly like GitHub in the git hosting space).

[0]: https://github.com/yarnpkg/yarn/graphs/contributors

Re: Yarn – A new package manager for JavaScript

#179

Post by jcheng »

rubber_duck wrote: post #148
k__ wrote: post #93

Earlier quoted context omitted.

The whole version range stuff got me many times. I went to use fixed versions on my own package.json files, but the deps of my deps could still be dynamic, which is even worse, since they sit deeper in my dependency graph AND there are more indirect deps than direct deps. (~50 direct, >200 indirect) Also, npm isn't deterministic and it got even worse with v3. Sometimes you get a flat list of libs, if a lib is used wi…

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.

With or without npm-shrinkwrap.json? Not chastising, I'm sincerely asking.

Re: Yarn – A new package manager for JavaScript

#180

Post by hswolff »

This is super exciting! Really excited to try this out and glad to see innovation in this area.

I'm also bummed cuz I've been working on a static site generator for over a year written in node called Yarn as well[1].

I guess it's time for a rename! Any suggestions? :D

[1] https://github.com/yarnjs/yarn

Post reply on HN