TypeScript 5.x Features Every Developer Should Be Using in 2026

TypeScript 5.0 through 5.7 landed quietly but changed a surprising amount about how TypeScript code reads and behaves. Decorators finally reached Stage 3 spec compliance, a new using keyword handles resource cleanup deterministically, the satisfies operator killed most legitimate uses of as casts, and const type parameters removed a whole class of as const workarounds. This guide focuses on features that change daily coding patterns — not the release notes items you'll read once and forget.

Stage 3 Decorators — Now Production Ready

TypeScript's experimental decorators have existed since version 1.5, but they were based on an early TC39 proposal that changed substantially. TypeScript 5.0 implemented the finalised Stage 3 decorator specification — a different, cleaner design that works without reflect-metadata for basic use cases.

The new decorators are functions that receive a context object describing what's being decorated. Here's a practical logging decorator:

// Method decorator — logs call duration
function logDuration(
  target: Function,
  context: ClassMethodDecoratorContext
) {
  const methodName = String(context.name);

  return function (this: unknown, ...args: unknown[]) {
    const start = performance.now();
    const result = target.apply(this, args);

    if (result instanceof Promise) {
      return result.finally(() => {
        console.log(`${methodName} took ${(performance.now() - start).toFixed(2)}ms`);
      });
    }

    console.log(`${methodName} took ${(performance.now() - start).toFixed(2)}ms`);
    return result;
  };
}

class ReportService {
  @logDuration
  async generateMonthlyReport(month: number, year: number) {
    // Expensive computation
    const data = await this.fetchData(month, year);
    return this.processData(data);
  }
}

Class decorators can now modify and replace the class itself. A validation decorator for request bodies:

function validateSchema(schema: ZodSchema) {
  return function<T extends new (...args: any[]) => any>(
    Target: T,
    context: ClassDecoratorContext
  ) {
    return class extends Target {
      constructor(...args: any[]) {
        const parsed = schema.parse(args[0]);
        super(parsed);
      }
    };
  };
}

const CreateUserSchema = z.object({
  name: z.string().min(2),
  email: z.string().email(),
  role: z.enum(['admin', 'member', 'viewer']),
});

@validateSchema(CreateUserSchema)
class CreateUserCommand {
  constructor(public readonly data: z.infer<typeof CreateUserSchema>) {}
}

Const Type Parameters — Infer Literals Without as const

Before TypeScript 5.0, if you wanted a generic function to infer literal types rather than widened types, callers had to remember to add as const at the call site. The const modifier on type parameters tells TypeScript to infer the narrowest possible type automatically.

// Before — caller must remember 'as const'
function createRoutes<T extends Record<string, string>>(routes: T): T {
  return routes;
}

const routes = createRoutes({
  home: '/',
  dashboard: '/dashboard',
});
// routes.home is inferred as 'string', not '/'

// After — const modifier on the type parameter
function createRoutes<const T extends Record<string, string>>(routes: T): T {
  return routes;
}

const routes = createRoutes({
  home: '/',
  dashboard: '/dashboard',
});
// routes.home is now inferred as '/' — literal type preserved

This is particularly useful for event emitter systems, route registries, and config objects where you want downstream code to autocomplete with specific values, not just the widened type:

function definePermissions<const T extends readonly string[]>(
  perms: T
): { [K in T[number]]: boolean } {
  return Object.fromEntries(perms.map(p => [p, false])) as any;
}

const permissions = definePermissions([
  'read:users',
  'write:users',
  'delete:users',
  'admin:billing',
]);

// permissions.read:users — TypeScript knows this key exists
// permissions.unknown — TypeScript error

The satisfies Operator — Validation Without Type Widening

One of the most practically useful additions to TypeScript in recent years. When you annotate a variable with a type, TypeScript widens the inferred type to match the annotation — you lose specific information. When you use satisfies, TypeScript validates the value against the type but keeps the inferred type for subsequent code.

type ThemeColor = string | [number, number, number];

type Theme = {
  primary: ThemeColor;
  secondary: ThemeColor;
  background: ThemeColor;
};

// Using type annotation — loses specific type information
const themeA: Theme = {
  primary: '#0066ff',
  secondary: [100, 200, 255],
  background: '#ffffff',
};
themeA.secondary.toUpperCase(); // ERROR — TypeScript thinks it might be an array
themeA.secondary[0];            // Also allowed — because it might be an array

// Using satisfies — validates AND preserves specific types
const themeB = {
  primary: '#0066ff',
  secondary: [100, 200, 255],
  background: '#ffffff',
} satisfies Theme;

themeB.secondary[0];            // OK — TypeScript knows this is an array
themeB.secondary.toUpperCase(); // ERROR — TypeScript knows it's not a string
themeB.primary.toUpperCase();   // OK — TypeScript knows primary is a string

The satisfies operator is particularly valuable for configuration objects that other parts of the system index into:

const API_ENDPOINTS = {
  users:    '/api/v2/users',
  products: '/api/v2/products',
  orders:   '/api/v2/orders',
} satisfies Record<string, string>;

// Autocomplete works on the specific keys
const url = API_ENDPOINTS.users; // inferred as '/api/v2/users', not just string
// API_ENDPOINTS.invoices — TypeScript error (key doesn't exist)

Template Literal Types for String Unions

Template literal types let you construct new string union types from existing ones. Combined with mapped types, they enable strongly-typed event systems and API route builders with zero runtime overhead.

// Type-safe event bus
type Entity = 'user' | 'order' | 'product';
type Action = 'created' | 'updated' | 'deleted';
type EventName = `${Entity}:${Action}`;
// Expands to: 'user:created' | 'user:updated' | 'user:deleted' |
//             'order:created' | ... | 'product:deleted'

class TypedEventBus {
  private handlers = new Map<string, Function[]>();

  on<E extends EventName>(
    event: E,
    handler: (payload: EventPayloadMap[E]) => void
  ): void {
    if (!this.handlers.has(event)) this.handlers.set(event, []);
    this.handlers.get(event)!.push(handler);
  }

  emit<E extends EventName>(event: E, payload: EventPayloadMap[E]): void {
    this.handlers.get(event)?.forEach(h => h(payload));
  }
}

const bus = new TypedEventBus();
bus.on('user:created', (payload) => {
  // payload is typed as EventPayloadMap['user:created']
});
bus.on('user:sent', () => {}); // TypeScript error — invalid event name

The using Declaration — Deterministic Resource Cleanup

TypeScript 5.2 implemented the TC39 Explicit Resource Management proposal. The using keyword binds a resource that has a [Symbol.dispose] method — when the variable goes out of scope (even if an exception is thrown), the method is called automatically. This is similar to C#'s using or Python's with statement.

// Define a disposable database connection
class DatabaseConnection {
  private isOpen = true;

  async query(sql: string) {
    if (!this.isOpen) throw new Error('Connection closed');
    // ... execute query
  }

  [Symbol.dispose]() {
    console.log('Closing DB connection');
    this.isOpen = false;
    // Release connection back to pool
  }
}

function getConnection(): DatabaseConnection {
  return new DatabaseConnection();
}

async function processOrder(orderId: string) {
  using db = getConnection(); // db is disposed when this block exits

  const order = await db.query(`SELECT * FROM orders WHERE id = '${orderId}'`);
  const items = await db.query(`SELECT * FROM order_items WHERE order_id = '${orderId}'`);

  return { order, items };
  // db[Symbol.dispose]() called here, even if an exception occurred above
}

For async resources, use await using with [Symbol.asyncDispose]:

class FileHandle {
  constructor(private path: string) {}

  async write(data: string) { /* ... */ }

  async [Symbol.asyncDispose]() {
    await this.flush();
    await this.close();
    console.log(`Closed: ${this.path}`);
  }
}

async function writeReport(data: ReportData) {
  await using file = new FileHandle('/tmp/report.json');
  await file.write(JSON.stringify(data, null, 2));
  // file is async-disposed here
}

tsconfig.json for Next.js + Node.js Monorepos

Setting up TypeScript correctly across a monorepo with a Next.js frontend and Node.js backend requires base config inheritance and project references. This is the configuration pattern that avoids duplicate type definitions and cross-package type bleeding:

// tsconfig.base.json — root of monorepo
{
  "compilerOptions": {
    "strict": true,
    "exactOptionalPropertyTypes": true,
    "noUncheckedIndexedAccess": true,
    "moduleResolution": "bundler",
    "target": "ES2022",
    "lib": ["ES2022"],
    "declaration": true,
    "declarationMap": true,
    "sourceMap": true,
    "skipLibCheck": true
  }
}

// apps/web/tsconfig.json — Next.js app
{
  "extends": "../../tsconfig.base.json",
  "compilerOptions": {
    "lib": ["ES2022", "DOM", "DOM.Iterable"],
    "jsx": "preserve",
    "plugins": [{ "name": "next" }],
    "paths": {
      "@/*": ["./src/*"],
      "@shared/*": ["../../packages/shared/src/*"]
    }
  },
  "include": ["src", "next-env.d.ts"],
  "exclude": ["node_modules"]
}

// packages/api/tsconfig.json — Node.js backend
{
  "extends": "../../tsconfig.base.json",
  "compilerOptions": {
    "module": "NodeNext",
    "moduleResolution": "NodeNext",
    "outDir": "./dist"
  },
  "include": ["src"]
}

Type-Safe Environment Variables with Zod

Environment variable access via process.env.SOMETHING returns string | undefined, which means you either cast it or add null checks everywhere. Validating your env schema at startup with Zod gives you fully typed access throughout the application and fails loudly at boot time — not at runtime when a feature is actually used:

// lib/env.ts
import { z } from 'zod';

const envSchema = z.object({
  DATABASE_URL:        z.string().url(),
  NEXTAUTH_SECRET:     z.string().min(32),
  NEXTAUTH_URL:        z.string().url(),
  STRIPE_SECRET_KEY:   z.string().startsWith('sk_'),
  RAZORPAY_KEY_ID:     z.string().optional(),
  RAZORPAY_KEY_SECRET: z.string().optional(),
  NODE_ENV:            z.enum(['development', 'test', 'production']),
  PORT:                z.coerce.number().default(3000),
});

// Parse at module load time — fail fast if misconfigured
export const env = envSchema.parse(process.env);

// Usage elsewhere — fully typed, no undefined
import { env } from '@/lib/env';
const db = new PrismaClient({ datasources: { db: { url: env.DATABASE_URL } } });

Common TypeScript Mistakes That Bite Indian Development Teams

Working with teams across Kerala and remote projects, a few patterns come up repeatedly:

Overusing any to unblock compilation: The instant you write : any, you've disabled TypeScript for that variable and anything it touches. Use unknown instead — it forces you to narrow the type before using it, which is what you actually want:

// Instead of casting API responses to any
const data: any = await response.json(); // loses all type safety

// Parse with Zod — runtime validation + inferred types
const ResponseSchema = z.object({
  users: z.array(z.object({ id: z.string(), name: z.string() })),
  total: z.number(),
});

const data = ResponseSchema.parse(await response.json());
// data.users[0].name — TypeScript knows this exists and is a string

Forgetting async function return types: TypeScript infers return types from async functions, but when the implementation changes, downstream callers may silently receive a different type. Annotating explicitly catches this:

// Implicit — return type changes silently with implementation
async function fetchUser(id: string) {
  return prisma.user.findUnique({ where: { id } });
}

// Explicit — compiler error if implementation drifts
async function fetchUser(id: string): Promise<User | null> {
  return prisma.user.findUnique({ where: { id } });
}

Frequently Asked Questions

Should I enable strict mode in TypeScript for a new project in 2026?

Yes, without exception. Strict mode enables strictNullChecks, noImplicitAny, strictFunctionTypes, and several other checks that catch entire categories of runtime errors at compile time. The initial friction of fixing strict-mode errors in a new codebase is far less painful than hunting null reference crashes in production. Enable it in tsconfig.json with "strict": true — this single setting activates all the important checks and is the default expectation for any modern TypeScript project.

When should I use the satisfies operator instead of a type annotation?

Use satisfies when you want TypeScript to validate that a value matches a type but still infer the most specific type for subsequent code. A type annotation like const config: Config = ... widens the type to Config, losing specific literal information. satisfies preserves that information while still checking conformance. It's especially useful for config objects, route maps, and any structure where you need both validation and precise autocomplete downstream.

Are TypeScript decorators in 5.x compatible with older decorator libraries like reflect-metadata?

TypeScript 5.0 introduced Stage 3 decorators, which are a different specification from the legacy experimental decorators that reflect-metadata was built around. The two systems are not compatible. If your project uses NestJS, TypeORM, or class-validator — which rely on experimental decorators and reflect-metadata — keep experimentalDecorators: true and emitDecoratorMetadata: true in your tsconfig for those packages. New code can use Stage 3 decorators alongside, but you cannot mix decorator styles on the same class.