Yarn – A new package manager for JavaScript • Hacker News Board

Re: Yarn – A new package manager for JavaScript

#161

Post by pcsanwald » Tue, Oct 11, 2016, 5:19 PM UTC

rubber_duck wrote: post #148

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…

The fun of kicking off a CI build after the weekend with no commits and see stuff randomly break because some dependency of a dependency got updated and broke things in a minor version is something I've only experienced in JS - beautiful.

I agree 100%, but the default upgrade strategy for npm --install does not help matters: it's much saner to wildcard patch versions only and lock major.minor to specific versions.

this obviously doesn't fix anything and I think the points in this discussion stand, but I've never understood why the defaults are not more conservative in this regard.

Re: Yarn – A new package manager for JavaScript

#162

Post by jameside » Tue, Oct 11, 2016, 5:20 PM UTC

mvdanj wrote: post #126

wycats wrote: 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 say "decent performance" and "predictability". What is the basis of this claim? I've heard these all before, but unless you've actually shipped a product using this tool I don't know how you can back this up.

As for performance, Yarn is about 3-5x faster installing all of the dependencies and devDependencies of react-native. The benchmarks are here: https://yarnpkg.com/en/compare. It's much faster in most scenarios, especially the ones that used to take minutes.

Re: Yarn – A new package manager for JavaScript

#163

Post by MatthewPhillips » Tue, Oct 11, 2016, 5:21 PM UTC

spankalee wrote: post #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 proje…

This is what I was most curious about, but it looks like --flat is a cli option but not the default. Definitely moving in the right direction though!

Re: Yarn – A new package manager for JavaScript

#164

Post by 33degrees » Tue, Oct 11, 2016, 5:22 PM UTC

tomdale wrote: post #137

33degrees wrote: post #110

Earlier quoted context omitted.

> I loved Bundler's deterministic builds but chafed against the Ruby limitation of only having a single version of a dependency at once This is due to the way that Ruby includes code, where it's available globally, vs Node where code is scoped to the including module. I'm not sure how Ruby could support multiple versions with changes to the language and/or RubyGems

Yes, that's why I said it was a Ruby limitation, not a Bundler limitation.

Right, my comment wasn't neccesarily directed at you, but to others who might not be familiar with both

Re: Yarn – A new package manager for JavaScript

#165

Post by ateevchopra » Tue, Oct 11, 2016, 5:22 PM UTC

swang wrote: post #35

wow already one of the features i'm loving in yarn is that it tells you which package is firing warnings about package incompatability. warning electron-prebuilt-compile > electron-compilers > jade@1.11.0: Jade has been renamed to pug, please install the latest version of pug instead of jade in npm, that would have just said the part after "jade@1.11.0" which was really vague and didn't really make you want to "fix"…

Just experienced the same. Loved it! npm was giving vague errors about dependency's dependency. Now it's so much clearer that which package needs to be updated. Also the speed of installation has reduced a lot !

Re: Yarn – A new package manager for JavaScript

#166

Post by Touche » Tue, Oct 11, 2016, 5:23 PM UTC

epmatsw wrote: post #17

This looks awesome. But I have to wonder why create a whole new project rather than fork or upstream these changes to NPM? It doesn't seem like it's doing anything fundamentally different or outside of NPM's scope of responsibility.

Go take a look at npm's code and then tell me you'd want to contribute to that.

Re: Yarn – A new package manager for JavaScript

#167

Post by BinaryIdiot » Tue, Oct 11, 2016, 5:23 PM UTC

jrs235 wrote: post #78

Here is npm's response: http://blog.npmjs.org/post/151660845210/hello-yarn

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 to no users. Yeah that's probably unlikely for the immediate future but Yarn is positioned perfectly to siphon off npm's users very painlessly.

Re: Yarn – A new package manager for JavaScript

#168

Post by bcherny » Tue, Oct 11, 2016, 5:25 PM UTC

I use JS+Node+NPM for my day job and many side projects.

Initial thoughts:

- Why didn't Facebook contribute the updates to NPM directly?

- They are coupling a package manager and registry proxy; the latter has many existing implementations already

- The differenced between Yarn and NPM+Shrinkwrap do not seem substantive; NPM made the design decision to use a sometimes non-deterministic install algo in NPM3 to speed up install times - when network is involved, there is a serious trade off between idempotency and speed

In general, FB seems to love building their own versions of existing tools:

- Flow, introduced 3 months after TypeScript

- Nuclide instead of Atom/Sublime/VSCode

- Jest instead of Jasmine/Mocha

- DraftJS instead of (insert of of the existing 100 text editors here)

- ...

I get that these are useful internally at FB, but I don't think they help the community much. It would be better to work with existing tools and contribute back to them than to reinvent the wheel every time something doesn't work perfectly for their use case.

I get that FB uses these as recruiting tools, it's useful for them to have rights for these projects, and it gives their engineers something to do and be excited about, but I do not want a whole dev tool ecosystem controlled by big FB.

Also, I find IED's approach to speeding up builds far more novel and interesting - https://github.com/alexanderGugel/ied

Re: Yarn – A new package manager for JavaScript

#169

Post by steveklabnik » Tue, Oct 11, 2016, 5:25 PM UTC

markus2012 wrote: post #157

rubber_duck wrote: post #148

Earlier quoted context omitted.

The fun of kicking off a CI build after the weekend with no commits and see stuff randomly break because some dependency of a dependency got updated and broke things in a minor version is something I've only experienced in JS - beautiful.

Well, now you can do that in Cargo as well :-) What we do currently is we lock everything to an explicit version - even libraries. At least it's possible to get deterministic builds if you are willing to do a bit of work carefully / manually updating all of your dependencies at once.

You shouldn't have that happen with Cargo, given that we have a lockfile. Even when you specify version ranges, you're locked to a single, specific version.

Re: Yarn – A new package manager for JavaScript

#170

Post by kin » Tue, Oct 11, 2016, 5:26 PM UTC

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…

Javascript in my opinion is still very young. You can't compile it to web assembly (yet) and the fact that there are different browsers that interpret it in so many different ways make for libraries to exist to mitigate this. Also none of these tools are 100% necessary, they just make your life easier and tools always have room for improvement. I'm sure others can add to this. I don't think any of this is a bad thing, it's just overwhelming for newcomers that haven't been following this whole thing.