ci: test Node.js 6, 8, 10 and 11

[DanielRuf]

Test only Node.js 6, 8, 10 (LTS) and stable (11).

https://github.com/nodejs/Release/blob/master/README.md

[nfischer]

• For dropping v4/v5, see Drop node v4 support #873
• v10 has a bug right now (chore: bump CI to run against node v10 #856) (help would be appreciated)
• We probably won't drop v7/v9
• We can't use npm install, we have our own script (see chore(npm): add ci-or-install script #896)
• We chose c++ as a language a long time ago, and I can't remember why (so I can't tell you if the reason is still relevant). I think it was just to get finer-grained control over our CI steps

[DanielRuf]

We probably won't drop v7/v9

But why? They reached their EOL.

[DanielRuf]

We can't use npm install, we have our own script (see #896)

This produces different results in CI and production (lockfiles are not working there).

We chose c++ as a language a long time ago, and I can't remember why (so I can't tell you if the reason is still relevant). I think it was just to get finer-grained control over our CI steps

But it does not seem to be used.
I'll check and update the CI script.

[nfischer]

But why? They reached their EOL.

I'm not aware of a compelling argument to support v6 but not v7. If we support v7, we should probably test it too.

---

Did some digging, and it seems like we switched to language: c++ in order to support OS X (#283). I assume Travis OS X builders understand nodejs now, so I would accept a PR to switch back to language: node_js (but please do that in a separate PR).

[nfischer]

We can't use npm install, we have our own script (see #896)

This produces different results in CI and production (lockfiles are not working there).

Not sure I quite understand. Are you objecting to the use of lockfiles in general, or objecting to our install wrapper?

[DanielRuf]

Not sure I quite understand. Are you objecting to the use of lockfiles in general, or objecting to our install wrapper?

The first, this is why npm ci is a bit dangerous (works in our CI - but not in production).

[nfischer]

The first, this is why npm ci is a bit dangerous (works in our CI - but not in production).

Might consider something like npm/npm#16867 (comment), since lockfiles have so-far caused more trouble than they've been worth.

[DanielRuf]

Probably, or use npm install on CI.
At least CI often produces a different dependency tree than the installed package in production as it is often a child dependency of another dependency and below the root lockfile it is only locked to the SemVer range in the package.json files (or better: pinned there to a specific version).

Not yet sure what the best solution for everyone is. It's a bit inconsistent across platforms (dev, prod, CI), tools (yarn, npm version) and repository settings (a lockfile might be useful for contributors and CI to build reproducible builds but many big devs like Sindre and others do not use lockfiles for such reasons afaik).

Also see sindresorhus/ama#479

[nfischer]

Replaced by #910, #917, and #921