Back in the summer of 2015 we wrote a post on some useful tools that we were using in our Node.js projects. It’s proven to be a popular post, and a lot has happened since then. We’ve therefore decided to make a 2018 edition showcasing some new tools that we’re currently using in our workflow. The tools cover areas such as code linting and formatting, workflow efficiency, cross-platform application development, and testing.
ESLint
Code linting is a good practice for keeping code in a consistent format with development teams, as well as spotting issues in the code such as unused variables.
ESLint was designed to support the latest versions of JavaScript (ESNext), as well as being able to support file formats like JSX as used in React/Preact projects. ESLint allows you to setup a custom configuration for linting rules for your project. Simply do the following below to get started:
npm i eslint --save-dev
node_mdoules/.bin/eslint --initOne of the useful features of ESLint is that it can be used to fix code issues automatically, rather than having to do the changes manually by hand. Simply run the command below:
node_mdoules/.bin/eslint --fixThis will make changes to your project’s code automatically, saving you time and effort.
ESLint is used by a large number of organisations, some of whom have made their ESLint configurations public, like Airbnb.
Prettier
Continuing on the subject of code linting and formatting, a couple of months ago a really cool tool called Prettier came out. It is an opinionated code formatting tool that enforces a consistent code style by parsing your code and re-printing it with its own rules.
It can be used to format JavaScript, JSX, CSS, Markdown and more:
You can either use it via the CLI, or you can integrate it into your text editor of choice, and have it execute after you’ve saved a file. This can help to ensure that your projects follow a consistent code format and style across developers and teams, as a seamless part of your developer workflow.
Probot
Moving onto the topic of improving developer workflow, GitHub have been developing an internal project that has come to fruition recently called Probot.
Probot is a collection of plugin apps that can run inside your GitHub repositories, and do things like:
- Close stale issues and Pull Requests
- Enforce GPG signatures on Pull Requests
- Reply to toxic comments with a maintainer designated reply and a link to the repo‘s code of conduct.
By integrating these plugins into GitHub repositories, Probot is able to automate a number of small manual tasks that project maintainers would otherwise have to do manually, freeing them to dedicate their energy to other things. For me, my favourite app within Probot is the TODO app:
Those who read the original post we did from 2015 will know that we recommended an NPM module called “Notes” that printed out any TODO or NOTE code comments in our Node.js project. This tool from Jason Etcovitch goes one step further, and is able to create GitHub issues in the repo when code containing a TODO code comment is pushed to the repo. This helps to coordinate tracking of those issues in the GitHub repo, as part of prioritising the work to do in a project.
There is a lot of potential for improving developer workflows via Probot, it’s worth a good look, especially for helping to make maintaining open source popular projects easier.
Cross-env
A common practice of Node.js projects is to use scripts defined in the package.json file to trigger various commands. One of the challenges that we run into is setting environment variables in our npm scripts whilst also wanting to support running on both Windows and Mac OS/Linux, as both have different ways for setting environment variables. Enter Cross-env.
Cross-env provides a way to use environment variables in your scripts, and have it work across both Windows and Mac OS/Linux:
npm install --save-dev cross-envAnd then you can use it like this in your package.json file:
{
"scripts": {
"build": "cross-env NODE_ENV=production myBuildTask.js"
}
}This is very useful in the context of working on popular open source projects and also cross-platform apps like desktop apps built with NW.js and Electron, which brings me conveniently onto the next useful tool.
Spectron
This tool is bit specific to working on Electron apps, but is very useful nonetheless. Spectron is a testing framework for Electron apps.
From 2015–2017 I wrote a book for Manning publications on building cross-platform desktop applications with NW.js and Electron. During the time of writing the book, being able to test desktop apps was tricky and during NW.JS’ 0.10–0.12 upgrade cycle the solutions for testing desktop apps stopped working, which was a frustrating experience. The Electron team at GitHub recognised that being able to test desktop apps was a challenge, and came up with Spectron.
Spectron makes it very easy to automatically open your app, execute user actions, and check the state of the application after those actions have occurred. You can easily link it into another testing tool like Mocha or Cucumber.js, as well as run those tests in a CI platform such as Travis or CircleCI. This is possible because Spectron is built on top of ChromeDriver.
What about testing web applications?
Puppeteer
Setting up Selenium and getting it to work with browser drivers can sometimes involve a bit of configuration and trial & error. This can tend to be a point of frustration and lead to people giving up on setting up automated testing for their web apps.
https://github.com/GoogleChrome/puppeteer
Puppetter by the Google Chrome team is an NPM module that provides a high-level API to controlling Chrome via the DevTools Protocol. It can also be configured to run Chrome in either headless mode (no Browser Window is rendered on screen) or Full, making it suitable for use in CLI and CI environments.
Although I originally described the tool in the context of automated testing, the scope of Puppeteer is much broader than that. Puppeteer can be used to create screenshots or PDFs of web pages (it is a much more reliable solution than using WkhtmltoPDF), do screen-scraping for web spiders, as well as generate and capture timeline traces of a page loading and save the results. You can even run Puppeteer in a serverless fashion with AWS Lambda.
We’ve used it to help generate PDF print reports for one project, and in another project we have used it alongside NPM’s link functionality and Cucumber.js to test a combination of a Backend REST API and a React Frontend application working together, despite both parts existing in separate repositories. We will show that approach in a later post.
NPX
If you find yourself constantly using node_modules/.bin in your NPM command scripts, you can DRY them up a bit by using NPX instead.
https://medium.com/@maybekatz/introducing-npx-an-npm-package-runner-55f7d4bd282b
NPX is a command supplied as part of NPM 5.2.0 and greater. You can use it to turn this…
node_mdoules/.bin/eslint --init…into this:
npx eslint --initThis is just one thing that NPX does. It actually does a lot more, but I will encourage you to read the link above to find out more.
Accessibility
Recently I attended the DotJS 2017 conference in Paris. There were some great talks there, and one of the recurring themes among the talks was on accessibility, looking at ways to ensure that HTML markup is valid, that img alt tags contain meaningful descriptions of the objects and context inside of the image, and that CSS colour themes are compliant with people who experience colour blindness. To find out more, check out the talks and posts from Suz Hinton and Marcy Sutton.
Accessibility is something that deserves more attention, and admittedly I haven’t given it as much as it merits, so that’s why it will be covered in a separate post in the near future.
Thoughts?
Those are some of the tools that I’ve used during the past year. If there are any topics that you want to hear more about or queries in general, feel free to get in touch at paul@anephenix.com.
