{"id":4429,"date":"2024-09-09T09:13:26","date_gmt":"2024-09-09T17:13:26","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/typescript\/?p=4429"},"modified":"2024-09-09T09:13:26","modified_gmt":"2024-09-09T17:13:26","slug":"announcing-typescript-5-6","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/typescript\/announcing-typescript-5-6\/","title":{"rendered":"Announcing TypeScript 5.6"},"content":{"rendered":"

Today we’re excited to announce the release of TypeScript 5.6!<\/p>\n

If you’re not familiar with TypeScript, it’s a language that builds on top of JavaScript by adding syntax for types<\/em>.\nTypes describe the shapes we expect of our variables, parameters, and functions, and the TypeScript type-checker<\/em> can help catch issues like typos, missing properties, and bad function calls before we even run our code.\nTypes also power TypeScript’s editor tooling like the auto-completion, code navigation, and refactorings that you might see in editors like Visual Studio and VS Code.\nIn fact, if you write JavaScript in either of those editors, that experience is powered by TypeScript!\nYou can learn more at the TypeScript website<\/a>.<\/p>\n

You can get started using TypeScript using npm with the following command:<\/p>\n

npm install -D typescript\r\n<\/code><\/pre>\n
or through NuGet<\/a>.<\/p>\n
<\/p>\n
What’s New Since the Beta and RC?<\/h2>\n
Since TypeScript 5.6 beta, we reverted a change around how TypeScript’s language service searched for tsconfig.json<\/code> files<\/a>.\nPreviously the language service would keep walking up looking for every possible project file named tsconfig.json<\/code> that might contain a file.\nBecause this could lead to opening many referenced projects, we reverted the behavior<\/a> and are investigating ways to bring back the behavior in TypeScript 5.7<\/a>.<\/p>\n
Additionally, several new types have been renamed since the beta.\nPreviously, TypeScript provided a single type called BuiltinIterator<\/code> to describe every value backed by Iterator.prototype<\/code>.\nIt has been renamed IteratorObject<\/code>, has a different set of type parameters, and now has several subtypes like ArrayIterator<\/code>, MapIterator<\/code>, and more.<\/p>\n
A new flag called --stopOnBuildErrors<\/code> has been added for --build<\/code> mode.\nWhen a project builds with any errors, no other projects will continue to be built.\nThis provides something close to the behavior of previous versions of TypeScript since TypeScript 5.6 always builds in the face of errors<\/a>.<\/p>\n
New editor functionality has been added such as direct support for commit characters<\/a> and exclude patterns for auto-imports<\/a>.<\/p>\n
Disallowed Nullish and Truthy Checks<\/h2>\n
Maybe you’ve written a regex and forgotten to call .test(...)<\/code> on it:<\/p>\n
if (\/0x[0-9a-f]\/) {\r\n    \/\/ Oops! This block always runs.\r\n    \/\/ ...\r\n}\r\n<\/code><\/pre>\n
or maybe you’ve accidentally written =><\/code> (which creates an arrow function) instead of >=<\/code> (the greater-than-or-equal-to operator):<\/p>\n
if (x => 0) {\r\n    \/\/ Oops! This block always runs.\r\n    \/\/ ...\r\n}\r\n<\/code><\/pre>\n
or maybe you’ve tried to use a default value with ??<\/code>, but mixed up the precedence of ??<\/code> and a comparison operator like <<\/code>:<\/p>\n
function isValid(value: string | number, options: any, strictness: \"strict\" | \"loose\") {\r\n    if (strictness === \"loose\") {\r\n        value = +value\r\n    }\r\n    return value < options.max ?? 100;\r\n    \/\/ Oops! This is parsed as (value < options.max) ?? 100\r\n}\r\n\r\n<\/code><\/pre>\n
or maybe you’ve misplaced a parenthesis in a complex expression:<\/p>\n
if (\r\n    isValid(primaryValue, \"strict\") || isValid(secondaryValue, \"strict\") ||\r\n    isValid(primaryValue, \"loose\" || isValid(secondaryValue, \"loose\"))\r\n) {\r\n    \/\/                           ^^^^ \ud83d\udc40 Did we forget a closing ')'?\r\n}\r\n<\/code><\/pre>\n
None of these examples do what the author intended, but they’re all valid JavaScript code.\nPreviously TypeScript also quietly accepted these examples.<\/p>\n
But with a little bit of experimentation, we found that many many<\/em> bugs could be caught from flagging down suspicious examples like above.\nIn TypeScript 5.6, the compiler now errors when it can syntactically determine a truthy or nullish check will always evaluate in a specific way.\nSo in the above examples, you’ll start to see errors:<\/p>\n
if (\/0x[0-9a-f]\/) {\r\n\/\/  ~~~~~~~~~~~~\r\n\/\/ error: This kind of expression is always truthy.\r\n}\r\n\r\nif (x => 0) {\r\n\/\/  ~~~~~~\r\n\/\/ error: This kind of expression is always truthy.\r\n}\r\n\r\nfunction isValid(value: string | number, options: any, strictness: \"strict\" | \"loose\") {\r\n    if (strictness === \"loose\") {\r\n        value = +value\r\n    }\r\n    return value < options.max ?? 100;\r\n    \/\/     ~~~~~~~~~~~~~~~~~~~\r\n    \/\/ error: Right operand of ?? is unreachable because the left operand is never nullish.\r\n}\r\n\r\nif (\r\n    isValid(primaryValue, \"strict\") || isValid(secondaryValue, \"strict\") ||\r\n    isValid(primaryValue, \"loose\" || isValid(secondaryValue, \"loose\"))\r\n) {\r\n    \/\/                    ~~~~~~~\r\n    \/\/ error: This kind of expression is always truthy.\r\n}\r\n<\/code><\/pre>\n
Similar results can be achieved by enabling the ESLint no-constant-binary-expression<\/code> rule, and you can see some of the results they achieved in their blog post<\/a>;\nbut the new checks TypeScript performs does not have perfect overlap with the ESLint rule, and we also believe there is a lot of value in having these checks built into TypeScript itself.<\/p>\n
Note that certain expressions are still allowed, even if they are always truthy or nullish.\nSpecifically, true<\/code>, false<\/code>, 0<\/code>, and 1<\/code> are all still allowed despite always being truthy or falsy, since code like the following:<\/p>\n
while (true) {\r\n    doStuff();\r\n\r\n    if (something()) {\r\n        break;\r\n    }\r\n\r\n    doOtherStuff();\r\n}\r\n<\/code><\/pre>\n
is still idiomatic and useful, and code like the following:<\/p>\n
if (true || inDebuggingOrDevelopmentEnvironment()) {\r\n    \/\/ ...\r\n}\r\n<\/code><\/pre>\n
is useful while iterating\/debugging code.<\/p>\n
If you’re curious about the implementation or the sorts of bugs it catches, take a look at the pull request that implemented this feature<\/a>.<\/p>\n
Iterator Helper Methods<\/h2>\n
JavaScript has a notion of iterables<\/em> (things which we can iterate over by calling a [Symbol.iterator]()<\/code> and getting an iterator) and iterators<\/em> (things which have a next()<\/code> method which we can call to try to get the next value as we iterate).\nBy and large, you don’t typically have to think about these things when you toss them into a for<\/code>\/of<\/code> loop, or [...spread]<\/code> them into a new array.\nBut TypeScript does model these with the types Iterable<\/code> and Iterator<\/code> (and even IterableIterator<\/code> which acts as both!), and these types describe the minimal set of members you need for constructs like for<\/code>\/of<\/code> to work on them.<\/p>\n
Iterable<\/code>s (and IterableIterator<\/code>s) are nice because they can be used in all sorts of places in JavaScript – but a lot of people found themselves missing methods on Array<\/code>s like map<\/code>, filter<\/code>, and for some reason reduce<\/code>.\nThat’s why a recent proposal was brought forward in ECMAScript<\/a> to add many methods (and more) from Array<\/code> onto most of the IterableIterator<\/code>s that are produced in JavaScript.<\/p>\n
For example, every generator now produces an object that also has a map<\/code> method and a take<\/code> method.<\/p>\n
function* positiveIntegers() {\r\n    let i = 1;\r\n    while (true) {\r\n        yield i;\r\n        i++;\r\n    }\r\n}\r\n\r\nconst evenNumbers = positiveIntegers().map(x => x * 2);\r\n\r\n\/\/ Output:\r\n\/\/    2\r\n\/\/    4\r\n\/\/    6\r\n\/\/    8\r\n\/\/   10\r\nfor (const value of evenNumbers.take(5)) {\r\n    console.log(value);\r\n}\r\n<\/code><\/pre>\n
The same is true for methods like keys()<\/code>, values()<\/code>, and entries()<\/code> on Map<\/code>s and Set<\/code>s.<\/p>\n
function invertKeysAndValues<K, V>(map: Map<K, V>): Map<V, K> {\r\n    return new Map(\r\n        map.entries().map(([k, v]) => [v, k])\r\n    );\r\n}\r\n<\/code><\/pre>\n
You can also extend the new Iterator<\/code> object:<\/p>\n
\/**\r\n * Provides an endless stream of `0`s.\r\n *\/\r\nclass Zeroes extends Iterator<number> {\r\n    next() {\r\n        return { value: 0, done: false } as const;\r\n    }\r\n}\r\n\r\nconst zeroes = new Zeroes();\r\n\r\n\/\/ Transform into an endless stream of `1`s.\r\nconst ones = zeroes.map(x => x + 1);\r\n<\/code><\/pre>\n
And you can adapt any existing Iterable<\/code>s or Iterator<\/code>s into this new type with Iterator.from<\/code>:<\/p>\n
Iterator.from(...).filter(someFunction);\r\n<\/code><\/pre>\n
All these new methods work as long as you’re running on a newer JavaScript runtime, or you’re using a polyfill for the new Iterator<\/code> object.<\/p>\n
Now, we have to talk about naming.<\/p>\n
Earlier we mentioned that TypeScript has types for Iterable<\/code> and Iterator<\/code>;\nhowever, like we mentioned, these act sort of like “protocols” to ensure certain operations work.\nThat means that not every value that is declared Iterable<\/code> or Iterator<\/code> in TypeScript will have those methods we mentioned above.<\/em><\/p>\n
But there is still a new runtime value<\/strong> called Iterator<\/code>.\nYou can reference Iterator<\/code>, as well as Iterator.prototype<\/code>, as actual values in JavaScript.\nThis is a bit awkward since TypeScript already defines its own thing called Iterator<\/code> purely for type-checking.\nSo due to this unfortunate name clash, TypeScript needs to introduce a separate type to describe these native\/built-in iterable iterators.<\/p>\n
TypeScript 5.6 introduces a new type called IteratorObject<\/code>.\nIt is defined as follows:<\/p>\n
interface IteratorObject<T, TReturn = unknown, TNext = unknown> extends Iterator<T, TReturn, TNext> {\r\n    [Symbol.iterator](): IteratorObject<T, TReturn, TNext>;\r\n}\r\n<\/code><\/pre>\n
Lots of built-in collections and methods produce subtypes of IteratorObject<\/code>s (like ArrayIterator<\/code>, SetIterator<\/code>, MapIterator<\/code>, and more), and both the core JavaScript and DOM types in lib.d.ts<\/code>, along with @types\/node<\/code>, have been updated to use this new type.<\/p>\n
We’d like to thank Kevin Gibbons<\/a> who contributed the changes for these types<\/a>, and who is one of the co-authors of the proposal<\/a>.<\/p>\n
Strict Builtin Iterator Checks (and --strictBuiltinIteratorReturn<\/code>)<\/h2>\n
When you call the next()<\/code> method on an Iterator<T, TReturn><\/code>, it returns an object with a value<\/code> and a done<\/code> property.\nThis is modeled with the type IteratorResult<\/code>.<\/p>\n
type IteratorResult<T, TReturn = any> = IteratorYieldResult<T> | IteratorReturnResult<TReturn>;\r\n\r\ninterface IteratorYieldResult<TYield> {\r\n    done?: false;\r\n    value: TYield;\r\n}\r\n\r\ninterface IteratorReturnResult<TReturn> {\r\n    done: true;\r\n    value: TReturn;\r\n}\r\n<\/code><\/pre>\n
The naming here is inspired by the way a generator function works.\nGenerator functions can yield<\/code> values, and then return<\/code> a final value – but the types between the two can be unrelated.<\/p>\n
function abc123() {\r\n    yield \"a\";\r\n    yield \"b\";\r\n    yield \"c\";\r\n    return 123;\r\n}\r\n\r\nconst iter = abc123();\r\n\r\niter.next(); \/\/ { value: \"a\", done: false }\r\niter.next(); \/\/ { value: \"b\", done: false }\r\niter.next(); \/\/ { value: \"c\", done: false }\r\niter.next(); \/\/ { value: 123, done: true }\r\n<\/code><\/pre>\n
With the new IteratorObject<\/code> type, we discovered some difficulties in allowing safe implementations of IteratorObject<\/code>s.\nAt the same time, there’s been a long standing unsafety with IteratorResult<\/code> in cases where TReturn<\/code> was any<\/code> (the default!).\nFor example, let’s say we have an IteratorResult<string, any><\/code>.\nIf we end up reaching for the value<\/code> of this type, we’ll end up with string | any<\/code>, which is just any<\/code>.<\/p>\n
function* uppercase(iter: Iterator<string, any>) {\r\n    while (true) {\r\n        const { value, done } = iter.next();\r\n        yield value.toUppercase(); \/\/ oops! forgot to check for `done` first and misspelled `toUpperCase`\r\n\r\n        if (done) {\r\n            return;\r\n        }\r\n    }\r\n}\r\n<\/code><\/pre>\n
It would be hard to fix this on every Iterator<\/code> today without introducing a lot of breaks, but we can at least fix it with most IteratorObject<\/code>s that get created.<\/p>\n
TypeScript 5.6 introduces a new intrinsic type called BuiltinIteratorReturn<\/code> and a new --strict<\/code>-mode flag called --strictBuiltinIteratorReturn<\/code>.\nWhenever IteratorObject<\/code>s are used in places like lib.d.ts<\/code>, they are always written with BuiltinIteratorReturn<\/code> type for TReturn<\/code> (though you’ll see the more-specific MapIterator<\/code>, ArrayIterator<\/code>, SetIterator<\/code> more often).<\/p>\n
interface MapIterator<T> extends IteratorObject<T, BuiltinIteratorReturn, unknown> {\r\n    [Symbol.iterator](): MapIterator<T>;\r\n}\r\n\r\n\/\/ ...\r\n\r\ninterface Map<K, V> {\r\n    \/\/ ...\r\n\r\n    \/**\r\n     * Returns an iterable of key, value pairs for every entry in the map.\r\n     *\/\r\n    entries(): MapIterator<[K, V]>;\r\n\r\n    \/**\r\n     * Returns an iterable of keys in the map\r\n     *\/\r\n    keys(): MapIterator<K>;\r\n\r\n    \/**\r\n     * Returns an iterable of values in the map\r\n     *\/\r\n    values(): MapIterator<V>;\r\n}\r\n<\/code><\/pre>\n
By default, BuiltinIteratorReturn<\/code> is any<\/code>, but when --strictBuiltinIteratorReturn<\/code> is enabled (possibly via --strict<\/code>), it is undefined<\/code>.\nUnder this new mode, if we use BuiltinIteratorReturn<\/code>, our earlier example now correctly errors:<\/p>\n
function* uppercase(iter: Iterator<string, BuiltinIteratorReturn>) {\r\n    while (true) {\r\n        const { value, done } = iter.next();\r\n        yield value.toUppercase();\r\n        \/\/    ~~~~~ ~~~~~~~~~~~\r\n        \/\/ error! \u2503      \u2503\r\n        \/\/        \u2503      \u2517\u2501 Property 'toUppercase' does not exist on type 'string'. Did you mean 'toUpperCase'?\r\n        \/\/        \u2503\r\n        \/\/        \u2517\u2501 'value' is possibly 'undefined'.\r\n\r\n        if (done) {\r\n            return;\r\n        }\r\n    }\r\n}\r\n<\/code><\/pre>\n
You’ll typically see BuiltinIteratorReturn<\/code> paired up with IteratorObject<\/code> throughout lib.d.ts<\/code>.\nIn general, we recommend being more explicit around the TReturn<\/code> in your own code when possible.<\/p>\n
For more information, you can read up on the feature here<\/a>.<\/p>\n
Support for Arbitrary Module Identifiers<\/h2>\n
JavaScript allows modules to export bindings with invalid identifier names as string literals:<\/p>\n
const banana = \"\ud83c\udf4c\";\r\n\r\nexport { banana as \"\ud83c\udf4c\" };\r\n<\/code><\/pre>\n
Likewise, it allows modules to grab imports with these arbitrary names and bind them to valid identifiers:<\/p>\n
import { \"\ud83c\udf4c\" as banana } from \".\/foo\"\r\n\r\n\/**\r\n * om nom nom\r\n *\/\r\nfunction eat(food: string) {\r\n    console.log(\"Eating\", food);\r\n};\r\n\r\neat(banana);\r\n<\/code><\/pre>\n
This seems like a cute party trick (if you’re as fun as we are at parties), but it has its uses for interoperability with other languages (typically via JavaScript\/WebAssembly boundaries), since other languages may have different rules for what constitutes a valid identifier.\nIt can also be useful for tools that generate code, like esbuild with its inject<\/code> feature<\/a>.<\/p>\n
TypeScript 5.6 now allows you to use these arbitrary module identifiers in your code!\nWe’d like to thank Evan Wallace<\/a> who contributed this change to TypeScript<\/a>!<\/p>\n
The --noUncheckedSideEffectImports<\/code> Option<\/h2>\n
In JavaScript it’s possible to import<\/code> a module without actually importing any values from it.<\/p>\n
import \"some-module\";\r\n<\/code><\/pre>\n
These imports are often called side effect imports<\/em> because the only useful behavior they can provide is by executing some side effect (like registering a global variable, or adding a polyfill to a prototype).<\/p>\n
In TypeScript, this syntax has had a pretty strange quirk: if the import<\/code> could be resolved to a valid source file, then TypeScript would load and check the file.\nOn the other hand, if no source file could be found, TypeScript would silently ignore the import<\/code>!<\/p>\n
This is surprising behavior, but it partially stems from modeling patterns in the JavaScript ecosystem.\nFor example, this syntax has also been used with special loaders in bundlers to load CSS or other assets.\nYour bundler might be configured in such a way where you can include specific .css<\/code> files by writing something like the following:<\/p>\n
import \".\/button-component.css\";\r\n\r\nexport function Button() {\r\n    \/\/ ...\r\n}\r\n<\/code><\/pre>\n
Still, this masks potential typos on side effect imports.\nThat’s why TypeScript 5.6 introduces a new compiler option called --noUncheckedSideEffectImports<\/code>, to catch these cases.\nWhen --noUncheckedSideEffectImports<\/code> is enabled, TypeScript will now error if it can’t find a source file for a side effect import.<\/p>\n
import \"oops-this-module-does-not-exist\";\r\n\/\/     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\r\n\/\/ error: Cannot find module 'oops-this-module-does-not-exist' or its corresponding type declarations.\r\n<\/code><\/pre>\n
When enabling this option, some working code may now receive an error, like in the CSS example above.\nTo work around this, users who want to just write side effect import<\/code>s for assets might be better served by writing what’s called an ambient module declaration<\/em> with a wildcard specifier.\nIt would go in a global file and look something like the following:<\/p>\n
\/\/ .\/src\/globals.d.ts\r\n\r\n\/\/ Recognize all CSS files as module imports.\r\ndeclare module \"*.css\" {}\r\n<\/code><\/pre>\n
In fact, you might already have a file like this in your project!\nFor example, running something like vite init<\/code> might create a similar vite-env.d.ts<\/code>.<\/p>\n
While this option is currently off by default, we encourage users to give it a try!<\/p>\n
For more information, check out the implementation here<\/a>.<\/p>\n
The --noCheck<\/code> Option<\/h2>\n
TypeScript 5.6 introduces a new compiler option, --noCheck<\/code>, which allows you to skip type checking for all input files.\nThis avoids unnecessary type-checking when performing any semantic analysis necessary for emitting output files.<\/p>\n
One scenario for this is to separate JavaScript file generation from type-checking so that the two can be run as separate phases.\nFor example, you could run tsc --noCheck<\/code> while iterating, and then tsc --noEmit<\/code> for a thorough type check.\nYou could also run the two tasks in parallel, even in --watch<\/code> mode, though note you’d probably want to specify a separate --tsBuildInfoFile<\/code> path if you’re truly running them at the same time.<\/p>\n
--noCheck<\/code> is also useful for emitting declaration files in a similar fashion.\nIn a project where --noCheck<\/code> is specified on a project that conforms to --isolatedDeclarations<\/code>, TypeScript can quickly generate declaration files without a type-checking pass.\nThe generated declaration files will rely purely on quick syntactic transformations.<\/p>\n
Note that in cases where --noCheck<\/code> is specified, but a project does not<\/em> use --isolatedDeclarations<\/code>, TypeScript may still perform as much type-checking as necessary to generate .d.ts<\/code> files.\nIn this sense, --noCheck<\/code> is a bit of a misnomer; however, the process will be lazier than a full type-check, only calculating the types of unannotated declarations.\nThis should be much faster than a full type-check.<\/p>\n
noCheck<\/code> is also available via the TypeScript API as a standard option.\nInternally, transpileModule<\/code> and transpileDeclaration<\/code> already used noCheck<\/code> to speed things up (at least as of TypeScript 5.5).\nNow any build tool should be able to leverage the flag, taking a variety of custom strategies to coordinate and speed up builds.<\/p>\n
For more information, see the work done in TypeScript 5.5 to power up noCheck<\/code> internally<\/a>, along with the relevant work to make it publicly available on the command line<\/a> and<\/p>\n
Allow --build<\/code> with Intermediate Errors<\/h2>\n
TypeScript’s concept of project references<\/em> allows you to organize your codebase into multiple projects and create dependencies between them.\nRunning the TypeScript compiler in --build<\/code> mode (or tsc -b<\/code> for short) is the built-in way of actually conducting that build across projects and figuring out which projects and files need to be compiled.<\/p>\n
Previously, using --build<\/code> mode would assume --noEmitOnError<\/code> and immediately stop the build if any errors were encountered.\nThis meant that “downstream” projects could never be checked and built if any of their “upstream” dependencies had build errors.\nIn theory, this is a very cromulent approach – if a project has errors, it is not necessarily in a coherent state for its dependencies.<\/p>\n
In reality, this sort of rigidity made things like upgrades a pain.\nFor example, if projectB<\/code> depends on projectA<\/code>, then people more familiar with projectB<\/code> can’t proactively upgrade their code until their dependencies are upgraded.\nThey are blocked by work on upgrading projectA<\/code> first.<\/p>\n
As of TypeScript 5.6, --build<\/code> mode will continue to build projects even if there are intermediate errors in dependencies.\nIn the face of intermediate errors, they will be reported consistently and output files will be generated on a best-effort basis;\nhowever, the build will continue to completion on the specified project.<\/p>\n
If you want to stop the build on the first project with errors, you can use a new flag called --stopOnBuildErrors<\/code>.\nThis can be useful when running in a CI environment, or when iterating on a project that’s heavily depended upon by other projects.<\/p>\n
Note that to accomplish this, TypeScript now always emits a .tsbuildinfo<\/code> file for any project in a --build<\/code> invocation (even if --incremental<\/code>\/--composite<\/code> is not specified).\nThis is to keep track of the state of how --build<\/code> was invoked and what work needs to be performed in the future.<\/p>\n
You can read more about this change here on the implementation<\/a>.<\/p>\n
Region-Prioritized Diagnostics in Editors<\/h2>\n
When TypeScript’s language service is asked for the diagnostics<\/em> for a file (things like errors, suggestions, and deprecations), it would typically require checking the entire file<\/em>.\nMost of the time this is fine, but in extremely large files it can incur a delay.\nThat can be frustrating because fixing a typo should feel like a quick operation, but can take seconds<\/em> in a big-enough file.<\/p>\n
To address this, TypeScript 5.6 introduces a new feature called region-prioritized diagnostics<\/em> or region-prioritized checking<\/em>.\nInstead of just requesting diagnostics for a set of files, editors can now also provide a relevant region of a given file – and the intent is that this will typically be the region of the file that is currently visible to a user.\nThe TypeScript language server can then choose to provide two sets of diagnostics: one for the region, and one for the file in its entirety.\nThis allows editing to feel way<\/em> more responsive in large files so you’re not waiting as long for thoes red squiggles to disappear.<\/p>\n
For some specific numbers, in our testing on TypeScript’s own checker.ts<\/code><\/a>, a full semantic diagnostics response took 3330ms.\nIn contrast, the response for the first region-based diagnostics response took 143ms!\nWhile the remaining whole-file response took about 3200ms, this can make a huge difference for quick edits.<\/p>\n
This feature also includes quite a bit of work to also make diagnostics report more consistently throughout your experience.\nDue the way our type-checker leverages caching to avoid work, subsequent checks between the same types could often have a different (typically shorter) error message.\nTechnically, lazy out-of-order checking could cause diagnostics to report differently between two locations in an editor – even before this feature – but we didn’t want to exacerbate the issue.\nWith recent work, we’ve ironed out many of these error inconsistencies.<\/p>\n
Currently, this functionality is available in Visual Studio Code for TypeScript 5.6 and later.<\/p>\n
For more detailed information, take a look at the implementation and write-up here<\/a>.<\/p>\n
Granular Commit Characters<\/h2>\n
TypeScript’s language service now provides its own commit characters<\/em> for each completion item.\nCommit characters are specific characters that, when typed, will automatically commit the currently-suggested completion item.<\/p>\n
What this means is that over time your editor will now more frequently commit to the currently-suggested completion item when you type certain characters.\nFor example, take the following code:<\/p>\n
declare let food: {\r\n    eat(): any;\r\n}\r\n\r\nlet f = (foo\/**\/\r\n<\/code><\/pre>\n
If our cursor is at \/**\/<\/code>, it’s unclear if the code we’re writing is going to be something like let f = (food.eat())<\/code> or let f = (foo, bar) => foo + bar<\/code>.\nYou could imagine that the editor might be able to auto-complete differently depending on which character we type out next.\nFor instance, if we type in the period\/dot character (.<\/code>), we probably want the editor to complete with the variable food<\/code>;\nbut if we type the comma character (,<\/code>), we might be writing out a parameter in an arrow function.<\/p>\n
Unfortunately, previously TypeScript just signaled to editors that the current text might define a new parameter name so that no<\/em> commit characters were safe.\nSo hitting a .<\/code> wouldn’t do anything even if it was “obvious” that the editor should auto-complete with the word food<\/code>.<\/p>\n
TypeScript now explicitly lists which characters are safe to commit for each completion item.\nWhile this won’t immediately<\/em> change your day-to-day experience, editors that support these commit characters should see behavioral improvements over time.\nTo see those improvements right now, you can now use the TypeScript nightly extension<\/a> with Visual Studio Code Insiders<\/a>.\nHitting .<\/code> in the code above correctly auto-completes with food<\/code>.<\/p>\n
For more information, see the pull request that added commit characters<\/a> along with our adjustments to commit characters depending on context<\/a>.<\/p>\n
Exclude Patterns for Auto-Imports<\/h2>\n
TypeScript’s language service now allows you to specify a list of regular expression patterns which will filter away auto-import suggestions from certain specifiers.\nFor example, if you want to exclude all “deep” imports from a package like lodash<\/code>, you could configure the following preference in Visual Studio Code:<\/p>\n
{\r\n    \"typescript.preferences.autoImportSpecifierExcludeRegexes\": [\r\n        \"^lodash\/.*$\"\r\n    ]\r\n}\r\n<\/code><\/pre>\n
Or going the other way, you might want to disallow importing from the entry-point of a package:<\/p>\n
{\r\n    \"typescript.preferences.autoImportSpecifierExcludeRegexes\": [\r\n        \"^lodash$\"\r\n    ]\r\n}\r\n<\/code><\/pre>\n
One could even avoid node:<\/code> imports by using the following setting:<\/p>\n
{\r\n    \"typescript.preferences.autoImportSpecifierExcludeRegexes\": [\r\n        \"^node:\"\r\n    ]\r\n}\r\n<\/code><\/pre>\n
To specify certain regular expression flags like i<\/code> or u<\/code>, you will need to surround your regular expression with slashes.\nWhen providing surrounding slashes, you’ll need to escape other inner slashes.<\/p>\n
{\r\n    \"typescript.preferences.autoImportSpecifierExcludeRegexes\": [\r\n        \"^.\/lib\/internal\",        \/\/ no escaping needed\r\n        \"\/^.\\\\\/lib\\\\\/internal\/\",  \/\/ escaping needed - note the leading and trailing slashes\r\n        \"\/^.\\\\\/lib\\\\\/internal\/i\"  \/\/ escaping needed - we needed slashes to provide the 'i' regex flag\r\n    ]\r\n}\r\n<\/code><\/pre>\n
The same settings can be applied for JavaScript through javascript.preferences.autoImportSpecifierExcludeRegexes<\/code> in VS Code.<\/p>\n
Note that while this option may overlap a bit with typescript.preferences.autoImportFileExcludePatterns<\/code>, there are differences.\nThe existing autoImportFileExcludePatterns<\/code> takes a list of glob patterns that exclude file paths<\/em>.\nThis might be simpler for a lot of scenarios where you want to avoid auto-importing from specific files and directories, but that’s not always enough.\nFor example, if you’re using the package @types\/node<\/code>, the same file declares both fs<\/code> and node:fs<\/code>, so we can’t use autoImportExcludePatterns<\/code> to filter out one or the other.<\/p>\n
The new autoImportSpecifierExcludeRegexes<\/code> is specific to module specifiers<\/em> (the specific string we write in our import<\/code> statements), so we could write a pattern to exclude fs<\/code> or node:fs<\/code> without excluding the other.\nWhat’s more, we could write patterns to force auto-imports to prefer different specifier styles (e.g. preferring .\/foo\/bar.js<\/code> over #foo\/bar.js<\/code>).<\/p>\n
For more information, see the implementation here<\/a>.<\/p>\n
Notable Behavioral Changes<\/h2>\n
This section highlights a set of noteworthy changes that should be acknowledged and understood as part of any upgrade.\nSometimes it will highlight deprecations, removals, and new restrictions.\nIt can also contain bug fixes that are functionally improvements, but which can also affect an existing build by introducing new errors.<\/p>\n
lib.d.ts<\/code><\/h3>\n
Types generated for the DOM may have an impact on type-checking your codebase.\nFor more information, see linked issues related to DOM and lib.d.ts<\/code> updates for this version of TypeScript<\/a>.<\/p>\n
.tsbuildinfo<\/code> is Always Written<\/h3>\n
To enable --build<\/code> to continue building projects even if there are intermediate errors in dependencies, and to support --noCheck<\/code> on the command line, TypeScript now always emits a .tsbuildinfo<\/code> file for any project in a --build<\/code> invocation.\nThis happens regardless of whether --incremental<\/code> is actually on.\nSee more information here<\/a>.<\/p>\n
Respecting File Extensions and package.json<\/code> from within node_modules<\/code><\/h3>\n
Before Node.js implemented support for ECMAScript modules in v12, there was never a good way for TypeScript to know whether .d.ts<\/code> files it found in node_modules<\/code> represented JavaScript files authored as CommonJS or ECMAScript modules.\nWhen the vast majority of npm was CommonJS-only, this didn’t cause many problems – if in doubt, TypeScript could just assume that everything behaved like CommonJS.\nUnfortunately, if that assumption was wrong it could allow unsafe imports:<\/p>\n
\/\/ node_modules\/dep\/index.d.ts\r\nexport declare function doSomething(): void;\r\n\r\n\/\/ index.ts\r\n\/\/ Okay if \"dep\" is a CommonJS module, but fails if\r\n\/\/ it's an ECMAScript module - even in bundlers!\r\nimport dep from \"dep\";\r\ndep.doSomething();\r\n<\/code><\/pre>\n
In practice, this didn’t come up very often.\nBut in the years since Node.js started supporting ECMAScript modules, the share of ESM on npm has grown.\nFortunately, Node.js also introduced a mechanism that can help TypeScript determine if a file is an ECMAScript module or a CommonJS module: the .mjs<\/code> and .cjs<\/code> file extensions and the package.json<\/code> \"type\"<\/code> field.\nTypeScript 4.7 added support for understanding these indicators, as well as authoring .mts<\/code> and .cts<\/code> files;\nhowever, TypeScript would only<\/em> read those indicators under --module node16<\/code> and --module nodenext<\/code>, so the unsafe import above was still a problem for anyone using --module esnext<\/code> and --moduleResolution bundler<\/code>, for example.<\/p>\n
To solve this, TypeScript 5.6 collects module format information and uses it to resolve ambiguities like the one in the example above in all<\/em> module<\/code> modes (except amd<\/code>, umd<\/code>, and system<\/code>).\nFormat-specific file extensions (.mts<\/code> and .cts<\/code>) are respected anywhere they’re found, and the package.json<\/code> \"type\"<\/code> field is consulted inside node_modules<\/code> dependencies, regardless of the module<\/code> setting.\nPreviously, it was technically possible to produce CommonJS output into a .mjs<\/code> file or vice versa:<\/p>\n
\/\/ main.mts\r\nexport default \"oops\";\r\n\r\n\/\/ $ tsc --module commonjs main.mts\r\n\/\/ main.mjs\r\nObject.defineProperty(exports, \"__esModule\", { value: true });\r\nexports.default = \"oops\";\r\n<\/code><\/pre>\n
Now, .mts<\/code> files never emit CommonJS output, and .cts<\/code> files never emit ESM output.<\/p>\n
Note that much of this behavior was provided in pre-release versions of TypeScript 5.5 (implementation details here<\/a>), but in 5.6 this behavior is only extended to files within node_modules<\/code>.<\/p>\n
More details are available on the change here<\/a>.<\/p>\n
Correct override<\/code> Checks on Computed Properties<\/h3>\n
Previously, computed properties marked with override<\/code> did not correctly check for the existence of a base class member.\nSimilarly, if you used noImplicitOverride<\/code>, you would not get an error if you forgot<\/em> to add an override<\/code> modifier to a computed property.<\/p>\n
TypeScript 5.6 now correctly checks computed properties in both cases.<\/p>\n
const foo = Symbol(\"foo\");\r\nconst bar = Symbol(\"bar\");\r\n\r\nclass Base {\r\n    [bar]() {}\r\n}\r\n\r\nclass Derived extends Base {\r\n    override [foo]() {}\r\n\/\/           ~~~~~\r\n\/\/ error: This member cannot have an 'override' modifier because it is not declared in the base class 'Base'.\r\n\r\n    [bar]() {}\r\n\/\/  ~~~~~\r\n\/\/ error under noImplicitOverride: This member must have an 'override' modifier because it overrides a member in the base class 'Base'.\r\n}\r\n<\/code><\/pre>\n
This fix was contributed thanks to Oleksandr Tarasiuk<\/a> in this pull request<\/a>.<\/p>\n
What’s Next?<\/h2>\n
If you want to see what’s coming next, you can also take a look at the TypeScript 5.7 iteration plan<\/a> where you’ll see a list of prioritized features, bug fixes, and target release dates that you can plan around.\nTypeScript’s nightly releases<\/a> are easy to use over npm, and there’s also an extension to use those nightly releases in Visual Studio Code<\/a>.\nNightly releases tend not to be disruptive, but they can give you a good sense of what’s coming next while helping the TypeScript project catch bugs early!<\/p>\n
Otherwise, we hope TypeScript 5.6 gives you a great experience, and makes your day-to-day coding a joy!<\/p>\n
Happy Hacking!<\/p>\n
– Daniel Rosenwasser and the TypeScript Team<\/p>\n","protected":false},"excerpt":{"rendered":"
Today we’re excited to announce the release of TypeScript 5.6! If you’re not familiar with TypeScript, it’s a language that builds on top of JavaScript by adding syntax for types. Types describe the shapes we expect of our variables, parameters, and functions, and the TypeScript type-checker can help catch issues like typos, missing properties, and […]<\/p>\n","protected":false},"author":381,"featured_media":1797,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[],"class_list":["post-4429","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-typescript"],"acf":[],"blog_post_summary":"
Today we’re excited to announce the release of TypeScript 5.6! If you’re not familiar with TypeScript, it’s a language that builds on top of JavaScript by adding syntax for types. Types describe the shapes we expect of our variables, parameters, and functions, and the TypeScript type-checker can help catch issues like typos, missing properties, and […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/typescript\/wp-json\/wp\/v2\/posts\/4429","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/typescript\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/typescript\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/typescript\/wp-json\/wp\/v2\/users\/381"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/typescript\/wp-json\/wp\/v2\/comments?post=4429"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/typescript\/wp-json\/wp\/v2\/posts\/4429\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/typescript\/wp-json\/wp\/v2\/media\/1797"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/typescript\/wp-json\/wp\/v2\/media?parent=4429"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/typescript\/wp-json\/wp\/v2\/categories?post=4429"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/typescript\/wp-json\/wp\/v2\/tags?post=4429"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
Similarly, there is a AsyncIteratorObject<\/code> type for parity.\nAsyncIterator<\/code> does not yet exist as a runtime value in JavaScript that brings the same methods for AsyncIterable<\/code>s, but it is an active proposal<\/a> and this new type prepares for it.<\/p>\n