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.