How to Make Your JavaScript Beautiful

Robert Cooper
Feb 20, 2018 · 6 min read

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.


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


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


Sample .editorconfig file

Husky and lint-staged

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.


Montreal based tech agency taking work-life harmony to a higher level.

Robert Cooper

Written by

Front-end Web Developer



Montreal based tech agency taking work-life harmony to a higher level.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade