Linting for React Native

Linting is the process of running your code through a tool to analyse for potential errors. Linting isn’t language specific and can be customised on a per project basis to ensure code quality, improved performance, reduce developer decision making fatigue and consistency.

Here’s a few examples of where linting can help:

• Show me when I’ve defined a variable, but haven’t used it (OR show me when I’ve used a variable but never defined it!)
• Error when I’ve got a syntax error (eg. missing a closing parentheses)
• Show me when there’s a more performant way to write that (eg. with Javascript, I may have written something the ‘old’ ES5 way, but my project is setup for ES6+, so use the more performant version of that code)
• Show me an error when I’m not abiding by my team’s code standards (eg. always use spaces and not tabs or our code standards may say that object definitions should always have a dangling comma)

I’ve missed a semi-colon — our code standards state that we need one. My linter shows me an error then and there.

Sounds too good to be true. How how how?

So far we’ve been introduced to linting. Let’s get setup. This guide will walk you through getting setup with linting for React Native (JS) development, but you can apply the same principles for any language.

Linting requires a few tools (once you’re setup, it’ll be silky smooth, promise).

1. Define a Code Styleguide

We didn’t have a code styleguide — the process to define all of the individual syntax choices seemed pretty daunting. Instead of re-inventing the wheel, we looked through the styleguides from the “big-boys” of the industry and landed on AirBnB’s Javascript styleguide.

Get your developers to review and agree to use your chosen styleguide as a central source of truth.

2. IDE Plugins

First up, let’s install a linter into your code editor of choice. These will work together to show you the warnings/errors on demand.

• VS Code — ESLint
• Sublime Text 3 — SublimeLinter and SublimeLinter-contrib-eslint
• Atom — Linter and Linter-eslint
• PHPStorm — ESLint
• Others? Let me know in the comments

I’ve configured my IDE plugin to analyse code both when I open a file + when I hit save. Mine shows me errors/warnings in the gutter, a squiggly line under the code in question + when I hit save, it pops up and gives me more info.

3. Per project devDependencies

Our code editor is now setup to lint our code, however it needs to know what and how to lint. On a per project basis, you’ll simply need to install some NodeJS devDependencies and also produce a .eslintrc configuration file to wire up the plugins and rules to use.

2.1 Let’s install some devDependencies to our project:

• The Linter to run the processing — we chose ESLint

npm install eslint eslint-plugin-import eslint-plugin-react eslint-plugin-jsx-a11y --save-dev

• Linter plugin/s, to define your rules — we really liked AirBnB’s Javascript styleguide which also comes with all the matching ESLint rules + it‘s built for React development

npm install eslint-config-airbnb --save-dev

• We use ES7 syntax like Javascript classes in React Native, so we‘ll need to use babel-eslint as our parser

npm install babel-eslint --save-dev

Wire it all together:

Good news is, that everything’s installed, now it’s time to wire it together via a magical .eslintrc configuration file.

Create a .eslintrc file in the projects root with the following:

{
  "extends": "airbnb",
  "parser": "babel-eslint",
  "ecmaFeatures": {
    "classes": true
  },
  "rules": {
    "react/jsx-filename-extension": ["error", { "extensions": [".js", ".jsx"] }]
  }
}

Conclusion

If everything’s working correctly, you should be able to simply hit save and you’ll very likely get some errors (example shown below).

You can also run a command in terminal, to analyse and report back on all files at once (instead of going into each file in your IDE to look for errors):

./node_modules/.bin/eslint -c .eslintrc — ext .js src

Don’t be too afraid of the errors. It’ll likely be minor syntax issues, changing tabs to spaces and things like that. Instead of refactoring the whole project in one go, we decided to refactor files as we touch them.

Overall, it feels super clean when everyone’s forced to follow the same styleguide!