Guided: JavaScript Linters and Formatters

This lab will teach you how to configure and use ESLint and Prettier.

Imagine you've joined a new team and you're tasked with setting up ESLint and Prettier because the team wants to enforce a common coding style in the codebase.

You have been provided a Node.js project that simulates a functional app with some inconsistencies that needs to be fixed along the way. The necessary dependencies have been installed, and your task is to configure them for proper use.

ESLint is a linter for JavaScript projects. A linter helps you find and fix problems, or enforce a coding style in your project.

You're going to configure ESLint to check for issues in the current project. The configuration will use the default JavaScript rule from the @eslint/js plugin.

Prettier is a code formatting tool that helps you maintain the code formatting rule across your project. It can format the following document types:

• TypeScript, JavaScript, and JSX
• CSS, LESS, and SCSS
• Markdown
• HTML
• JSON
• YAML

Unlike ESLint, it only cares about how text are rendered in a document.

You should have the same lint and style rules across projects when working in a team with multiple projects. This is where shareable configration files are useful. You can use or extend something from the OSS community via npm.

Shared ESLint Config

You're going to use the rules from eslint-config-xo for this lab's project. This a shareable config with good rules for JavaScript/TypeScript projects. You'll notice a new set of errors because of the new config. Most of them are formatting issues, except the one for eval can be harmful.

The styling issue is a good example of where ESLint and Prettier rules could clash. You will resolve that in the next step. In this step, you will focus on the issue with using eval.

Disable Rules Inline

There may be times when you want to disable a rule just for a particular file or line. The use of eval is intentional in your case. Therefore, disable it inline so that ESLint doesn't show error for that line.

You saw how ESLint stylistic rule from the eslint-config-xo package can conflict with Prettier rules. You're going to use the package eslint-config-prettier to turn off all rules that might conflict with Prettier.

The package is already installed in the project. All you need to do is add it to the ESLint config

Automating the enforcement of your ESLint and Prettier rules via your CI system (e.g. GitHub Actions) is beneficial to you and your team. You're going to add a few scripts to package.json that can be used in any CI system.

There are other linters and formatters for JavaScript-related projects. However, they're relatively new and ESLint and Prettier are more advanced in terms of features, rules, and community extensions/plugins.

Oxlint

Oxlint is designed to catch erroneous or useless code without requiring any configurations by default. It supports lint rules for JavaScript/TypeScript projects including <script> in .vue, .astro, and .svelte files. Unlike ESLint, it doesn't support stylistic rules.

At its current stage, Oxlint can be used to fully replace ESLint in small projects.

For larger projects, they advise you to turn off ESLint rules via eslint-plugin-oxlint, and run Oxlint before ESLint in your CI setup.

Biome

Biome is a complete toolchain that includes formatter and linter, and comes with IDE extensions much like ESLint and Prettier. Their recent v2 release has gotten them close to Prettier/ESLint, so it's worth a try.

Wrap Up

Well done! You've configured the the JavaScript library in this lab to enforce coding practices via ESLint and Prettier. You added scripts to automate the process and to ensure code adheres to those rules before being committed to source control.

You also looked at alternative linters and formatters. Most of the selling points for the new ones are mostly about execution speed. Given the knowledge acquired in this lab, you can explore the newer tools and decide how you want to use them.

Happy hacking!