Switch to yarn

[peterbe]

yarn is still much better than npm. It's faster, has support for "resolutions", easier to upgrade packages, ability to check that packages weren't manually added (without using the cli), etc. And from experience feels a lot more predictable and solid than npm.

Just today, I checked out master and ran npm install and it caused this massive change to package-lock.json

[peterbe]

▶ npm --version
6.9.0

by the way.

I have no idea why we have npm as a dependency which seems just a strange chicken-and-egg thing.

[peterbe]

Not sure if this matters:

▶ node --version
v11.12.0

[wbamberg]

I don't feel qualified to have an opinion on this.

But also: is this a thing we should try to make consistent across our projects? I mean if yarn is better, is it also better for kumascript and browser-compat-data and interactive-examples? This feels to me like a thing we should get consensus across the team and apply consistently.

[ddbeck]

I'm wondering if this will introduce some unneeded contributor friction. When I install Node on my machine, I get npm too. But yarn is an additional tool I have to install before I can start contributing.

[peterbe]

[should we] try to make consistent across our projects?

Yeah. Maybe. But not right now. It's more complicated there because of the breadth and legacy. mdn2 is all yarn because it's a fresh new project so no excuse using aging/inferior tools when it's easy to make the upgrade now.

[peterbe]

But yarn is an additional tool I have to install before I can start contributing.

yarn is rapidly becoming more and more adopted. Most Node docker images on Dockerhub come with yarn pre-installed.

Senior JS developers who have experienced both usually prefer yarn. Me included. Oftentimes, the only proponents for npm is those who haven't tried yarn yet. Reminds me about how the only people who prefer MySQL (over Postgres) are those who've never had a chance to try Postgres properly.

When I worked in Product Delivery (last team before MDN) all JS projects used yarn and we were very happy with that.

[peterbe]

By the way, to me, a killer feature that we'd get right now is that with our current package-lock.json, every time I do cd stumptown-experiment && npm install it generates a different package-lock.json even though I didn't touch anything. So I have to then type git checkout package-lock.json to unstage that.

[peterbe]

Also,

[should we] try to make consistent across our projects?

I'm more than happy to take stabs at projects like browser-compat-data later. But I'd also like not to let this rot before we reach consensus. If it turns out that all everyone hates yarn in the stumptown eco system, at least we'll have experienced and learned a new tech that doesn't seem to be going away.

[peterbe]

Another reason why I prefer yarn is that you can poke at sub-dependencies without necessarily installing them. For example, one of your dependencies depends on (or depends on something that depends on etc) fstream. Then, you find out that that version of fstream is insecure and must be upgraded.

First of all, with yarn you can run:

yarn why fstream

and it lists all "parents" of that package.

Second, you can then indicate that no sub-dependency uses a version older than 1.0.12 So you add, to your package.json:

"resolutions": {
    "fstream": ">=1.0.12"
}

and run yarn again.

With npm you have to add "fstream": ">=1.0.12" to your dependencies (or devDependencies if you know where it comes from). But since you can't write comments in package.json the future you won't understand why it's there. "Apparently this project, top-level, depends on fstream but it's strange that I don't see it any of the ./src/**/*.js code!"

[wbamberg]

I believe I've listed enough reasons why yarn is better than npm.

I'm totally happy to believe that yarn is better, but the point stands: I'd like us to have a considered and consistent policy for this across the MDN team. Adding more reasons yarn is better doesn't change that.

As a minimum, I'd like to bring this topic up in a whole-team setting and either:

• have consensus to standardise on one or other package manager, with some level of commitment from maintainers of affected projects to move over to the winner

• have consensus that it does not in fact matter to standardise a particular package manager, and different projects can choose package managers effectively at random (or at least, that the cost to established projects of switching is not worth the value of consistency).

[peterbe]

I can draft a draft ADR to be discussed in Whistler.

[wbamberg]

Thank you! (I don't think it needs to be in Whistler, FWIW, email is fine. But Whistler is probably a good chance to pin people down.)