TypeScript 6.0's strict default would turn your callbacks into a variance audit

A post on dev.to argues that TypeScript 6.0 enables strict mode by default, and that the flag most likely to break working code on upgrade is `strictFunctionTypes` ^[1]. If that holds, a setting you never opted into starts rejecting callbacks that have compiled for years ^[1], and the remedy is not one line of tsconfig but a review of how each callback was declared ^[4].

The shape of the break is small and common. A callback registered against an array method declares that it accepts `Animal` while the consumer will call it with `Dog`; pre-6.0 TypeScript allowed that through bivariant parameter checking, and post-6.0 the compiler rejects it as unsafe ^[3]. The rule being enforced is contravariance: a function accepting a more general parameter type can stand in for one accepting a more specific type, so a slot expecting `Dog` will take a function that accepts `Animal`, but not the reverse ^[5]. Return types run the other way and are covariant, because a function returning `Dog` can substitute for one returning `Animal` and the caller only ever receives something more specific than it asked for ^[7].

The compiler cares because the consumer controls the arguments. `Array<Dog>.map` will invoke the callback with `Dog` instances, and if the signature declares `(animal: Animal) => void` then every operation in the body has to be safe for the broader type; the post's example is that accepting a function which expects `Dog` lets `dog.bark()` run against a generic `Animal` and crash at runtime ^[6].

Here is why this is an audit rather than a flag flip. Variance depends on the syntax you used: a method signature such as `foo(x: T): void` keeps bivariant checking for backward compatibility, while the property form `foo: (x: T) => void` gets contravariant checking ^[4]. Two declarations that read identically to a human are treated differently by the compiler, so the error count you get from turning the flag on is a symptom, not a measure of the work.

The escape hatches are where the cost gets moved rather than paid. Teams facing hundreds of errors reach for `any` or incorrect casts that introduce runtime bugs, according to the post ^[8], which lists the legitimate options as widening parameter types to unions, switching to method syntax where bivariance is genuinely intended, or adding generic constraints that preserve assignability without `any` ^[9]. Note what the method-syntax rewrite actually does: because method signatures retain bivariance, rewriting a function property as a method restores exactly the pre-6.0 acceptance and changes nothing at runtime ^[1]. A cast does the same trick, keeping the unsound call path and removing the warning about it ^[2]. The post also argues that disabling `strictFunctionTypes` outright leaves you with a type system that diverges from third-party libraries whose types are built for contravariance ^[10].

Two things to check before you budget for this. The dev.to post carries a disclosure that it was written with AI assistance under human supervision and review ^[2], and in the text supplied it asserts the 6.0 default change without pointing to a release note, issue number, or date ^[11]; confirm the default against TypeScript's own release notes before scheduling work. In the meantime the dry run is cheap: set `strictFunctionTypes` to true on a branch and count what falls over ^[1]. That number is your exposure whether or not 6.0 ships the default.