But if you’re already familiar, you can start using TypeScript 5.9 today!<\/p>\n
npm install -D typescript\r\n<\/code><\/pre>\nLet’s take a look at what’s new in TypeScript 5.9!<\/p>\n
\n- Minimal and Updated
tsc --init<\/code><\/a><\/li>\n- Support for
import defer<\/code><\/a><\/li>\n- Support for
--module node20<\/code><\/a><\/li>\n- Summary Descriptions in DOM APIs<\/a><\/li>\n
- Expandable Hovers (Preview)<\/a><\/li>\n
- Configurable Maximum Hover Length<\/a><\/li>\n
- Optimizations<\/a><\/li>\n
- Notable Behavioral Changes<\/a><\/li>\n<\/ul>\n
What’s New Since the Beta and RC?<\/h2>\n
There have been no changes to TypeScript 5.9 since the release candidate.<\/p>\n
A few fixes for reported issues have been made since the 5.9 beta<\/a>, including the restoration of AbortSignal.abort()<\/code> to the DOM library.\nAdditionally, we have added a section about Notable Behavioral Changes<\/a>.<\/p>\nMinimal and Updated tsc --init<\/code><\/h2>\nFor a while, the TypeScript compiler has supported an --init<\/code> flag that can create a tsconfig.json<\/code> within the current directory.\nIn the last few years, running tsc --init<\/code> created a very “full” tsconfig.json<\/code>, filled with commented-out settings and their descriptions.\nWe designed this with the intent of making options discoverable and easy to toggle.<\/p>\nHowever, given external feedback (and our own experience), we found it’s common to immediately delete most of the contents of these new tsconfig.json<\/code> files.\nWhen users want to discover new options, we find they rely on auto-complete from their editor, or navigate to the tsconfig reference on our website<\/a> (which the generated tsconfig.json<\/code> links to!).\nWhat each setting does is also documented on that same page, and can be seen via editor hovers\/tooltips\/quick info.\nWhile surfacing some commented-out settings might be helpful, the generated tsconfig.json<\/code> was often considered overkill.<\/p>\nWe also felt that it was time that tsc --init<\/code> initialized with a few more prescriptive settings than we already enable.\nWe looked at some common pain points and papercuts users have when they create a new TypeScript project.\nFor example, most users write in modules (not global scripts), and --moduleDetection<\/code> can force TypeScript to treat every implementation file as a module.\nDevelopers also often want to use the latest ECMAScript features directly in their runtime, so --target<\/code> can typically be set to esnext<\/code>.\nJSX users often find that going back to set --jsx<\/code> is needless friction, and its options are slightly confusing.\nAnd often, projects end up loading more declaration files from node_modules\/@types<\/code> than TypeScript actually needs; but specifying an empty types<\/code> array can help limit this.<\/p>\nIn TypeScript 5.9, a plain tsc --init<\/code> with no other flags will generate the following tsconfig.json<\/code>:<\/p>\n{\r\n \/\/ Visit https:\/\/aka.ms\/tsconfig to read more about this file\r\n \"compilerOptions\": {\r\n \/\/ File Layout\r\n \/\/ \"rootDir\": \".\/src\",\r\n \/\/ \"outDir\": \".\/dist\",\r\n\r\n \/\/ Environment Settings\r\n \/\/ See also https:\/\/aka.ms\/tsconfig_modules\r\n \"module\": \"nodenext\",\r\n \"target\": \"esnext\",\r\n \"types\": [],\r\n \/\/ For nodejs:\r\n \/\/ \"lib\": [\"esnext\"],\r\n \/\/ \"types\": [\"node\"],\r\n \/\/ and npm install -D @types\/node\r\n\r\n \/\/ Other Outputs\r\n \"sourceMap\": true,\r\n \"declaration\": true,\r\n \"declarationMap\": true,\r\n\r\n \/\/ Stricter Typechecking Options\r\n \"noUncheckedIndexedAccess\": true,\r\n \"exactOptionalPropertyTypes\": true,\r\n\r\n \/\/ Style Options\r\n \/\/ \"noImplicitReturns\": true,\r\n \/\/ \"noImplicitOverride\": true,\r\n \/\/ \"noUnusedLocals\": true,\r\n \/\/ \"noUnusedParameters\": true,\r\n \/\/ \"noFallthroughCasesInSwitch\": true,\r\n \/\/ \"noPropertyAccessFromIndexSignature\": true,\r\n\r\n \/\/ Recommended Options\r\n \"strict\": true,\r\n \"jsx\": \"react-jsx\",\r\n \"verbatimModuleSyntax\": true,\r\n \"isolatedModules\": true,\r\n \"noUncheckedSideEffectImports\": true,\r\n \"moduleDetection\": \"force\",\r\n \"skipLibCheck\": true,\r\n }\r\n}\r\n<\/code><\/pre>\nFor more details, see the implementing pull request<\/a> and discussion issue<\/a>.<\/p>\nSupport for import defer<\/code><\/h2>\nTypeScript 5.9 introduces support for ECMAScript’s deferred module evaluation proposal<\/a> using the new import defer<\/code> syntax.\nThis feature allows you to import a module without immediately executing the module and its dependencies, providing better control over when work and side-effects occur.<\/p>\nThe syntax only permits namespace imports:<\/p>\n
import defer * as feature from \".\/some-feature.js\";\r\n<\/code><\/pre>\nThe key benefit of import defer<\/code> is that the module is only evaluated when one of its exports is first accessed.\nConsider this example:<\/p>\n\/\/ .\/some-feature.ts\r\ninitializationWithSideEffects();\r\n\r\nfunction initializationWithSideEffects() {\r\n \/\/ ...\r\n specialConstant = 42;\r\n\r\n console.log(\"Side effects have occurred!\");\r\n}\r\n\r\nexport let specialConstant: number;\r\n<\/code><\/pre>\nWhen using import defer<\/code>, the initializationWithSideEffects()<\/code> function will not be called until you actually access a property of the imported namespace:<\/p>\nimport defer * as feature from \".\/some-feature.js\";\r\n\r\n\/\/ No side effects have occurred yet\r\n\r\n\/\/ ...\r\n\r\n\/\/ As soon as `specialConstant` is accessed, the contents of the `feature`\r\n\/\/ module are run and side effects have taken place.\r\nconsole.log(feature.specialConstant); \/\/ 42\r\n<\/code><\/pre>\nBecause evaluation of the module is deferred until you access a member off of the module, you cannot use named imports or default imports with import defer<\/code>:<\/p>\n\/\/ \u274c Not allowed\r\nimport defer { doSomething } from \"some-module\";\r\n\r\n\/\/ \u274c Not allowed \r\nimport defer defaultExport from \"some-module\";\r\n\r\n\/\/ \u2705 Only this syntax is supported\r\nimport defer * as feature from \"some-module\";\r\n<\/code><\/pre>\nNote that when you write import defer<\/code>, the module and its dependencies are fully loaded and ready for execution.\nThat means that the module will need to exist, and will be loaded from the file system or a network resource.\nThe key difference between a regular import<\/code> and import defer<\/code> is that the execution of statements and declarations<\/em> is deferred until you access a property of the imported namespace.<\/p>\nThis feature is particularly useful for conditionally loading modules with expensive or platform-specific initialization. It can also improve startup performance by deferring module evaluation for app features until they are actually needed.<\/p>\n
Note that import defer<\/code> is not transformed or “downleveled” at all by TypeScript.\nIt is intended to be used in runtimes that support the feature natively, or by tools such as bundlers that can apply the appropriate transformation.\nThat means that import defer<\/code> will only work under the --module<\/code> modes preserve<\/code> and esnext<\/code>.<\/p>\nWe’d like to extend our thanks to Nicol\u00f2 Ribaudo<\/a> who championed the proposal in TC39 and also provided the implementation for this feature<\/a>.<\/p>\nSupport for --module node20<\/code><\/h2>\nTypeScript provides several node*<\/code> options for the --module<\/code> and --moduleResolution<\/code> settings.\nMost recently, --module nodenext<\/code> has supported the ability to require()<\/code> ECMAScript modules from CommonJS modules, and correctly rejects import assertions (in favor of the standards-bound import attributes<\/a>).<\/p>\nTypeScript 5.9 brings a stable option for these settings called node20<\/code>, intended to model the behavior of Node.js v20.\nThis option is unlikely to have new behaviors in the future, unlike --module nodenext<\/code> or --moduleResolution nodenext<\/code>.\nAlso unlike nodenext<\/code>, specifying --module node20<\/code> will imply --target es2023<\/code> unless otherwise configured.\n--module nodenext<\/code>, on the other hand, implies the floating --target esnext<\/code>.<\/p>\nFor more information, take a look at the implementation here<\/a>.<\/p>\nSummary Descriptions in DOM APIs<\/h2>\n
Previously, many of the DOM APIs in TypeScript only linked to the MDN documentation for the API.\nThese links were useful, but they didn’t provide a quick summary of what the API does.\nThanks to a few changes from Adam Naji<\/a>, TypeScript now includes summary descriptions for many DOM APIs based on the MDN documentation.\nYou can see more of these changes here<\/a> and here<\/a>.<\/p>\nExpandable Hovers (Preview)<\/h2>\n
Quick Info<\/em> (also called “editor tooltips” and “hovers”) can be very useful for peeking at variables to see their types, or at type aliases to see what they actually refer to.\nStill, it’s common for people to want to go deeper<\/em> and get details from whatever’s displayed within the quick info tooltip.\nFor example, if we hover our mouse over the parameter options<\/code> in the following example:<\/p>\nexport function drawButton(options: Options): void\r\n<\/code><\/pre>\nWe’re left with (parameter) options: Options<\/code>.<\/p>\n![\"Tooltip](\"https:\/\/devblogs.microsoft.com\/typescript\/wp-content\/uploads\/sites\/11\/2025\/06\/bare-hover-5.8-01.png\")
<\/p>\n
Do we really need to jump to the definition of the type Options<\/code> just to see what members this value has?<\/p>\nPreviously, that was actually the case.\nTo help here, TypeScript 5.9 is now previewing a feature called expandable hovers<\/em>, or “quick info verbosity”.\nIf you use an editor like VS Code, you’ll now see a +<\/code> and -<\/code> button on the left of these hover tooltips.\nClicking on the +<\/code> button will expand out types more deeply, while clicking on the -<\/code> button will collapse to the last view.<\/p>\n