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

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

# typescript# javascript# opensource# webdev
TS2339 Isn't Hard to Fix. It's Just Repetitive.i-am-killvish

One TypeScript Error That Creates More Workflow Friction Than It Should One TypeScript...

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;
}
Enter fullscreen mode Exit fullscreen mode

A few seconds later the compiler responds with:

Property 'subtitle' does not exist on type 'Props'
Enter fullscreen mode Exit fullscreen mode

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;
Enter fullscreen mode Exit fullscreen mode

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;
Enter fullscreen mode Exit fullscreen mode

The friction is everything around it.

Stop coding
↓
Find the type definition
↓
Add the property
↓
Return to the component
↓
Run TypeScript again
Enter fullscreen mode Exit fullscreen mode

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;
};
Enter fullscreen mode Exit fullscreen mode

Then requirements change.

Add subtitle
↓
Add description
↓
Add icon
↓
Add badge
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

In many cases the remaining work is simply:

Structural synchronization
Enter fullscreen mode Exit fullscreen mode

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?
Enter fullscreen mode Exit fullscreen mode

I became more interested in:

How do I eliminate repetitive developer actions?
Enter fullscreen mode Exit fullscreen mode

The latest release adds TS2339 property synchronization.

For example:

type Props = {
  title: string;
};

function Card({ title, subtitle }: Props) {
  return subtitle;
}
Enter fullscreen mode Exit fullscreen mode

can automatically become:

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

function Card({ title, subtitle }: Props) {
  return subtitle;
}
Enter fullscreen mode Exit fullscreen mode

using compiler diagnostics and AST transformations.

The Workflow 

TypeScript Diagnostic
        ↓
AST Analysis
        ↓
Safe Structural Mutation
        ↓
Recompile
        ↓
Verify
Enter fullscreen mode Exit fullscreen mode

No AI.

No semantic guessing.

No invented types.

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

subtitle?: unknown;
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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?
Enter fullscreen mode Exit fullscreen mode