DEV Community: i-am-killvish

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 🙂