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.