Yarn – A new package manager for JavaScript

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 serious consquences for the JS community and would take years to recover, in my opinion.

Excellent. The NPM cli is a dumpster fire-- cf https://github.com/npm/npm/issues/11283

A better std lib for node and module LTO would be a good step forward to removing the proliferation of tiny packages

> Flow, introduced 3 months after TypeScript

Do you think Flow was built in 3 months as a reaction to Typescript? Not that it was a big enough problem that two different groups of people independently decided to try to solve it? EDIT: disregard this, Flow was introduced much longer than 3 months after TypeScript. The blog post introducing Flow mentions TypeScript, and is probably worth reading for background [1]

> Nuclide instead of Atom/Sublime/VSCode

Nuclide is an Atom plugin.

> Jest instead of Jasmine/Mocha

Jest provides a superset of Jasmine functionality, and uses Jasmine as its test runner.

[1] https://code.facebook.com/posts/1505962329687926/flow-a-new-...

As I understand it, it automatically locks in the (exact) version of everything you install, rather than having this as a separate, optional feature (like shrinkwrap does, despite it not working well - but that's an implementation problem).

The big deal about semver and how it's implemented in NPM is that there is a choice of how to deal with it - either you automatically allow compatible updates and risk an occasional maintainer fuckup, or you explicitly pin everything and take on the burden of constantly updating your versions manually and tracking security releases.

The latter might work for Facebook and other large organizations, but for many smaller developers, the consequences of an accidental break are much, much less serious than those of constantly having to keep pinned dependencies up to date. End result: people don't bother at all, and insecure versions never get upgraded for the majority of the userbase.

This, in turn, removes the incentive for package authors to do anything with semver at all, once Yarn's approach becomes commonplace. Why bother with semantic versioning if everybody is expected to manually check and pin their dependencies anyway?

Facebook also needs to take into account their influence over the ecosystem. The reality is that whatever project Facebook puts out is immediately seen as gospel and "naturally, a well-engineered thing and a good choice to use!" - this is literally a daily argument in #Node.js when somebody is trying to argue why a poorly-fitting tool is somehow appropriate for their usecase. "Well, Facebook uses it!"

In reality, the Yarn workflow is designed to work for Facebook and organizations of similar size, and in all likelihood it will break down in other situations. People will not realize this until they've already bought into it, and by then it's too late.

npm should not be terrified, we've been working with them and they've been very encouraging.

From their perspective it's very difficult to make breaking changes to the client because of the sheer number of people depending on them. (We've faced similar problems on Babel)

Yarn still makes use of the npm registry and all the high quality infrastructure they've built and support they provide for the ecosystem. They are a critical piece of this.