TypeScript defaults belong in the upgrade review

A TypeScript upgrade can change a project's behavior while its application source stays untouched. An omitted compiler option still has a value, supplied by the compiler version and the surrounding configuration. Before treating new diagnostics as a queue of code defects, establish which effective choices changed. The useful review starts with the compiler the project actually uses and ends with the environment that consumes its output.

TypeScript 6.0 makes that obligation concrete. The stable announcement of 23 March 2026 sets the default module to esnext. With a tsconfig.json, the default rootDir becomes the directory containing that file. Previously, the compiler inferred a common directory from non-declaration input files. Command-line compilation without a configuration file still infers it. Those are version-specific rules, not findings from running a particular application.

Start with the effective project

A repository's configuration file is only the visible part of its compiler policy. Read inherited configuration and the build entry point before concluding that an option is absent. An explicit value in a shared base can already settle the choice. Different packages may also have different contracts: a browser application sent through a bundler and a server package loaded directly should not inherit a module decision merely because they share a repository.

Record the installed compiler version separately from the version named in a proposal. The 11 February 2026 beta announcement is preview context; the March announcement establishes stable availability. Reading either page does not establish which compiler an editor, package script or continuous integration job selects. Resolve that question from the project's dependency and invocation records before making changes. Otherwise, two people can discuss the same option while reasoning about different compilers.

The same distinction applies to runtime assumptions. A compiler's default cannot establish which Node.js version runs a service, which browsers a product supports or which transformations a bundler performs. Document those facts beside the options that depend on them. This gives a reviewer a reason to accept an explicit value or a new default, instead of asking them to trust that a contemporary setting must suit every deployment.

Output layout is part of the interface

rootDir deserves attention because output location often has consumers beyond the source tree. The stable announcement describes its role in output directory structure. A review should therefore trace the generated paths expected by package entry points, deployment packaging and any scripts that locate emitted files. The possible consequence is a mismatch between producer and consumer; the announcement alone cannot tell you that your own deployment will fail.

Keep file selection and output layout separate in that discussion. Naming a root is not a substitute for explaining which files belong to a project. If a package deliberately includes files outside its configuration directory, review that arrangement explicitly. Copying a familiar source-directory setting into every package can hide the reason the previous layout existed, especially where several projects share generated code or declarations.

A practical acceptance note should name the expected emitted entry point and who consumes it. That is more useful than saying that the build configuration has been modernized. It creates a specific question for later validation: does the chosen compiler and configuration produce the layout that the consumer expects? This article does not supply a tested configuration or claim a compilation result.

Module policy needs a consumer

The esnext default is a reason to inspect module policy, not a universal prescription for deployment. Ask whether the project emits JavaScript for direct execution, delegates transformation to a bundler or only checks types. Then establish how the consuming environment interprets modules. The runtime, package metadata and build pipeline need a coherent agreement; the compiler's acceptance of a setting cannot by itself prove that agreement.

Avoid solving a module mismatch by changing unrelated application code first. If an upgrade changes an implicit choice, an intentional configuration decision can make the cause clearer. That does not justify suppressing type checks until the error count looks familiar. Configuration changes and genuine defects can coexist. Review them separately so that a temporary compatibility choice does not erase the work needed to improve the program.

Explicit choices have a maintenance cost

The strongest objection to this approach is the cost of pinning everything. It is valid. A configuration that spells out every historical default can preserve assumptions long after their justification disappears. Every extra option asks future maintainers to distinguish deliberate product requirements from copied boilerplate. Exhaustive configuration can make a project harder to understand while giving only an appearance of control.

Prefer selective explicitness. Keep a value explicit when it protects a real runtime requirement, output contract or consciously staged migration. Let an appropriate default stand when the team understands its effect and has no reason to diverge. When a temporary value remains, give it an owner and a condition for reconsideration. The review should make the decision easier to revisit, rather than turn a snapshot of one compiler into permanent policy.

This approach does not remove the need for project-specific validation. It narrows what that validation must establish and prevents a source-only review from overlooking configuration behavior. If you need help defining the runtime and output contracts of a changing application, AL+ offers custom software development. Bring the current build entry points and deployment requirements. The first useful outcome is an agreed compiler policy that explains which defaults you accept and which obligations require explicit choices.