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

91–100 of 486 posts

Re: Yarn – A new package manager for JavaScript

#91

Post by epmatsw »

koolba wrote: post #86

> Finally, updating a single dependency with npm also updates many unrelated ones based on semantic versioning rules. This makes every change much larger than anticipated, and having to do things like committing node_modules or uploading it to a CDN made the process less than ideal for engineers. You shouldn't check in node_modules. You should use a shrinkwrap file to indicating the specific sub-dependency versions y…

They address pretty throroughly why that does not work for them in the linked article.

Re: Yarn – A new package manager for JavaScript

#92

Post by sotojuan »

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.

90% of those files are probably Babel-related.

Re: Yarn – A new package manager for JavaScript

#93

Post by k__ »

cygned wrote: post #83
k__ wrote: post #27

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

Would you mind going a bit into detail? I work with npm on a daily basis and I am pretty happy so far.

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 with multiple versions, the first usage will get installed flat, the rest in the directory of the parent lib, etc.

The npm-cli is basically a mess :\

Re: Yarn – A new package manager for JavaScript

#94

Post by andreygrehov »

thejameskyle wrote: post #74
andreygrehov wrote: post #68

I just tried to install yarn and ran it to against a relatively large React application. What's interesting is that it found an incompatible module and could not proceed, whilst npm works fine. The article states that running `yarn` is the same as `npm install`, which doesn't look like the case. At that point, I'm curious what are the differences.

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.

Re: Yarn – A new package manager for JavaScript

#95

Post by epmatsw »

currywurst wrote: post #44

I wish some kind of "auto-bundle" feature prevented the creation of multiple hundred MB's worth of tests, readmes and docs on disk when something like single "babel.bundle.js" file would do. Is it really important that one knows that a tool dependency uses left-pad ? What could be the drawbacks of such bundling?

In theory, those submodules should be npmignoring those files and subdirectories, right?

Re: Yarn – A new package manager for JavaScript

#96

Post by emerongi »

pfraze wrote: post #82
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…

> This also highlights a shrewd move on the part of npm: a clear decoupling between the npm registry and client, with a well-defined protocol between the two. The strength of Node is in the staggering size of its ecosystem; how those bits end up on disk is an implementation detail. This smart separation allows for this kind of experimentation on the client side, without causing the ecosystem fragmentation that happen…

> 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

Re: Yarn – A new package manager for JavaScript

#97

Post by tolmasky »

My initial tests with this are very positive (I tried this use case here: https://github.com/npm/npm/issues/10999 ). It handled it quite well and we'll definitely be considering this for our package.

I'm curious about the "flattening" approach though -- and why something like ied ( https://github.com/alexanderGugel/ied ) wasn't done instead. ied only ever installs one copy of a module, but allows each module to think they have their own copy of it through clever symlinkery (essentially making it FEEL like npm 2 while getting the benefits of npm3/yarn). I'm not a fan of (explicit) flattening for a number of reasons:

1. Mimicking recursive dependencies while still only having on physical copy on disk has the benefit (or downside I suppose) of isolating and protecting different module's dependencies from each other. AKA, if you require("x").mutate = true, this won't be seen by other modules. Again, depends whether you like this feature or not, but with node's treat-symlinks-as-different-files configurable switch, you can actually control it yourself in ied I believe.

2. You don't run into tricky situations where require("x") can accidentally pick something up you didn't mean to (since it is now in the parent path of ALL your dependencies). So, if A depends on x, and you install B, it will be able to require("x") (maliciously?) and modify it, affecting A's behavior. Perhaps this is considered a strange possibility, but it gets particularly weird with peer dependencies, where you expect the user to choose their own top level dependency, but this can now be accidentally "chosen for you" by a subdependency of another package.

3. I just don't like clicking on my node modules folder and seeing 100 top level directories when conceptually I typed "pkg-manager install one-thing". This can lead to you yourself making the above mistake, by require("x") and having it "just" work, then having it "just break" when you remove the dependency that included x.

I'm willing to be convinced though (on RunKit we had module-fs simulate npm2 install behavior, super simple recursive installation, conceptually similar to what ied does).

Re: Yarn – A new package manager for JavaScript

#98

Post by fold_left »

Brilliant. I've been trying to tackle this problem for the last year or so with shrinkpack (https://github.com/JamieMason/shrinkpack) with _some_ degree of success and a nagging feeling that much more could be done.

It's great to see attention is being spent on what is a really important area, one which has been largely under-appreciated in Node.js until now (aside from for a short period after the left-pad incident).

Kudos to Facebook, I look forward to giving it a try.

Post reply on HN