Yes, you should upgrade to TypeScript 5.9 — here’s why

TypeScript 5.9 is here. The question on your mind after you read the announcement is likely: “Should we upgrade?”

The short answer is a definitive yes. TypeScript 5.9 is not an incremental update; it’s a significant leap forward that offers a good mix of performance improvements and developer-centered features that will impact your work.

This release speaks to the TypeScript team’s commitment to listening to its community and creating a type system that is not only great but also a joy to use. What’s particularly noteworthy about 5.9 is how it prioritizes small improvements that actually matter, telling us the most impactful changes aren’t always the loud ones.

In this article, we’ll look into the key features of TypeScript 5.9, exploring what they are and why they matter. We’ll examine the redesigned tsc --init command, the exciting new import defer syntax, expandable hovers, and significant performance improvements that make this upgrade worthwhile.

The philosophy behind the changes in TypeScript 5.9

What strikes me most about TypeScript 5.9 isn’t a single feature in particular, but rather the philosophy that seems to guide this release.

Personally, I do feel the TypeScript team appears to be asking fundamentally different questions: How do we reduce cognitive load? How do we make performance improvements that developers will actually feel? How do we bridge the gap between language features?

This shift in thinking is evident in four key areas that deserve deeper exploration.

Project initialization: The tsc --init

Let’s start with something seemingly not exciting: the previous project initialization. The revamped tsc --init command might appear like a minor quality-of-life improvement, but it represents something much more significant. It’s a recognition that first impressions matter in any developer tools.

The old tsconfig.json generated by previous versions was more like a comprehensive documentation. Every possible option was meticulously commented out, creating a file that was simultaneously helpful and overwhelming. It was like handing someone a 200-page manual when they just wanted to turn on a device.

The new approach generates this instead:

{
  "compilerOptions": {
    "target": "es2020",
    "module": "node16",
    "strict": true,
    "esModuleInterop": true,
    "skipLibCheck": true,
    "forceConsistentCasingInFileNames": true
  }
}

It’s not just about fewer lines of code. It’s more about making good choices that reflect current best practices. The inclusion of "strict": true by default sends a message that reads that the TypeScript team believes strict type checking should be normal, and not an exception.

While the default configuration was intentionally minimal, it establishes a foundation that every team should build on. For example, adding "noUncheckedIndexedAccess": true is a common next step that many teams adopt to enhance array safety:

// Without noUncheckedIndexedAccess (current default)
const users = ['Alice', 'Bob'];
const thirdUser = users[2]; // Type: string (but actually undefined!)
console.log(thirdUser.toUpperCase()); // Runtime error!

// With noUncheckedIndexedAccess enabled (recommended addition)
const users = ['Alice', 'Bob'];
const thirdUser = users[2]; // Type: string | undefined
if (thirdUser) {
  console.log(thirdUser.toUpperCase()); // Safe!
}

This change reveals a bigger picture in tooling; it’s a move from configure this first to convention-first approaches.

It’s the same philosophy that made Create React App successful, drives the popularity of Next.js, and makes tools like Vite appealing to developers who want to start building rather than configuring.

Performance improvements

From observation, performance improvements can be perceived in two forms:

1. Impressive technical achievements that users really never get to notice, and
2. The meaningful improvements that genuinely affect their users’ daily workflows.

TypeScript 5.9 undoubtedly belongs to the second, and here is how:

Caching intermediate type instantiations might sound like an obscure implementation detail, but it has a real impact every time you save a file in a large codebase.

When working with complex types — the kind that libraries like React Query or tRPC largely use — the TypeScript compiler spends a good amount of time creating and destroying temporary type representations. This caching optimization helps reduce that overhead, making your development experience noticeably faster.

Here’s an example of the optimization address:

// Complex generic types that benefit from instantiation caching
type DeepPartial<T> = {
  [P in keyof T]?: T[P] extends object
    ? DeepPartial<T[P]>
    : T[P];
};

type APIResponse<T extends Record<string, any>> = {
  data: T;
  meta: {
    timestamp: number;
    version: string;
  };
  errors?: Array<{
    field: keyof T;
    message: string;
  }>;
};

// When used with complex nested types, this creates many intermediate instantiations
type UserResponse = APIResponse<{
  user: {
    profile: {
      personal: { name: string; age: number };
      professional: { title: string; company: string };
    };
    preferences: DeepPartial<{
      notifications: { email: boolean; push: boolean };
      privacy: { public: boolean; analytics: boolean };
    }>;
  };
}>;

When TypeScript processes types like this, it creates numerous intermediate type representations. Previously, the compiler would regenerate these intermediate types repeatedly, even when working with the same type combinations. The new caching mechanism recognizes when it’s already computed a specific type instantiation and reuses that work.

---

Over 200k developers use LogRocket to create better digital experiences

Learn more →

---

This optimization reveals something important about how TypeScript is actually used in production. TypeScript applications don’t just use basic types; they rely heavily on generic patterns, conditional types, and mapped types that push the language’s type system to its limits.

Combined with other compiler optimizations in 5.9 (like removing unnecessary function wrappers in generated code), these improvements deliver an 11% speed increase in type checking. While that might sound modest, consider what this means in practice: a more responsive IDE experience, quicker feedback during development, and reduced CI/CD pipeline times.

Understanding import defer

With the introduction of import defer syntax, we can see TypeScript’s attempt to stay ahead of JavaScript specifications while solving performance problems.

Let’s start with how the syntax looks:

import defer * as expensiveLibrary from "./heavy-processing-module.js";

This simple syntax addresses a fundamental problem in JavaScript applications. As an application grows, importing and evaluating modules can impact user experience. Here’s a practical example that shows the behavior of deferred imports:

// heavy-chart-module.ts
console.log("Initializing expensive WebGL context...");

// This expensive initialization would happen at module evaluation
const gl = canvas.getContext('webgl2');
initializeShaders();
compileComplexMathLibrary();

export class AdvancedChartRenderer {
  render(data: ChartData) {
    // Complex rendering logic
  }
}

// main.ts
import defer * as chartModule from "./heavy-chart-module.js";

// Application starts immediately - no expensive WebGL initialization yet
console.log("App is ready!");

// Later, when the user clicks a button...
function showAdvancedCharts() {
  // Only NOW would the expensive initialization happen
  const renderer = new chartModule.AdvancedChartRenderer();
  renderer.render(chartData);
}

However, it’s important we understand the reality of this feature. As of today, import defer is not yet supported by any major browser or Node.js runtime. This means that while you can write the code in TypeScript, it will fail in a production environment without a specialized bundler support or experimental runtime flags.

So why should we include it then? What’s particularly intriguing is what TypeScript doesn’t try to do with it. The compiler doesn’t transform import defer into a polyfill; it passes the syntax through, unchanged.

The restriction to namespace imports only (aka import defer * as module) makes sense when you consider the evaluations. Named imports would create unclear expectations about when individual exports become available:

// This would be confusing - when does `heavyFunction` get evaluated?
import defer { heavyFunction } from "./expensive-module.js";

// This is clear - the entire module evaluates when you access any property
import defer * as expensiveModule from "./expensive-module.js";
const result = expensiveModule.heavyFunction(); // Evaluation happens here

This exposes a strong perspective on language design; sometimes, the best thing a transpiler can do is get out of the way and let the underlying platform grow.

The expandable hovers

The expandable hovers feature might seem like the least significant addition, but it shows the recognition that developer experience is also about what’s discoverable.

Complex types provide safety and expressiveness, but they can also be complex to explore. Being able to expand and collapse type information directly when we hover makes the exploration process seamless.

Let’s look at this common scenario when working with a library like React Hook Form:

import { useForm } from 'react-hook-form';

// Previously, hovering over `control` would show something like:
// control: Control<FieldValues, any>
// Which tells you almost nothing useful

const { control, handleSubmit } = useForm<{
  username: string;
  email: string;
  preferences: {
    newsletter: boolean;
    notifications: Array<{
      type: 'email' | 'push';
      enabled: boolean;
    }>;
  };
}>();

With expandable hovers, developers can now dig deep into these complex types directly in their editor, seeing the full structure without losing context or opening multiple files.

I’ve noticed my confidence with TypeScript directly correlates with the ability to understand and navigate complex types. When team members can quickly explore type definitions, they’re more likely to use advanced TypeScript features.

The hover feature complements this beautifully. Here’s a practical example:

'use client';
import { useForm } from 'react-hook-form';
// Complex nested form type that will demonstrate expandable hovers beautifully
interface UserRegistrationForm {
  username: string;
  email: string;
  password: string;
  profile: {
    firstName: string;
    lastName: string;
    dateOfBirth: string;
    address: {
      street: string;
      city: string;
      state: string;
      zipCode: string;
      country: string;
    };
  };
  preferences: {
    newsletter: boolean;
    notifications: Array<{
      type: 'email' | 'push' | 'sms';
      enabled: boolean;
      frequency: 'immediate' | 'daily' | 'weekly' | 'never';
      categories: Array<{
        name: string;
        subscribed: boolean;
        priority: 'low' | 'medium' | 'high';
      }>;
    }>;
    privacy: {
      profileVisible: boolean;
      dataSharing: {
        analytics: boolean;
        marketing: boolean;
        thirdParty: boolean;
        retention: {
          duration: number;
          unit: 'days' | 'months' | 'years';
          autoDelete: boolean;
        };
      };
    };
  };
  socialMedia: Record<string, {
    platform: 'twitter' | 'facebook' | 'linkedin' | 'github';
    username: string;
    isPublic: boolean;
    verificationStatus: 'verified' | 'pending' | 'unverified';
    metadata: Record<string, any>;
  }>;
}
export function ReactHookFormDemo() {
  // Hovering over 'control' here will show the expandable Control<UserRegistrationForm, any> type
  // You can expand it to see the full UserRegistrationForm structure
  const { control, handleSubmit, formState: { errors } } = useForm<UserRegistrationForm>({
    defaultValues: {
      username: '',
      email: '',
      password: '',
      profile: {
        firstName: '',
        lastName: '',
        dateOfBirth: '',
        address: {
          street: '',
          city: '',
          state: '',
          zipCode: '',
          country: 'US'
        }
      },
      preferences: {
        newsletter: false,
        notifications: [{
          type: 'email',
          enabled: true,
          frequency: 'daily',
          categories: [{
            name: 'updates',
            subscribed: true,
            priority: 'medium'
          }]
        }],
        privacy: {
          profileVisible: true,
          dataSharing: {
            analytics: false,
            marketing: false,
            thirdParty: false,
            retention: {
              duration: 365,
              unit: 'days',
              autoDelete: true
            }
          }
        }
      },
      socialMedia: {}
    }

Here’s a GIF for better visualization:

This feature acknowledges that TypeScript development often involves working with types you didn’t write, in libraries you don’t maintain, solving problems you’re encountering for the first time. The ability to understand complex types without losing context, without jumping between files or opening multiple editors, is a genuine productive add-on.

Looking forward: What’s next for TypeScript?

This article wasn’t only focused on answering whether to upgrade to TypeScript 5.9, because the improvements make it a straightforward decision for most teams.

The more interesting question is: what does this release tell us about the direction of JavaScript tools and developer experience?

TypeScript 5.9 suggests that we’re entering a phase where improvements to existing workflows matter as much as any and every groundbreaking new feature. It’s a recognition that the most impactful changes aren’t always the most visible ones. Sometimes the best thing a tool can do is let you focus on solving the problems that matter to your users.

LogRocket understands everything users do in your web and mobile apps.

LogRocket lets you replay user sessions, eliminating guesswork by showing exactly what users experienced. It captures console logs, errors, network requests, and pixel-perfect DOM recordings — compatible with all frameworks, and with plugins to log additional context from Redux, Vuex, and @ngrx/store.

With Galileo AI, you can instantly identify and explain user struggles with automated monitoring of your entire product experience.

Modernize how you understand your web and mobile apps — start monitoring for free.