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.
.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.
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
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 command
eslint --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).
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.
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.
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.