Today we are excited to announce the beta release of TypeScript 4.6!<\/p>\n
To get started using the beta, you can get it\u00a0through NuGet<\/a>, or use npm with the following command:<\/p>\n You can also get editor support by<\/p>\n Here’s a quick list of what’s new in TypeScript 4.6!<\/p>\n In JavaScript classes it’s mandatory to call\u00a0 This made it cheap to check that\u00a0 We’d like to extend our thanks to\u00a0Joshua Goldberg<\/a>\u00a0for\u00a0patiently working with us to land this change<\/a>!<\/p>\n TypeScript has some interesting challenges due to the fact that it’s built on a structural type system that also provides generics.<\/p>\n In a structural type system, object types are compatible based on the members they have.<\/p>\n Notice that whether or not\u00a0 When you introduce generics into this, there are some harder questions to answer. For instance, is a\u00a0 In order to answer that, TypeScript needs to check whether the types of\u00a0 TypeScript has a few heuristics here – if a type\u00a0appears<\/em>\u00a0to be infinitely expanding after encountering a certain depth check, then it considers that the types\u00a0could<\/em>\u00a0be compatible. This is usually enough, but embarrassingly there were some false-negatives that this wouldn’t catch.<\/p>\n A human reader can see that\u00a0 TypeScript 4.6 is now able to distinguish these cases, and correctly errors on the last example. Additionally, because the language is no longer concerned with false-positives from explicitly-written types, TypeScript can conclude that a type is infinitely expanding much earlier, and save a bunch of work in checking for type compatibility. As a result, libraries on DefinitelyTyped like\u00a0 You may already have this change because it was cherry-picked into TypeScript 4.5.3, but it is a notable feature of TypeScript 4.6 which you can read up more about\u00a0here<\/a>.<\/p>\n TypeScript now can correctly infer to indexed access types which immediately index into a mapped object type.<\/p>\nnpm install typescript@beta<\/pre>\n<\/div>\n
\n
\n
super()<\/code><\/a><\/li>\n<\/a>Allowing Code in Constructors Before\u00a0
super()<\/code><\/h2>\nsuper()<\/code>\u00a0before referring to\u00a0this<\/code>. TypeScript enforces this as well, though it was a bit too strict in\u00a0how<\/em>\u00a0it ensured this. In TypeScript, it was previously an error to contain\u00a0any<\/em>\u00a0code at the beginning of a constructor if its containing class had any property initializers.<\/p>\nclass<\/span> Base<\/span> {<\/span>\r\n \/\/ ...<\/span>\r\n}<\/span>\r\n\r\nclass<\/span> Derived<\/span> extends<\/span> Base<\/span> {<\/span>\r\n someProperty<\/span> =<\/span> true<\/span>;<\/span>\r\n\r\n constructor<\/span>(<\/span>)<\/span> {<\/span>\r\n \/\/ error!<\/span>\r\n \/\/ have to call 'super()' first because it needs to initialize 'someProperty'.<\/span>\r\n doSomeStuff<\/span>(<\/span>)<\/span>;<\/span>\r\n super<\/span>(<\/span>)<\/span>;<\/span>\r\n }<\/span>\r\n}<\/span><\/pre>\n<\/div>\nsuper()<\/code>\u00a0got called before\u00a0this<\/code>\u00a0was referenced, but this ends up rejecting a lot of valid code. TypeScript 4.6 is now much more lenient in that check and permits other code to run before\u00a0super()<\/code>., all while still ensuring that\u00a0super()<\/code>\u00a0occurs at the top-level before any references to\u00a0this<\/code>.<\/p>\n<\/a>Improved Recursion Depth Checks<\/h2>\n
interface<\/span> Source<\/span> {<\/span>\r\n prop<\/span>: string<\/span>;<\/span>\r\n}<\/span>\r\n\r\ninterface<\/span> Target<\/span> {<\/span>\r\n prop<\/span>: number<\/span>;<\/span>\r\n}<\/span>\r\n\r\nfunction<\/span> check<\/span>(<\/span>source<\/span>: Source<\/span>,<\/span> target<\/span>: Target<\/span>)<\/span> {<\/span>\r\n target<\/span> =<\/span> source<\/span>;<\/span>\r\n \/\/ error!<\/span>\r\n \/\/ Type 'Source' is not assignable to type 'Target'.<\/span>\r\n \/\/ Types of property 'prop' are incompatible.<\/span>\r\n \/\/ Type 'string' is not assignable to type 'number'.<\/span>\r\n}<\/span><\/pre>\n<\/div>\nSource<\/code>\u00a0is compatible with\u00a0Target<\/code>\u00a0has to do with whether their\u00a0properties<\/em>\u00a0are assignable. In this case, that’s just\u00a0prop<\/code>.<\/p>\nSource<string><\/code>\u00a0assignable to a\u00a0Target<number><\/code>\u00a0in the following case?<\/p>\ninterface<\/span> Source<\/span><<\/span>T<\/span>><\/span> {<\/span>\r\n prop<\/span>: Source<\/span><<\/span>Source<\/span><<\/span>T<\/span>><\/span>><\/span>;<\/span>\r\n}<\/span>\r\n\r\ninterface<\/span> Target<\/span><<\/span>T<\/span>><\/span> {<\/span>\r\n prop<\/span>: Target<\/span><<\/span>Target<\/span><<\/span>T<\/span>><\/span>><\/span>;<\/span>\r\n}<\/span>\r\n\r\nfunction<\/span> check<\/span>(<\/span>source<\/span>: Source<\/span><<\/span>string<\/span>><\/span>,<\/span> target<\/span>: Target<\/span><<\/span>number<\/span>><\/span>)<\/span> {<\/span>\r\n target<\/span> =<\/span> source<\/span>;<\/span>\r\n}<\/span><\/pre>\n<\/div>\nprop<\/code>\u00a0are compatible. That leads to the another question: is a\u00a0Source<Source<string>><\/code>\u00a0assignable to a\u00a0Target<Target<number>><\/code>? To answer that, TypeScript checks whether\u00a0prop<\/code>\u00a0is compatible for\u00a0those<\/em>\u00a0types, and ends up checking whether\u00a0Source<Source<Source<string>>><\/code>\u00a0is assignable to\u00a0Target<Target<Target<number>>><\/code>. Keep going for a bit, and you might notice that the type infinitely expands the more you dig in.<\/p>\ninterface<\/span> Foo<\/span><<\/span>T<\/span>><\/span> {<\/span>\r\n prop<\/span>: T<\/span>;<\/span>\r\n}<\/span>\r\n\r\ndeclare<\/span> let<\/span> x<\/span>: Foo<\/span><<\/span>Foo<\/span><<\/span>Foo<\/span><<\/span>Foo<\/span><<\/span>Foo<\/span><<\/span>Foo<\/span><<\/span>string<\/span>><\/span>><\/span>><\/span>><\/span>><\/span>><\/span>;<\/span>\r\ndeclare<\/span> let<\/span> y<\/span>: Foo<\/span><<\/span>Foo<\/span><<\/span>Foo<\/span><<\/span>Foo<\/span><<\/span>Foo<\/span><<\/span>string<\/span>><\/span>><\/span>><\/span>><\/span>><\/span>;<\/span>\r\n\r\nx<\/span> =<\/span> y<\/span>;<\/span><\/pre>\n<\/div>\nx<\/code>\u00a0and\u00a0y<\/code>\u00a0should be incompatible in the above example. While the types are deeply nested, that’s just a consequence of how they were declared. The heuristic was meant to capture cases where deeply-nested types were generated through exploring the types, not from when a developer wrote that type out themselves.<\/p>\nredux-immutable<\/code>,\u00a0react-lazylog<\/code>, and\u00a0yup<\/code>\u00a0saw a 50% reduction in check-time.<\/p>\n<\/a>Indexed Access Inference Improvements<\/h2>\n