Course overview

Introduction

What is an Abstract Syntax Tree? Visualizing Code Like a Compiler

How to View Abstract Syntax Tree Code With AST Explorer

The Best JavaScript AST Tools - ESLint, Babel, Terser, and More

Environment setup

Understanding Abstract Syntax Trees (AST)

How to Generate a JavaScript AST With Babel Plugins

Traversing an AST With Babel Traverse

Add Type Safety and Prevent Runtime Errors With AST

Working with Abstract Syntax Trees

Practical code audits

How to Audit Your Code With AST Programming

How to Add a Component and Update an AST

When to Use Abstract Syntax Tree Tooling to Refactor at Scale

Code Audits

How to Mutate an AST and Automatically Replace Code Components

How to Create Codemods Using jscodeshift

How to Unit Test jscodeshift Transforms With ts-jest

Codemods

How to Ensure Codebase is Up to Date With Linting Rules

How to Use ESLint to Create AST Rules With Babel Traverse

How to Test Custom ESLint Linting Rules With AST

Linting

node.js

In this course, we'll start with the fundamentals of abstract syntax trees (ASTs) and learn the basic mental models. This general AST knowledge can be translated to almost any tool that works with ASTs.

## Why this course?

Understanding and using ASTs unlocks the ability to make sweeping changes in a safe and reliable way in any size codebase.

## Course topics

Throughout this course, we'll have converted source code into ASTs, traversed, mutated, and generated ASTs. With these concepts we'll then explore several practical applications including things like code audits (static analysis), code transformations (codemods), and linting.

### Module 1

We'll learn the fundamentals of abstract syntax trees. 

- What is an AST?
- How to explore an AST
- Examples of JavaScript tools that work with ASTs

### Module 2

We'll learn how to work with ASTs.

- How to turn code into an AST
- How to programmatically navigate any AST 
- How to leverage TypeScript to prevent runtime errors

### Module 3

We'll learn how to statically analyze, or "audit" code to understand the state of the codebase using abstract syntax trees.

- An introduction to an example codebase and refactor
- Understanding the state of the current codebase
- When to use an AST-based tool versus doing something manually

### Module 4

We'll learn how to transform, or "codemod" code from one state to another using abstract syntax trees.

- How to make changes to an AST
- How to change ASTs with [jscodeshift](https://github.com/facebook/jscodeshift)
- How to test a code transform

### Module 5

We'll learn how to write rules, or "lint" code using abstract syntax trees.

- How to create rules for code
- How to create custom rules with [ESLint](https://eslint.org)
- How to test a rule

In this course, you'll learn the fundamentals of abstract syntax trees, what they are, how they work, and dive into several practical use cases of abstract syntax trees to maintain a JavaScript codebase.

Practical Abstract Syntax Trees

JavaScript tools that work with abstract syntax trees

How to parse, traverse, and generate abstract syntax trees

Practical skill set for maintaining large JavaScript codebases

Testing custom ESLint rules has similar benefits to testing a custom jscodeshift transform. First, taking a test-driven approach when creating custom rules can offer a faster feedback loop. The tests run significantly faster than trying to run them on an entire codebase. Second, if the rule is complex or shared across many different codebases, tests can help provide confidence that the rule is working as intended.

 directory, with an import for the rule and the 

// Import the custom rule definition.
const rule = require("./no-button-element");
// Import the utility provided by ESLint to test custom rules.
const { RuleTester } = require("eslint");

The rule tester uses the default ESLint configuration (not the one provided by Create React App) so any necessary configuration also needs to be passed to the 

 when initialized. By default, ESLint only expects ES5 syntax. In this case, only the 

 need to be specified to enable JSX support (eg: 

) otherwise the ESLint parser will throw an invalid syntax error.

// Initialize a new rule tester instance, with the default
// configuration to use for all test cases.
const ruleTester = new RuleTester({
  parserOptions: {
    ecmaFeatures: {
      // Enable support for JSX (eg: <button>)
      jsx: true,
    },
  },
});

Then, the test cases can be defined and run. The 

 to execute tests. It expects three arguments: the rule name, the rule definition, and test cases.

// Invoke the `run` method to run the tests cases for
// the given rule.
ruleTester.run(
  // The name of the rule.
  "no-button-element",
  // The custom rule definition itself.
  rule,
  // All test cases are contained in a single object
  // with two keys:
  //  - `valid`: code samples that should pass the
  //    linting rule (not trigger a linting error).
  //  - `invalid`: code samples that should not pass
  //    the linting rule (should trigger a linting error).
  //
  // Each test case (object) must have the `code` property
  // to run the rule on. There are several other options,
  // and many more for invalid test cases.
  //
  // See the docs for the full list: 
  //  https://eslint.org/docs/developer-guide/nodejs-api#ruletester
  {
    valid: [
      {
        // Missing `className`, so valid.
        code: "<button>Button</button>",
      },
      {
        // Missing "button" `className`, so valid.
        code: "<button className='custom-button'>Button</button>",
      },
      {
        // Already a `Button` component, so valid.
        code: "<Button className='button'>Button</Button>",
      },
      {
        // Not a `button` element, so valid.
        code: "<div className='button'>Button</div>",
      },
    ],
    invalid: [
      {
        // `button` element with a "button" `className`, so invalid.
        code: "<button className='button'>Button</button>",
        errors: [
          {
            message:
              'Found "button" element that should be "Button" component.',
          },
        ],
      },
      {
        // `button` element with a "button" `className`, so invalid.
        // This verifies the rule can handle multiple class names.
        code:
          "<button className='otherClassName button anotherClassName'>Button</button>",
        errors: [
          {
            message:
              'Found "button" element that should be "Button" component.',
          },
        ],
      },
    ],
  }
);

---
title: How to Test Custom ESLint Linting Rules With AST
description: Testing custom ESLint linting rules to verify they work as expected
privateVideoUrl: "https://fullstack.wistia.com/medias/ga71wnpusa"
---

# Testing custom linting rules

Testing custom ESLint rules has similar benefits to testing a custom jscodeshift transform. First, taking a test-driven approach when creating custom rules can offer a faster feedback loop. The tests run significantly faster than trying to run them on an entire codebase. Second, if the rule is complex or shared across many different codebases, tests can help provide confidence that the rule is working as intended.

## Testing a rule

To get started, create a new file `no-button-element.test.js` alongside the rule in the `eslint-rules` directory, with an import for the rule and the `RuleTester` utility from ESLint.

```javascript { actualFilename=./protected/flash-cards/eslint-rules/no-button-element.test.js endLine=4 startLine=1 statedFilename=no-button-element.test.js url=https&#x3A;//gitlab.com/fullstackio/books/practical-ast-and-codemods/module_05/lesson_05.03/protected/flash-cards/eslint-rules/no-button-element.test.js }
// Import the custom rule definition.
const rule = require("./no-button-element");
// Import the utility provided by ESLint to test custom rules.
const { RuleTester } = require("eslint");
```

The rule tester uses the default ESLint configuration (not the one provided by Create React App) so any necessary configuration also needs to be passed to the `RuleTester` when initialized. By default, ESLint only expects ES5 syntax. In this case, only the [parser options](https://eslint.org/docs/user-guide/configuring/language-options#specifying-parser-options) need to be specified to enable JSX support (eg: `<button>`) otherwise the ESLint parser will throw an invalid syntax error.

```javascript { actualFilename=./protected/flash-cards/eslint-rules/no-button-element.test.js endLine=15 startLine=6 statedFilename=no-button-element.test.js url=https&#x3A;//gitlab.com/fullstackio/books/practical-ast-and-codemods/module_05/lesson_05.03/protected/flash-cards/eslint-rules/no-button-element.test.js#L6 }
// Initialize a new rule tester instance, with the default
// configuration to use for all test cases.
const ruleTester = new RuleTester({
  parserOptions: {
    ecmaFeatures: {
      // Enable support for JSX (eg: <button>)
      jsx: true,
    },
  },
});
```

Then, the test cases can be defined and run. The `RuleTester` has a [`run` method](https://eslint.org/docs/developer-guide/nodejs-api#ruletester) to execute tests. It expects three arguments: the rule name, the rule definition, and test cases.

```javascript { actualFilename=./protected/flash-cards/eslint-rules/no-button-element.test.js endLine=82 startLine=17 statedFilename=no-button-element.test.js url=https&#x3A;//gitlab.com/fullstackio/books/practical-ast-and-codemods/module_05/lesson_05.03/protected/flash-cards/eslint-rules/no-button-element.test.js#L17 }
// Invoke the `run` method to run the tests cases for
// the given rule.
ruleTester.run(
  // The name of the rule.
  "no-button-element",
  // The custom rule definition itself.
  rule,
  // All test cases are contained in a single object
  // with two keys:
  //  - `valid`: code samples that should pass the
  //    linting rule (not trigger a linting error).
  //  - `invalid`: code samples that should not pass
  //    the linting rule (should trigger a linting error).
  //
  // Each test case (object) must have the `code` property
  // to run the rule on. There are several other options,
  // and many more for invalid test cases.
  //
  // See the docs for the full list: 
  //  https://eslint.org/docs/developer-guide/nodejs-api#ruletester
  {
    valid: [
      {
        // Missing `className`, so valid.
        code: "<button>Button</button>",
      },
      {
        // Missing "button" `className`, so valid.
        code: "<button className='custom-button'>Button</button>",
      },
      {
        // Already a `Button` component, so valid.
        code: "<Button className='button'>Button</Button>",
      },
      {
        // Not a `button` element, so valid.
        code: "<div className='button'>Button</div>",
      },
    ],
    invalid: [
      {
        // `button` element with a "button" `className`, so invalid.
        code: "<button className='button'>Button</button>",
        errors: [
          {
            message:
              'Found "button" element that should be "Button" component.',
          },
        ],
      },
      {
        // `button` element with a "button" `className`, so invalid.
        // This verifies the rule can handle multiple class names.
        code:
          "<button className='otherClassName button anotherClassName'>Button</button>",
        errors: [
          {
            message:
              'Found "button" element that should be "Button" component.',
          },
        ],
      },
    ],
  }
);
```

Testing custom ESLint linting rules to verify they work as expected

Is it possible to create ESLint test and rule files as TypeScript files with type definitions?

fabrizzio.gz

Yes, absolutely. You can refer to ESLint plugins written in TypeScript, such as eslint-plugin-teting-library. Note that there are custom abstractions in this repository but you could likely reuse them if you find them useful, or look at their implementation for the underlying helpers.

Learn

The newline Guide to Building Your First GraphQL Server with Node and TypeScript

Teach

Amelia Wattenberger

Author of Fullstack D3

Community

Practical Abstract Syntax Trees

Module 1: Introduction

Introduction:

Start Here

Introduction: (2:27)

Course overview

Module 2: Understanding Abstract Syntax Trees (AST)

Lesson 1: (5:55)

What is an Abstract Syntax Tree? Visualizing Code Like a Compiler

Lesson 2: (4:21)

How to View Abstract Syntax Tree Code With AST Explorer

Lesson 3: (1:46)

The Best JavaScript AST Tools - ESLint, Babel, Terser, and More

Lesson 4: (1:03)

Environment setup

Module 3: Working with Abstract Syntax Trees

Lesson 1: (6:29)

How to Generate a JavaScript AST With Babel Plugins

Lesson 2: (7:33)

Traversing an AST With Babel Traverse

Lesson 3: (9:31)

Add Type Safety and Prevent Runtime Errors With AST

Module 4: Code Audits

Lesson 1: (2:35)

Practical code audits

Lesson 2: (15:29)

How to Audit Your Code With AST Programming

Lesson 3: (2:32)

How to Add a Component and Update an AST

Lesson 4: (1:43)

When to Use Abstract Syntax Tree Tooling to Refactor at Scale

Module 5: Codemods

Lesson 1: (21:13)

How to Mutate an AST and Automatically Replace Code Components

Lesson 2: (10:03)

How to Create Codemods Using jscodeshift

Lesson 3: (5:55)

How to Unit Test jscodeshift Transforms With ts-jest

Module 6: Linting

Lesson 1: (8:44)

How to Ensure Codebase is Up to Date With Linting Rules

Lesson 2: (5:31)

How to Use ESLint to Create AST Rules With Babel Traverse

Lesson 3: (4:31)

How to Test Custom ESLint Linting Rules With AST

How to Test Custom ESLint Linting Rules With AST