We manage an example editor hosted on GitHub, which is actively contributed to by a diverse group of developers. Given the inherent diversity in their choice of operating systems and IDEs, achieving uniformity in coding styles becomes challenging. To address this issue, we use ESLint, a tool designed to assist us in adhering to the project-specific coding standards, ensuring consistency across your codebase.

The prerequisites for this blog post assume that you have already upgraded your project to TypeScript. We previously discussed the process of transitioning to TypeScript in one of our earlier blog posts. However, it works just as well for JavaScript files.

Let’s get started with linting!

Previously, we mentioned our GitHub-hosted example editor. We’ll use this as the example for this blog post. Let’s take a closer look at the files needed to get started.

• .eslintrc.js

  A .eslintrc.js file is used to configure ESLint. This file specifies rules, plugins, and settings for how code in a project should be checked and formatted for consistency.

• .prettierrc.js

  A .prettierrc.js file is used to configure Prettier, an opinionated code formatter. This file contains settings that define how code in a project should be automatically formatted for consistency.

• package.json

  A package.json file is used in Node.js and npm (Node Package Manager) projects to manage and describe the project’s dependencies, scripts, and metadata. In this blog post we’ll be using the devDependencies and script properties.

The easiest way to begin is by copying both .eslintrc.js and .prettierrc.js files into the root directory of your editor source code.

If your project doesn’t already contain a package.json this file can be copied as well. And don’t forget to update it to suit your project by, for example, changing the name and description properties or simply omit them. In case the file already exists, copy/merge the devDependencies and scripts properties manually. Specifically, for scripts, we’ll just be using the lint property.

Once this is done, let’s install the dependencies using npm install.

Now we can run the linter for the first time using npm run lint. This will give a result similar to the following output:

$ npm run lint
# <truncated />
✖ 6476 problems (518 errors, 5958 warnings)
407 errors and 5636 warnings potentially fixable with the `--fix` option.

Great! It’s working. But that’s a lot of problems. And what about those potentially fixable errors and warnings? Not a problem, let’s run npm run lint – –fix giving us the following output:

$ npm run lint -- --fix
# <truncated />
✖ 407 problems (98 errors, 309 warnings)

Your source code has been altered and ESLint was able to find and fix 6069 errors and warnings. Nice!

At this point, the 407 problems that are left are most likely due to either unused imports, unused variables, incorrect file casings and/or missing typings for example. These will have to be fixed manually but given the fact that we went from 6476 problems to 407, the task to fix these has significantly been reduced.

Integrate ESLint into your IDE

Now, let’s discuss strategies to proactively avoid these issues from arising as we do not want to run npm run lint each time we make a change to the code. To achieve this, we want to integrate it into our IDE. In this example, we will concentrate on Visual Studio Code, the most widely utilized IDE at Fonto. However, it’s worth noting that other IDE such as Emacs and WebStorm also offer similar capabilities to assist you in identifying and addressing problems during code composition.

Let’s start by installing two new extensions called:

• ESLint for Visual Studio Code
• Prettier for Visual Studio Code

These plugins do not require any configuration. The extensions are clever enough to find the eslint and prettier executables in your node_modules, seeing as we already installed them when running npm install.

After reloading your code editor, it should work right away. Any problems that ESLint detects are now highlighted in your source code!

ESLint configuration

As a closing note, it’s good to point out that we use our own set of rules which we standardized for our projects. For more information about these rules, you can check out fontoxml/eslint-config. While it does require knowledge of ESLint and its inner workings, you are free to fork the configuration and change it yourself to suit your needs.

I’m looking forward to any questions you may have when using Fonto and shed light on how we are configuring our own editors. Your feedback is important, and I’m here to help and just a support ticket​ away!