Live data from Hacker News

Yarn – A new package manager for JavaScript

code.facebook.com

61–70 of 486 posts

Re: Yarn – A new package manager for JavaScript

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

Cargo does allow multiple versions of transitive dependencies. It tries to unify them as much as possible, but if it can't, it will bring in two different versions.

What it _won't_ let you do is pass a v1.0 type to something that requires a v2.0 type. This will result in a compilation error.

There's been some discussion around increasing Cargo's capacity in this regard (being able to say that a dependency is purely internal vs not), we'll see.

Re: Yarn – A new package manager for JavaScript

#62
Yarn is particularly great for front-end web apps because of its flat installation mode.

ES6 module imports and HTML Imports both require that dependencies are imported by URL. This means that the only reliable way to import another module is by relative URL, like:

    import * as $ from '../jquery/jquery.js';
This requires that packages are installed flat, as siblings. Yarn is going to enable native JS modules and projects like Polymer to use npm instead of Bower. :)

Re: Yarn – A new package manager for JavaScript

#64
Overall looks good, but it's a shame that flat mode is opt-in instead of the default - this is the sane way of doing package management. Would have been nice to flip the options over so you have to explicitly allow multiple versions of the same package - which you could automatically enable if you're converting from npm.

Re: Yarn – A new package manager for JavaScript

#65
post #16

I wrote a post explaining why I'm psyched to be working on it: TLDR: - open, community governance that will support long-term evolution - the technical details get a lot right out of the gate (decent performance, predictability, and security)

Interested to see the emphasis on security, it's definitely something that could use more focus in this area. On that note, are there any plans to implement TUF (https://theupdateframework.github.io/) or similar into Yarn?

Re: Yarn – A new package manager for JavaScript

#66
post #39
post #26

Earlier quoted context omitted.

Have you guys approached the ridiculous folder nesting situation? E.g. breaking out of the current/broken node_modules structure?

There has been no problems with folder nesting in `npm` in general since the version@3 came out over a year ago.

This isn't true though.

npm chooses the first version of a package it encounters to install at the top level. Every other version is installed nested. If you have N uses of version A and one use of version B, but version B is installed first, then you get N copies of the package at version A.

Re: Yarn – A new package manager for JavaScript

#67
post #56
post #41

Yarn is currently being powered by a service running at https://registry.yarnpkg.com - at least that's what's referenced in the yarn.lock file that's created. I see no documentation nor code for the service powering this, nor is there a way to tell the command line tool to use a registry at a different address. Aren't we just replacing the dependency on npm, Inc.'s registry with a new dependency on Facebook Inc's reg…

that registry is a mirror of npm's registry. the mirror contains all package data but does not include any of the permissions or user management, so this tool still depends on npm infra for both that, and as a replication source.

registry.yarnpkg.com is a proxy, it doesn't contain any package data except for what gets cached by Cloudflare. Just a Cloudflare'd "CNAME registry.yarnpkg.com. registry.npmjs.org."

Re: Yarn – A new package manager for JavaScript

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

Re: Yarn – A new package manager for JavaScript

#69
post #39
post #26

Earlier quoted context omitted.

Have you guys approached the ridiculous folder nesting situation? E.g. breaking out of the current/broken node_modules structure?

There has been no problems with folder nesting in `npm` in general since the version@3 came out over a year ago.

It's improved but it's not fixed. if a depends on c 1.0 and b depend on c 2.0, both versions of c need to be installed and one of them will be nested.

Re: Yarn – A new package manager for JavaScript

#70
post #39

Earlier quoted context omitted.

There has been no problems with folder nesting in `npm` in general since the version@3 came out over a year ago.

(other than its non-determinism)

And Yarn it deterministic! :party_parrot:
Post reply on HN