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

---
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"
code: https://gitlab.com/fullstackio/books/newline-course-apps/spencer-miskoviak-practical-abstract-syntax-trees-app/-/tree/main/code/module_06/lesson_06.01/App?ref_type=heads
---

# 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-00.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-00.ts url=https&#x3A;//gitlab.com/fullstackio/books/practical-ast-and-codemods/module_06/lesson_06.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_06/lesson_06.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-01.ts url=https&#x3A;//gitlab.com/fullstackio/books/practical-ast-and-codemods/module_06/lesson_06.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