How to Test Custom ESLint Linting Rules With AST

[00:00 - 00:45] Testing custom ES lint rules has similar benefits to testing the custom JS code shift chint form. First, taking a test-driven approach when creating custom rules can offer a faster feedback loop. The test runs significantly faster than trying to run them on an entire codebase. Second, if the rules complex or shared across many different code bases, tests can help provide confidence that the rule is working as expected. To get started, we'll create a new file to test the no- button element linting rule alongside this rule in the ES lint rules directory. Then we'll start by requiring our rule. Next, we'll require ES lint and specifically import the rule tester class.

[00:46 - 01:11] The rule tester uses the default ES lint configuration, not the one provided by create React app, so any necessary configuration also needs to be passed to the rule tester when initialized. By default, ES lint only expects ES5 syntax. In this case, only the parser option needs to be specified to enable JSX support. Otherwise, the ES lint parser will throw an invalid syntax error.

[01:12 - 01:37] Then, we can define test cases to run against our linting rule with this rule tester. The rule tester has a run method to execute tests. It expects three arguments. The first argument is the name of the rule. The next argument is the rule definition, which we've already required. All these test cases are contained in a single object with two keys, valid and invalid.

[01:38 - 02:05] Valid contains code samples that should pass the linting rule and not trigger linting error, while invalid contains code samples that should not pass the linting rule and therefore should trigger a linting error. Each test case is an object that must have the code property to run the rule on. There are several other options and many more for invalid test cases. You can reference the docs for the full list of all of the test case options. .

[02:06 - 02:11] . . .

[02:12 - 02:48] . . [ Silence ] Now that we've defined a test case for our rule, we can run this test with node .

[02:49 - 03:00] There won't be any output if all of the tests pass. We can confirm that this test is indeed working by moving an invalid case to valid, or vice versa, and run the test again.

[03:01 - 03:08] The error should then be printed to the console. Let's switch back to our editor and make one of the valid test cases invalid.

[03:09 - 03:20] Then back in the terminal, let's run the tests again. We can see that the script now failed with the error message that we should have no errors, but we had one.

[03:21 - 03:34] We can then undo this change to make our tests pass again. If you're curious to see more complex examples of ESLint rule tests, all the test cases for the included ESLint rules are in the GitHub repository.

[03:35 - 03:54] Using tests like this can provide a faster feedback loop when creating custom rules and validate that they're working as expected. The Flash codebase has now been fully refactored, replacing button elements with button components, and we've introduced a Linting rule to prevent future violations.

[03:55 - 04:20] As we should now realize, there are countless practical uses for ASTs, ranging from understanding the code to refactoring, Linting, and others, such as formatting code with prettier or minifying code with tracer. ASTs and the associated tooling can be jargon heavy and seem complex, but with a basic understanding of what ASTs are, along with some of the terms and general concepts, we can unlock a whole new range of skills.

[04:21 - 04:42] Next time you're faced with a refactor or similar problem in a large codebase, consider if ASTs might be the right tool for the job. [ Silence ]