Should we use Yarn?

[alanmoo]

Anyone have thoughts on Yarn? I've been using it here and there, and it's mighty fast. Lockfiles are also nice. From what I've researched, you don't want to use it for consumable packages, but for end products it works great.

All it takes is adding lockfiles that yarn generates to the commit, though the one thing I'm not entirely sure on is if there's a potential for issues when someone uses npm i instead. (It would probably be a minor issue, but something to be aware of nonetheless)

@Pomax @gvn @mmmavis @simonwex @gideonthomas @cadecairos @ScottDowne @acabunoc

[gvn]

I'm looking into it more and it's definitely faster.

Committing the yarn.lock raises my eyebrow a bit since it's large and machine generated. As far as I can tell it will lock dependencies regardless of whether you use version ranges in the manifest. That's different than npm FWIW.

Personally, I'm pro-version locking. I like the greater consistency between environments. I always lock regular (non-dev) deps. Semver is great in theory, but it's often used wrong even with good intentions.

The interesting thing is I think we will have to regenerate the yarn.lock anytime we want to do even a patch bump on a ranged dependency. We might want to add some kind of version checking to npm start that warns about outdated deps so this gets done.

Fundamentally there doesn't seem to be anything preventing people from using Yarn now. What we're trying to figure out is if we should endorse Yarn and/or commit yarn.locks. Correct?

[alanmoo]

Yeah, pretty much- is there any reason we shouldn't commit yarn.locks?

[gvn]

1. Same reason committing any large machine generated code/text is sub-optimal. Repo bloat, large diffs. Possible merge conflicts.
2. If we don't commit yarn.lock then the resolution behavior essentially goes back to npm's for better or worse.

Neither is an absolute deal breaker. If anything, I'd like to try Yarn on a project or two before we go all in on it.

[Pomax]

does it have an npm run now? When it last hit hackernews it wasn't quite there yet, with npm start and npm test working but no equivalent to npm run sometask, which we rely on. A lot.

edit looks like the most recent version has a run equivalent.

[gvn]

That does raise another thing to think about.

Would we refactor our package.json scripts to do yarn run blah instead of npm run blah? That'd mean creating a hard dependency on Yarn, which just adding yarn.lock doesn't do.

Also is there a yarn-run-all type module, or would we be safe to continue using npm-run-all without a global npm install required?

[gvn]

Another question: Is there any benefit to using Yarn over npm aside from faster install speed?

[Pomax]

as task runners, I guess it doesn't matter. Everyone gets npm for free, and the time savings don't come from optimizing run scripts, but from installing fast, so we could use yarn for just the package management, and defer to npm for runs scripts without anyone noticing.

[gvn]

True. Sounds like we should just leave our scripts alone.

[alanmoo]

Agreed, leave the scripts alone, and even if contributors continue to npm install it should be fine, I just want to make sure there isn't any downside to using lockfiles in the repos if we want to. According to this very helpful page it shouldn't be an issue, at least any more than issues that exist when using npm today.

[Pomax]

the only last tricky bit I think is if we're reaching into ./node_modules for something (like style guides) for something that npm and yarn organize differently.

[alanmoo]

Do they organize differently or just resolve dependencies slightly differently (sub-dependencies in a different order?) ?

[Pomax]

looked into it a bit but it sounds like they use the same flie layout.