title: TypeScript 4.9
layout: docs
permalink: /ko/docs/handbook/release-notes/typescript-4-9.html

oneline: TypeScript 4.9 Release Notes

satisfies operator

TypeScript developers often face a dilemma. We have some expressions with this type and _accord_I'd like to make sure it does, but for inference, the expression of _The most specific type_There are times when you want to keep it.

For example

// 각 속성은 문자열 또는 RGB 튜플일 수 있습니다.constpalette={red:[255,0,0],green:"#00ff00",bleu:[0,0,255]//  ^^^^ sacrebleu - 오타를 냈습니다!};// 우리는 배열 메서드를 'red'에 사용하고 싶습니다...constredComponent=palette.red.at(0);// 혹은 'green'에 문자열 메서드를 사용하고 싶을 수 있습니다...constgreenNormalized=palette.green.toUpperCase();

We arebleu ministerblueshould have been written.
paletteBy indicating the type inbleu You can catch typos, but if you do, you'll lose information about each attribute.

typeColors="red"|"green"|"blue";typeRGB=[red:number,green:number,blue:number];constpalette:Record<Colors,string|RGB>={red:[255,0,0],green:"#00ff00",bleu:[0,0,255]//  ~~~~ 이제 오타를 올바르게 감지했습니다.};// 하지만 여기서 원치 않는 문제가 발생했습니다. 'palette.red'가 문자열이 "될 수 있다"는것 입니다.constredComponent=palette.red.at(0);

satisfies You can use operators to verify that the type of an expression matches a specific type without changing the result type of the expression.
For example, we havesatisfiesUsing thepaletteAll properties ofstring | number[]You can verify that it is compatible with

typeColors="red"|"green"|"blue";typeRGB=[red:number,green:number,blue:number];constpalette={red:[255,0,0],green:"#00ff00",bleu:[0,0,255]//  ~~~~ 오타가 잡혔습니다!}satisfiesRecord<Colors,string|RGB>;// 두 메서드 모두 여전히 접근할 수 있습니다!constredComponent=palette.red.at(0);constgreenNormalized=palette.green.toUpperCase();

satisfiescan be used to detect many errors.
For example, if an object is of a certain type,all You can have the key, but not more.

typeColors="red"|"green"|"blue";// 'Colors' 키가 정확한지 확인합니다.constfavoriteColors={"red":"yes","green":false,"blue":"kinda","platypus":false//  ~~~~~~~~~~ 에러 - "platypus"는 'Colors' 리스트에 없습니다.}satisfiesRecord<Colors,unknown>;// 'red', 'green' 및 'blue' 속성의 모든 정보가 유지됩니다.constg:boolean=favoriteColors.green;

Sometimes we may be more interested in the type of each attribute than in whether the attribute name matches.
In this case, you can also check whether all attribute values of the object conform to some type.

typeRGB=[red:number,green:number,blue:number];constpalette={red:[255,0,0],green:"#00ff00",blue:[0,0]//    ~~~~~~ 에러!}satisfiesRecord<string,string|RGB>;// 각 속성에 대한 정보는 계속 유지됩니다.constredComponent=palette.red.at(0);constgreenNormalized=palette.green.toUpperCase();

For more examples,Proposed issue andA pull request that implements thisCheck it out.
We have implemented this feature withOleksandr TarasiukThank you.

Unlisted Property Narrowing with thein Operator

As developers, we often need to deal with values that aren't fully known at runtime.
In fact, we often don't know if properties exist, whether we're getting a response from a server or reading a configuration file.
JavaScript'sin operator can check whether a property
exists on an object.

Previously, TypeScript allowed us to narrow away any types that don't explicitly list a property.

interfaceRGB{red:number;green:number;blue:number;}interfaceHSV{hue:number;saturation:number;value:number;}functionsetColor(color:RGB|HSV){if("hue"incolor){// 'color' now has the type HSV}// ...}

Here, the typeRGB didn't list thehue and got narrowed away, and leaving us with the typeHSV.

But what about examples where no type listed a given property?
In those cases, the language didn't help us much.
Let's take the following example in #"auto" data-snippet-clipboard-copy-content="function tryGetPackageName(context) { const packageJSON = context.packageJSON; // Check to see if we have an object. if (packageJSON && typeof packageJSON === "object") { // Check to see if it has a string name property. if ("name" in packageJSON && typeof packageJSON.name === "string") { return packageJSON.name; } } return undefined;}">

functiontryGetPackageName(context){constpackageJSON=context.packageJSON;// Check to see if we have an object.if(packageJSON&&typeofpackageJSON==="object"){// Check to see if it has a string name property.if("name"inpackageJSON&&typeofpackageJSON.name==="string"){returnpackageJSON.name;}}returnundefined;}

Rewriting this to canonical TypeScript would just be a matter of defining and using a type forcontext;
however, picking a safe type likeunknown for thepackageJSON property would cause issues in older versions of TypeScript.

interfaceContext{packageJSON:unknown;}functiontryGetPackageName(context:Context){constpackageJSON=context.packageJSON;// Check to see if we have an object.if(packageJSON&&typeofpackageJSON==="object"){// Check to see if it has a string name property.if("name"inpackageJSON&&typeofpackageJSON.name==="string"){//                                              ~~~~// error! Property 'name' does not exist on type 'object.returnpackageJSON.name;//                     ~~~~// error! Property 'name' does not exist on type 'object.}}returnundefined;}

This is because while the type ofpackageJSON was narrowed fromunknown toobject, thein operator strictly narrowed to types that actually defined the property being checked.
As a result, the type ofpackageJSON remainedobject.

TypeScript 4.9 makes thein operator a little bit more powerful when narrowing types thatdon't list the property at all.
Instead of leaving them as-is, the language will intersect their types withRecord<"property-key-being-checked", unknown>.

So in our example,packageJSON will have its type narrowed fromunknown toobject toobject & Record<"name", unknown>
That allows us to accesspackageJSON.name directly and narrow that independently.

interfaceContext{packageJSON:unknown;}functiontryGetPackageName(context:Context):string|undefined{constpackageJSON=context.packageJSON;// Check to see if we have an object.if(packageJSON&&typeofpackageJSON==="object"){// Check to see if it has a string name property.if("name"inpackageJSON&&typeofpackageJSON.name==="string"){// Just works!returnpackageJSON.name;}}returnundefined;}

TypeScript 4.9 also tightens up a few checks around howin is used, ensuring that the left side is assignable to the typestring | number | symbol, and the right side is assignable toobject.
This helps check that we're using valid property keys, and not accidentally checking primitives.

For more information,read the implementing pull request

Auto-Accessors in Classes

TypeScript 4.9 supports an upcoming feature in ECMAScript called auto-accessors.
Auto-accessors are declared just like properties on classes, except that they're declared with theaccessor keyword.

classPerson{    accessorname:string;constructor(name:string){this.name=name;}}

Under the covers, these auto-accessors "de-sugar" to aget andset accessor with an unreachable private property.

classPerson{    #__name:string;getname(){returnthis.#__name;}setname(value:string){this.#__name=name;}constructor(name:string){this.name=name;}}

You can [read up more about the auto-accessors pull request on the original PR](https://github.com/microsoft/TypeScript/pull/49705).

Checks For Equality onNaN

A major gotcha for JavaScript developers is checking against the valueNaN using the built-in equality operators.

For some background,NaN is a special numeric value that stands for "Not a Number".
Nothing is ever equal toNaN - evenNaN!

console.log(NaN==0)// falseconsole.log(NaN===0)// falseconsole.log(NaN==NaN)// falseconsole.log(NaN===NaN)// false

But at least symmetricallyeverything is always not-equal toNaN.

console.log(NaN!=0)// trueconsole.log(NaN!==0)// trueconsole.log(NaN!=NaN)// trueconsole.log(NaN!==NaN)// true

This technically isn't a JavaScript-specific problem, since any language that contains IEEE-754 floats has the same behavior;
but JavaScript's primary numeric type is a floating point number, and number parsing in JavaScript can often result inNaN.
In turn, checking againstNaN ends up being fairly common, and the correct way to do so is to use [Number.isNaN](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Number/isNaN) -but as we mentioned, lots of people accidentally end up checking withsomeValue === NaN instead.

TypeScript now errors on direct comparisons againstNaN, and will suggest using some variation ofNumber.isNaN instead.

functionvalidate(someValue:number){returnsomeValue!==NaN;//     ~~~~~~~~~~~~~~~~~// error: This condition will always return 'true'.//        Did you mean '!Number.isNaN(someValue)'?}

We believe that this change should strictly help catch beginner errors, similar to how TypeScript currently issues errors on comparisons against object and array literals.

We'd like to extend our thanks to [Oleksandr Tarasiuk](https://github.com/a-tarasyuk) who [contributed this check](https://github.com/microsoft/TypeScript/pull/50626).

File-Watching Now Uses File System Events

In earlier versions, TypeScript leaned heavily onpolling for watching individual files.
Using a polling strategy meant checking the state of a file periodically for updates.
On Node.js, [fs.watchFile](https://nodejs.org/docs/latest-v18.x/api/fs.html#fswatchfilefilename-options-listener) is the built-in way to get a polling file-watcher.
While polling tends to be more predictable across platforms and file systems, it means that your CPU has to periodically get interrupted and check for updates to the file, even when nothing's changed.
For a few dozen files, this might not be noticeable;
but on a bigger project with lots of files - or lots of files innode_modules - this can become a resource hog.

Generally speaking, a better approach is to use file system events.
Instead of polling, we can announce that we're interested in updates of specific files and provide a callback for when those filesactually do change.
Most modern platforms in use provide facilities and APIs likeCreateIoCompletionPort,kqueue,epoll, andinotify.
Node.js mostly abstracts these away by providing [fs.watch](https://nodejs.org/docs/latest-v18.x/api/fs.html#fswatchfilename-options-listener).
File system events usually work great, but there are [lots of caveats](https://nodejs.org/docs/latest-v18.x/api/fs.html#caveats) to using them, and in turn, to using thefs.watch API.
A watcher needs to be careful to consider [inode watching](https://nodejs.org/docs/latest-v18.x/api/fs.html#inodes), [unavailability on certain file systems](https://nodejs.org/docs/latest-v18.x/api/fs.html#availability) (e.g.networked file systems), whether recursive file watching is available, whether directory renames trigger events, and even file watcher exhaustion!
In other words, it's not quite a free lunch, especially if you're looking for something cross-platform.

As a result, our default was to pick the lowest common denominator: polling.
Not always, but most of the time.

Over time, we've provided the means to [choose other file-watching strategies](https://www.typescriptlang.org/docs/handbook/configuring-watch.html).
This allowed us to get feedback and harden our file-watching implementation against most of these platform-specific gotchas.
As TypeScript has needed to scale to larger codebases, and has improved in this area, we felt swapping to file system events as the default would be a worthwhile investment.

In TypeScript 4.9, file watching is powered by file system events by default, only falling back to polling if we fail to set up event-based watchers.
For most developers, this should provide a much less resource-intensive experience when running in--watch mode, or running with a TypeScript-powered editor like Visual Studio or VS Code.

[The way file-watching works can still be configured] (https://www.typescriptlang.org/docs/handbook/configuring-watch.html) through environment variables andwatchOptions - and [some editors like VS Code can supportwatchOptions independently](https://code.visualstudio.com/docs/getstarted/settings#:~:text=typescript%2etsserver%2ewatchOptions).
Developers using more exotic set-ups where source code resides on a networked file systems (like NFS and SMB) may need to opt back into the older behavior; though if a server has reasonable processing power, it might just be better to enable SSH and run TypeScript remotely so that it has direct local file access.
VS Code has plenty of [remote extensions](https://marketplace.visualstudio.com/search?term=remote&target=VSCode&category=All%20categories&sortBy=Relevance) to make this easier.

You can [read up more on this change on GitHub](https://github.com/microsoft/TypeScript/pull/50366).

"Remove Unused Imports" and "Sort Imports" Commands for Editors

Previously, TypeScript only supported two editor commands to manage imports.
For our examples, take the following code:

import{Zebra,Moose,HoneyBadger}from"./zoo";import{foo,bar}from"./helper";letx:Moose|HoneyBadger=foo();

The first was called "Organize Imports" which would remove unused imports, and then sort the remaining ones.
It would rewrite that file to look like this one:

import{foo}from"./helper";import{HoneyBadger,Moose}from"./zoo";letx:Moose|HoneyBadger=foo();

In TypeScript 4.3, we introduced a command called "Sort Imports" which wouldonly sort imports in the file, but not remove them - and would rewrite the file like this.

import{bar,foo}from"./helper";import{HoneyBadger,Moose,Zebra}from"./zoo";letx:Moose|HoneyBadger=foo();

The caveat with "Sort Imports" was that in Visual Studio Code, this feature was only available as an on-save command - not as a manually triggerable command.

TypeScript 4.9 adds the other half, and now provides "Remove Unused Imports".
TypeScript will now remove unused import names and statements, but will otherwise leave the relative ordering alone.

import{Moose,HoneyBadger}from"./zoo";import{foo}from"./helper";letx:Moose|HoneyBadger=foo();

This feature is available to all editors that wish to use either command;
but notably, Visual Studio Code (1.73 and later) will have support built inand will surface these commands via its Command Palette.
Users who prefer to use the more granular "Remove Unused Imports" or "Sort Imports" commands should be able to reassign the "Organize Imports" key combination to them if desired.

You can [view specifics of the feature here](https://github.com/microsoft/TypeScript/pull/50931).

Go-to-Definition onreturn Keywords

In the editor, when running a go-to-definition on thereturn keyword, TypeScript will now jump you to the top of the corresponding function.
This can be helpful to get a quick sense of which function areturn belongs to.

We expect TypeScript will expand this functionality to more keywords [such asawait andyield](https://github.com/microsoft/TypeScript/issues/51223) or [switch,case, anddefault](https://github.com/microsoft/TypeScript/issues/51225).

[This feature was implemented] (https://github.com/microsoft/TypeScript/pull/51227) thanks to [Oleksandr Tarasiuk](https://github.com/a-tarasyuk).

Performance Improvements

TypeScript has a few small, but notable, performance improvements.

First, TypeScript'sforEachChild function has been rewritten to use a function table lookup instead of aswitch statement across all syntax nodes.
forEachChild is a workhorse for traversing syntax nodes in the compiler, and is used heavily in the binding stage of our compiler, along with parts of the language service.
The refactoring offorEachChild yielded up to a 20% reduction of time spent in our binding phase and across language service operations.

Once we discovered this performance win forforEachChild, we tried it out onvisitEachChild, a function we use for transforming nodes in the compiler and language service.
The same refactoring yielded up to a 3% reduction in time spent in generating project output.

The initial exploration inforEachChild was [inspired by a blog post](https://artemis.sh/2022/08/07/emulating-calculators-fast-in-js.html) by [Artemis Everfree](https://artemis.sh/).
While we have some reason to believe the root cause of our speed-up might have more to do with function size/complexity than the issues described in the blog post, we're grateful that we were able to learn from the experience and try out a relatively quick refactoring that made TypeScript faster.

Finally, the way TypeScript preserves the information about a type in the true branch of a conditional type has been optimized.
In a type like

interfaceZoo<TextendsAnimal>{// ...}typeMakeZoo<A>=AextendsAnimal ?Zoo<A> :never;

TypeScript has to "remember" thatA must also be anAnimal when checking ifZoo<A> is valid.
This is basically done by creating a special type that used to hold the intersection ofA withAnimal;
however, TypeScript previously did this eagerly which isn't always necessary.
Furthermore, some faulty code in our type-checker prevented these special types from being simplified.
TypeScript now defers intersecting these types until it's necessary.
For codebases with heavy use of conditional types, you might witness significant speed-ups with TypeScript, but in our performance testing suite, we saw a more modest 3% reduction in type-checking time.

You can read up more on these optimizations on their respective pull requests:

• [forEachChild as a jump-table](https://github.com/SwapforEachChild to use a table of functions instead of aswitch statement. TypeScript#50225)
• [visitEachChild as a jump-table](https://github.com/Add a jump-table for visitEachChild TypeScript#50266)
• [Optimize substitition types] (https://github.com/Optimize substitution types TypeScript#50397)

Correctness Fixes and Breaking Changes

lib.d.ts Updates

While TypeScript strives to avoid major breaks, even small changes in the built-in libraries can cause issues.
We don't expect major breaks as a result of DOM andlib.d.ts updates, but there may be some small ones.

Better Types forPromise.resolve

Promise.resolve now uses theAwaited type to unwrap Promise-like types passed to it.
This means that it more often returns the rightPromise type, but that improved type can break existing code if it was expectingany orunknown instead of aPromise.
For more information, [see the original change](https://github.com/microsoft/TypeScript/pull/33074).

JavaScript Emit No Longer Elides Imports

When TypeScript first supported type-checking and compilation for JavaScript, it accidentally supported a feature called import elision.
In short, if an import is not used as a value, or the compiler can detect that the import doesn't refer to a value at runtime, the compiler will drop the import during emit.

This behavior was questionable, especially the detection of whether the import doesn't refer to a value, since it means that TypeScript has to trust sometimes-inaccurate declaration files.
In turn, TypeScript now preserves imports in JavaScript files.

// Input:import{someValue,SomeClass}from"some-module";/**@type {SomeClass} */letval=someValue;// Previous Output:import{someValue}from"some-module";/**@type {SomeClass} */letval=someValue;// Current Output:import{someValue,SomeClass}from"some-module";/**@type {SomeClass} */letval=someValue;

More information is available at [the implementing change](https://github.com/microsoft/TypeScript/pull/50404).

exports is Prioritized OvertypesVersions

Previously, TypeScript incorrectly prioritized thetypesVersions field over theexports field when resolving through apackage.json under--moduleResolution node16.
If this change impacts your library, you may need to addtypes@ version selectors in yourpackage.json'sexports field.

  {      "type": "module",      "main": "./dist/main.js"      "typesVersions": {          "<4.8": { ".": ["4.8-types/main.d.ts"] },          "*": { ".": ["modern-types/main.d.ts"] }      },      "exports": {          ".": {+             "types@<4.8": "4.8-types/main.d.ts",+             "types": "modern-types/main.d.ts",              "import": "./dist/main.js"          }      }  }

For more information, [see this pull request](https://github.com/microsoft/TypeScript/pull/50890).

substitute Replaced Withconstraint onSubstitutionTypes

As part of an optimization on substitution types,SubstitutionType objects no longer contain thesubstitute property representing the effective substitution (usually an intersection of the base type and the implicit constraint) - instead, they just contain theconstraint property.

For more details, [read more on the original pull request](https://github.com/microsoft/TypeScript/pull/50397).