Using yarn vs npm for learning team repos

Learning Team
1

There are multiple repos managed by the learning team and we have a mix of npm and yarn as dependency manager in them. This poll is to decide on one to use on all existing and future repos. Please vote below.

  • Yarn
  • Npm

0 voters

1 Like
2

Hi folks :wave:

I was hoping that this would be more of a discussion than a simple vote :thinking: maybe it’s worth getting a feel for people’s initial preferences and then having a second vote at the end? I don’t know if this is even possible, and I am already digressing :confounded:

The first thing that I would like to bring up as part of this discussion is that I don’t believe this is entirely a technical question, and I would like to implore us to not just try to approach this from that point of view. I voted for npm above, and advocate for the use of npm over yarn because of a similar principle of “the rule of least power” and the onboarding experience of new developers.

Let’s approach this by way of an example: We have a new developer approaching the Guides App in a month or so, and their experience is mostly in HTML and CSS and has never worked with Node before. In our CONTRIBUTING document, we are likely to say: “Download the latest LTS Node from https://nodejs.org/ before getting started”. This is the point at which our story diverges based on the decision we make here today.

In scenario one: our next instruction is: "run npm i and then npm start and you will see the guides app will be available at https://localhost:4200. Job done.

In scenario two: the instructions are "run npm i -g yarn (add some text about troubleshooting permissions) yarn and then run yarn start

The difference between these two scenarios is that in the second one you have introduced quite a few new concepts that will be adding to the cognitive load of the new developer. “What does -g do in the command? What do you mean ‘global’ install? What is yarn? So you’re using a package manager to install a package manager? Why can’t I just use npm if it’s also a package manager?” etc.

I think especially in the learning team we need to be cognisant of the message that we’re sending out by “making yarn the default”, and considering the fact that our team seems to be a great place for “first contributions” it is my personal opinion that that the extra cognitive load is entirely not worth it for the diminishing returns that you get using yarn.

I wanted to try to avoid the technical question as part of this discussion but it is at least salient to note that as of npm 5.6 a lot of the reasons that inspired the creation of yarn in the first place have now been fixed, this is why I refer to any technical superiority of yarn as “diminishing returns”.

3

The vote is only about using yarn/npm in our repos for developing those apps. So it’s fair to assume that they’ll know what npm & yarn are. Its not really about recommending any to the community :slightly_smiling_face:

I agree on your point on npm being least effort for entry, but considering contributors who jump around multiple repos in a day, there’s definitely a significant pain that they face on npm that yarn eases.

This particular topic is close enough to vim vs emacs, which is why I left it to a vote.

Even if npm is decided, i’d still use yarn while working with that repo finally delete the yarn.lock file & run npm install once to update the package-lock.json before i push any code. I don’t see why anyone who strongly feels about npm can’t do so either if yarn ends up being the choice :slightly_smiling_face:

2 Likes
4

I don’t understand the comparison that npm/yarn is simlar to the vim/emacs conversation, and you are not the first person to say that to me either.

The main difference here is that we don’t have CONTRIBUTOR documentation that would start any line with “open up emacs and run this emacs command” (i’ve never actually used emacs so I don’t know if that makes any sense)

The fact that I’ve actually never used emacs before so this would be a hurdle for me to get over to get started. This is why I’m so focused on the “npm being least effort for entry” side of this argument.

5

Just because people feel strongly about both of those IDEs that its hard to get them to stop talking about them. Didn’t meant to sidetrack the conversation.

6

I believe @real_ate has a valid point, we cannot assume that developers that want to contribute to Ember are intimately familiar with yarn. So it introduces a potential roadblock to new contributions and contributors. Ember has made it a point of pride to be welcoming to new contributors (at least, that’s the message I have received, and heard from others in podcasts, talks and so on) and so that should be a consideration.

As a side point, I’ve yet to see a good comparison of the two that doesn’t boil down to some UI niceness and developer preferences, but I’m open to changing my mind if presented with good arguments. I believe the speed argument is mostly moot at this point (at least for me, anecdotally) npm is actually faster than yarn for the two Ember apps I am working with.

1 Like
7

Weighing in:

  1. if a project uses npm or uses yarn, don’t change it w/o discussing with the team first.
  2. yarn isn’t hard to pick up - took me less than five minutes, and a post-it note next to my monitor. ymmv.
  3. it would behoove all involved to commit to de-personalizing the issue.

if people want to contribute, they’ll learn the tool. It’s fine.

1 Like
8

Hey all, thanks for your input. We’re going to align with the rest of core projects (like GitHub - emberjs/ember.js: Ember.js - A JavaScript framework for creating ambitious web applications) and use yarn across the board, so this discussion is complete.

One main actionable item from this discussion is that we can (and should) do more to help make it easy for people to get started, so that means better instructions in docs like READMEs and CONTRIBUTING.md. If anyone feels inspired, please open an issue with some suggested text!

1 Like