Add the latest stable node version

[ghost]

Summary

This PR adds node since Node.js 11 has been released.

https://github.com/nodejs/node/blob/master/doc/changelogs/CHANGELOG_V11.md#11.0.0

Details

Specifying Node.js versions

Specifying Node.js versions #
The easiest way to specify Node.js versions is to use one or more of the latest releases in your .travis.yml:

node latest stable Node.js release
iojs latest stable io.js release
lts/* latest LTS Node.js release

[iansu]

We should decide how we want to handle non-LTS releases. I think this config might make sense. We explicitly list the LTS releases we support and then just use node to catch the latest version.

When node 10 was the latest, if we had 10 and node, would that have run the test suite on node 10 twice? I guess we'll find out when node 12 comes out.

[ghost]

@iansu Hi,
We can decide on how to handle the testing overhead.
To decide that you might want to check out this:

Why Adding “node”?

In short: To fail early for new Node.js releases.

At the time of writing this tutorial, the latest Node.js version is 9.x. That means Travis runs tests with the same environment for the configured versions 9 and node. Both run Node.js v9.

In some months, there will be a Node.js v10 release. At that point, the node config points to version 10 instead of 9.

While updating a project you’ll see at an early stage whether it's compatible with the new Node.js major release.

There’s no additional configuration required to test against the next Node.js release. It’s an early heads up for required maintenance.

Eventually you should add the related Node.js version represented by node to your .travis.yml. For an early heads up, it’s a great way to recognize failing tests.

Should You Worry About the Testing Overhead?

As mentioned above, most of the time you’re running tests against the same versions when using a dedicated version number (like 9) and node. This will test your project twice against the same environment.

Well, for us it’s worth testing a repository against the same Node.js twice for most of the time, because testing is cheap.

Be proactive in testing rather than running behind compatibility and needing manual work to test against the latest stable release.

[iansu]

So it does run it twice. Maybe that doesn't matter if they run in parallel.

[stale]

This pull request has been automatically marked as stale because it has not had any recent activity. It will be closed in 5 days if no further activity occurs.

[iansu]

Thanks!