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.

@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.

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

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.

Thanks!