{"id":412,"date":"2026-03-09T20:18:12","date_gmt":"2026-03-09T20:18:12","guid":{"rendered":"https:\/\/blog.rebalai.com\/en\/2026\/03\/09\/typescript-5x-in-2026-features-that-actually-matte\/"},"modified":"2026-03-18T22:00:04","modified_gmt":"2026-03-18T22:00:04","slug":"typescript-5x-in-2026-features-that-actually-matte","status":"publish","type":"post","link":"https:\/\/blog.rebalai.com\/en\/2026\/03\/09\/typescript-5x-in-2026-features-that-actually-matte\/","title":{"rendered":"TypeScript 5.x in 2026: Features That Actually Matter for Production Code"},"content":{"rendered":"

Spent most of last winter doing something I should have done a year earlier: actually reading the TypeScript 5.x changelogs. Not skimming the headlines \u2014 reading them, then dropping each feature into a scratch project to see how it actually<\/a> behaved. Our codebase sits at around 180k lines \u2014 a team of seven, a mix of Node.js inference services and React front-ends \u2014 and we’d been on TypeScript 5.x for over a year without meaningfully adopting anything new. We’d bumped the package version, confirmed the build didn’t break, moved on.<\/p>\n

What I found: maybe six features that genuinely changed how I write TypeScript, and a longer tail of things that are technically interesting but haven’t touched my day-to-day work. This isn’t a changelog recap. It’s what actually<\/a> earned its place.<\/p>\n

using<\/code> Declarations Fixed a Leak I’d Been Ignoring for Eight Months<\/h2>\n

The explicit resource management proposal \u2014 using<\/code> and await using<\/code> \u2014 landed in TypeScript 5.2, and I’m genuinely annoyed it took<\/a> me this long<\/a> to use<\/a> it. The thing that finally pushed me to look: a slow memory leak in one of our LLM inference services I’d been deferring for months.<\/p>\n

We were pooling inference sessions, and somewhere in the<\/a> request-handling code, sessions weren’t always being released. The try\/finally<\/code> blocks were there \u2014 mostly. One code path through a batch endpoint was missing the cleanup call. The session sat there, held in memory, until the process restarted. I pushed a fix on a Friday afternoon after tracing it for two hours, and I thought: this is the kind of bug that shouldn’t be possible.<\/p>\n

The old pattern:<\/p>\n

\/\/ The before: try\/finally that's correct until someone adds a code path\nasync function runBatchInference(prompts: string[]) {\n  const session = await pool.acquire();\n  try {\n    return await Promise.all(prompts.map(p => session.complete(p)));\n  } catch (err) {\n    logger.error('batch inference failed', err);\n    throw err;\n    \/\/ pool.release() was added here by a colleague \u2014 but not in the<\/a> finally block\n  } finally {\n    await pool.release(session); \/\/ sometimes ran twice. sometimes not at all.\n  }\n}\n<\/code><\/pre>\n
After implementing Symbol.asyncDispose<\/code> on the session class:<\/p>\n
class InferenceSession {\n  private released = false;\n\n  async complete(prompt: string): Promise<string> { \/* ... *\/ }\n\n  async [Symbol.asyncDispose](): Promise<void> {\n    if (!this.released) {\n      await pool.release(this);\n      this.released = true;\n    }\n  }\n}\n\nasync function runBatchInference(prompts: string[]) {\n  await using session = await pool.acquire();\n  \/\/ No try\/finally. Disposal is guaranteed at scope exit,\n  \/\/ regardless of which path the function takes.\n  return Promise.all(prompts.map(p => session.complete(p)));\n}\n<\/code><\/pre>\n
What surprised me was the disposal ordering. When you stack multiple using<\/code> declarations in the<\/a> same scope, TypeScript disposes them in reverse order \u2014 last declared, first disposed, LIFO. I expected to have to verify this carefully and maybe work around edge cases. Nope. It just works the way you’d want it to if one resource depends on another.<\/p>\n
If you manage any resource in TypeScript \u2014 database connections, file handles, WebSocket sessions, anything with a close()<\/code> \u2014 implementing Symbol.dispose<\/code> or Symbol.asyncDispose<\/code> and switching to using<\/code> is the most immediately practical change in all of 5.x.<\/p>\n
Inferred Type Predicates Deleted About 300 Lines of Manual Guards<\/h2>\n
Before TypeScript 5.5, getting .filter()<\/code> to actually narrow a type required an explicit type predicate function. We had a file of them: isNonNull<\/code>, isLoaded<\/code>, isSuccessResponse<\/code>, isAPIError<\/code>. About 300 lines across two utility modules, and someone would add a new one every couple of weeks. Every time we introduced a new union type, we’d forget to add the corresponding predicate, use the wrong one, or find out the type was wider than expected somewhere downstream.<\/p>\n
TypeScript 5.5 introduced automatic inference of type predicates \u2014 when the compiler can determine from the function body that a value is being narrowed, it infers the value is T<\/code> return type for you. The case that hit us hardest:<\/p>\n
\/\/ Before 5.5 \u2014 you wrote this (correctly) every time\nfunction isNonNull<T>(value: T | null | undefined): value is T {\n  return value != null;\n}\n\nconst rawResults: (InferenceResult | null)[] = await runBatch(prompts);\nconst results = rawResults.filter(isNonNull); \/\/ InferenceResult[]\n\n\/\/ After 5.5 \u2014 TypeScript infers the predicate from the inline callback\nconst results = rawResults.filter(r => r !== null);\n\/\/ results is InferenceResult[], not (InferenceResult | null)[]\n\/\/ No helper. No import. Just correct.\n<\/code><\/pre>\n
I deleted most of those utility files the same afternoon I confirmed this worked. Not all of them \u2014 there are still cases where the inference doesn’t trigger. The rule of thumb I’ve built up: simple null and equality checks work reliably; anything with nested property access or custom logic still needs an explicit predicate.<\/p>\n
One thing I noticed: this pairs well with typed AI SDK responses, where you’re often getting back something like CompletionResult | RateLimitError | null<\/code> from a batch call and need to split it into separate arrays. Used to be a predicate per type. Now it’s an inline condition and the types just follow.<\/p>\n
NoInfer Is Nine Characters and It Stopped a Real Bug<\/h2>\n
I’ll be honest \u2014 I thought NoInfer<T><\/code> (added in 5.4) was a library-author concern when I first read about it. I was wrong. I ran into the problem it solves within two weeks<\/a>.<\/p>\n
The setup is \u2014 okay, let me back up a second. We have a config resolution function that looks up model configurations by key and falls back to a default. The default value was silently widening the inferred type, because TypeScript was using the fallback argument to infer T<\/code> rather than the caller’s intended type.<\/p>\n
\/\/ Without NoInfer: the fallback widens T\nfunction resolveConfig<T>(\n  registry: Map<string, T>,\n  key: string,\n  fallback: T  \/\/ TypeScript infers T partly from here \u2014 the problem\n): T {\n  return registry.get(key) ?? fallback;\n}\n\n\/\/ resolveConfig(myRegistry, 'gpt-4o', { temperature: 0.7 })\n\/\/ infers T as { temperature: number }, not ModelConfig\n\/\/ downstream code that expects ModelConfig now has no error\n\n\/\/ With NoInfer: only the registry type informs T\nfunction resolveConfig<T>(\n  registry: Map<string, T>,\n  key: string,\n  fallback: NoInfer<T>  \/\/ can't influence T inference\n): T {\n  return registry.get(key) ?? fallback;\n}\n<\/code><\/pre>\n
That function had been silently widening types for months. I’m not 100% sure we ever shipped a production bug because of it \u2014 but we had tests passing on wider types than they should have been, and that’s a bad place to be.<\/p>\n
Reach for NoInfer<\/code> when you write generic utilities with default or fallback parameters. You’ll know when you need it because you’ll see the inferred type being wider than you intended, and you’ll wonder why. Then it’ll click immediately.<\/p>\n
verbatimModuleSyntax Is the Price of Admission for ESM in 2026<\/h2>\n
verbatimModuleSyntax<\/code> shipped in 5.0, but I keep seeing teams who’ve skipped it \u2014 usually because enabling it immediately breaks forty files and no one wants to deal with that mid-sprint. I deferred it for months too. But now that Node.js 22+ handles TypeScript natively via --experimental-strip-types<\/code>, and TypeScript 5.8 introduced --erasableSyntaxOnly<\/code> more cleanly, verbatimModuleSyntax<\/code> is effectively required if you want your TypeScript to run without a transformation step.<\/p>\n
Here’s the thing: when this flag is off, TypeScript can rewrite your imports. An import { SomeInterface }<\/code> that’s type-only might get stripped, or it might get emitted, depending on whether the compiler thinks it’s a value. That ambiguity is fine until you’re on an edge runtime or a tool that doesn’t do the same inference TypeScript does. Then you get subtle bundling issues \u2014 not crashes, usually, just slightly wrong output that’s hard to trace back.<\/p>\n
The fix is boring: turn the flag on, let the compiler tell you<\/a> which imports need import type<\/code>, run the VS Code quick-fix on each file. It took<\/a> me about ninety minutes across our codebase. I haven’t thought about import emission since.<\/p>\n
If you’re still on a CommonJS Node.js setup with no edge runtime in sight, you can defer this. If you’re deploying to Cloudflare Workers<\/a>, Deno, or native Node.js strip mode \u2014 do it now.<\/p>\n
Two Features I Overhyped in Slack, and Two Small Wins That Earned Their Place<\/h2>\n
After migrating the using<\/code> declarations and cleaning up the predicates, I made the mistake of posting “TypeScript 5.x is actually<\/a> great” in our engineering channel and listing six more features I was excited to explore. Two of them did not pan out the way I expected.<\/p>\n
Decorator metadata (5.2).<\/strong> I went in thinking we could annotate validation schemas directly on request classes, reflect on them at runtime, and eliminate some boilerplate in our API layer. You can do that. The problem is runtime support \u2014 you need either a polyfill or an environment that natively supports the TC39 Decorator Metadata proposal. For our<\/a> Node.js services, fine. For the React front-end running in whatever browsers our users have, I didn’t want to ship a polyfill for something Zod schemas solved in an afternoon. If you’re building a framework where you control the runtime, worth evaluating. For application code, the cost-benefit didn’t work out.<\/p>\n
Const type parameters (5.0).<\/strong> I do use these, just much less often than I expected. When you declare function foo<const T>()<\/code>, TypeScript infers literal types for T<\/code> instead of widening. Useful for typed config builders and tuple utilities. I’ve reached for it maybe eight times in the<\/a> past year. Good to know it exists; not a weekly-driver feature.<\/p>\n
The smaller wins that actually earned their place: preserved narrowing after last assignment (5.4) caught a real bug where a closure was capturing a variable I thought was permanently narrowed but could have been reassigned before the callback fired. The compiler surfaced it before it shipped. And regex syntax checking (5.5) has caught two invalid patterns that would have been silent runtime failures \u2014 the kind of thing that used to be completely invisible to the type system.<\/p>\n
\n
Anyway \u2014 those four. using<\/code> declarations and inferred predicates are the ones I’d push on any TypeScript team right now, regardless of what kind of code they’re writing. verbatimModuleSyntax<\/code> is a one-time cost you pay once and never think about again. NoInfer<\/code> you’ll understand the second you hit the problem it solves.<\/p>\n
The rest of 5.x I’d skim when a release drops and learn on demand. The six features I was posting about excitedly in Slack? Genuinely cool. Not in my daily workflow.<\/p>\n
These four are.<\/p>\n
<\/p>\n","protected":false},"excerpt":{"rendered":"
Spent most of last winter doing something I should have done a year earlier: actually reading the TypeScript 5.x changelogs.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"default","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","ast-disable-related-posts":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"default","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"footnotes":""},"categories":[1],"tags":[],"class_list":["post-412","post","type-post","status-publish","format-standard","hentry","category-general"],"_links":{"self":[{"href":"https:\/\/blog.rebalai.com\/en\/wp-json\/wp\/v2\/posts\/412","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.rebalai.com\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.rebalai.com\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.rebalai.com\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.rebalai.com\/en\/wp-json\/wp\/v2\/comments?post=412"}],"version-history":[{"count":8,"href":"https:\/\/blog.rebalai.com\/en\/wp-json\/wp\/v2\/posts\/412\/revisions"}],"predecessor-version":[{"id":558,"href":"https:\/\/blog.rebalai.com\/en\/wp-json\/wp\/v2\/posts\/412\/revisions\/558"}],"wp:attachment":[{"href":"https:\/\/blog.rebalai.com\/en\/wp-json\/wp\/v2\/media?parent=412"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.rebalai.com\/en\/wp-json\/wp\/v2\/categories?post=412"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.rebalai.com\/en\/wp-json\/wp\/v2\/tags?post=412"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}