![\"Extracting](\"https://devblogs.microsoft.com/typescript/wp-content/uploads/sites/11/2020/03/printSquaresWithoutNewlines-3.9.gif.gif\")
Promise.allRecent versions of TypeScript (around 3.7) have had updates to the declarations of functions like Promise.all and Promise.race.\nUnfortunately, that introduced a few regressions, especially when mixing in values with null or undefined.
\ntsinterface Lion {\n roar(): void;\n}\n\ninterface Seal {\n singKissFromARose(): void;\n}\n\nasync function visitZoo(\n lionExhibit: Promise<Lion>,\n sealExhibit: Promise<Seal | undefined>\n) {\n let [lion, seal] = await Promise.all([lionExhibit, sealExhibit]);\n lion.roar(); // uh oh\n // ~~~~\n // Object is possibly 'undefined'.\n}
This is strange behavior!\nThe fact that sealExhibit contained an undefined somehow poisoned type of lion to include undefined.
Thanks to a pull request from Jack Bates, this has been fixed with improvements in our inference process in TypeScript 3.9.\nThe above no longer errors.\nIf you’ve been stuck on older versions of TypeScript due to issues around Promises, we encourage you to give 3.9 a shot!
awaited Type?If you’ve been following our issue tracker and design meeting notes, you might be aware of some work around a new type operator called awaited.\nThis goal of this type operator is to accurately model the way that Promise unwrapping works in JavaScript.
We initially anticipated shipping awaited in TypeScript 3.9, but as we’ve run early TypeScript builds with existing codebases, we’ve realized that the feature needs more design work before we can roll it out to everyone smoothly.\nAs a result, we’ve decided to pull the feature out of our main branch until we feel more confident.\nWe’ll be experimenting more with the feature, but we won’t be shipping it as part of this release.
TypeScript 3.9 ships with many new speed improvements.\nOur team has been focusing on performance after observing extremely poor editing/compilation speed with packages like material-ui and styled-components.\nWe’ve dived deep here, with a series of different pull requests that optimize certain pathological cases involving large unions, intersections, conditional types, and mapped types.
\nEach of these pull requests gains about a 5-10% reduction in compile times on certain codebases.\nIn total, we believe we’ve achieved around a 40% reduction in material-ui’s compile time!
\nWe also have some changes to file renaming functionality in editor scenarios.\nWe heard from the Visual Studio Code team that when renaming a file, just figuring out which import statements needed to be updated could take between 5 to 10 seconds.\nTypeScript 3.9 addresses this issue by changing the internals of how the compiler and language service caches file lookups.
\nWhile there’s still room for improvement, we hope this work translates to a snappier experience for everyone!
\n// @ts-expect-error CommentsImagine that we’re writing a library in TypeScript and we’re exporting some function called doStuff as part of our public API.\nThe function’s types declare that it takes two strings so that other TypeScript users can get type-checking errors, but it also does a runtime check (maybe only in development builds) to give JavaScript users a helpful error.
\ntsfunction doStuff(abc: string, xyz: string) {\n assert(typeof abc === \"string\");\n assert(typeof xyz === \"string\");\n\n // do some stuff\n}
So TypeScript users will get a helpful red squiggle and an error message when they misuse this function, and JavaScript users will get an assertion error.\nWe’d like to test this behavior, so we’ll write a unit test.
\n\ntsexpect(() => {\n doStuff(123, 456);\n}).toThrow();
Unfortunately if our tests are written in TypeScript, TypeScript will give us an error!
\n\ntsdoStuff(123, 456);\n// ~~~\n// error: Type 'number' is not assignable to type 'string'.
That’s why TypeScript 3.9 brings a new feature: // @ts-expect-error comments.\nWhen a line is prefixed with a // @ts-expect-error comment, TypeScript will suppress that error from being reported;\nbut if there’s no error, TypeScript will report that // @ts-expect-error wasn’t necessary.
As a quick example, the following code is okay
\n\nts// @ts-expect-error\nconsole.log(47 * \"octopus\");
while the following code
\n\nts// @ts-expect-error\nconsole.log(1 + 1);
results in the error
\nUnused '@ts-expect-error' directive.\nWe’d like to extend a big thanks to Josh Goldberg, the contributor who implemented this feature.\nFor more information, you can take a look at the ts-expect-error pull request.
ts-ignore or ts-expect-error?In some ways // @ts-expect-error can act as a suppression comment, similar to // @ts-ignore.\nThe difference is that // @ts-ignore will do nothing if the following line is error-free.
You might be tempted to switch existing // @ts-ignore comments over to // @ts-expect-error, and you might be wondering which is appropriate for future code.\nWhile it’s entirely up to you and your team, we have some ideas of which to pick in certain situations.
Pick ts-expect-error if:
Pick ts-ignore if:
In TypeScript 3.7 we introduced uncalled function checks to report an error when you’ve forgotten to call a function.
\n\ntsfunction hasImportantPermissions(): boolean {\n // ...\n}\n\n// Oops!\nif (hasImportantPermissions) {\n // ~~~~~~~~~~~~~~~~~~~~~~~\n // This condition will always return true since the function is always defined.\n // Did you mean to call it instead?\n deleteAllTheImportantFiles();\n}
However, this error only applied to conditions in if statements.\nThanks to a pull request from Alexander Tarasyuk, this feature is also now supported in ternary conditionals (i.e. the cond ? trueExpr : falseExpr syntax).
\ntsdeclare function listFilesOfDirectory(dirPath: string): string[];\ndeclare function isDirectory(): boolean;\n\nfunction getAllFiles(startFileName: string) {\n const result: string[] = [];\n traverse(startFileName);\n return result;\n\n function traverse(currentPath: string) {\n return isDirectory\n ? // ~~~~~~~~~~~\n // This condition will always return true\n // since the function is always defined.\n // Did you mean to call it instead?\n listFilesOfDirectory(currentPath).forEach(traverse)\n : result.push(currentPath);\n }\n}
https://github.com/microsoft/TypeScript/issues/36048
\nThe TypeScript compiler not only powers the TypeScript editing experience in most major editors, it also powers the JavaScript experience in the Visual Studio family of editors and more.\nUsing new TypeScript/JavaScript functionality in your editor will differ depending on your editor, but
\nOne great new improvement is in auto-imports in JavaScript files using CommonJS modules.
\nIn older versions, TypeScript always assumed that regardless of your file, you wanted an ECMAScript-style import like
\n\njsimport * as fs from \"fs\";
However, not everyone is targeting ECMAScript-style modules when writing JavaScript files.\nPlenty of users still use CommonJS-style require(...) imports like so
\njsconst fs = require(\"fs\");
TypeScript now automatically detects the types of imports you’re using to keep your file’s style clean and consistent.
\n\nFor more details on the change, see the corresponding pull request.
\nTypeScript’s refactorings and quick fixes often didn’t do a great job of preserving newlines.\nAs a really basic example, take the following code.
\n\ntsconst maxValue = 100;\n\n/*start*/\nfor (let i = 0; i <= maxValue; i++) {\n // First get the squared value.\n let square = i ** 2;\n\n // Now print the squared value.\n console.log(square);\n}\n/*end*/
If we highlighted the range from /*start*/ to /*end*/ in our editor to extract to a new function, we’d end up with code like the following.
\ntsconst maxValue = 100;\n\nprintSquares();\n\nfunction printSquares() {\n for (let i = 0; i <= maxValue; i++) {\n // First get the squared value.\n let square = i ** 2;\n // Now print the squared value.\n console.log(square);\n }\n}
That’s not ideal - we had a blank line between each statement in our for loop, but the refactoring got rid of it!\nTypeScript 3.9 does a little more work to preserve what we write.
\ntsconst maxValue = 100;\n\nprintSquares();\n\nfunction printSquares() {\n for (let i = 0; i <= maxValue; i++) {\n // First get the squared value.\n let square = i ** 2;\n\n // Now print the squared value.\n console.log(square);\n }\n}
![\"Extracting](\"https://devblogs.microsoft.com/typescript/wp-content/uploads/sites/11/2020/03/printSquaresWithNewlines-3.9.gif.gif\")
You can see more about the implementation in this pull request
\nThere are occasions where we might forget to return the value of the last statement in a function, especially when adding curly braces to arrow functions.
\n\nts// before\nlet f1 = () => 42;\n\n// oops - not the same!\nlet f2 = () => {\n 42;\n};
Thanks to a pull request from community member Wenlu Wang, TypeScript can provide a quick-fix to add missing return statements, remove curly braces, or add parentheses to arrow function bodies that look suspiciously like object literals.
![\"TypeScript](\"https://devblogs.microsoft.com/typescript/wp-content/uploads/sites/11/2020/04/missingReturnValue-3-9.gif\")
tsconfig.json FilesEditors need to figure out which configuration file a file belongs to so that it can apply the appropriate options and figure out which other files are included in the current “project”.\nBy default, editors powered by TypeScript’s language server do this by walking up each parent directory to find a tsconfig.json.
One case where this slightly fell over is when a tsconfig.json simply existed to reference other tsconfig.json files.
\njson// tsconfig.json\n{\n files: [],\n references: [\n { path: \"./tsconfig.shared.json\" },\n { path: \"./tsconfig.frontend.json\" },\n { path: \"./tsconfig.backend.json\" },\n ],\n}
This file that really does nothing but manage other project files is often called a “solution” in some environments.\nHere, none of these tsconfig.*.json files get picked up by the server, but we’d really like the language server to understand that the current .ts file probably belongs to one of the mentioned projects in this root tsconfig.json.
TypeScript 3.9 adds support to editing scenarios for this configuration.\nFor more details, take a look at the pull request that added this functionality.
\nTypeScript recently implemented the optional chaining operator, but we’ve received user feedback that the behavior of optional chaining (?.) with the non-null assertion operator (!) is extremely counter-intuitive.
Specifically, in previous versions, the code
\n\ntsfoo?.bar!.baz;
was interpreted to be equivalent to the following JavaScript.
\n\njs(foo?.bar).baz;
In the above code the parentheses stop the “short-circuiting” behavior of optional chaining, so if foo is undefined, accessing baz will cause a runtime error.
The Babel team who pointed this behavior out, and most users who provided feedback to us, believe that this behavior is wrong.\nWe do too!\nThe thing we heard the most was that the ! operator should just “disappear” since the intent was to remove null and undefined from the type of bar.
In other words, most people felt that the original snippet should be interpreted as
\n\njsfoo?.bar.baz;
which just evaluates to undefined when foo is undefined.
This is a breaking change, but we believe most code was written with the new interpretation in mind.\nUsers who want to revert to the old behavior can add explicit parentheses around the left side of the ! operator.
\ntsfoo?.bar!.baz;
} and > are Now Invalid JSX Text CharactersThe JSX Specification forbids the use of the } and > characters in text positions.\nTypeScript and Babel have both decided to enforce this rule to be more comformant.\nThe new way to insert these characters is to use an HTML escape code (e.g. <span> 2 > 1 </div>) or insert an expression with a string literal (e.g. <span> 2 {\">\"} 1 </div>).
Luckily, thanks to the pull request enforcing this from Brad Zacher, you’ll get an error message along the lines of
\nUnexpected token. Did you mean `{'>'}` or `>`?\nUnexpected token. Did you mean `{'}'}` or `}`?\nFor example:
\n\ntsxlet directions = <span>Navigate to: Menu Bar > Tools > Options</div>\n// ~ ~\n// Unexpected token. Did you mean `{'>'}` or `>`?
That error message came with a handy quick fix, and thanks to Alexander Tarasyuk, you can apply these changes in bulk if you have a lot of errors.
\nGenerally, an intersection type like A & B is assignable to C if either A or B is assignable to C; however, sometimes that has problems with optional properties.\nFor example, take the following:
\ntsinterface A {\n a: number; // notice this is 'number'\n}\n\ninterface B {\n b: string;\n}\n\ninterface C {\n a?: boolean; // notice this is 'boolean'\n b: string;\n}\n\ndeclare let x: A & B;\ndeclare let y: C;\n\ny = x;
In previous versions of TypeScript, this was allowed because while A was totally incompatible with C, B was compatible with C.
In TypeScript 3.9, so long as every type in an intersection is a concrete object type, the type system will consider all of the properties at once.\nAs a result, TypeScript will see that the a property of A & B is incompatible with that of C:
Type 'A & B' is not assignable to type 'C'.\n Types of property 'a' are incompatible.\n Type 'number' is not assignable to type 'boolean | undefined'.\nFor more information on this change, see the corresponding pull request.
\nThere are a few cases where you might end up with types that describe values that just don’t exist.\nFor example
\n\ntsdeclare function smushObjects<T, U>(x: T, y: U): T & U;\n\ninterface Circle {\n kind: \"circle\";\n radius: number;\n}\n\ninterface Square {\n kind: \"square\";\n sideLength: number;\n}\n\ndeclare let x: Circle;\ndeclare let y: Square;\n\nlet z = smushObjects(x, y);\nconsole.log(z.kind);
This code is slightly weird because there’s really no way to create an intersection of a Circle and a Square - they have two incompatible kind fields.\nIn previous versions of TypeScript, this code was allowed and the type of kind itself was never because \"circle\" & \"square\" described a set of values that could never exist.
In TypeScript 3.9, the type system is more aggressive here - it notices that it’s impossible to intersect Circle and Square because of their kind properties.\nSo instead of collapsing the type of z.kind to never, it collapses the type of z itself (Circle & Square) to never.\nThat means the above code now errors with:
Property 'kind' does not exist on type 'never'.\nMost of the breaks we observed seem to correspond with slightly incorrect type declarations.\nFor more details, see the original pull request.
\nIn older versions of TypeScript, get and set accessors in classes were emitted in a way that made them enumerable; however, this wasn’t compliant with the ECMAScript specification which states that they must be non-enumerable.\nAs a result, TypeScript code that targeted ES5 and ES2015 could differ in behavior.
Thanks to a pull request from GitHub user pathurs, TypeScript 3.9 now conforms more closely with ECMAScript in this regard.
\nany No Longer Act as anyIn previous versions of TypeScript, a type parameter constrained to any could be treated as any.
\ntsfunction foo<T extends any>(arg: T) {\n arg.spfjgerijghoied; // no error!\n}
This was an oversight, so TypeScript 3.9 takes a more conservative approach and issues an error on these questionable operations.
\n\ntsfunction foo<T extends any>(arg: T) {\n arg.spfjgerijghoied;\n // ~~~~~~~~~~~~~~~\n // Property 'spfjgerijghoied' does not exist on type 'T'.\n}
export * is Always RetainedIn previous TypeScript versions, declarations like export * from \"foo\" would be dropped in our JavaScript output if foo didn’t export any values.\nThis sort of emit is problematic because it’s type-directed and can’t be emulated by Babel.\nTypeScript 3.9 will always emit these export * declarations.\nIn practice, we don’t expect this to break much existing code.
We are continuing to move more of TypeScript’s built-in .d.ts library (lib.d.ts and family) to be generated from Web IDL files directly from the DOM specification.\nAs a result some vendor-specific types related to media access have been removed.
\nAdding this file to an ambient *.d.ts to your project will bring them back:
","headings":[{"value":"Improvements in Inference and Promise.all","depth":2},{"value":"What About the awaited Type?","depth":3},{"value":"Speed Improvements","depth":2},{"value":"// @ts-expect-error Comments","depth":2},{"value":"ts-ignore or ts-expect-error?","depth":3},{"value":"Uncalled Function Checks in Conditional Expressions","depth":2},{"value":"Editor Improvements","depth":2},{"value":"CommonJS Auto-Imports in JavaScript","depth":3},{"value":"Code Actions Preserve Newlines","depth":3},{"value":"Quick Fixes for Missing Return Expressions","depth":3},{"value":"Support for “Solution Style” tsconfig.json Files","depth":3},{"value":"Breaking Changes","depth":2},{"value":"Parsing Differences in Optional Chaining and Non-Null Assertions","depth":3},{"value":"} and > are Now Invalid JSX Text Characters","depth":3},{"value":"Stricter Checks on Intersections and Optional Properties","depth":3},{"value":"Intersections Reduced By Discriminant Properties","depth":3},{"value":"Getters/Setters are No Longer Enumerable","depth":3},{"value":"Type Parameters That Extend any No Longer Act as any","depth":3},{"value":"export * is Always Retained","depth":3},{"value":"More libdom.d.ts refinements","depth":3}],"frontmatter":{"permalink":"/docs/handbook/release-notes/typescript-3-9.html","title":"TypeScript 3.9","disable_toc":null,"oneline":"TypeScript 3.9 Release Notes"}},"prev":null,"next":null},"pageContext":{"id":"typescript-3.9","slug":"/docs/handbook/release-notes/typescript-3-9.html","repoPath":"/packages/documentation/copy/en/release-notes/TypeScript 3.9.md","lang":"en","modifiedTime":"2020-08-07T17:00:36.347Z"}}}tsinterface AudioTrackList {\n [Symbol.iterator](): IterableIterator<AudioTrack>;\n }\n\ninterface HTMLVideoElement {\n readonly audioTracks: AudioTrackList\n\n msFrameStep(forward: boolean): void;\n msInsertVideoEffect(activatableClassId: string, effectRequired: boolean, config?: any): void;\n msSetVideoRectangle(left: number, top: number, right: number, bottom: number): void;\n webkitEnterFullScreen(): void;\n webkitEnterFullscreen(): void;\n webkitExitFullScreen(): void;\n webkitExitFullscreen(): void;\n\n msHorizontalMirror: boolean;\n readonly msIsLayoutOptimalForPlayback: boolean;\n readonly msIsStereo3D: boolean;\n msStereo3DPackingMode: string;\n msStereo3DRenderMode: string;\n msZoom: boolean;\n onMSVideoFormatChanged: ((this: HTMLVideoElement, ev: Event) => any) | null;\n onMSVideoFrameStepCompleted: ((this: HTMLVideoElement, ev: Event) => any) | null;\n onMSVideoOptimalLayoutChanged: ((this: HTMLVideoElement, ev: Event) => any) | null;\n webkitDisplayingFullscreen: boolean;\n webkitSupportsFullscreen: boolean;\n}\n\ninterface MediaError {\n readonly msExtendedCode: number;\n readonly MS_MEDIA_ERR_ENCRYPTED: number;\n}