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

341–350 of 486 posts

Re: Yarn – A new package manager for JavaScript

#341

Post by sotojuan »

nmgsd wrote: post #240
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…

A lot of these answers are pointing out the x-browser complexity which is true but that isn't what drives JS package mgmt. It's mostly Node stuff. The mature common JS libs for browser work are pretty robust when it comes to x-browser stuff now days. For browser work, you can do almost everything you need with some jQuery, handlebars and moment if there are dates. A few other small libs here and there and you've got…

That's interesting because I have less JS headaches when using Node. I avoid front end JS these days

Re: Yarn – A new package manager for JavaScript

#342

Post by steveklabnik »

mvdanj wrote: post #333
steveklabnik wrote: post #144

Earlier quoted context omitted.

> unless you've actually shipped a product using this tool Given that wycats _worked on_ this tool, I would assume it's his experience helping build it that's the basis of the claim. (I don't work at Tilde so I can't tell you if it's been shipping with yarn, but it would shock me if it wasn't.)

Ok, didn't realize he worked on it. Bundler is great so that gives me some hope for Yarn. But in general I think its more stable in the long-term for projects to use open standards instead of vendor solutions for browser package management.

I can understand this sentiment in general, but don't think it applies here. npm is also a private company, and this does work with their registry. There currently isn't a vendor-neutral standard to follow.

Re: Yarn – A new package manager for JavaScript

#343

Post by k__ »

cygned wrote: post #154
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…

Mhm that sounds reasonable. I haven't gotten into problems with versions yet but I don't really trust npm update, because I am not always sure how it behaves. From a build tool perspective (we use npm scripts for basically everything [and some webpack]) I am also not missing something particular. Looking at other comparable solutions (from other languages) I'd say npm does a pretty good job.

sure, it's better than pip or something.

but it still far from perfect.

Re: Yarn – A new package manager for JavaScript

#344

Post by jay_kyburz »

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…

Yeah, but we could have a big, standard library polyfill, and it would quickly find its way into everybody cache, just like jQuery.

Re: Yarn – A new package manager for JavaScript

#345

Post by spion »

fryguy wrote: post #317
spion wrote: post #291

Earlier quoted context omitted.

The problem does happen in JavaScript. But since its unityped, there is a strategy to deal with it * Figure out early on (before 1.0) what your base interface will be. For example, for a promise library, that would be `then` as specified by Promises/A+ * Check if the argument is an instance of the exact same version. This works well enough if you use `instanceof`, since classes defined in a different copy of the modu…

Would this even work in what I describe? For instance, if mat.normalize() was added in LA-6, and B provides an LA-5 mat, and then A (which has been updated to use the new method) calls mat.normalize() on the LA-5 mat expecting an LA-6 mat but because of duck-typing that method doesn't exist.

It would not.

However, since A exposes outside methods that take a matrix as an argument, it should not assume anything beyond the core interface and should use LA-6's cast() to convert the matrix.

The problem is partially alleviated when using TypeScript. In that case the inferred type for A demands a structure containing the `normalize` method, which TypeScript will report as incompatible with the passed LA-5 matrix (at compile time). That makes it clearer that `cast` would need to be used.

Re: Yarn – A new package manager for JavaScript

#346

Post by secoif »

zamalek wrote: post #338
secoif wrote: post #335

Earlier quoted context omitted.

what you described is npm@2's behaviour. npm@3 will flatten dependencies as much as possible

How does it flatten dependencies? Symlinks?

no, it just installs everything it can into the top level node_modules. npm@2 would do this to a degree as well, it was just less sophisticated about it.

Re: Yarn – A new package manager for JavaScript

#347

Post by secoif »

sotojuan wrote: post #175
BinaryIdiot wrote: post #167

Earlier quoted context omitted.

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?

technical debt and not wanting to break people's workflows

Re: Yarn – A new package manager for JavaScript

#348

Post by miralabs »

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 main problem with npm is just when its used internally. It is painful really. Using it when you have internet connection is just seamless

Re: Yarn – A new package manager for JavaScript

#349

Post by pcsanwald »

l1ambda wrote: post #330
tigershark wrote: post #325

Earlier quoted context omitted.

Why is that? In the Java ecosystem there is Spock framework that gives you everything required for testing, you don't even need junit+mockito. In which scenario would be better to use 11 different libraries for doing the same thing as a well written framework?

In this case, I would argue it is not better. Many JS devs have moved onto simpler, greener pastures. https://github.com/substack/tape is what I prefer. Small little library. Its API has everything I need and nothing I don't. Those other test libraries listed are pretty much overkill. Similar with http://mithril.js.org/ over React, Angular and Ember. A single drop-in library with 13 functions in it's API. The library…

But, this is exactly what I'm saying. you start with a small, focused library that contains everything you need, which is usually fairly minimal, so that library is small. but then, along the way, you find yourself wanting, so you add a library that adds support for that specific thing.

I didn't add sinon-as-promised for fun, I added it for in-memory sequelize integration tests. same for all the other libraries I mentioned.

My point is that by keeping libraries small, you will end up with either more dependencies, or a lot more hand-rolled code. Neither of these things are inherently bad or good, and I'm not defending them. What I am trying to do is explain to the commenter why the node ecosystem seems to have such an emphasis on package management and the tooling around that.

Re: Yarn – A new package manager for JavaScript

#350

Post by kcorbitt »

prodigal_erik wrote: post #318
gakada wrote: post #300

Earlier quoted context omitted.

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.

It's almost certain that a's version of x and b's version of x have distinct types whose names collide, and I don't know of any Typescript or Flow notation to prevent passing incompatible instances between them (e.g., a wants to call a method that didn't exist in b's version of x), so if anything works it's only by luck. Edit: I haven't dug into this, but it might be possible to use Typescript namespaces to distingui…

Node's module system doesn't import dependencies into a global namespace. So the `x` required by `a` and the `x` required by `b` will have separate namespaces and won't conflict, or even know of each others' existence. There are pros and cons to this approach, but it definitely does work. Flow, at least, (and presumably Typescript) understands the module resolution logic and handles this very common situation without issue.
Post reply on HN