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

Re: Yarn – A new package manager for JavaScript

#441

Post by ngrilly » Wed, Oct 12, 2016, 2:48 PM UTC

skevy wrote: post #236

Exponent has been testing out Yarn for about a month, and it's been an incredibly pleasant experience, both in working with the Yarn team and using the tool. Exponent uses a monolithic code repository (rather than many small code repos) to manage our many interdependent projects. Our repo is actually setup very similarly to Facebook's mono-repo, though obviously considerably smaller in size. We were encountering _man…

> [...] the ability to build a distributable offline cache of dependencies. We have a "node_modules-tarballs" folder in our mono-repo that contains tarballs of all the dependencies for every single project that we maintain at Exponent.

That's exactly what we need! How do you tell Yarn to build and use this offline cache?

Re: Yarn – A new package manager for JavaScript

#442

Post by pluma » Wed, Oct 12, 2016, 3:24 PM UTC

flukus wrote: post #354

pluma wrote: post #114

Earlier quoted context omitted.

Because the npm client is a hot mess? The official npm cli is quite old and evolved along with all the different coding styles and architecture choices of the node and JS ecosystems. It's also full of dependencies on originally purpose-built modules that suffer from the same problems. This compounds various issues, resulting in long-standing bugs like `npm publish` sometimes not actually including all files in the ta…

It's not old at all, it's first release was 2010.

The first release of Node.js was in 2009. "Old" is relative.

Nearly all modern JavaScript build tools are built on Node.js and NPM pre-dates most of them.

The only other thing I can think of that has seen as many shifts in JS development practices as NPM is Express (*2009) and that library has far smaller complexity and has arrived at a drastic reduction in features and a far tighter scope.

The NPM client on the other hand was originally cobbled together by Isaac and then grew organically as the NPM registry massively grew over the months and years of node's success.

The NPM client and registry are the epitome of technical debt. Calling it "old" is the most charitable way to phrase this.

Re: Yarn – A new package manager for JavaScript

#443

Post by jbondeson » Wed, Oct 12, 2016, 3:29 PM UTC

cpojer wrote: post #370

bcherny wrote: post #168

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 u…

Hey, I work on Yarn and Jest. Let me respond to why we built Jest: It solves a ton of problems no other test runner solves and it works well at Facebook's scale. We open sourced it more than two years ago but only recently started to promote the project in open source more actively because it is working so well at FB. If you are curious to find out more about why we built it, please read our blog posts, beginning wit…

I for one am thankful for Jest and Yarn. I recently switched over to Jest and I love most everything about it and the built in watch with caching reduces friction immensely (now if we can just allow custom preprocessors to return promises that would make life easier for integration of things like rollup). And yesterday I flipped over to using yarn and it definitely solves most of my pain points with npm.

So yeah, I'm definitely on the "keep reinventing" side of this debate.

Re: Yarn – A new package manager for JavaScript

#444

Post by Jean-Philipe » Wed, Oct 12, 2016, 3:52 PM UTC

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?

What do you mean by moving slowly? IMO there's not much to add. I'd like to see some speed improvements, but otherwise I'm not sure npm should evolve.

Re: Yarn – A new package manager for JavaScript

#445

Post by sontek » Wed, Oct 12, 2016, 4:42 PM UTC

Has anyone successfully got this to work? I was excited to try it so I did:

    $ rm -rf ./node_modules
    $ npm install yarnpkg
    $ ./node_modules/yarnpkg/bin/yarn

and it just freezes up and never finishes:

    [4/4]   Building fresh packages...
    [1/3] ⠈ node-sass
    [2/3] ⠈ radium
    [3/3] ⠈ phantomjs-prebuilt
    [-/3] ⠈ waiting...
    [-/3] ⠈ waiting...

This is not a particularly complex app, the dependencies:

http://paste.openstack.org/show/585495/

Re: Yarn – A new package manager for JavaScript

#446

Post by bcherny » Wed, Oct 12, 2016, 5:29 PM UTC

mlsarecmg wrote: post #440

bcherny wrote: post #327

Earlier quoted context omitted.

Not sure I understand. Can you give a concrete example?

You can only do as much as TS allows you to, unless you route through babel in a second pass. TS is a tool that controls to which extend you can use language features that are drafted. They do pick drafts here and there, but others they omitt, object spread for instance which is very common for Redux. As i said, try to transpile this in TS: http://redux.js.org/docs/basics/ExampleTodoList.html This is why they made Fl…

Still not sure I understand. All the code in that link is valid TS - TS is just a superset of JS.

Object spread is not part of the ES7 spec. It is a proposal which has not made it to stage 3 yet, and might still be dropped. That said, there is a TS issue tracking adding support for it: https://github.com/Microsoft/TypeScript/issues/2103.

Re: Yarn – A new package manager for JavaScript

#447

Post by rbanffy » Wed, Oct 12, 2016, 5:34 PM UTC

Gigablah wrote: post #374

__raccoons__ wrote: post #328

Earlier quoted context omitted.

Yet Another Redundant NPM

Redundancy for package registries? Sounds like a good thing to me ;)

Redundancy needs consistency. Not sure how that will be done.

Re: Yarn – A new package manager for JavaScript

#448

Post by nilliams » Wed, Oct 12, 2016, 6:37 PM UTC

mvindahl wrote: post #408

_ea1k wrote: post #258

Earlier quoted context omitted.

In fairness to the language and tools, this seems to be more of a cultural problem than anything. You can do the same kind of version range tricks in typical Java builds, for example (Maven), but most people hardcode the values to keep builds as deterministic as possible. For some reason, the JS community seems to prefer just trusting that new versions won't break anything. Its either very brave of them really (or ma…

But can yarn fix this? Say that I use yarn to depend upon some module X, specifying a fixed version number like the good boy scout that I am. Module X resides on npmjs and in turn depends upon the bleeding edge version of module Y. And then one day module Y goes all Galaxy Note and bursts into flames. Can yarn shield my app from that?

Yes it claims to provide a lockfile while locks all your deps all the way down the dependency tree.

You can do (and are supposed to do) the same with npm's own shrinkwrap, but people claim that it doesn't work as intended.

Re: Yarn – A new package manager for JavaScript

#449

Post by nilliams » Wed, Oct 12, 2016, 6:41 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.

You shouldn't be kicking off CI builds based on unpinned deps (unless you're deliberately doing 'canary testing' etc), because of course that will break. The npm solution for this is to use 'npm shrinkwrap' and you should always have been using this at your site/project level otherwise there was no hope it could work.

It's not that npm devs were naive enough to believe that unpinned deps would be safe for reproducible builds.

However I've heard several people allude over the years that 'npm shrinkwrap' is buggy, and isn't fully reproducible (though never experienced any problems personally). This is the aspect yarn claims to address, along with a supposedly more succinct lockfile format.

Re: Yarn – A new package manager for JavaScript

#450

Post by sctb » Wed, Oct 12, 2016, 6:42 PM UTC

LunaSea wrote: post #295

sotojuan wrote: post #175

Earlier quoted context omitted.

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.

Please resist the temptation to glom ideological snark onto unrelated threads. That's not what this site is for and it ruins threads for everyone by being simultaneously distracting and boring.