Let your tools do the dirty work
4 min read
·
By Kristine Steine
·
December 7, 2018
Let's be honest - manually formatting your code is super boring.
In any project, consistent code formatting brings value by improving readability and reducing frustration among coworkers. Some coders are really good at writing readable, understandable code, with consistent patterns and just the right amount of spacing. But honestly - I'm not one of them. You'll find me writing drafts of code until it works the way it should, then I'll start working on readability. I want my code to make sense to my coworkers (not to mention: to myself the next time I read it!) and I dread receiving code reviews requiring formatting changes. At the same time, I find spending time manually converting code to match our team's code conventions really draining 😩
Enter ESLint! ESLint is a linting tool that helps you achieve consistent code by configuring rules describing your team's preferred code format and patterns. Installation is really simple:
$ npm install eslint --save-dev
$ eslint --init
You should now see a file named .eslintrc
in your directory. This is your config file, describing the environment your code runs in and the rules you want your code to follow. ESLint comes with a set of available rules, but you can also write your own ones if you feel like it. Rules come with docs describing what the rule evaluates as correct or incorrect code, as well as any available configuration options.
The rules in .eslintrc
can be turned off, set to warn (meaning ESLint will not throw an error, just show a warning in your console) or set to throw errors:
"rules": {
"semi": "off",
"eqeqeq": "warn",
"quotes": ["error", "single"] // specify options by adding them to an array along with the rule config
}
To have ESLint check your files, run this command:
$ eslint yourfile.js
Even better, let's have ESLint fix as many errors automatically as possible:
$ eslint yourfile.js --fix
Alright. So you've got ESLint set up, but configuring rules is a bit of a chore. Instead of defining all the rules yourself, you can have your config extend another project's config. Neat! In your .eslintrc
file, you can remove all the rules and add this:
"extends": "some-other-imported-config"
Okay, so that's not actually a valid config. But here are some widely used ones you should take a look at:
"extends": "plugin:jsx-a11y/recommended"
You can still override an imported config by configuring rules under the rules
property. Now you have a really nice tool that will help you write readable code, enforce accessibility and best practices!
If you want ESLint to keep its hands off some of your files (node_modules
comes to mind), you can add a CLI argument or an .eslintignore
-file. Ours looks something like this:
node_modules
assets
build
Let's fix even more formatting automatically. There are some really good formatting tools that will improve your workflow immensely (trust me!).
My team uses Prettier, which is a code formatter that will go through your code formatting and just fix it. Nice! Prettier allows you some configuration control, but you don't really have to configure much at all. Prettier has an online sandbox that you can use to test the tool, or to prettify a code snippet. You can use Prettier as a standalone tool, but I mostly use it in combination with the full Airbnb ESLint config. Just add "prettier"
to your list of extended ESLint configs, and ESLint will know not to worry about formatting - but still tell you about accessibility issues, unused code and bad patterns.
If you want even less config, and you're not into semicolons, check out StandardJS. StandardJS is a linter and formatter that will do much of the same as ESLint and Prettier, without the config. Just like Prettier, you can use this as a standalone tool or in combination with ESLint.
Save more time: Both of these can be configured to format files on save in most editors!
Almost! I just want to tell you about one last thing. Let's save even more time by having ESLint (and Prettier, in my case) verify your code during pull requests. In our package.json
we have a couple of npm scripts that have to run without errors in order to merge a pull request:
"scripts": {
"verify": "npm run verify:lint && npm run verify:format",
"verify:format": "prettier '**/*.{less,js}' --ignore-path='.eslintignore' -l"
"verify:lint": "eslint ."
}
Never worry about pushing ugly, unused, or inconsistent code to master branch again! I hope this is useful for you in some way - thanks for reading, and happy coding!
Loading…
Loading…
Loading…