Automagically beautify your code

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:

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:

To have ESLint check your files, run this command:

Even better, let's have ESLint fix as many errors automatically as possible:

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:

Okay, so that's not actually a valid config. But here are some widely used ones you should take a look at:

• Airbnb has a really nice base-config that I personally love to use. They have also shared their config for React projects, including accessibility checks and their set of best practices.
• Google's JavaScript style guide is available as an ESLint config
• If you've set up your own formatting rules but want to avoid accessibility issues, there's a react-a11y plugin for ESLint that adds accessibility rules. You can configure these yourself or use the recommended set of rules using this extension: "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:

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:

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!