How to Use ESLint to Create AST Rules With Babel Traverse

[00:00 - 00:17] ES lint brings many of the same benefits for linting that JS code shift brought to transforms in terms of reduced setup and configuration. A standard solution also means that more generic ES lint rules can be shared across many code bases, which reduces the need for custom linting rules in the first place.

[00:18 - 00:24] ES lint includes a large set of these linting rules by default. It also makes it easy to include rules for different use cases.

[00:25 - 00:37] For example, there's the ES lint React plugin package which includes a large set of rules for a code base using React. There are many plugins like this for all sorts of libraries, as well as encouraging good practices for things like accessibility.

[00:38 - 00:52] The rules included with ES lint, in combination with many of the rules provided by plugins, can cover many of the common needs in a code base. However, a large code base is constantly evolving, which usually means specific patterns become outdated or deprecated.

[00:53 - 00:59] This is one area that custom linting rules are useful. Let's start by opening the flashcards code base.

[01:00 - 01:11] As mentioned in an earlier lesson, the flash app was built using create react app. It takes care of much of the standard boilerplate in configuration for a project, even including the ES lint configuration.

[01:12 - 01:31] The default create react app ES lint configuration can be updated using the standard ES lint configuration options by updating the ES lint config property in the package.json file. When working on a project that doesn't have ES lint already set up and configured, the official documentation for getting started can be followed.

[01:32 - 01:45] The simplest approach for creating custom rules with ES lint is to use runtime rules. To get started, we'll create a new ES lint rules directory within the existing flashcards project.

[01:46 - 02:00] Then we'll create a new file named noButtonElement.js in this ES lint rules directory. ES lint will then allow us to pass the custom option to specify where these custom rules are defined.

[02:01 - 02:13] We can update the ES lint configuration to enable this custom rule. Note that the file name must match this rule name.

[02:14 - 02:21] And finally, we can add the boilerplate for this rule. ES lint expects the export to be an object with a few keys defined.

[02:22 - 02:30] The first key is meta, which defines metadata for this rule. In this case, we're only going to define the type property, which defines the type of rule.

[02:31 - 02:36] It can be either problem, suggestion, or layout. In this case, this rule is a suggestion.

[02:37 - 02:51] The next key we need to define is create, which is a function that returns an object with visitors. It also passes in a context parameter, which provides several utilities for creating the rule.

[02:52 - 03:08] To start out, let's traverse all JSX opening elements like the previous scripts . We can then use the report function on the context object to report a message for this given node.

[03:09 - 03:25] This file now defines a rule which exports an object with some metadata and a function to visit specific types of nodes in an AST. This file is an ES lint specific configuration, but the object with visitors looks like many of the previous scripts that use Babel traverse.

[03:26 - 03:46] It's still missing many of the same constraints, so this will produce many lint ing errors since it's targeting all JSX opening elements. Let's switch to our terminal and try running ES lint in the flashcards directory, including our custom linting rules directory.

[03:47 - 04:05] We can see that this triggered many linting errors because we're targeting every JSX opening element in every file. Let's switch back to our editor and start by pasting in the logic from the previous custom linting script.

[04:06 - 04:13] We can also reuse the exact same message from the previous script. The last change we need to make is converting string literal to literal.

[04:14 - 04:20] This is because ES lint uses a different parser instead of Babel. This script is now equivalent to the custom linter.

[04:21 - 04:30] One difference is using the context.report function to report the violation. ES lint passes the context object to the create function which provides helpers and metadata.

[04:31 - 04:50] ES lint will then handle all of the grouping in other logic to surface the error once it's been reported. Let's again add a violation in the landing page component with a button element that has a button class name that should instead be a button component.

[04:51 - 05:00] We can then switch back to our terminal and rerun ES lint. We can see that it produces the same linting error from the previous custom l inting script.

[05:01 - 05:07] ES lint removed much of the boilerplate in dependency management. With minimal setup we were able to get a custom linting rule working.

[05:08 - 05:13] ES lint has many other benefits. For example, it can implement performance optimizations in caching.

[05:14 - 05:23] It also provides a shared framework so rules can be reused more widely. Another benefit of ES lint is that it provides tests and utilities to make it easier to test custom rules.

[05:24 - 05:28] The next lesson will add test cases for this rule to verify it's working as expected.