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

Codemods

How to Ensure Codebase is Up to Date With Linting Rules

How to Use ESLint to Create AST Rules With Babel Traverse

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

 components. To get to this point, we first performed an audit of the codebase to understand how 

 elements were being used today. Then, we created a 

 component that was capable of handling all those use cases. Finally, we performed a codemod to transform all of the 

This completes the original refactor described in Module 3. However, an actual codebase will continue to evolve and have further changes made. How do we ensure the codebase 

A common approach for this is to create a 

 for that codebase that enforces this. Any time a change is made, the codebase can be checked against that rule. If there are any violations, the change can be blocked.

For example, in a git workflow, a change is made in a branch off the main branch. Before that branch can be merged, this rule (in addition to other things like tests) need to pass. This way, the main branch should never violate this rule.

This concept of applying rules to code is commonly referred to as 

Let's start by creating a new linter directory and adding the necessary dependencies.

# Create a new directory for the linter script
mkdir linter

# Change into the new linter directory
cd linter

# Initialize a new package.json file
npm init -y

# Add the necessary dependencies
npm i @babel/parser @babel/traverse @babel/code-frame glob ts-node typescript
npm i -D @types/babel__traverse @types/babel__code-frame @types/glob

 file with much of the same initial setup as the previous custom audit script.

import { parse } from "@babel/parser";
import traverse from "@babel/traverse";
import * as fs from "fs";
import * as glob from "glob";

const files = glob.sync("../flash-cards/src/components/**/*.js");

files.forEach((file) => {
  const contents = fs.readFileSync(file).toString();

  const ast = parse(contents, {
    sourceType: "module",
    plugins: ["jsx"],
  });

  traverse(ast, {
    JSXOpeningElement({ node }) {
      if (node.name.type === "JSXIdentifier" && node.name.name === "button") {
        // Find the JSXAttribute (prop) with a name of
        // `className` where it's value is a space separated
        // string of class names where one of the class
        // names is `button`.
        const hasButtonClassName = node.attributes.find((attribute) => {
          return (
            attribute.type === "JSXAttribute" &&
            attribute.name.type === "JSXIdentifier" &&
            attribute.name.name === "className" &&
            attribute.value.type === "StringLiteral" &&
            attribute.value.value.split(" ").includes("button")
          );
        });

        // Ignore any button elements that don't also have 
        // the button class name
        if (!hasButtonClassName) return;

        // TODO: lint...
      }
    },
  });
});

Since all the nodes that matched these criteria were transformed in the previous module, no nodes will match these criteria in the codebase.

To test this, a new violation can intentionally be added to verify it works as expected. Update the 

 component in the Flash codebase (or any other component) with the following snippet anywhere in the component.

    <button className="button">
      Hello World!
    </button>

Now there is a violation, the linting rule can be updated to log the file and line that violates this rule, to make it easy to find and fix. Each node contains a 

 property that is an object with information about the starting and ending lines and the column numbers.

// Example value of the `loc` property on a node:
{
  "start": { "line": 23, "column": 4 },
  "end": { "line": 23, "column": 31 }
}

 for this module. It will otherwise hide all of the 

This location information can be appended to the filename to make it easier to jump directly to the position in the code that the violation occurs.

    JSXOpeningElement({ node }) {
      if (node.name.type === "JSXIdentifier" && node.name.name === "button") {
        const hasButtonClassName = node.attributes.find((attribute) => {
          return (
            attribute.type === "JSXAttribute" &&
            attribute.name.type === "JSXIdentifier" &&
            attribute.name.name === "className" &&
            attribute.value.type === "StringLiteral" &&
            attribute.value.value.split(" ").includes("button")
          );
        });

        if (!hasButtonClassName) return;

        // At this point, it means a violation (eg: 
        // `<button className="button" />`) was found. 
        // Print the error, the current file, and 
        // concatenate the line and column of the 
        // violation position in the original source 
        // code. This makes it easy to copy and paste 
        // into an editor like VSCode and it'll open the
        // file with the cursor at that position.
        const { start } = node.loc;
        console.error(
          `${path.resolve(file)}:${start.line}:${start.column + 1}`
        );
        console.error(
          `  Found "button" element that should be "Button" component.`
        );
      }
    },

Now, let's run the script with the known violation.

---
title: How to Ensure Codebase is Up to Date With Linting Rules
description: Implement a linting rule to prevent the code we just transformed from being reintroduced in the future
privateVideoUrl: "https://fullstack.wistia.com/medias/ev3e1mm4g4"
---

# Creating rules for code

The Flash codebase now uses `Button` components. To get to this point, we first performed an audit of the codebase to understand how `button` elements were being used today. Then, we created a `Button` component that was capable of handling all those use cases. Finally, we performed a codemod to transform all of the `button` elements to the `Button` component.

This completes the original refactor described in Module 3. However, an actual codebase will continue to evolve and have further changes made. How do we ensure the codebase _stays_ up-to-date using the `Button` component where appropriate?

A common approach for this is to create a **rule** for that codebase that enforces this. Any time a change is made, the codebase can be checked against that rule. If there are any violations, the change can be blocked.

For example, in a git workflow, a change is made in a branch off the main branch. Before that branch can be merged, this rule (in addition to other things like tests) need to pass. This way, the main branch should never violate this rule.

This concept of applying rules to code is commonly referred to as **linting**.

## Creating a rule

Let's start by creating a new linter directory and adding the necessary dependencies.

```bash
# Create a new directory for the linter script
mkdir linter

# Change into the new linter directory
cd linter

# Initialize a new package.json file
npm init -y

# Add the necessary dependencies
npm i @babel/parser @babel/traverse @babel/code-frame glob ts-node typescript
npm i -D @types/babel__traverse @types/babel__code-frame @types/glob
```

Then, create a new `rule.ts` file with much of the same initial setup as the previous custom audit script.

```typescript { actualFilename=./protected/linter/rule-00.ts endChar=1281 endLine=42 startChar=0 startLine=1 statedFilename=rule.ts url=https&#x3A;//gitlab.com/fullstackio/books/practical-ast-and-codemods/module_05/lesson_05.01/protected/linter/rule-00.ts }
import { parse } from "@babel/parser";
import traverse from "@babel/traverse";
import * as fs from "fs";
import * as glob from "glob";

const files = glob.sync("../flash-cards/src/components/**/*.js");

files.forEach((file) => {
  const contents = fs.readFileSync(file).toString();

  const ast = parse(contents, {
    sourceType: "module",
    plugins: ["jsx"],
  });

  traverse(ast, {
    JSXOpeningElement({ node }) {
      if (node.name.type === "JSXIdentifier" && node.name.name === "button") {
        // Find the JSXAttribute (prop) with a name of
        // `className` where it's value is a space separated
        // string of class names where one of the class
        // names is `button`.
        const hasButtonClassName = node.attributes.find((attribute) => {
          return (
            attribute.type === "JSXAttribute" &&
            attribute.name.type === "JSXIdentifier" &&
            attribute.name.name === "className" &&
            attribute.value.type === "StringLiteral" &&
            attribute.value.value.split(" ").includes("button")
          );
        });

        // Ignore any button elements that don't also have 
        // the button class name
        if (!hasButtonClassName) return;

        // TODO: lint...
      }
    },
  });
});
```

Since all the nodes that matched these criteria were transformed in the previous module, no nodes will match these criteria in the codebase.

To test this, a new violation can intentionally be added to verify it works as expected. Update the `LandingPage` component in the Flash codebase (or any other component) with the following snippet anywhere in the component.

```javascript { actualFilename=./protected/flash-cards/src/components/LandingPage/LandingPage.js endLine=25 startLine=23 statedFilename=src/components/LandingPage/LandingPage.js url=https&#x3A;//gitlab.com/fullstackio/books/practical-ast-and-codemods/module_05/lesson_05.01/protected/flash-cards/src/components/LandingPage/LandingPage.js#L23 }
    <button className="button">
      Hello World!
    </button>
```

Now there is a violation, the linting rule can be updated to log the file and line that violates this rule, to make it easy to find and fix. Each node contains a `loc` property that is an object with information about the starting and ending lines and the column numbers.

```json
// Example value of the `loc` property on a node:
{
  "start": { "line": 23, "column": 4 },
  "end": { "line": 23, "column": 31 }
}
```

:::note

When using AST Explorer, make sure **Hide location data** is **disabled** for this module. It will otherwise hide all of the `loc` properties from the tree view.

:::

This location information can be appended to the filename to make it easier to jump directly to the position in the code that the violation occurs.

```typescript { actualFilename=./protected/linter/rule-01.ts endChar=1651 endLine=48 startChar=418 startLine=18 statedFilename=rule.ts url=https&#x3A;//gitlab.com/fullstackio/books/practical-ast-and-codemods/module_05/lesson_05.01/protected/linter/rule-01.ts#L18 }
    JSXOpeningElement({ node }) {
      if (node.name.type === "JSXIdentifier" && node.name.name === "button") {
        const hasButtonClassName = node.attributes.find((attribute) => {
          return (
            attribute.type === "JSXAttribute" &&
            attribute.name.type === "JSXIdentifier" &&
            attribute.name.name === "className" &&
            attribute.value.type === "StringLiteral" &&
            attribute.value.value.split(" ").includes("button")
          );
        });

        if (!hasButtonClassName) return;

        // At this point, it means a violation (eg: 
        // `<button className="button" />`) was found. 
        // Print the error, the current file, and 
        // concatenate the line and column of the 
        // violation position in the original source 
        // code. This makes it easy to copy and paste 
        // into an editor like VSCode and it'll open the
        // file with the cursor at that position.
        const { start } = node.loc;
        console.error(
          `${path.resolve(file)}:${start.line}:${start.column + 1}`
        );
        console.error(
          `  Found "button" element that should be "Button" component.`
        );
      }
    },
```

Implement a linting rule to prevent the code we just transformed from being reintroduced in the future

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

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

How to Ensure Codebase is Up to Date With Linting Rules