Today we’re excited to announce the release of TypeScript 3.9!<\/p>\n
If you’re unfamiliar with TypeScript, it’s a language that builds on JavaScript by adding syntax for type declarations and annotations. This syntax can be used by the TypeScript compiler to type-check our code, and then output clean readable JavaScript that runs on lots of different runtimes. Static type-checking can tell us about errors in our code before we even run it, or before we even save our files thanks to TypeScript’s rich editing functionality across editors. But beyond error-checking, TypeScript powers things like completions, quick fixes, and refactorings for both TypeScript and<\/em> JavaScript in some of your favorite editors. In fact, if you already use Visual Studio or Visual Studio Code, you might already be using TypeScript when you write JavaScript code! So if you’re interested in learning more, check out our website<\/a>!<\/p>\n But if you’re already using TypeScript in your project, you can either get it through NuGet<\/a> or use npm with the following command:<\/p>\n You can also get editor support by<\/p>\n For this release our team been has been focusing on performance, polish, and stability. We’ve been working on speeding up the compiler and editing experience, getting rid of friction and papercuts, and reducing bugs and crashes. We’ve also received a number of useful and much-appreciated features and fixes from the external community!<\/p>\n Recent versions of TypeScript (around 3.7) have had updates to the declarations of functions like This is strange behavior! The fact that Thanks to a pull request<\/a> from Jack Bates<\/a>, this has been fixed with improvements in our inference process in TypeScript 3.9. The above no longer errors. If you’ve been stuck on older versions of TypeScript due to issues around 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 We initially anticipated shipping TypeScript 3.9 ships with many new speed improvements. Our team has been focusing on performance after observing extremely poor editing\/compilation speed with packages like material-ui and styled-components. We’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.<\/p>\n Each of these pull requests gains about a 5-10% reduction in compile times on certain codebases. In total, we believe we’ve achieved around a 25% reduction the We also have some changes to file renaming functionality in editor scenarios. We 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. TypeScript 3.9 addresses this issue by changing the internals of how the compiler and language service caches file lookups<\/a>.<\/p>\n While there’s still room for improvement, we hope this work translates to a snappier experience for everyone!<\/p>\n Imagine that we’re writing a library in TypeScript and we’re exporting some function called 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. We’d like to test this behavior, so we’ll write a unit test.<\/p>\n Unfortunately if our tests are written in TypeScript, TypeScript will give us an error!<\/p>\n That’s why TypeScript 3.9 brings a new feature: As a quick example, the following code is okay<\/p>\n while the following code<\/p>\n results in the error<\/p>\n We’d like to extend a big thanks to Josh Goldberg<\/a>, the contributor who implemented this feature. For more information, you can take a look at the In some ways npm install typescript<\/pre>\n<\/div>\n
\n
\n
Promise.all<\/code><\/a><\/li>\n\/\/ @ts-expect-error<\/code> Comments<\/a><\/li>\n\n
tsconfig.json<\/code> Files<\/a><\/li>\n<\/ul>\n<\/li>\nImprovements in Inference and
Promise.all<\/code><\/h2>\nPromise.all<\/code> and Promise.race<\/code>. Unfortunately, that introduced a few regressions, especially when mixing in values with null<\/code> or undefined<\/code>.<\/p>\ninterface<\/span> Lion<\/span> {<\/span>\r\n roar<\/span>(<\/span>)<\/span>: void<\/span><\/span>\r\n}<\/span>\r\n\r\ninterface<\/span> Seal<\/span> {<\/span>\r\n singKissFromARose<\/span>(<\/span>)<\/span>: void<\/span><\/span>\r\n}<\/span>\r\n\r\nasync<\/span> function<\/span> visitZoo<\/span>(<\/span>lionExhibit<\/span>: Promise<\/span><<\/span>Lion<\/span>><\/span>,<\/span> sealExhibit<\/span>: Promise<\/span><<\/span>Seal<\/span> | undefined<\/span>><\/span>)<\/span> {<\/span>\r\n let<\/span> [<\/span>lion<\/span>,<\/span> seal<\/span>]<\/span> =<\/span> await<\/span> Promise<\/span>.<\/span>all<\/span>(<\/span>[<\/span>lionExhibit<\/span>,<\/span> sealExhibit<\/span>]<\/span>)<\/span>;<\/span>\r\n lion<\/span>.<\/span>roar<\/span>(<\/span>)<\/span>;<\/span> \/\/ uh oh<\/span>\r\n\/\/ ~~~~<\/span>\r\n\/\/ Object is possibly 'undefined'.<\/span>\r\n}<\/span><\/pre>\n<\/div>\nsealExhibit<\/code> contained an undefined<\/code> somehow poisoned type of lion<\/code> to include undefined<\/code>.<\/p>\nPromise<\/code>s, we encourage you to give 3.9 a shot!<\/p>\nWhat About the
awaited<\/code> Type?<\/h3>\nawaited<\/code><\/a>. This goal of this type operator is to accurately model the way that Promise<\/code> unwrapping works in JavaScript.<\/p>\nawaited<\/code> 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. As a result, we’ve decided to pull the feature out of our main branch until we feel more confident. We’ll be experimenting more with the feature, but we won’t be shipping it as part of this release.<\/p>\nSpeed Improvements<\/h2>\n
\n
material-ui-styles<\/code><\/a> project’s compile time. Furthermore, we’ve gotten feedback from teams at Microsoft that TypeScript 3.9 has reduced their compile time from 26 seconds to around 10 seconds<\/a>.<\/p>\n\/\/ @ts-expect-error<\/code> Comments<\/h2>\ndoStuff<\/code> as part of our public API. The function’s types declare that it takes two string<\/code>s 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.<\/p>\nfunction<\/span> doStuff<\/span>(<\/span>abc<\/span>: string<\/span>,<\/span> xyz<\/span>: string<\/span>)<\/span> {<\/span>\r\n assert<\/span>(<\/span>typeof<\/span> abc<\/span> ===<\/span> \"string\"<\/span>)<\/span>;<\/span>\r\n assert<\/span>(<\/span>typeof<\/span> xyz<\/span> ===<\/span> \"string\"<\/span>)<\/span>;<\/span>\r\n\r\n \/\/ do some stuff<\/span>\r\n}<\/span><\/pre>\n<\/div>\nexpect<\/span>(<\/span>(<\/span>)<\/span> =><\/span> {<\/span>\r\n doStuff<\/span>(<\/span>123<\/span>,<\/span> 456<\/span>)<\/span>;<\/span>\r\n}<\/span>)<\/span>.<\/span>toThrow<\/span>(<\/span>)<\/span>;<\/span><\/pre>\n<\/div>\n doStuff<\/span>(<\/span>123<\/span>,<\/span> 456<\/span>)<\/span>;<\/span>\r\n\/\/ ~~~<\/span>\r\n\/\/ error: Type 'number' is not assignable to type 'string'.<\/span><\/pre>\n<\/div>\n\/\/ @ts-expect-error<\/code> comments. When a line is prefixed with a \/\/ @ts-expect-error<\/code> comment, TypeScript will suppress that error from being reported; but if there’s no error, TypeScript will report that \/\/ @ts-expect-error<\/code> wasn’t necessary.<\/p>\n\/\/ @ts<\/span>-expect-error<\/span>\r\nconsole<\/span>.<\/span>log<\/span>(<\/span>47<\/span> * \"octopus\"<\/span>)<\/span>;<\/span><\/pre>\n<\/div>\n\/\/ @ts<\/span>-expect-error<\/span>\r\nconsole<\/span>.<\/span>log<\/span>(<\/span>1<\/span> +<\/span> 1<\/span>)<\/span>;<\/span><\/pre>\n<\/div>\nUnused '@ts-expect-error' directive.\r\n<\/code><\/pre>\nts-expect-error<\/code> pull request<\/a>.<\/p>\nts-ignore<\/code> or ts-expect-error<\/code>?<\/h3>\n\/\/ @ts-expect-error<\/code> can act as a suppression comment, similar to