How to Make Your JavaScript Beautiful

W hen working on a project, it’s nice to have the code in each of your project files formatted the same way. Not only does it look nice, but it also makes your code easier to understand since the structure is the same across all project files. Also, when working with others using a version control system like git, it’s important that all files are formatted the same way to only highlight and commit the important changes to your version control.

Imagine if one developer works on a file and uses 2 spaces for indentation and then another developer ends up working on the same file and uses 4 spaces for indentation. This can cause problems. The developer using 4 spaces could leave the lines using 2 spaces untouched, but then the file will have differences in indentation spacing which means poor readability. The alternative could be to have the developer using 4 spaces reformat the entire file to use 2 spaces for indentation (by either doing it manually or use one of the formatting tools mentioned below to automatically format the code). However, when this reformatted file gets committed to version control, all lines of code will be marked as changed and this makes reviewing code difficult. When reviewing code, you only want to see the code changes related to implementing new features or fixing bugs, not changes in spacing or other formatting related things.

Look at all that red and green! There must be some really valuable work done here! Actually, all of these changes are formatting related 😑

There are many tools available to help you format your code and help avoid issues like the one described above. Three popular tools to format your JavaScript code are ESLint, Prettier, and EditorConfig. There are also tools such as Husky and lint-staged that ensure that all code added to a repository is formatted in a consistent way.

ESLint

ESLint is a tool that identifies and reports on patterns in your JavaScript code and notifies the user of any improperly structured code. ESLint determines what code is properly structured based on the rules it is given. Rules are specified in an .eslintrc configuration file and there are many rules you can implement in a project. Some rules aren’t available in the native ESLint tool, but can be added through the use of plugins. For example, there is an ESLint plugin to allow the use of React specific linting rules.

Simple example of ESLint rules in an .eslintrc file setting rules for the use of semicolons and double quotes

You’re able to specify the error levels for each rule. The three error levels are “off”, “warn”, and “error”. “off” turns the rule off (I know, surprising), “warn” displays a warning to the user, and “error” will output an error to the user if the rule is violated.

ESLint also allows you to extend rules from existing configuration files found on npm. At Osedea, we have our own set of ESLint rules bundled into a configuration package and we include the rules by extending it in our project’s .eslintrc file.

Extending from an external set of ESLint rules

ESLint does have the ability to do some formatting based on the rules you set in your .eslintrc file, but ESLint is limited in how much formatting it can do. To format your code with ESLint, you will have to run the eslint --fix command in your project directory and pass the files you want formatted to the commandeslint --fix. In order to run ESLint commands, make sure you have ESLint installed in your project as a developer dependency (npm i eslint --save-dev). Also, it’s worth mentioning that the ESLint documentation says to have ESLint installed globally, but the issue with having ESLint installed globally vs. locally to your project is that the global installation can only make use of globally installed ESLint plugins. For this reason we consider it to be best practice to install all ESLint related dependencies locally. Read more about the available ESLint CLI commands here.

ESLint warnings and errors will appear right in a code editor if you have the appropriate plugin installed. Warnings and errors will manifest themselves as underlined code (different colours are used depending on the error level).

A look at ESLint errors appearing in an editor

Prettier

Prettier formats your code for you. Prettier is opinionated in how it formats code and as a result there are only a few configuration options. Some command options used with Prettier include setting the print width, enforcing the use of semicolons and using either single or double quotes.

It’s common to use both Prettier and ESLint together, and there are tools to help facilitate using both tools together. See prettier-eslint, prettier-eslint-cli, eslint-plugin-prettier, and eslint-config-prettier. I recommend using prettier-eslint since it’s the simplest one to work with in my opinion. prettier-eslint will run prettier to format your code based on your prettier config, and then it will run eslint --fix to fix any formatting issues that ESLint finds.

Another cool thing that you can do with Prettier is have it automatically format your code upon saving your file. This is done through the installation of a plugin for your respective code editor. Prettier plugins exist for many of the commonly used editors.

Look how that code formats upon save!

Editors that support the Prettier plugin

EditorConfig

One way to maintain coding styles between different editors and IDEs is to use an .editorconfig file. Like Prettier, EditorConfig can be used with code editors by installing the appropriate plugin. Setting properties for indent style, indent width, tab width, and others allow for consistent formatting behaviour while writing code in any editor. Of course, Prettier and ESLint will cover anything that is not correctly formatted, but it’s nice to be able to hit the tab key in your editor and have it tab the right amount of spaces to be consistent with all your other code.

Sample .editorconfig file

Husky and lint-staged

Husky allows you to run scripts during certain git related actions, such as before a commit or before pushing code to a remote repository. lint-staged allows you to look at the files being committed and run commands such as prettier --write and eslint --fix before committing your files to version control.

Setting up Husky and lint-staged is great when working with a team of developers since you don’t have to worry if every developer on the team has run the formatting commands before committing their code, since it’s all done automatically! This forces all code that is added to version control to be formatted the same way.

As you can see there is a lot you can do to make sure your code is formatted nicely and consistently among teams of developers. It’s well worth the time to figure out a good setup to handle your project’s code formatting as it makes development easier. Once you’ve got a good setup figured out, you can add it to a boilerplate to ensure it is used on all future projects. To read more about what makes a good boilerplate read this article.