{"id":116976,"date":"2020-08-20T16:52:00","date_gmt":"2020-08-20T16:52:00","guid":{"rendered":"https:\/\/news.microsoft.com\/?p=438785"},"modified":"2020-08-20T16:52:00","modified_gmt":"2020-08-20T16:52:00","slug":"developers-learn-whats-new-in-typescript-4-0","status":"publish","type":"post","link":"https:\/\/sickgaming.net\/blog\/2020\/08\/20\/developers-learn-whats-new-in-typescript-4-0\/","title":{"rendered":"Developers: Learn what\u2019s new in TypeScript 4.0"},"content":{"rendered":"
\n
\n
\"Avatar\"<\/p>\n

Daniel<\/p>\n<\/div>\n<\/div>\n<\/div>\n

\n

August 20th, 2020<\/p>\n<\/div>\n

Today we are thrilled to announce the availability of TypeScript 4.0! This version of the language represents our next generation of TypeScript releases, as we dive deeper into expressivity, productivity, and scalability.<\/p>\n

If you\u2019re not familiar with TypeScript, it\u2019s a language that builds on top of JavaScript by adding syntax for static types<\/em>. The idea is that by writing down the types of your values and where they\u2019re used, you can use TypeScript to type-check your code and tell you about mistakes before you run your code (and even before saving your file). You can then use the TypeScript compiler to then strip away types from your code, and leaving you with clean, readable JavaScript that runs anywhere. Beyond checking, TypeScript also uses static types to power great editor tooling like auto-completion, code navigation, refactorings, and more. In fact, if you\u2019ve used JavaScript in an editor like Visual Studio Code or Visual Studio, you\u2019ve already been using an experience powered by types and TypeScript. You can learn more about all of this on our website<\/a>.<\/p>\n

With TypeScript 4.0, there are no major breaking changes. In fact, if you\u2019re new to the language, now is the best time to start using it. The community is already here and growing, with working code and great new resources to learn. And one thing to keep in mind: despite all the good stuff we\u2019re bringing in 4.0, you really only need to know the basics of TypeScript to be productive!<\/p>\n

If you\u2019re already using TypeScript in your project, you can either get it through NuGet<\/a> or use npm with the following command:<\/p>\n

\n
npm install -D typescript<\/pre>\n<\/div>\n
You can also get editor support by<\/p>\n
TypeScript is a core part of many people\u2019s JavaScript stack today. On npm, TypeScript saw over 50 million monthly downloads for the first time in July! And while we recognize there\u2019s always room for growth and improvement, it\u2019s clear that most people coding in TypeScript really do enjoy it. StackOverflow\u2019s most recent developer survey pins TypeScript as the 2nd most-loved language<\/a>. In the most recent State of JS Survey, around 89% of developers who used TypeScript said that they would use it again<\/a>.<\/p>\n
It\u2019s worth digging a bit into how we got here. In our past two major versions, we looked back at some highlights that shined over the years. For TypeScript 4.0, we\u2019re going to keep up that tradition.<\/p>\n
Looking back from 3.0 onward, there\u2019s a dizzying number of changes, but TypeScript 3.0<\/a> itself came out with a punch. Unifying tuple types and parameter lists was a big highlight, enabling tons of existing JavaScript patterns on functions. The release also featured project references to help scale up, organize, and share across codebases. One small change that had a big impact was that 3.0 introduced a type-safe alternative to any<\/code> called unknown<\/code>.<\/p>\n
TypeScript 3.1<\/a> extended the capabilities of mapped types<\/a> to work on tuple and array types, and made it dramatically easier to attach properties to functions without resorting to TypeScript-specific runtime features that have fallen out of use.<\/p>\n
TypeScript 3.2<\/a> allowed object spreads on generic types, and leveraged 3.0\u2019s capabilities to better model meta-programming with functions by strictly typing bind<\/code>, call<\/code>, and apply<\/code>. TypeScript 3.3<\/a> focused a bit on stability following 3.2, but also brought quality-of-life improvements when using union type methods, and added file-incremental builds under --build<\/code> mode.<\/p>\n
In the 3.4 release<\/a>, we leaned farther into supporting functional patterns, with better support for immutable data structures, and improved inference on higher-order generic functions. As a big plus, this release introduced the --incremental<\/code> flag, a way to get faster compiles and type-checks by avoiding a full rebuild on every run of TypeScript, without project references.<\/p>\n
With TypeScript 3.5<\/a> and 3.6<\/a>, we saw some tightening up of the type system rules, along with smarter compatibility checking rules.<\/p>\n
TypeScript 3.7<\/a> was a very noteworthy release because it featured a rich combination of new type system features with ECMAScript features. From the type-system side, we saw recursive type alias references and support for assertion-style functions, both which are unique type-system features. From the JavaScript side, the release brought optional chaining and coalescing, two of the most highly demanded features for TypeScript and JavaScript users alike, championed in TC39 in part by our team.<\/p>\n
Much more recently, 3.8<\/a> and 3.9<\/a> have brought type-only imports\/exports, along with ECMAScript features like private fields, top-level await<\/code> in modules, and new export *<\/code> syntaxes. These releases also delivered performance and scalability optimizations.<\/p>\n
We haven\u2019t even touched on all the work in our language service, our infrastructure, our website, and other core projects which are incredibly valuable to the TypeScript experience. Beyond the core team\u2019s projects is the incredible community of contributors in the ecosystem, pushing the experience forward, and helping out with DefinitelyTyped and even TypeScript itself. DefinitelyTyped had just 80 pull requests in 2012 when it first started, picking up on the tail end of the year. In 2019, it had over 8300 pull requests<\/em>, which still astounds us. These contributions are fundamental to the TypeScript experience, so we\u2019re grateful for such a bustling and eager community that\u2019s been improving the ecosystem and pushed us to constantly improve.<\/p>\n
What\u2019s New?<\/h2>\n
All this brings us to 4.0! So, without further ado, let\u2019s dive into what\u2019s new!<\/p>\n
Variadic Tuple Types<\/h2>\n
Consider a function in JavaScript called concat<\/code> that takes two array or tuple types and concatenates them together to make a new array.<\/p>\n
\n
function<\/span> concat<\/span>(<\/span>arr1<\/span>,<\/span> arr2<\/span>)<\/span> {<\/span> return<\/span> [<\/span>...arr1<\/span>,<\/span> ...arr2<\/span>]<\/span>;<\/span>\n}<\/span><\/pre>\n<\/div>\n
Also consider tail<\/code>, that takes an array or tuple, and returns all elements but the first.<\/p>\n
\n
function<\/span> tail<\/span>(<\/span>arg<\/span>)<\/span> {<\/span> const<\/span> [<\/span>_<\/span>,<\/span> ...result<\/span>]<\/span> =<\/span> arg<\/span>;<\/span> return<\/span> result<\/span>\n}<\/span><\/pre>\n<\/div>\n
How would we type either of these in TypeScript?<\/p>\n
For concat<\/code>, the only valid thing we could do in older versions of the language was to try and write some overloads.<\/p>\n
\n
function<\/span> concat<\/span>(<\/span>arr1<\/span>: [<\/span>]<\/span>,<\/span> arr2<\/span>: [<\/span>]<\/span>)<\/span>: [<\/span>]<\/span>;<\/span>\nfunction<\/span> concat<\/span><<\/span>A<\/span>><\/span>(<\/span>arr1<\/span>: [<\/span>A<\/span>]<\/span>,<\/span> arr2<\/span>: [<\/span>]<\/span>)<\/span>: [<\/span>A<\/span>]<\/span>;<\/span>\nfunction<\/span> concat<\/span><<\/span>A<\/span>,<\/span> B<\/span>><\/span>(<\/span>arr1<\/span>: [<\/span>A<\/span>,<\/span> B<\/span>]<\/span>,<\/span> arr2<\/span>: [<\/span>]<\/span>)<\/span>: [<\/span>A<\/span>,<\/span> B<\/span>]<\/span>;<\/span>\nfunction<\/span> concat<\/span><<\/span>A<\/span>,<\/span> B<\/span>,<\/span> C<\/span>><\/span>(<\/span>arr1<\/span>: [<\/span>A<\/span>,<\/span> B<\/span>,<\/span> C<\/span>]<\/span>,<\/span> arr2<\/span>: [<\/span>]<\/span>)<\/span>: [<\/span>A<\/span>,<\/span> B<\/span>,<\/span> C<\/span>]<\/span>;<\/span>\nfunction<\/span> concat<\/span><<\/span>A<\/span>,<\/span> B<\/span>,<\/span> C<\/span>,<\/span> D<\/span>><\/span>(<\/span>arr1<\/span>: [<\/span>A<\/span>,<\/span> B<\/span>,<\/span> C<\/span>,<\/span> D<\/span>]<\/span>,<\/span> arr2<\/span>: [<\/span>]<\/span>)<\/span>: [<\/span>A<\/span>,<\/span> B<\/span>,<\/span> C<\/span>,<\/span> D<\/span>]<\/span>;<\/span>\nfunction<\/span> concat<\/span><<\/span>A<\/span>,<\/span> B<\/span>,<\/span> C<\/span>,<\/span> D<\/span>,<\/span> E<\/span>><\/span>(<\/span>arr1<\/span>: [<\/span>A<\/span>,<\/span> B<\/span>,<\/span> C<\/span>,<\/span> D<\/span>,<\/span> E<\/span>]<\/span>,<\/span> arr2<\/span>: [<\/span>]<\/span>)<\/span>: [<\/span>A<\/span>,<\/span> B<\/span>,<\/span> C<\/span>,<\/span> D<\/span>,<\/span> E<\/span>]<\/span>;<\/span>\nfunction<\/span> concat<\/span><<\/span>A<\/span>,<\/span> B<\/span>,<\/span> C<\/span>,<\/span> D<\/span>,<\/span> E<\/span>,<\/span> F<\/span>><\/span>(<\/span>arr1<\/span>: [<\/span>A<\/span>,<\/span> B<\/span>,<\/span> C<\/span>,<\/span> D<\/span>,<\/span> E<\/span>,<\/span> F<\/span>]<\/span>,<\/span> arr2<\/span>: [<\/span>]<\/span>)<\/span>: [<\/span>A<\/span>,<\/span> B<\/span>,<\/span> C<\/span>,<\/span> D<\/span>,<\/span> E<\/span>,<\/span> F<\/span>]<\/span>;<\/span>)<\/span><\/pre>\n<\/div>\n
Uh\u2026okay, that\u2019s\u2026seven overloads for when the second array is always empty. Let\u2019s add some for when arr2<\/code> has one argument.<\/p>\n
\n
function<\/span> concat<\/span><<\/span>A2<\/span>><\/span>(<\/span>arr1<\/span>: [<\/span>]<\/span>,<\/span> arr2<\/span>: [<\/span>A2<\/span>]<\/span>)<\/span>: [<\/span>A2<\/span>]<\/span>;<\/span>\nfunction<\/span> concat<\/span><<\/span>A1<\/span>,<\/span> A2<\/span>><\/span>(<\/span>arr1<\/span>: [<\/span>A1<\/span>]<\/span>,<\/span> arr2<\/span>: [<\/span>A2<\/span>]<\/span>)<\/span>: [<\/span>A1<\/span>,<\/span> A2<\/span>]<\/span>;<\/span>\nfunction<\/span> concat<\/span><<\/span>A1<\/span>,<\/span> B1<\/span>,<\/span> A2<\/span>><\/span>(<\/span>arr1<\/span>: [<\/span>A1<\/span>,<\/span> B1<\/span>]<\/span>,<\/span> arr2<\/span>: [<\/span>A2<\/span>]<\/span>)<\/span>: [<\/span>A1<\/span>,<\/span> B1<\/span>,<\/span> A2<\/span>]<\/span>;<\/span>\nfunction<\/span> concat<\/span><<\/span>A1<\/span>,<\/span> B1<\/span>,<\/span> C1<\/span>,<\/span> A2<\/span>><\/span>(<\/span>arr1<\/span>: [<\/span>A1<\/span>,<\/span> B1<\/span>,<\/span> C1<\/span>]<\/span>,<\/span> arr2<\/span>: [<\/span>A2<\/span>]<\/span>)<\/span>: [<\/span>A1<\/span>,<\/span> B1<\/span>,<\/span> C1<\/span>,<\/span> A2<\/span>]<\/span>;<\/span>\nfunction<\/span> concat<\/span><<\/span>A1<\/span>,<\/span> B1<\/span>,<\/span> C1<\/span>,<\/span> D1<\/span>,<\/span> A2<\/span>><\/span>(<\/span>arr1<\/span>: [<\/span>A1<\/span>,<\/span> B1<\/span>,<\/span> C1<\/span>,<\/span> D1<\/span>]<\/span>,<\/span> arr2<\/span>: [<\/span>A2<\/span>]<\/span>)<\/span>: [<\/span>A1<\/span>,<\/span> B1<\/span>,<\/span> C1<\/span>,<\/span> D1<\/span>,<\/span> A2<\/span>]<\/span>;<\/span>\nfunction<\/span> concat<\/span><<\/span>A1<\/span>,<\/span> B1<\/span>,<\/span> C1<\/span>,<\/span> D1<\/span>,<\/span> E1<\/span>,<\/span> A2<\/span>><\/span>(<\/span>arr1<\/span>: [<\/span>A1<\/span>,<\/span> B1<\/span>,<\/span> C1<\/span>,<\/span> D1<\/span>,<\/span> E1<\/span>]<\/span>,<\/span> arr2<\/span>: [<\/span>A2<\/span>]<\/span>)<\/span>: [<\/span>A1<\/span>,<\/span> B1<\/span>,<\/span> C1<\/span>,<\/span> D1<\/span>,<\/span> E1<\/span>,<\/span> A2<\/span>]<\/span>;<\/span>\nfunction<\/span> concat<\/span><<\/span>A1<\/span>,<\/span> B1<\/span>,<\/span> C1<\/span>,<\/span> D1<\/span>,<\/span> E1<\/span>,<\/span> F1<\/span>,<\/span> A2<\/span>><\/span>(<\/span>arr1<\/span>: [<\/span>A1<\/span>,<\/span> B1<\/span>,<\/span> C1<\/span>,<\/span> D1<\/span>,<\/span> E1<\/span>,<\/span> F1<\/span>]<\/span>,<\/span> arr2<\/span>: [<\/span>A2<\/span>]<\/span>)<\/span>: [<\/span>A1<\/span>,<\/span> B1<\/span>,<\/span> C1<\/span>,<\/span> D1<\/span>,<\/span> E1<\/span>,<\/span> F1<\/span>,<\/span> A2<\/span>]<\/span>;<\/span><\/pre>\n<\/div>\n
We hope it\u2019s clear that this is getting unreasonable. Unfortunately, you\u2019d also end up with the same sorts of issues typing a function like tail<\/code>.<\/p>\n
This is another case of what we like to call \u201cdeath by a thousand overloads\u201d, and it doesn\u2019t even solve the problem generally. It only gives correct types for as many overloads as we care to write. If we wanted to make a catch-all case, we\u2019d need an overload like the following:<\/p>\n
\n
function<\/span> concat<\/span><<\/span>T<\/span>,<\/span> U<\/span>><\/span>(<\/span>arr1<\/span>: T<\/span>[<\/span>]<\/span>,<\/span> arr2<\/span>: U<\/span>[<\/span>]<\/span>)<\/span>: Array<\/span><<\/span>T<\/span> | U<\/span>><\/span>;<\/span><\/pre>\n<\/div>\n
But that signature doesn\u2019t encode anything about the lengths of the input, or the order of the elements, when using tuples.<\/p>\n
TypeScript 4.0 brings two fundamental changes, along with inference improvements, to make typing these possible.<\/p>\n
The first change is that spreads in tuple type syntax can now be generic. This means that we can represent higher-order operations on tuples and arrays even when we don\u2019t know the actual types we\u2019re operating over. When generic spreads are instantiated (or, replaced with a real type) in these tuple types, they can produce other sets of array and tuple types.<\/p>\n
For example, that means we can type function like tail<\/code>, without our \u201cdeath by a thousand overloads\u201d issue.<\/p>\n
\n
function<\/span> tail<\/span><<\/span>T<\/span> extends<\/span> any<\/span>[<\/span>]<\/span>><\/span>(<\/span>arr<\/span>: readonly<\/span> [<\/span>any<\/span>,<\/span> ...T<\/span>]<\/span>)<\/span> {<\/span> const<\/span> [<\/span>_ignored<\/span>,<\/span> ...rest<\/span>]<\/span> =<\/span> arr<\/span>;<\/span> return<\/span> rest<\/span>;<\/span>\n}<\/span> const<\/span> myTuple<\/span> =<\/span> [<\/span>1<\/span>,<\/span> 2<\/span>,<\/span> 3<\/span>,<\/span> 4<\/span>]<\/span> as<\/span> const<\/span>;<\/span>\nconst<\/span> myArray<\/span> =<\/span> [<\/span>\"hello\"<\/span>,<\/span> \"world\"<\/span>]<\/span>;<\/span> \/\/ type [2, 3, 4]<\/span>\nconst<\/span> r1<\/span> =<\/span> tail<\/span>(<\/span>myTuple<\/span>)<\/span>;<\/span> \/\/ type [2, 3, 4, ...string[]]<\/span>\nconst<\/span> r2<\/span> =<\/span> tail<\/span>(<\/span>[<\/span>...myTuple<\/span>,<\/span> ...myArray<\/span>]<\/span> as<\/span> const<\/span>)<\/span>;<\/span><\/pre>\n<\/div>\n
The second change is that rest elements can occur anywhere in a tuple \u2013 not just at the end!<\/p>\n
\n
type<\/span> Strings<\/span> =<\/span> [<\/span>string<\/span>,<\/span> string<\/span>]<\/span>;<\/span>\ntype<\/span> Numbers<\/span> =<\/span> [<\/span>number<\/span>,<\/span> number<\/span>]<\/span>;<\/span> \/\/ [string, string, number, number, boolean]<\/span>\ntype<\/span> StrStrNumNumBool<\/span> =<\/span> [<\/span>...Strings<\/span>,<\/span> ...Numbers<\/span>,<\/span> boolean<\/span>]<\/span>;<\/span><\/pre>\n<\/div>\n
Previously, TypeScript would issue an error like the following:<\/p>\n
A rest element must be last in a tuple type.\n<\/code><\/pre>\n
But with TypeScript 4.0, this restriction is relaxed.<\/p>\n
Note that in cases when we spread in a type without a known length, the resulting type becomes unbounded as well, and all the following elements factor into the resulting rest element type.<\/p>\n
\n
type<\/span> Strings<\/span> =<\/span> [<\/span>string<\/span>,<\/span> string<\/span>]<\/span>;<\/span>\ntype<\/span> Numbers<\/span> =<\/span> number<\/span>[<\/span>]<\/span> \/\/ [string, string, ...Array<number | boolean>]<\/span>\ntype<\/span> Unbounded<\/span> =<\/span> [<\/span>...Strings<\/span>,<\/span> ...Numbers<\/span>,<\/span> boolean<\/span>]<\/span>;<\/span><\/pre>\n<\/div>\n
By combining both of these behaviors together, we can write a single well-typed signature for concat<\/code>:<\/p>\n
\n
type<\/span> Arr<\/span> =<\/span> readonly<\/span> any[<\/span>]<\/span>;<\/span> function<\/span> concat<\/span><<\/span>T<\/span> extends<\/span> Arr<\/span>,<\/span> U<\/span> extends<\/span> Arr<\/span>><\/span>(<\/span>arr1<\/span>: T<\/span>,<\/span> arr2<\/span>: U<\/span>)<\/span>: [<\/span>...T<\/span>,<\/span> ...U<\/span>]<\/span> {<\/span> return<\/span> [<\/span>...arr1<\/span>,<\/span> ...arr2<\/span>]<\/span>;<\/span>\n}<\/span><\/pre>\n<\/div>\n
While that one signature is still a bit lengthy, it\u2019s just one signature that doesn\u2019t have to be repeated, and it gives predictable behavior on all arrays and tuples.<\/p>\n
This functionality on its own is great, but it shines in more sophisticated scenarios too. For example, consider a function to partially apply arguments<\/a> called partialCall<\/code>. partialCall<\/code> takes a function \u2013 let\u2019s call it f<\/code> \u2013 along with the initial few arguments that f<\/code> expects. It then returns a new function that takes any other arguments that f<\/code> still needs, and calls f<\/code> when it receives them.<\/p>\n
\n
function<\/span> partialCall<\/span>(<\/span>f<\/span>,<\/span> ...headArgs<\/span>)<\/span> {<\/span> return<\/span> (<\/span>...tailArgs<\/span>)<\/span> =><\/span> f<\/span>(<\/span>...headArgs<\/span>,<\/span> ...tailArgs<\/span>)<\/span>\n}<\/span><\/pre>\n<\/div>\n
TypeScript 4.0 improves the inference process for rest parameters and rest tuple elements so that we can type this and have it \u201cjust work\u201d.<\/p>\n
\n
type<\/span> Arr<\/span> =<\/span> readonly<\/span> unknown<\/span>[<\/span>]<\/span>;<\/span> function<\/span> partialCall<\/span><<\/span>T<\/span> extends<\/span> Arr<\/span>,<\/span> U<\/span> extends<\/span> Arr<\/span>,<\/span> R<\/span>><\/span>(<\/span> f<\/span>: (<\/span>...args<\/span>: [<\/span>...T<\/span>,<\/span> ...U<\/span>]<\/span>)<\/span> =><\/span> R<\/span>,<\/span> ...headArgs<\/span>: T<\/span>\n)<\/span> {<\/span> return<\/span> (<\/span>...tailArgs<\/span>: U<\/span>)<\/span> =><\/span> f<\/span>(<\/span>...headArgs<\/span>,<\/span> ...tailArgs<\/span>)<\/span>\n}<\/span><\/pre>\n<\/div>\n
In this case, partialCall<\/code> understands which parameters it can and can\u2019t initially take, and returns functions that appropriately accept and reject anything left over.<\/p>\n
\n
const<\/span> foo<\/span> =<\/span> (<\/span>x<\/span>: string<\/span>,<\/span> y<\/span>: number<\/span>,<\/span> z<\/span>: boolean<\/span>)<\/span> =><\/span> {<\/span>}<\/span> \/\/ This doesn't work because we're feeding in the wrong type for 'x'.<\/span>\nconst<\/span> f1<\/span> =<\/span> partialCall<\/span>(<\/span>foo<\/span>,<\/span> 100<\/span>)<\/span>;<\/span>\n\/\/ ~~~<\/span>\n\/\/ error! Argument of type 'number' is not assignable to parameter of type 'string'.<\/span> \/\/ This doesn't work because we're passing in too many arguments.<\/span>\nconst<\/span> f2<\/span> =<\/span> partialCall<\/span>(<\/span>foo<\/span>,<\/span> \"hello\"<\/span>,<\/span> 100<\/span>,<\/span> true<\/span>,<\/span> \"oops\"<\/span>)<\/span>\n\/\/ ~~~~~~<\/span>\n\/\/ error! Expected 4 arguments, but got 5.<\/span> \/\/ This works! It has the type '(y: number, z: boolean) => void'<\/span>\nconst<\/span> f3<\/span> =<\/span> partialCall<\/span>(<\/span>foo<\/span>,<\/span> \"hello\"<\/span>)<\/span>;<\/span> \/\/ What can we do with f3 now?<\/span> f3<\/span>(<\/span>123<\/span>,<\/span> true<\/span>)<\/span>;<\/span> \/\/ works!<\/span> f3<\/span>(<\/span>)<\/span>;<\/span>\n\/\/ error! Expected 2 arguments, but got 0.<\/span> f3<\/span>(<\/span>123<\/span>,<\/span> \"hello\"<\/span>)<\/span>;<\/span>\n\/\/ ~~~~~~~<\/span>\n\/\/ error! Argument of type 'string' is not assignable to parameter of type 'boolean'.<\/span><\/pre>\n<\/div>\n
Variadic tuple types enable a lot of new exciting patterns, especially around function composition. We expect we may be able to leverage it to do a better job type-checking JavaScript\u2019s built-in bind<\/code> method. A handful of other inference improvements and patterns also went into this, and if you\u2019re interested in learning more, you can take a look at the pull request<\/a> for variadic tuples.<\/p>\n
Labeled Tuple Elements<\/h2>\n
Improving the experience around tuple types and parameter lists is important because it allows us to get strongly typed validation around common JavaScript idioms \u2013 really just slicing and dicing argument lists and passing them to other functions. The idea that we can use tuple types for rest parameters is one place where this is crucial.<\/p>\n
For example, the following function that uses a tuple type as a rest parameter\u2026<\/p>\n
\n
function<\/span> foo<\/span>(<\/span>...args<\/span>: [<\/span>string<\/span>,<\/span> number<\/span>]<\/span>)<\/span>: void<\/span><\/span> {<\/span> \/\/ ...<\/span>\n}<\/span><\/pre>\n<\/div>\n
\u2026should appear no different from the following function\u2026<\/p>\n
\n
function<\/span> foo<\/span>(<\/span>arg0<\/span>: string<\/span>,<\/span> arg1<\/span>: number<\/span>)<\/span>: void<\/span><\/span> {<\/span> \/\/ ...<\/span>\n}<\/span><\/pre>\n<\/div>\n
\u2026for any caller of foo<\/code>.<\/p>\n
\n
foo<\/span>(<\/span>\"hello\"<\/span>,<\/span> 42<\/span>)<\/span>;<\/span> \/\/ works<\/span> foo<\/span>(<\/span>\"hello\"<\/span>,<\/span> 42<\/span>,<\/span> true<\/span>)<\/span>;<\/span> \/\/ error<\/span>\nfoo<\/span>(<\/span>\"hello\"<\/span>)<\/span>;<\/span> \/\/ error<\/span><\/pre>\n<\/div>\n
There is one place where the differences begin to become observable though: readability. In the first example, we have no parameter names for the first and second elements. While these have no impact on type-checking, the lack of labels on tuple positions can make them harder to use \u2013 harder to communicate our intent.<\/p>\n
That\u2019s why in TypeScript 4.0, tuples types can now provide labels.<\/p>\n
\n
type<\/span> Range<\/span> =<\/span> [<\/span>start<\/span>: number,<\/span> end<\/span>: number]<\/span>;<\/span><\/pre>\n<\/div>\n
To deepen the connection between parameter lists and tuple types, the syntax for rest elements and optional elements mirrors the syntax for parameter lists.<\/p>\n
\n
type<\/span> Foo<\/span> =<\/span> [<\/span>first<\/span>: number,<\/span> second<\/span>?: string,<\/span> ...rest<\/span>: any[<\/span>]<\/span>]<\/span>;<\/span><\/pre>\n<\/div>\n
There are a few rules when using labeled tuples. For one, when labeling a tuple element, all other elements in the tuple must also be labeled.<\/p>\n
\n
type<\/span> Bar<\/span> =<\/span> [<\/span>first<\/span>: string,<\/span> number<\/span>]<\/span>;<\/span>\n\/\/ ~~~~~~<\/span>\n\/\/ error! Tuple members must all have names or all not have names.<\/span><\/pre>\n<\/div>\n
It\u2019s worth noting \u2013 labels don\u2019t require us to name our variables differently when destructuring. They\u2019re purely there for documentation and tooling.<\/p>\n
\n
function<\/span> foo<\/span>(<\/span>x<\/span>: [<\/span>first<\/span>: string<\/span>,<\/span> second<\/span>: number<\/span>]<\/span>)<\/span> {<\/span> \/\/ ...<\/span> \/\/ note: we didn't need to name these 'first' and 'second'<\/span> let<\/span> [<\/span>a<\/span>,<\/span> b<\/span>]<\/span> =<\/span> x<\/span>;<\/span> \/\/ ...<\/span>\n}<\/span><\/pre>\n<\/div>\n
Overall, labeled tuples are handy when taking advantage of patterns around tuples and argument lists, along with implementing overloads in a type-safe way. In fact, TypeScript\u2019s editor support will try to display them as overloads when possible.<\/p>\n
\"Signature<\/p>\n
To learn more, check out the pull request<\/a> for labeled tuple elements.<\/p>\n
Class Property Inference from Constructors<\/h2>\n
TypeScript 4.0 can now use control flow analysis to determine the types of properties in classes when noImplicitAny<\/code> is enabled.<\/p>\n
\n
class<\/span> Square<\/span> {<\/span> \/\/ Previously: implicit any!<\/span> \/\/ Now: inferred to `number`!<\/span> area<\/span>;<\/span> sideLength<\/span>;<\/span> constructor<\/span>(<\/span>sideLength<\/span>: number<\/span>)<\/span> {<\/span> this<\/span>.<\/span>sideLength<\/span> =<\/span> sideLength<\/span>;<\/span> this<\/span>.<\/span>area<\/span> =<\/span> sideLength<\/span> ** 2<\/span>;<\/span> }<\/span>\n}<\/span><\/pre>\n<\/div>\n
In cases where not all paths of a constructor assign to an instance member, the property is considered to potentially be undefined<\/code>.<\/p>\n
\n
class<\/span> Square<\/span> {<\/span> sideLength<\/span>;<\/span> constructor<\/span>(<\/span>sideLength<\/span>: number<\/span>)<\/span> {<\/span> if<\/span> (<\/span>Math<\/span>.<\/span>random<\/span>(<\/span>)<\/span>)<\/span> {<\/span> this<\/span>.<\/span>sideLength<\/span> =<\/span> sideLength<\/span>;<\/span> }<\/span> }<\/span> get<\/span> area<\/span>(<\/span>)<\/span> {<\/span> return<\/span> this<\/span>.<\/span>sideLength<\/span> ** 2<\/span>;<\/span> \/\/ ~~~~~~~~~~~~~~~<\/span> \/\/ error! Object is possibly 'undefined'.<\/span> }<\/span>\n}<\/span><\/pre>\n<\/div>\n
In cases where you know better (e.g. you have an initialize<\/code> method of some sort), you\u2019ll still need an explicit type annotation along with a definite assignment assertion (!<\/code>) if you\u2019re in strictPropertyInitialization<\/code>.<\/p>\n
\n
class<\/span> Square<\/span> {<\/span> \/\/ definite assignment assertion<\/span> \/\/ v<\/span> sideLength<\/span>!: number<\/span>;<\/span> \/\/ ^^^^^^^^<\/span> \/\/ type annotation<\/span> constructor<\/span>(<\/span>sideLength<\/span>: number<\/span>)<\/span> {<\/span> this<\/span>.<\/span>initialize<\/span>(<\/span>sideLength<\/span>)<\/span> }<\/span> initialize<\/span>(<\/span>sideLength<\/span>: number<\/span>)<\/span> {<\/span> this<\/span>.<\/span>sideLength<\/span> =<\/span> sideLength<\/span>;<\/span> }<\/span> get<\/span> area<\/span>(<\/span>)<\/span> {<\/span> return<\/span> this<\/span>.<\/span>sideLength<\/span> ** 2<\/span>;<\/span> }<\/span>\n}<\/span><\/pre>\n<\/div>\n
For more details, see the implementing pull request<\/a>.<\/p>\n
Short-Circuiting Assignment Operators<\/h2>\n
JavaScript, and a lot of other languages, support a set of operators called compound assignment<\/em> operators. Compound assignment operators apply an operator to two arguments, and then assign the result to the left side. You may have seen these before:<\/p>\n
\n
\/\/ Addition<\/span>\n\/\/ a = a + b<\/span>\na<\/span> +=<\/span> b<\/span>;<\/span> \/\/ Subtraction<\/span>\n\/\/ a = a - b<\/span>\na<\/span> -=<\/span> b<\/span>;<\/span> \/\/ Multiplication<\/span>\n\/\/ a = a * b<\/span>\na<\/span> *= b<\/span>;<\/span> \/\/ Division<\/span>\n\/\/ a = a \/ b<\/span>\na<\/span> \/= b<\/span>;<\/span> \/\/ Exponentiation<\/span>\n\/\/ a = a ** b<\/span>\na<\/span> **= b<\/span>;<\/span> \/\/ Left Bit Shift<\/span>\n\/\/ a = a << b<\/span>\na<\/span> <<= b<\/span>;<\/span><\/pre>\n<\/div>\n
So many operators in JavaScript have a corresponding assignment operator! Up until recently, however, there were three notable exceptions: logical and<\/em> (&&<\/code>), logical or<\/em> (||<\/code>), and nullish coalescing (??<\/code>).<\/p>\n
That\u2019s why TypeScript 4.0 supports a new ECMAScript feature to add three new assignment operators: &&=<\/code>, ||=<\/code>, and ??=<\/code>.<\/p>\n
These operators are great for substituting any example where a user might write code like the following:<\/p>\n
\n
a<\/span> =<\/span> a<\/span> &&<\/span> b<\/span>;<\/span>\na<\/span> =<\/span> a<\/span> ||<\/span> b<\/span>;<\/span>\na<\/span> =<\/span> a<\/span> ?? b<\/span>;<\/span><\/pre>\n<\/div>\n
Or a similar if<\/code> block like<\/p>\n
\n
\/\/ could be 'a ||= b'<\/span>\nif<\/span> (<\/span>!a<\/span>)<\/span> {<\/span> a<\/span> =<\/span> b<\/span>;<\/span>\n}<\/span><\/pre>\n<\/div>\n
There are even some patterns we\u2019ve seen (or, uh, written ourselves) to lazily initialize values, only if they\u2019ll be needed.<\/p>\n
\n
let<\/span> values<\/span>: string<\/span>[<\/span>]<\/span>;<\/span> \/\/ Before<\/span>\n(<\/span>values<\/span> ?? (<\/span>values<\/span> =<\/span> [<\/span>]<\/span>)<\/span>)<\/span>.<\/span>push<\/span>(<\/span>\"hello\"<\/span>)<\/span>;<\/span> \/\/ After<\/span>\n(<\/span>values<\/span> ??=<\/span> [<\/span>]<\/span>)<\/span>.<\/span>push<\/span>(<\/span>\"hello\"<\/span>)<\/span>;<\/span><\/pre>\n<\/div>\n
(look, we\u2019re not proud of all<\/em> the code we write\u2026)<\/p>\n
On the rare case that you use getters or setters with side-effects, it\u2019s worth noting that these operators only perform assignments if necessary. In that sense, not only is the right side of the operator \u201cshort-circuited\u201d \u2013 the assignment itself is too.<\/p>\n
\n
obj<\/span>.<\/span>prop<\/span> ||<\/span>=<\/span> foo<\/span>(<\/span>)<\/span>;<\/span> \/\/ roughly equivalent to either of the following<\/span> obj<\/span>.<\/span>prop<\/span> ||<\/span> (<\/span>obj<\/span>.<\/span>prop<\/span> =<\/span> foo<\/span>(<\/span>)<\/span>)<\/span>;<\/span> if<\/span> (<\/span>!obj<\/span>.<\/span>prop<\/span>)<\/span> {<\/span> obj<\/span>.<\/span>prop<\/span> =<\/span> foo<\/span>(<\/span>)<\/span>;<\/span>\n}<\/span><\/pre>\n<\/div>\n
Try running the following example<\/a> to see how that differs from always<\/em> performing the assignment.<\/p>\n
\n
const<\/span> obj<\/span> =<\/span> {<\/span> get<\/span> prop<\/span>(<\/span>)<\/span> {<\/span> console<\/span>.<\/span>log<\/span>(<\/span>\"getter has run\"<\/span>)<\/span>;<\/span> \/\/ Replace me!<\/span> return<\/span> Math<\/span>.<\/span>random<\/span>(<\/span>)<\/span> <<\/span> 0.5<\/span>;<\/span> }<\/span>,<\/span> set<\/span> prop<\/span>(<\/span>_val<\/span>: boolean<\/span>)<\/span> {<\/span> console<\/span>.<\/span>log<\/span>(<\/span>\"setter has run\"<\/span>)<\/span>;<\/span> }<\/span>\n}<\/span>;<\/span> function<\/span> foo<\/span>(<\/span>)<\/span> {<\/span> console<\/span>.<\/span>log<\/span>(<\/span>\"right side evaluated\"<\/span>)<\/span>;<\/span> return<\/span> true<\/span>;<\/span>\n}<\/span> console<\/span>.<\/span>log<\/span>(<\/span>\"This one always runs the setter\"<\/span>)<\/span>;<\/span>\nobj<\/span>.<\/span>prop<\/span> =<\/span> obj<\/span>.<\/span>prop<\/span> ||<\/span> foo<\/span>(<\/span>)<\/span>;<\/span> console<\/span>.<\/span>log<\/span>(<\/span>\"This one *sometimes* runs the setter\"<\/span>)<\/span>;<\/span>\nobj<\/span>.<\/span>prop<\/span> ||<\/span>=<\/span> foo<\/span>(<\/span>)<\/span>;<\/span><\/pre>\n<\/div>\n
We\u2019d like to extend a big thanks to community member Wenlu Wang<\/a> for this contribution!<\/p>\n
For more details, you can take a look at the pull request here<\/a>. You can also check out TC39\u2019s proposal repository for this feature<\/a>.<\/p>\n
unknown<\/code> on catch<\/code> Clause Bindings<\/h2>\n
Since the beginning days of TypeScript, catch<\/code> clause variables have always been typed as any<\/code>. This meant that TypeScript allowed you to do anything you wanted with them.<\/p>\n
\n
try<\/span> {<\/span> \/\/ ...<\/span>\n}<\/span>\ncatch<\/span> (<\/span>x<\/span>)<\/span> {<\/span> \/\/ x has type 'any' - have fun!<\/span> console<\/span>.<\/span>log<\/span>(<\/span>x<\/span>.<\/span>message<\/span>)<\/span>;<\/span> console<\/span>.<\/span>log<\/span>(<\/span>x<\/span>.<\/span>toUpperCase<\/span>(<\/span>)<\/span>)<\/span>;<\/span> x<\/span>++<\/span>;<\/span> x<\/span>.<\/span>yadda<\/span>.<\/span>yadda<\/span>.<\/span>yadda<\/span>(<\/span>)<\/span>;<\/span>\n}<\/span><\/pre>\n<\/div>\n
The above has some undesirable behavior if we\u2019re trying to prevent more<\/em> errors from happening in our error-handling code! Because these variables have the type any<\/code> by default, they lack any type-safety which could have errored on invalid operations.<\/p>\n
That\u2019s why TypeScript 4.0 now lets you specify the type of catch<\/code> clause variables as unknown<\/code> instead. unknown<\/code> is safer than any<\/code> because it reminds us that we need to perform some sorts of type-checks before operating on our values.<\/p>\n
\n
try<\/span> {<\/span> \/\/ ...<\/span>\n}<\/span>\ncatch<\/span> (<\/span>e<\/span>: unknown<\/span>)<\/span> {<\/span> \/\/ error!<\/span> \/\/ Property 'toUpperCase' does not exist on type 'unknown'.<\/span> console<\/span>.<\/span>log<\/span>(<\/span>e<\/span>.<\/span>toUpperCase<\/span>(<\/span>)<\/span>)<\/span>;<\/span> if<\/span> (<\/span>typeof<\/span> e<\/span> ===<\/span> \"string\"<\/span>)<\/span> {<\/span> \/\/ works!<\/span> \/\/ We've narrowed 'e' down to the type 'string'.<\/span> console<\/span>.<\/span>log<\/span>(<\/span>e<\/span>.<\/span>toUpperCase<\/span>(<\/span>)<\/span>)<\/span>;<\/span> }<\/span>\n}<\/span><\/pre>\n<\/div>\n
While the types of catch<\/code> variables won\u2019t change by default, we might consider a new --strict<\/code> mode flag in the future so that users can opt in to this behavior. In the meantime, it should be possible to write a lint rule to force catch<\/code> variables to have an explicit annotation of either : any<\/code> or : unknown<\/code>.<\/p>\n
For more details you can peek at the changes for this feature<\/a>.<\/p>\n
Custom JSX Factories<\/h2>\n
When using JSX, a fragment<\/em><\/a> is a type of JSX element that allows us to return multiple child elements. When we first implemented fragments in TypeScript, we didn\u2019t have a great idea about how other libraries would utilize them. Nowadays most other libraries that encourage using JSX and support fragments have a similar API shape.<\/p>\n
In TypeScript 4.0, users can customize the fragment factory through the new jsxFragmentFactory<\/code> option.<\/p>\n
As an example, the following tsconfig.json<\/code> file tells TypeScript to transform JSX in a way compatible with React, but switches each factory invocation to h<\/code> instead of React.createElement<\/code>, and uses Fragment<\/code> instead of React.Fragment<\/code>.<\/p>\n
\n
{<\/span> \"compilerOptions\"<\/span>: {<\/span> \"target\"<\/span>: \"esnext\"<\/span>,<\/span> \"module\"<\/span>: \"commonjs\"<\/span>,<\/span> \"jsx\"<\/span>: \"react\"<\/span>,<\/span> \"jsxFactory\"<\/span>: \"h\"<\/span>,<\/span> \"jsxFragmentFactory\"<\/span>: \"Fragment\"<\/span> }<\/span>\n}<\/span><\/pre>\n<\/div>\n
In cases where you need to have a different JSX factory on a per-file basis, you can take advantage of the new \/** @jsxFrag *\/<\/code> pragma comment. For example, the following\u2026<\/p>\n
\n
\/\/ Note: these pragma comments need to be written<\/span>\n\/\/ with a JSDoc-style multiline syntax to take effect.<\/span>\n\/** @jsx<\/span> h *\/<\/span>\n\/** @jsxFrag<\/span> Fragment *\/<\/span> import<\/span> {<\/span> h<\/span>,<\/span> Fragment<\/span> }<\/span> from<\/span> \"preact\"<\/span>;<\/span> let<\/span> stuff<\/span> =<\/span> <<\/span>><\/span> <<\/span>div<\/span>><\/span>Hello<<\/span>\/div<\/span>><\/span>\n<<\/span>\/><\/span>;<\/span><\/pre>\n<\/div>\n
\u2026will get transformed to this output JavaScript\u2026<\/p>\n
\n
\/\/ Note: these pragma comments need to be written<\/span>\n\/\/ with a JSDoc-style multiline syntax to take effect.<\/span>\n\/** @jsx<\/span> h *\/<\/span>\n\/** @jsxFrag<\/span> Fragment *\/<\/span>\nimport<\/span> {<\/span> h<\/span>,<\/span> Fragment<\/span> }<\/span> from<\/span> \"preact\"<\/span>;<\/span>\nlet<\/span> stuff<\/span> =<\/span> h<\/span>(<\/span>Fragment<\/span>,<\/span> null<\/span>,<\/span> h<\/span>(<\/span>\"div\"<\/span>,<\/span> null<\/span>,<\/span> \"Hello\"<\/span>)<\/span>)<\/span>;<\/span><\/pre>\n<\/div>\n
We\u2019d like to extend a big thanks to community member Noj Vek<\/a> for sending this pull request and patiently working with our team on it.<\/p>\n
You can see that the pull request<\/a> for more details!<\/p>\n
Speed Improvements in build<\/code> mode with --noEmitOnError<\/code><\/h2>\n
Previously, compiling a program after a previous compile with errors under --incremental<\/code> would be extremely slow when using the --noEmitOnError<\/code> flag. This is because none of the information from the last compilation would be cached in a .tsbuildinfo<\/code> file based on the --noEmitOnError<\/code> flag.<\/p>\n
TypeScript 4.0 changes this which gives a great speed boost in these scenarios, and in turn improves --build<\/code> mode scenarios (which imply both --incremental<\/code> and --noEmitOnError<\/code>).<\/p>\n
For details, read up more on the pull request<\/a>.<\/p>\n
--incremental<\/code> with --noEmit<\/code><\/h2>\n
TypeScript 4.0 allows us to use the --noEmit<\/code> flag when while still leveraging --incremental<\/code> compiles. This was previously not allowed, as --incremental<\/code> needs to emit a .tsbuildinfo<\/code> files; however, the use-case to enable faster incremental builds is important enough to enable for all users.<\/p>\n
For more details, you can see the implementing pull request<\/a>.<\/p>\n
Editor Improvements<\/h2>\n
The TypeScript compiler doesn\u2019t only power the editing experience for TypeScript itself in most major editors \u2013 it also powers the JavaScript experience in the Visual Studio family of editors and more. For that reason, much of our work focuses on improving editor scenarios \u2013 the place you spend most of your time as a developer.<\/p>\n
Using new TypeScript\/JavaScript functionality in your editor will differ depending on your editor, but<\/p>\n
You can check out a partial list of editors that have support for TypeScript<\/a> to learn more about whether your favorite editor has support to use new versions.<\/p>\n
Convert to Optional Chaining<\/h3>\n
Optional chaining is a recent feature that\u2019s received a lot of love. That\u2019s why TypeScript 4.0 brings a new refactoring to convert common patterns to take advantage of optional chaining<\/a> and nullish coalescing<\/a>!<\/p>\n
\"Converting<\/p>\n
Keep in mind that while this refactoring doesn\u2019t perfectly<\/em> capture the same behavior due to subtleties with truthiness\/falsiness in JavaScript, we believe it should capture the intent for most use-cases, especially when TypeScript has more precise knowledge of your types.<\/p>\n
For more details, check out the pull request for this feature<\/a>.<\/p>\n
\/** @deprecated *\/<\/code> Support<\/h3>\n
TypeScript\u2019s editing support now recognizes when a declaration has been marked with a \/** @deprecated *<\/code> JSDoc comment. That information is surfaced in completion lists and as a suggestion diagnostic that editors can handle specially. In an editor like VS Code, deprecated values are typically displayed a strike-though style like this<\/del>.<\/p>\n
\"Some<\/p>\n
This new functionality is available thanks to Wenlu Wang<\/a>. See the pull request<\/a> for more details.<\/p>\n
Partial Semantic Mode at Startup<\/h3>\n
We\u2019ve heard a lot from users suffering from long startup times, especially on bigger projects. The culprit is usually a process called program construction<\/em>. This is the process of starting with an initial set of root files, parsing them, finding their dependencies, parsing those dependencies, finding those dependencies\u2019 dependencies, and so on. The bigger your project is, the longer you\u2019ll have to wait before you can get basic editor operations like go-to-definition or quick info.<\/p>\n
That\u2019s why we\u2019ve been working on a new mode for editors to provide a partial<\/em> experience until the full language service experience has loaded up. The core idea is that editors can run a lightweight partial server that only looks at the current files that the editor has open.<\/p>\n
It\u2019s hard to say precisely what sorts of improvements you\u2019ll see, but anecdotally, it used to take anywhere between 20 seconds to a minute<\/em> before TypeScript would become fully responsive on the Visual Studio Code codebase. In contrast, our new partial semantic mode seems to bring that delay down to just a few seconds<\/strong>. As an example, in the following video, you can see two side-by-side editors with TypeScript 3.9 running on the left and TypeScript 4.0 running on the right.<\/p>\n
When restarting both editors on a particularly large codebase, the one with TypeScript 3.9 can\u2019t provide completions or quick info at all. On the other hand, the editor with TypeScript 4.0 can immediately<\/em> give us a rich experience in the current file we\u2019re editing, despite loading the full project in the background.<\/p>\n
Currently the only editor that supports this mode is Visual Studio Code<\/a> which has some UX improvements coming up in Visual Studio Code Insiders<\/a>. We recognize that this experience may still have room for polish in UX and functionality, and we have a list of improvements<\/a> in mind. We\u2019re looking for more feedback on what you think might be useful.<\/p>\n
For more information, you can see the original proposal<\/a>, the implementing pull request<\/a>, along with the follow-up meta issue<\/a>.<\/p>\n
Smarter Auto-Imports<\/h3>\n
Auto-import is a fantastic feature that makes coding a lot easier; however, every time auto-import doesn\u2019t seem to work, it can throw users off a lot. One specific issue that we heard from users was that auto-imports didn\u2019t work on dependencies that were written in TypeScript \u2013 that is, until they wrote at least one explicit import somewhere else in their project.<\/p>\n
Why would auto-imports work for @types<\/code> packages, but not for packages that ship their own types? It turns out that auto-imports only work on packages your project already<\/em> includes. Because TypeScript has some quirky defaults that automatically add packages in node_modules\/@types<\/code> to your project, those<\/em> packages would be auto-imported. On the other hand, other packages were excluded because crawling through all your node_modules<\/code> packages can be really<\/em> expensive.<\/p>\n
All of this leads to a pretty lousy getting started experience for when you\u2019re trying to auto-import something that you\u2019ve just installed but haven\u2019t used yet.<\/p>\n
TypeScript 4.0 now does a little extra work in editor scenarios to include the packages you\u2019ve listed in your package.json<\/code>\u2018s dependencies<\/code> (and peerDependencies<\/code>) fields. The information from these packages is only used to improve auto-imports, and doesn\u2019t change anything else like type-checking. This allows us to provide auto-imports for all of your dependencies that have types, without incurring the cost of a complete node_modules<\/code> search.<\/p>\n
In the rare cases when your package.json<\/code> lists more than ten typed dependencies that haven\u2019t been imported yet, this feature automatically disables itself to prevent slow project loading. To force the feature to work, or to disable it entirely, you should be able to configure your editor. For Visual Studio Code, this is the \u201cInclude Package JSON Auto Imports\u201d (or typescript.preferences.includePackageJsonAutoImports<\/code>) setting.<\/p>\n
\"Configuring For more details, you can see the proposal issue<\/a> along with the implementing pull request<\/a>.<\/p>\n
Our New Website!<\/h2>\n
The TypeScript website<\/a> has recently been rewritten from the ground up and rolled out!<\/p>\n
\"A<\/p>\n
We already wrote a bit about our new site<\/a>, so you can read up more there; but it\u2019s worth mentioning that we\u2019re still looking to hear what you think! If you have questions, comments, or suggestions, you can file them over on the website\u2019s issue tracker<\/a>.<\/p>\n
Breaking Changes<\/h2>\n
lib.d.ts<\/code> Changes<\/h3>\n
Our lib.d.ts<\/code> declarations have changed \u2013 most specifically, types for the DOM have changed. The most notable change may be the removal of document.origin<\/code><\/a> which only worked in old versions of IE and Safari MDN recommends moving to self.origin<\/code><\/a>.<\/p>\n
Properties Overriding Accessors (and vice versa) is an Error<\/h3>\n
Previously, it was only an error for properties to override accessors, or accessors to override properties, when using useDefineForClassFields<\/code>; however, TypeScript now always issues an error when declaring a property in a derived class that would override a getter or setter in the base class.<\/p>\n
\n
class<\/span> Base<\/span> {<\/span> get<\/span> foo<\/span>(<\/span>)<\/span> {<\/span> return<\/span> 100<\/span>;<\/span> }<\/span> set<\/span> foo<\/span>(<\/span>)<\/span> {<\/span> \/\/ ...<\/span> }<\/span>\n}<\/span> class<\/span> Derived<\/span> extends<\/span> Base<\/span> {<\/span> foo<\/span> =<\/span> 10<\/span>;<\/span>\n\/\/ ~~~<\/span>\n\/\/ error!<\/span>\n\/\/ 'foo' is defined as an accessor in class 'Base',<\/span>\n\/\/ but is overridden here in 'Derived' as an instance property.<\/span>\n}<\/span><\/pre>\n<\/div>\n
\n
class<\/span> Base<\/span> {<\/span> prop<\/span> =<\/span> 10<\/span>;<\/span>\n}<\/span> class<\/span> Derived<\/span> extends<\/span> Base<\/span> {<\/span> get<\/span> prop<\/span>(<\/span>)<\/span> {<\/span> \/\/ ~~~~<\/span> \/\/ error!<\/span> \/\/ 'prop' is defined as a property in class 'Base', but is overridden here in 'Derived' as an accessor.<\/span> return<\/span> 100<\/span>;<\/span> }<\/span>\n}<\/span><\/pre>\n<\/div>\n
See more details on the implementing pull request<\/a>.<\/p>\n
Operands for delete<\/code> must be optional.<\/h3>\n
When using the delete<\/code> operator in strictNullChecks<\/code>, the operand must now be any<\/code>, unknown<\/code>, never<\/code>, or be optional (in that it contains undefined<\/code> in the type). Otherwise, use of the delete<\/code> operator is an error.<\/p>\n
\n
interface<\/span> Thing<\/span> {<\/span> prop<\/span>: string<\/span>;<\/span>\n}<\/span> function<\/span> f<\/span>(<\/span>x<\/span>: Thing<\/span>)<\/span> {<\/span> delete<\/span> x<\/span>.<\/span>prop<\/span>;<\/span> \/\/ ~~~~~~<\/span> \/\/ error! The operand of a 'delete' operator must be optional.<\/span>\n}<\/span><\/pre>\n<\/div>\n
See more details on the implementing pull request<\/a>.<\/p>\n
Usage of TypeScript\u2019s Node Factory is Deprecated<\/h3>\n
Today TypeScript provides a set of \u201cfactory\u201d functions for producing AST Nodes; however, TypeScript 4.0 provides a new node factory API. As a result, for TypeScript 4.0 we\u2019ve made the decision to deprecate these older functions in favor of the new ones.<\/p>\n
For more details, read up on the relevant pull request for this change<\/a>.<\/p>\n
What\u2019s Next?<\/h2>\n
You\u2019ve reached the end of this release post, but luckily there\u2019s more coming. TypeScript 4.1\u2019s iteration plan<\/a> is already up so you can get a sense of what\u2019s on the horizon. In the meantime, you can give new features in 4.1 a shot by using nightly builds in your workspace<\/a>, or maybe just in your editor<\/a>. Whether you\u2019re on TypeScript 4.0, or the next version, we\u2019re interested in hearing feedback! Feel free to leave a comment below, reach out over Twitter<\/a>, or file an issue on GitHub<\/a>.<\/p>\n
We said it once, and we\u2019ll say it again: we owe so much to our community for all their work and dedication. In turn, we want to making coding in TypeScript and JavaScript the pure joy you deserve. This involves not just focusing on one thing, but a combination of improving the language and editing experience, keeping an eye on speed, iterating on our UX, smoothing the onboarding and learning experience as a whole, and more.<\/p>\n
Thank you so much, and enjoy 4.0!<\/p>\n
Happy Hacking!<\/p>\n
\u2013 Daniel Rosenwasser and the TypeScript Team<\/p>\n","protected":false},"excerpt":{"rendered":"
Daniel August 20th, 2020 Today we are thrilled to announce the availability of TypeScript 4.0! This version of the language represents our next generation of TypeScript releases, as we dive deeper into expressivity, productivity, and scalability. If you\u2019re not familiar with TypeScript, it\u2019s a language that builds on top of JavaScript by adding syntax for […]<\/p>\n","protected":false},"author":2,"featured_media":116977,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[49],"tags":[467,50],"class_list":["post-116976","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-microsoft-news","tag-developers","tag-recent-news"],"_links":{"self":[{"href":"https:\/\/sickgaming.net\/blog\/wp-json\/wp\/v2\/posts\/116976","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/sickgaming.net\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/sickgaming.net\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/sickgaming.net\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/sickgaming.net\/blog\/wp-json\/wp\/v2\/comments?post=116976"}],"version-history":[{"count":0,"href":"https:\/\/sickgaming.net\/blog\/wp-json\/wp\/v2\/posts\/116976\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/sickgaming.net\/blog\/wp-json\/wp\/v2\/media\/116977"}],"wp:attachment":[{"href":"https:\/\/sickgaming.net\/blog\/wp-json\/wp\/v2\/media?parent=116976"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/sickgaming.net\/blog\/wp-json\/wp\/v2\/categories?post=116976"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/sickgaming.net\/blog\/wp-json\/wp\/v2\/tags?post=116976"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}