Flow JavaScript Type Checker: Still Worth It in 2026?

Is Flow Still Alive?

This deserves settling first, because the answer most search results imply is wrong. Here are the numbers, read from the npm registry for the same week.

Two conclusions follow, and they are not in tension. Flow is actively developed, with a release three days before this article was written. Flow is also roughly one six-hundredth the size of TypeScript by weekly downloads, which is the constraint that matters when you need type definitions for a package you did not write.

The version number is worth a note too. Flow has never reached 1.0, and 0.326.0 is a minor release in a long sequence rather than a sign of immaturity. Breaking changes do arrive in those minors, which is a real maintenance cost and a fair thing to weigh.

What Flow Actually Does

Flow reads your JavaScript, builds a model of what type each value can hold, and reports places where those types cannot be reconciled. It never executes the code, which puts it in the same family as a linter, checking properties of the source text rather than of the running program.

What separates it from a linter is inference. A linter matches patterns you configured. Flow reasons about values as they move through the program, so it can flag a mismatch several function calls away from where you introduced it, in code carrying no annotations at all.

Adoption is per file, which was a deliberate design decision and remains its most practical feature. A pragma comment marks a file for checking; without it, Flow ignores the file entirely.

// @flow

function greet(name: string): string {
  return 'Hello, ' + name;
}

greet(42);
// Flow reports: Cannot call greet with 42 bound to name
// because number is incompatible with string.

That means a repository can enable Flow globally and have it check only the twenty files someone opted in, then grow from there. Migrating a large codebase to a checker is otherwise an all-or-nothing commitment that teams postpone indefinitely.

Writing Flow Types

The syntax will look familiar to anyone who has written TypeScript, with a handful of deliberate differences.

// @flow

// A maybe type. The question mark allows null and undefined,
// and Flow will not let you use it until you have checked.
function label(count: ?number): string {
  if (count == null) return 'unknown';
  return String(count);
}

// An exact object type. The pipes mean no extra properties
// are permitted, which is the default Flow chose and
// TypeScript did not.
type User = {| id: number, email: string |};

// A union, and a function typed against it.
type Status = 'active' | 'suspended' | 'closed';

function canLogIn(user: User, status: Status): boolean {
  return status === 'active';
}

The maybe type is where Flow earned its early reputation. Null handling was strict by default years before that became the common expectation, and a value that might be null cannot be used until the check exists. Exact object types work the same way, refusing extra properties rather than tolerating them.

Neither advantage is decisive now, because equivalent strictness is available elsewhere. They explain why Flow was chosen at the time, which is useful context if you have inherited a codebase that uses it.

Flow vs TypeScript

The row that decides it is third-party types, and the reason is worth stating because it is not about language design at all. Types are most valuable at the boundaries of code you did not write. When most published packages ship TypeScript definitions and few ship Flow ones, choosing Flow means writing those definitions yourself or working without them at exactly the boundary where a checker helps most.

Who Should Use Flow

A short list, honestly drawn.

• Teams already running Flow across a substantial codebase, where the migration cost is real and the checker is doing its job. Working code is not a reason to migrate.
• Organisations that maintain their own type definitions regardless, because the ecosystem gap costs them least.
• Codebases that depend on a Flow-specific behaviour and have tests that would catch its absence, which is rarer than it sounds and worth verifying rather than assuming.

For a new project, the answer is TypeScript, and the reasoning is not that Flow's type system is worse. It is that a type checker's value comes from everything around it, and one of the two has a far larger everything.

Migrating Off Flow

If you have decided to move, move file by file. Both checkers ignore what is not theirs, so they coexist happily during a transition that may take months.

Codemods handle most of the syntax. What they cannot decide is nullability, because a Flow maybe type that was never really nullable in practice should become a plain type rather than a union, and only someone who knows the code can tell. Convert the leaf modules first, keep both checkers green on every commit, and do not mix a migration with a refactor.

What Types Cannot Prove

Whichever checker you land on, its guarantee has a precise shape: values have the types you declared. That is genuinely valuable and it is not the same as the program being correct.

// @flow

// Fully typed. Flow reports nothing.
function orderTotal(subtotal: number, taxRate: number, hasCoupon: boolean): number {
  if (!hasCoupon) {
    return subtotal * (1 + taxRate);
  }
  return subtotal;
}

// orderTotal(100, 0.2, false) -> 120
// orderTotal(100, 0.2, true)  -> 100   tax silently dropped

Every annotation is right. Every value has the type it claims. The function drops tax on any discounted order, and no type system in any language will report it, because nothing about the types is wrong. The intention is wrong, and intentions are not typed.

The same boundary applies to the browser. A component whose props typecheck can still render nothing, post to the wrong endpoint, or break on a viewport nobody tried. The distinction is the one covered in verification vs validation, and it is the reason a checker belongs in front of a test suite rather than instead of one.

That order is the practical takeaway. Types remove a class of defect cheaply and early. Executing the code removes a different class that no amount of annotation reaches, and the two do not overlap.

Conclusion

If you are on Flow and it is working, stay. The project ships releases, your codebase is annotated, and a migration is real engineering time spent on a change your users will never see. Revisit only when the ecosystem gap starts costing you, which usually shows up as writing your own definitions for a package everyone else gets typed for free.

If you are starting something new, use TypeScript, and understand that you are choosing an ecosystem rather than a type system. If you are migrating, go file by file, convert leaves first, and treat maybe types as the decisions rather than the codemod's job.

Either way, put a check behind the checker. Types stop the wrong shape reaching a function; running the code stops the wrong number reaching a customer. TestMu AI's automation cloud covers that second half across real browsers, the automation documentation covers wiring it in, and JavaScript unit testing covers the layer in between.