Use yarn instead of npm

[sndrs]

What does this change?

installs npm modules using yarn instead of npm

What is the value of this and can you measure success?

• gets rid of need for shrinkwrap, and (according to yarn) is more robust
• much faster to install
• doesn't hit the network if it doesn't need to

Does this affect other platforms - Amp, Apps, etc?

no, but there is this:

If you are using an npm-shrinkwrap.json file right now, be aware that you may end up with a different set of dependencies. Yarn does not support npm shrinkwrap files as they don’t have enough information in them to power Yarn’s more deterministic algorithm. If you are using a shrinkwrap file it may be easier to convert everyone working on the project to use Yarn at the same time. Simply remove your existing npm-shrinkwrap.json file and check in the newly created yarn.lock file.

this means all deps will now be installed up to the current top of their semver range. that should be ok, but we'll need to be vigilant nothing's snuck out (unlikely – rogue bad updates to deps of deps are why we started shrinkwrapping in the first place; they were very rare, but bad when they did get out)

Screenshots

⚡️ 🐻

Request for comment

@guardian/dotcom-platform

[rjmk]

this means all deps will now be installed up to the current top of their semver range

Have we discussed saving exact before? The tradeoff is not getting automatic patch fixes for avoiding possible breaking changes smuggled under patch version bumps.

Will play around with this branch and see if I can get anything to break!

[sndrs]

Have we discussed saving exact before?

yeah we had problems before with deps of deps releasing breaking changes as patches, everything unexpectedly breaking, and decided this was safer.

i'm no fan of shrinkwrap itself, but i think the argument for using it is pretty persuasive.

if we get everything up to date, add green keeper or a similar non-automated way of regularly keeping up to date, we should hopefully be able to avoid both situations

[gtrufitt]

Are you purposely only moving the install over, i.e what about the npm scripts:

watch: compile-dev
    @npm run sass-watch & \
        npm run css-watch & \
        npm run browser-sync

Should these be moved?

[gtrufitt]

I wonder whether we should run yarn install --force to have parity with the prune behaviour? Seems like a bug that they may decide yarn install will remove modules that aren't in the package.json

yarnpkg/yarn#696

[gtrufitt]

Actually... scratch that, --force would bypass the local cache and lose those benefits, so I guess there is some behaviour there that yarn needs to fix (but that isn't a blocker to us...)

(edit)
Or.. maybe yarn clean - but it says don't use it all the time. Could be worth using it cautiously to generate a yarn.clean periodically. Anyhoo, one to think about.

[sndrs]

yeah i was going to yarn clean but their specific warning gave me pause...

if it becomes an issue, make reinstall should cover you? prune was always just a courtesy really anyway, to my mind

[gtrufitt]

👍 Yup, makes sense.

[gtrufitt]

⭐️

For me this is a no-brainer test - easy to back out from if things go wrong but great rewards in performance if they go right.

Not as part of this PR, but in the future if we're happy, It might be worth us reviewing if the --flat option will work for us - from a quick test, there would be 82 versions to resolve, so it'll definitely need some proper thinking but an un-scientific resolution of 2 for every package shaved the node_modules folder from 340mb to 30mb.

[sndrs]

Should these be moved?

i see them moving as part of the retiring grunt/tools/assets work. kind of feel that they should be separate from the package manager, since they're related to our app, not npm or yarn?

at the start of last week, incidentally, I nearly made a case for moving npm scripts out to a runner, based on the idea that one day npm too would be replaced by something new and therefore we'd end up moving them again. that seemed to show it was the wrong place for build scripts, but it seemed a kind of pointless, because npm being replaced seemed like a verrrrry long way away :)

[gtrufitt]

because npm being replaced seemed like a verrrrry long way away

😆

kind of feel that they should be separate from the package manager, since their related to our app, not npm or yarn?

Ok, yeah that makes sense, I prefer the idea of a unified architecture for all tasks with only one level of abstraction (make).