Travis CI is a sophisticated continuous integration and deployment service. It integrates with GitHub and runs tests on events like commits or pull requests.
Node.js Series Overview
- Callback and Promise Support in your Node.js Modules
- Increase the Memory Limit for Your Process
- Why You Should Add “node” in Your Travis Config
- Create a PDF from HTML with Puppeteer and Handlebars
- Create Your Own Custom Error
- Extend Multiple Classes (Multi Inheritance)
- Get a File’s Created Date
- Get a File’s Last Modified/Updated Date
- Human-Readable JSON.stringify() With Spaces and Line Breaks
- Write a JSON Object to a File
- How to Create an Empty File
- Run Async Functions/Promises in Sequence
- Run Async Functions/Promises in Parallel
- Run Async Functions in Batches
- How to Merge Objects (Coming soon)
We run all tests for both plugins on Travis CI. Our
.travis.yml file looks like this:
language: node_js node_js: - 9 - 8 - node # <-- add this to your .travis.yml for Node.js projects
language defines the required environment to integrate your project on Travis CI. Before the test execution, Travis prepares the test setup by installing Node.js with NPM and NVM following the defined versions.
The configuration above tells Travis to run three integrations with different Node.js versions:
node, represents the latest stable Node.js release
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
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
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.
Testing Node.js projects on Travis CI is convenient and the GitHub integration is great. To always test against the latest Node.js stable release, you should add
node to the list of Node.js versions.
Are you testing your Node.js projects with
node in your Travis config as well? Share your thoughts in the comments below or send a tweet: @futurestud_io.