DEV Community: i-am-killvish

Regex vs AST: Why Compiler-Aware Code Transformations Are Safer

i-am-killvish — Mon, 08 Jun 2026 14:05:42 +0000

Regex vs AST: Why Compiler-Aware Code Transformations Are Safer

When developers want to automate code changes, the first instinct is often:

Find text
↓
Replace text
↓
Done

For simple cases, that works.

For real codebases, it becomes dangerous surprisingly fast.

The Regex Approach

Suppose we want to modify every occurrence of:

user.name

A regex solution might look like:

content.replace(/user.name/g, "user.fullName");

Simple.

Until you discover cases like:

const text = "user.name";

\ts // TODO: migrate user.name \\

Your regex doesn't understand code.

It only understands text.

The AST Approach

An AST (Abstract Syntax Tree) understands structure.

Instead of seeing:

\ts user.name \\

as characters, it sees:

\txt PropertyAccessExpression ├── user └── name \\

That distinction is powerful.

Now a transformation can target only actual code constructs and ignore comments, strings, and unrelated text.

A Real Example

While building a TypeScript auto-fixer, I recently worked on:

\txt TS2339: Property does not exist on type \\

The fix wasn't:

\txt Insert text somewhere \\

The fix was:

\txt Find interface ↓ Check existing properties ↓ Create AST node ↓ Update interface declaration ↓ Validate with compiler \\

At that point, regex isn't really an option.

The transformation needs structural understanding.

Why AST Wins

Regex:

\txt Fast Simple Fragile \\

AST:

\txt Structured Safe Compiler-aware \\

The larger the codebase becomes, the more valuable that structural understanding gets.

Final Thought

The biggest lesson I've learned building developer tooling is that code isn't text.

It's structure.

And once you start thinking in terms of structure instead of strings, a lot of automation problems become much easier to solve safely.

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

i-am-killvish — Mon, 08 Jun 2026 10:13:39 +0000

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;

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.

TS2339 Isn't Hard to Fix. It's Just Repetitive.

i-am-killvish — Fri, 05 Jun 2026 17:24:16 +0000

One TypeScript Error That Creates More Workflow Friction Than It Should

One TypeScript error I keep seeing across React and TypeScript projects looks like this:

type Props = {
  title: string;
};

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

A few seconds later the compiler responds with:

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

At first glance this seems completely reasonable.

And honestly, it is.

The Interesting Part

The problem usually isn't understanding the fix.

Most developers already know what needs to happen.

Somewhere inside the type definition:

subtitle?: unknown;

needs to be added.

The compiler knows a property is missing.

The developer knows a property is missing.

The remaining work is usually just a mechanical edit.

But From The Developer Side...

The actual friction isn't writing:

subtitle?: unknown;

The friction is everything around it.

Stop coding
↓
Find the type definition
↓
Add the property
↓
Return to the component
↓
Run TypeScript again

Individually none of these steps feel expensive.

Repeated dozens of times, they become workflow interruptions.

Why It Happens So Often

A component often starts here:

type Props = {
  title: string;
};

Then requirements change.

Add subtitle
↓
Add description
↓
Add icon
↓
Add badge

Implementation and types constantly drift out of sync.

TS2339 is often the compiler catching that drift.

The Real Friction

The more I work with TypeScript, the more I notice that many frustrations aren't difficult problems.

They're repetitive problems.

Obvious
Mechanical
Predictable
Interruptive

Individually tiny.

Repeated constantly.

Compiler Errors Are Often Already Solved

What's interesting about TS2339 is that the compiler already provides most of the information needed.

Missing property
Target type

In many cases the remaining work is simply:

Structural synchronization

Not debugging.

Not architecture.

Not reasoning.

Just synchronization.

Why This Became Interesting To Me

While building my CLI project fixmyfile, I started exploring these kinds of compiler-driven workflow interruptions.

Instead of asking:

How do I generate code?

I became more interested in:

How do I eliminate repetitive developer actions?

The latest release adds TS2339 property synchronization.

For example:

type Props = {
  title: string;
};

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

can automatically become:

type Props = {
  title: string;
  subtitle?: unknown;
};

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

using compiler diagnostics and AST transformations.

The Workflow

TypeScript Diagnostic
        ↓
AST Analysis
        ↓
Safe Structural Mutation
        ↓
Recompile
        ↓
Verify

No AI.

No semantic guessing.

No invented types.

If the compiler only knows a property is missing, FixMyFile adds:

subtitle?: unknown;

and verifies the result by recompiling.

What I Learned

Developer productivity isn't always about solving harder problems.

Sometimes it's about removing tiny interruptions that happen hundreds of times.

5 seconds
×
Hundreds of repetitions
=
Real workflow friction

Final Thoughts

I don't think TS2339 is a bad error.

The compiler is doing exactly what it should.

But I do think there's an opportunity for tooling that reduces repetitive structural fixes while preserving type safety.

Because many developer frustrations don't come from complexity.

They come from repetition.

If you work heavily with TypeScript:

Which compiler error do you find yourself fixing over and over again?

Why React + TypeScript Nullability Slowly Becomes Exhausting

i-am-killvish — Sat, 23 May 2026 14:47:44 +0000

One React + TypeScript Pattern That Slowly Turns Into Workflow Fatigue

One React + TypeScript pattern I keep seeing everywhere looks like this:

const [user, setUser] = useState<User | null>(null);

A few minutes later, the component becomes:

user?.name
user?.email
user?.profile?.avatar
user?.settings?.theme

Repeated across the entire component tree.

Individually, none of these lines feel like a huge problem.

But repeated hundreds of times across a codebase,
they slowly become surprisingly exhausting.

The Interesting Part

The frustrating thing is:

TypeScript is not wrong here.

React state often starts as null because:

data is loading
async requests haven't completed
auth state is unresolved
server data hasn't arrived yet

So the compiler is being intentionally conservative.

And honestly, that safety is useful.

But From The Developer Side...

After a while, it can start feeling like this:

user?.name
user?.email
user?.profile?.avatar
user?.settings?.theme
user?.preferences?.language

over and over again.

Especially in larger React applications where nullable async state exists almost everywhere.

Async Fetching Makes It Worse

A very common pattern looks like this:

const [user, setUser] = useState<User | null>(null);

useEffect(() => {
  fetchUser().then(setUser);
}, []);

From TypeScript’s perspective:

user might still be null

which is technically correct.

But mentally, developers often already understand the lifecycle flow:

loading → data arrives → component renders

That creates an interesting tension between:

compiler safety
runtime understanding
developer ergonomics

The Real Friction

I’ve started noticing that many TypeScript frustrations are not huge architectural problems.

They’re usually:

repetitive
mechanical
mentally interruptive
individually tiny
but exhausting when repeated constantly

Things like:

user?.name

or:

if (!user) return null;

don’t feel huge in isolation.

But repeated across hundreds of components,
they slowly create workflow fatigue.

React + TypeScript Has A Unique Kind Of Friction

What makes React especially interesting is that:

async UI state naturally creates nullability everywhere

Unlike many backend systems where data may already be validated before use,
React components constantly deal with:

loading states
delayed async data
partial renders
optional props
unresolved context values

which makes defensive rendering patterns extremely common.

Why This Became Interesting To Me

Recently I’ve been exploring these React + TypeScript friction patterns more deeply while working on compiler-aware tooling and AST-based fixes in my CLI project fixmyfile.

And honestly, the deeper I go into TypeScript ecosystems,
the more I feel developer frustration often comes from:

small repetitive safety patterns

not massive technical failures.

Final Thoughts

I don’t think TypeScript is wrong here.

The compiler is intentionally conservative.

But I do think there’s a growing opportunity for tooling and developer workflows that reduce:

repetitive defensive rendering
cognitive interruptions
mechanical nullability friction

without sacrificing type safety.

And honestly, React + strict TypeScript has become one of the most interesting ecosystems to study from a developer ergonomics perspective.

If you work heavily with React + TypeScript, I’d genuinely be curious:

what repetitive friction pattern annoys you the most?

Why Autofixing Missing TypeScript Arguments Is Harder Than It Looks

i-am-killvish — Mon, 18 May 2026 11:17:28 +0000

Why Autofixing Missing TypeScript Arguments Is Harder Than It Looks

One TypeScript error that looked deceptively simple to autofix at first was this:

greet("john");

TypeScript immediately complains:

Expected 2 arguments, but got 1.

At first glance, the fix feels obvious.

Why not just automatically transform this into:

greet("john", 0);

or maybe:

greet("john", "");

depending on the parameter type?

The compiler error disappears instantly.

Problem solved… right?

The Dangerous Part

The more I thought about it though, the more uncomfortable that approach started feeling.

Because now the compiler is happy.

But the runtime behavior may already be wrong.

That 0 might silently affect:

pricing logic
discounts
analytics
permissions
feature flags
business calculations

The code compiles.

But the original intent may already be broken.

A Small Example

Imagine something like this:

applyDiscount(user, percentage);

Now suppose the developer accidentally forgets the second argument:

applyDiscount(user);

A naive autofix might generate:

applyDiscount(user, 0);

TypeScript becomes happy.

But now the business logic silently changes.

That missing argument may not have meant:

0% discount

It may have meant:

"the developer forgot something important"

That was a pretty important realization for me.

Compiler Correct ≠ Runtime Correct

One thing I’ve started realizing while building TypeScript tooling is this:

making the compiler happy

and:

preserving runtime intent

are very different problems.

A fix can be technically valid from the compiler’s perspective while still being dangerous for the actual application logic.

That’s where autofixing becomes surprisingly tricky.

Because the more aggressively a tool tries to “repair” code automatically,
the easier it becomes to silently change behavior developers actually cared about.

Why This Felt Wrong

Initially, I tried generating values automatically based on the parameter type.

Something like:

number  -> 0
string  -> ""
boolean -> true

From the compiler’s perspective:

perfect

From a runtime/business perspective:

potentially dangerous

Because now the tool was effectively:

inventing developer intent

And that felt wrong.

A developer may have forgotten:

a discount percentage
a tax value
a feature flag
a permission value
a calculation input

Automatically generating fake business values could hide real logic mistakes instead of helping reveal them.

Rethinking The Repair Strategy

That realization eventually made me redesign the TS2554 repair logic inside my CLI tool fixmyfile.

Instead of inventing business values automatically,
the tool now prefers minimal compiler-safe placeholders like:

undefined as any

So this:

greet("john");

becomes:

greet("john", undefined as any);

The important difference is that:

the compiler error disappears
the missing value stays visible
runtime intent is not silently fabricated
developers can intentionally revisit the logic later

That felt like a much safer tradeoff.

The Interesting Part Wasn't The AST Transform

Ironically, generating the AST transformation itself was not even the hardest part.

The harder part was making the fix:

predictable
minimal
non-destructive
repeatable
compiler-aware

because AST transforms can become destructive very quickly if existing arguments are not preserved carefully.

Early versions of the fixer accidentally replaced valid existing arguments entirely.

That was the moment I started realizing how much developer tooling is really about:

preserving developer trust

instead of simply replacing syntax.

Small TypeScript Friction Adds Up

One thing I keep noticing in TypeScript ecosystems is that many frustrations are not huge architectural problems.

They’re usually:

repetitive
mechanical
mentally draining
individually tiny
but exhausting when repeated constantly

Things like:

user?.name

.filter(Boolean)

greet("john")

all look small individually.

But repeated hundreds of times,
they slowly create workflow friction.

Final Thoughts

I don’t think TypeScript is wrong here.

The compiler is intentionally conservative.

But I do think there’s a growing opportunity for tooling that helps bridge the gap between:

what developers obviously mean

and:

what the compiler can safely infer

That’s the direction I’ve been exploring recently with compiler-aware AST fixes and TypeScript tooling.

And honestly, it has become one of the most interesting parts of working with the TypeScript ecosystem so far.

If you’ve run into similar TypeScript friction patterns repeatedly, I’d genuinely love to hear which ones annoy you the most.

Why `.filter(Boolean)` Doesn't Narrow Types in TypeScript (and how I built an AST fixer for it)

i-am-killvish — Thu, 14 May 2026 01:09:00 +0000

One TypeScript behavior that confused me for a long time was this:

const values = [1, 2, undefined, 4].filter(Boolean);

values.map((v) => v * 2);

At runtime, this works perfectly.

But TypeScript may still complain:

'v' is possibly 'undefined'

At first glance, this feels wrong.

We already filtered the array.
Why is TypeScript still acting like undefined can exist?

The Important Thing to Understand

TypeScript does not deeply analyze what Boolean() actually does.

Instead, TypeScript mostly relies on:

control-flow analysis
recognized syntax patterns
explicit type predicates

So when you write:

.filter(Boolean)

TypeScript mainly sees:

"A function returning boolean"

not:

"This removes undefined and null values from the array"

That relationship gets lost.

Why `!!value` Feels Different

This is similar to another TypeScript behavior:

const isValid = !!value;

usually narrows correctly, while:

const isValid = Boolean(value);

often does not.

Even though both behave similarly at runtime.

The reason is that TypeScript recognizes:

!!value

as a direct truthiness check pattern.

But:

Boolean(value)

looks like a normal function call from the compiler’s perspective.

The Correct TypeScript-Friendly Fix

Instead of:

const values = [1, 2, undefined, 4].filter(Boolean);

use an explicit type predicate:

const values = [1, 2, undefined, 4].filter(
  (x): x is NonNullable<typeof x> => Boolean(x)
);

Now TypeScript understands:

“If this function returns true,
this value is not null or undefined.”

So this works safely:

values.map((v) => v * 2);

without narrowing issues.

The Problem

This fix is technically correct.

But after seeing this pattern repeatedly across projects, I realized something:

this is mostly mechanical work

A developer already knows what they meant.

The compiler just needs help understanding it.

And that made me wonder:

Could this be fixed automatically?

Building an AST Fixer for It

I’ve been building a small TypeScript CLI tool called fixmyfile that automatically repairs repetitive TypeScript friction using compiler diagnostics and AST transformations.

One of the fixes now detects:

.filter(Boolean)

and transforms it into:

.filter((x): x is NonNullable<typeof x> => Boolean(x))

automatically.

The Interesting Part

The transformation itself was not the hardest part.

The harder part was making the fix:

predictable
safe
repeatable
compiler-aware

because TypeScript diagnostics and AST nodes do not always align exactly the way you initially expect.

That was the moment I started realizing how much developer tooling is really about:

understanding compiler behavior deeply

instead of simply replacing strings.

One Thing I’ve Learned Building This

A surprising amount of TypeScript frustration comes from:

small repetitive mechanical fixes

not huge architectural problems.

Things like:

optional chaining insertion
.filter(Boolean) narrowing
missing arguments
repetitive null checks
strict-mode cleanup

individually feel tiny.

But repeated hundreds of times, they slowly create workflow friction.

Final Thoughts

I don’t think TypeScript is wrong here.

The compiler is being conservative intentionally.

But I do think there’s a growing opportunity for tooling that helps bridge the gap between:

what developers obviously mean

and:

what the compiler can safely infer

That’s the direction I’ve been exploring recently with AST-based fixes and compiler-driven transformations.

And honestly, it has been one of the most interesting parts of working with TypeScript so far.

If you’ve run into similar TypeScript friction patterns repeatedly, I’d genuinely love to hear which ones annoy you the most.

Extending my TypeScript auto-fix CLI to handle .filter(Boolean) narrowing issues

i-am-killvish — Mon, 04 May 2026 16:29:23 +0000

A few days ago I shared a small CLI experiment called fixmyfile that automatically fixes repetitive TypeScript errors using compiler diagnostics and AST transformations.

While testing it more, I kept running into another frustrating TypeScript pattern:

const users = data.filter(Boolean);

users.map((u) => u.name);

Even after filtering values, TypeScript can still complain that:

'u' is possibly undefined

Logically the values are already filtered, but TypeScript narrowing does not always behave the way developers expect.

So I started experimenting with AST-based transformations for these cases too.

Now the CLI automatically converts:

const users = data.filter(Boolean);

into:

const users = data.filter(
  (x): x is NonNullable<typeof x> => Boolean(x)
);

which preserves narrowing correctly and removes the repeated "possibly undefined" friction afterward.

What’s been interesting while building this project is realizing how many TypeScript frustrations are not necessarily difficult problems, but repetitive workflow interruptions developers hit every day.

Still very experimental, but AST transformations are turning out to be much more powerful than simple text replacements.

Current fixes supported:

Missing function arguments (TS2554)
Basic type mismatch fixes (TS2322)
Undefined references (TS2304)
.filter(Boolean) narrowing transformations

GitHub:
https://github.com/i-am-killvish/fixmyfile

Would love feedback on:

other repetitive TS friction points
weird narrowing cases
compiler issues developers repeatedly fight with

I built a CLI that fixes TypeScript errors automatically

i-am-killvish — Sat, 25 Apr 2026 01:20:24 +0000

Fixing TypeScript errors like:

“Expected 1 arguments, but got 0 (TS2554)”

gets repetitive really fast.

So I built a small CLI tool called fixmyfile that automatically fixes some common TypeScript errors using the compiler API and AST transformations.

⚡ Demo

Fixing a TypeScript error automatically:

🧠 What it does

The tool:

scans a .ts file
detects TypeScript compiler errors
applies automatic fixes
repeats until no more changes are possible

⚡ Example

❌ Before
function greet(name: string) {
console.log(name);
}

greet(); // missing args
✅ After
greet("text");

🖥 Try it

You can run it directly using:

npx fixmyfile yourfile.ts

🧩 Currently supports

Missing function arguments (TS2554)
Basic type mismatch fixes (TS2322)
Undefined references (TS2304)

⚠️ Note

This is still experimental and focuses on common, repetitive fixes.
Always review the output before committing changes.

💬 Feedback

Would love to know:

Did it work on your code?
What errors should it support next?
Where did it break?

👉 https://github.com/i-am-killvish/fixmyfile

🚀 Why I built this

I kept running into the same TypeScript errors during development and realized many of them are predictable enough to automate.

This is an early attempt at making that process faster.

If this sounds useful, give it a try and let me know what you think 🙂

DEV Community: i-am-killvish

Regex vs AST: Why Compiler-Aware Code Transformations Are Safer

Regex vs AST: Why Compiler-Aware Code Transformations Are Safer

The Regex Approach

The AST Approach

A Real Example

Why AST Wins

Final Thought

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

Building a TypeScript Auto-Fixer Taught Me Something Unexpected

What I Expected

What I Discovered

The Trust Problem

Final Thought

TS2339 Isn't Hard to Fix. It's Just Repetitive.

One TypeScript Error That Creates More Workflow Friction Than It Should

The Interesting Part

But From The Developer Side...

Why It Happens So Often

The Real Friction

Compiler Errors Are Often Already Solved

Why This Became Interesting To Me

The Workflow

What I Learned

Final Thoughts

Why React + TypeScript Nullability Slowly Becomes Exhausting

One React + TypeScript Pattern That Slowly Turns Into Workflow Fatigue

The Interesting Part

But From The Developer Side...

Async Fetching Makes It Worse

The Real Friction

React + TypeScript Has A Unique Kind Of Friction

Why This Became Interesting To Me

Final Thoughts

Why Autofixing Missing TypeScript Arguments Is Harder Than It Looks

Why Autofixing Missing TypeScript Arguments Is Harder Than It Looks

The Dangerous Part

A Small Example

Compiler Correct ≠ Runtime Correct

Why This Felt Wrong

Rethinking The Repair Strategy

The Interesting Part Wasn't The AST Transform

Small TypeScript Friction Adds Up

Final Thoughts

Why `.filter(Boolean)` Doesn't Narrow Types in TypeScript (and how I built an AST fixer for it)

The Important Thing to Understand

Why !!value Feels Different

The Correct TypeScript-Friendly Fix

The Problem

Building an AST Fixer for It

The Interesting Part

One Thing I’ve Learned Building This

Final Thoughts

Extending my TypeScript auto-fix CLI to handle .filter(Boolean) narrowing issues

I built a CLI that fixes TypeScript errors automatically

⚡ Demo

🧠 What it does

⚡ Example

🖥 Try it

🧩 Currently supports

⚠️ Note

💬 Feedback

🚀 Why I built this

Why `!!value` Feels Different