Live data from Hacker News

Yarn – A new package manager for JavaScript

code.facebook.com

291–300 of 486 posts

Re: Yarn – A new package manager for JavaScript

#291
post #282

Earlier quoted context omitted.

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

That can cause some serious problems in at least some portion of times. I've dealt with the subtle errors that have been caused by this problem in c++, and don't really know javascript libraries that well so I can't give a more concrete example. But imagine that there are the following libraries: * LA: handles linear algebra and defines a matrix object. * A: reads in a csv file and generates a matrix object using LA…

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 module will have their own class value - a different unique object.

  * If instanceof returns true, use the fast path code (no conversion)
  * Otherwise, perform a conversion (e.g. "thenable" assimilation) that
    only relies on the base interface
Its not easy, but its not always necessary either. Most JS libraries don't need to interoperate with objects from previous versions of themselves.

Re: Yarn – A new package manager for JavaScript

#292
It appears that yarn.lock resolves exactly one hash version of a package for one semvar version of it. What happens when your project depends on packages A and B, which both depend on the same semvar version, but due to manipulation by the author, rely on different hash versions?

Re: Yarn – A new package manager for JavaScript

#293

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

Oh that sucks..How about "yarnish"? It's available on npm, sticks to your roots, and you can play on varnish if you like. Or you can always go the thesaurus route and use fleece, wool, cotton fiber, flaxen thread...

Re: Yarn – A new package manager for JavaScript

#294

I get NPM for backend development but I don't understand why frontend developers require NodeJS just to utilize it's package management. It really does not make any sense to me considering that NodeJS is server side javascript. If my backend is Python or Go or .NET or Java or whatever, now I'll need NodeJS for the frontend and only for NPM (and now this). It's a reason why I don't enjoy dealing with "modern" frontend…

Is requiring Node really that bad? I don't write Bash or Ruby or Python or Go, but I have them all installed because various tools need them.

Re: Yarn – A new package manager for JavaScript

#295

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?

Because they focused on hiring SJW profiles that write codes of conducts and readme's all day long instead of actually software engineers that could improve the tool.

Re: Yarn – A new package manager for JavaScript

#296

I get NPM for backend development but I don't understand why frontend developers require NodeJS just to utilize it's package management. It really does not make any sense to me considering that NodeJS is server side javascript. If my backend is Python or Go or .NET or Java or whatever, now I'll need NodeJS for the frontend and only for NPM (and now this). It's a reason why I don't enjoy dealing with "modern" frontend…

Is requiring Node really that bad? I don't write Bash or Ruby or Python or Go, but I have them all installed because various tools need them.

It doesn't make sense to require a backend tool for frontend technologies. That's just me though. So that's why I'm asking. Couldn't they just create a package system that's not based on some backend tech?

Re: Yarn – A new package manager for JavaScript

#297

Earlier quoted context omitted.

Just imagine two packages you depend on (a and b) that both have a shared dependency (x). Both start off depending on x version 1.0 but then later a is updated to 2.0 while b isn't. Now you have two packages depending on different versions of the same package and hence the need for duplication. You have a that needs x@2.0 and b that needs x@1.0, so both copies are kept.

Don't upgrade a when it wants a half-baked x. Choose versions of a and b that agree on a known-good version of x. If there aren't any, it's not sane to use a and b together unless x is written very carefully to accommodate data from past and future versions of itself.

It's not as simple as that. Lodash is a great example of why the highlander rule doesn't work within the npm ecosystem: older versions are depended on by many widely-used packages which are now "complete" or abandoned. Refusing to use any packages which depend on the latest version of Lodash is just not practical.

Re: Yarn – A new package manager for JavaScript

#298
post #249

Earlier quoted context omitted.

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…

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

Have a read here: https://github.com/nodejs/NG/issues/29#issuecomment-17431452... - it's a writeup that I made a while ago about the requirements for a stable (decentralized) package registry, and it addresses your question as well.

Re: Yarn – A new package manager for JavaScript

#299

so, where are the packages stored? how is this more secure than npm? how does this solve the leftpad problem?

Lock file contains hashes of packages, so it works like many "trust on first use" systems (e.g. SSH): if you installed leftpad@0.2.3, you can be sure that futher installations of this same package will be exactly the same — if malicious npm server gives you something else, this should be detected and rejected.

Looks like they use SHA-1 hashes, though. Please, let's get rid of SHA-1 already.

Re: Yarn – A new package manager for JavaScript

#300
post #281

Earlier quoted context omitted.

That's not how it works. There will be two copies of x in the require cache. They don't know of each other's existence.

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.

Post reply on HN