From Compiler Error to Safe Fix: What I Learned Building a TypeScript Auto-Fixer

Building a TypeScript Auto-Fixer Taught Me Something Unexpected

When I started building a TypeScript auto-fixer, I assumed the problem was simple:

Compiler Error
↓
Edit Text
↓
Done

The more I worked on it, the more I realized I was completely wrong.

What I Expected

For example, consider this error:

interface Props {
title: string;
}

function Card({ title, subtitle }: Props) {
return subtitle;
}

TypeScript reports:

TS2339: Property 'subtitle' does not exist on type 'Props'

My first thought was:

Find the line
↓
Insert some text
↓
Save the file

Easy, right?

What I Discovered

The real problem wasn't editing text.

It was understanding code structure.

Before making a change, I needed to know:

What property is missing?
↓
Which type owns it?
↓
Does it already exist?
↓
Where should it be inserted?

That led me into the TypeScript Compiler API and AST transformations.

The implementation eventually looked more like this:

Compiler
↓
Diagnostics
↓
AST
↓
Transformation
↓
Validation

The Trust Problem

Suppose a tool discovers a missing property.

Should it generate:

subtitle?: string;

or

subtitle?: any;

Both require assumptions.

Instead, I chose:

subtitle?: unknown;

It's safer and deterministic.

The goal isn't to guess developer intent.

The goal is to make safe, predictable changes.

Final Thought

The biggest surprise wasn't learning the TypeScript Compiler API.

It was realizing that code automation is much closer to compiler engineering than text processing.

I thought I was building a tool that edits files.

What I was actually building was a pipeline that:

Understands
↓
Transforms
↓
Verifies

And that completely changed how I think about developer tooling.