- After deploy, `yarn tag` gets prompted for login, because npm login != yarn login
- When I tried to do it locally, `yarn tag remove thelounge next` consistently gave me a 404, but `npm dist-tag rm thelounge next` worked nbd.
See https://github.com/nodejs/Release
To this day, Node.js v6 is in maintenance mode, v8 is an active LTS, and v10 is the current stable. v9 has been EOL since June.
npmjs has invalidated all tokens recently, so I had to create a new one.
For the record (because it will happen again one day or another, and for the life of me I can never remember how to do it), the command I ran to encrypt this was:
```
travis encrypt ****************82f5 --add deploy.api_key -r thelounge/thelounge
```
Those last 4 characters should appear in Travis logs the next time we release, to confirm the encrypted value is correct.
This has several reasons, benefits and consequences:
- When running on root (which is not recommended anyway), `npm run build` was already necessary.
- This allows to not use the `prepublish` hook, whose behavior is going to change in npm v5 and again in npm v6.
- This allows to create both production and development builds when running from source.
- It makes `npm run build` compatible with Windows again for development environments (lost in previous commit).
- It uses the `prepublishOnly` hook added in npm v4. Since this hook is not available prior to that, deployment to npm from Travis has to be done on the Node.js v7 environment.
We are seeing more and more people installing on Node v7 so it's important to ensure `npm install` will pass correctly and our (limited but growing) test suite as well.
OSX builds have been nothing but a pain on Travis CI: they fail with no good reason, they stay pending forever, etc.
As far as I can tell, I can't remember one valid build they failed and we legitimately discovered a bug. Dev env on OSX is very close to Linux so it's good enough to have it here.
This allows for a more meaningful build: if a newer version of a sub-package breaks,
builds would still pass as it uses the cached version. This uses a cache for downloaded packages instead.
I am expecting this to slow down a little bit the builds (but we are OK overall)
but be more accurate in practice.
See https://docs.npmjs.com/cli/cache#configuration and https://docs.npmjs.com/files/folders#node-modules.
