Initial research:

• dev machine uses nvm to manage version on npm/node, nvm does not support yarn, https://github.com/creationix/nvm/issues/1280. I've tried to use nvm to manage node version, and yarn is installed globally (-g) and it works. As long as the node version is consistence, it should be fine.

• we use frontend-maven-plugin to download npm/node, need to replace with yarn, https://github.com/eirslett/frontend-maven-plugin#installing-node-and-yarn

• all other command we use at the moment is supported by yarn

• jenkins config of yarn?

Run (zanata-frontend module):
(yarn) mvn clean install 124.13s user 11.78s system 141% cpu 1:35.91 total
(npm) mvn clean install 285.47s user 20.03s system 122% cpu 4:08.57 total

Jenkins (zanata-frontend):
(npm)Zanata frontend 8 min 6 sec
(yarn)Zanata frontend 6 min 19 sec

This looks interesting: https://medium.com/@boennemann/avoid-yarn-for-packages-and-fully-enjoy-its-benefits-for-application-development-8bdd4deb33cf#.6f3gni2jq I had no idea npm was downloading all those tarballs to check shrinkwrap files, but it helps to explain the terrible performance.

The fact that yarn apparently ignores dependencies' shrinkwrap/yarn.lock files is a bit of a concern. But it seems to me that whenever you use yarn upgrade (or npm install --no-shrinkwrap; npm shrinkwrap --dev) you will get the latest version (within a semver range) of everything anyway, so it may not be much worse in practice.