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
- String Replace All Appearances
- How to Generage a UUID in Node.js
- How to Run an Asynchronous Function in Array.map()
- How to Reset and Empty an Array
- for…of vs. for…in Loops
- Get an Array With Unique Values (Delete Duplicates)
- Callback and Promise Support in your Node.js Modules
- Run Async Functions/Promises in Sequence
- Run Async Functions/Promises in Parallel
- Run Async Functions in Batches
- How to Merge Objects
- Get a File’s Created Date
- Get a File’s Last Modified/Updated Date
- How to Create an Empty File
- Check If a Path or File Exists
- How to Rename a File
- Check If a Path Is a Directory
- Check If a Path Is a File
- Retrieve the Path to the User’s Home Directory
- How to Touch a File
- Read File Content as String
- Check If a Directory Is Empty
- How to Create a Directory (and Parents If Needed)
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.