Live data from Hacker News

Yarn – A new package manager for JavaScript

code.facebook.com

41–50 of 486 posts

Re: Yarn – A new package manager for JavaScript

#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 registry with this?

Yes. The client has a few advantages, but the registry is still closed and while with npm there's an option of running a private registry if you pay them, here, there's no option at all.

Re: Yarn – A new package manager for JavaScript

#42

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

I think it's more secure because you can deliver to it ("somehow") a global cache of packages.

For e.g. Facebook, I bet they have some online filesystem like NFS or similar, that hosts the global yarn cache for their continuous integration system. This way, their CI system doesn't call out to the cloud for every build.

Re: Yarn – A new package manager for JavaScript

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

Re: Yarn – A new package manager for JavaScript

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

(other than its non-determinism)

Re: Yarn – A new package manager for JavaScript

#46
post #31

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

leftpad was a social issue. It's been solved by policy on the registry side stopping packages depended on by many others being unpublished.

actualyl at this point, unless there is a legal request or a serious security issue, we don't allow any unpublishes. we encourage transferring the package to the npm user and deprecating it. yay immutable registry!

Re: Yarn – A new package manager for JavaScript

#47
post #19

Earlier quoted context omitted.

This is something I really want to explore more through less-compatible modes. It was the original way yarn worked, but it wasn't compatible enough to be the default mode: https://github.com/yarnpkg/yarn/issues/57

Hmm.. is it still available as a configuration option somewhere? I couldn't find it on the site. I'm a huge fan of bundler - it's dependency heaven. I'm also a big fan of the rubygems repo. It does not allow changes in released versions. Even without symlinks it's a much needed improvement in the javascript ecosystem

This is something I hope to work on over the next few months. It's a priority for Ember :)

Re: Yarn – A new package manager for JavaScript

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

Re: Yarn – A new package manager for JavaScript

#49
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)

You forgot the link. :) http://yehudakatz.com/2016/10/11/im-excited-to-work-on-yarn-...

Yikes, thanks!

Re: Yarn – A new package manager for JavaScript

#50
post #20

It looks like this addresses the biggest issues people have with npm's CLI, and it's coming from such huge names: Facebook, Google, and Tilde. Reproducible builds are a _huge_ issue, and this gives you that. Looks great! One interesting little tidbit I found from diving into the source: https://github.com/yarnpkg/yarn/blob/master/src/constants.js#L15 https://github.com/yarnpkg/yarn/blob/master/src/registries/yarn-reg…

It's not the first one addressing these problems. Nix and ied (which borrowed from Nix) got these problems pretty much solved. I don't understand what spoke against these approaches? I mean okay, nix has its own language, which is probably a turnoff for JS devs, but ied?

ied didn't work on windows because of the linking strategy. many people who need to use npm use windows.
Post reply on HN