Today we are excited to announce the beta release of TypeScript 4.4!<\/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 Some major highlights of TypeScript 4.4 are:<\/p>\n Let’s explore these in more detail!<\/p>\n In JavaScript, we often have to probe a variable in different ways to see if it has a more specific type that we can use. TypeScript understands these checks and calls them\u00a0type guards<\/em>. Instead of having to convince TypeScript of a variable’s type whenever we use it, the type-checker leverages something called\u00a0control flow analysis<\/em>\u00a0to deduce the type within every language construct.<\/p>\n For example, we can write something like<\/p>\n In this example, we checked whether\u00a0 However, what happens if we move the condition out to a constant?<\/p>\n In previous versions of TypeScript, this would be an error – even though\u00a0 In TypeScript 4.4, that is no longer the case. The above example works with no errors! When TypeScript sees that we are testing a constant value, it will do a little bit of extra work to see if it contains a type guard. If that type guard operates on a\u00a0 Different sorts of type guard conditions are preserved – not just\u00a0 As another example, here’s a function that checks whether two of its inputs have contents.<\/p>\n TypeScript can understand that both\u00a0 One neat feature here is that this analysis works transitively. If we have a constant assigned to a condition which has more constants in it, and those constants are each assigned type guards, then TypeScript can propagate the conditions later on.<\/p>\nnpm install typescript@beta<\/pre>\n<\/div>\n
\n
\n
unknown<\/code>\u00a0Type in Catch Variables (--useUnknownInCatchVariables<\/code>)<\/a><\/li>\n--exactOptionalPropertyTypes<\/code>)<\/a><\/li>\ntsc --help<\/code>\u00a0Updates and Improvements<\/a><\/li>\n<\/a>Control Flow Analysis of Aliased Conditions<\/h2>\n
function<\/span> foo<\/span>(<\/span>arg<\/span>: unknown<\/span>)<\/span> {<\/span>\r\n if<\/span> (<\/span>typeof<\/span> arg<\/span> ===<\/span> \"string\"<\/span>)<\/span> {<\/span>\r\n \/\/ We know this is a string now.<\/span>\r\n console<\/span>.<\/span>log<\/span>(<\/span>arg<\/span>.<\/span>toUpperCase<\/span>(<\/span>)<\/span>)<\/span>;<\/span>\r\n }<\/span>\r\n}<\/span><\/pre>\n<\/div>\narg<\/code>\u00a0was a\u00a0string<\/code>. TypeScript recognized the\u00a0typeof arg === \"string\"<\/code>\u00a0check, which it considered a type guard, and was able to determine that\u00a0arg<\/code>\u00a0should be a\u00a0string<\/code>\u00a0in the body of the\u00a0if<\/code>\u00a0block.<\/p>\nfunction<\/span> foo<\/span>(<\/span>arg<\/span>: unknown<\/span>)<\/span> {<\/span>\r\n const<\/span> argIsString<\/span> =<\/span> typeof<\/span> arg<\/span> ===<\/span> \"string\"<\/span>;<\/span>\r\n if<\/span> (<\/span>argIsString<\/span>)<\/span> {<\/span>\r\n console<\/span>.<\/span>log<\/span>(<\/span>arg<\/span>.<\/span>toUpperCase<\/span>(<\/span>)<\/span>)<\/span>;<\/span>\r\n \/\/ ~~~~~~~~~~~<\/span>\r\n \/\/ Error! Property 'toUpperCase' does not exist on type 'unknown'.<\/span>\r\n }<\/span>\r\n}<\/span><\/pre>\n<\/div>\nargIsString<\/code>\u00a0was assigned the value of a type guard, TypeScript simply lost that information. That’s unfortunate since we might want to re-use the same check in several places. To get around that, users often have to repeat themselves or use type assertions (casts).<\/p>\nconst<\/code>, a\u00a0readonly<\/code>\u00a0property, or an un-modified parameter, then TypeScript is able to narrow that value appropriately.<\/p>\ntypeof<\/code>\u00a0checks. For example, checks on discriminated unions work like a charm.<\/p>\ntype<\/span> Shape<\/span> =<\/span>\r\n |<\/span> {<\/span> kind<\/span>: \"circle\"<\/span>,<\/span> radius<\/span>: number<\/span> }<\/span>\r\n |<\/span> {<\/span> kind<\/span>: \"square\"<\/span>,<\/span> sideLength<\/span>: number<\/span> }<\/span>;<\/span>\r\n\r\nfunction<\/span> area<\/span>(<\/span>shape<\/span>: Shape<\/span>)<\/span>: number<\/span> {<\/span>\r\n const<\/span> isCircle<\/span> =<\/span> shape<\/span>.<\/span>kind<\/span> ===<\/span> \"circle\"<\/span>;<\/span>\r\n if<\/span> (<\/span>isCircle<\/span>)<\/span> {<\/span>\r\n \/\/ We know we have a circle here!<\/span>\r\n return<\/span> Math<\/span>.<\/span>PI<\/span> *<\/span> shape<\/span>.<\/span>radius<\/span> **<\/span> 2<\/span>;<\/span>\r\n }<\/span>\r\n else<\/span> {<\/span>\r\n \/\/ We know we're left with a square here!<\/span>\r\n return<\/span> shape<\/span>.<\/span>sideLength<\/span> **<\/span> 2<\/span>;<\/span>\r\n }<\/span>\r\n}<\/span><\/pre>\n<\/div>\nfunction<\/span> doSomeChecks<\/span>(<\/span>\r\n inputA<\/span>: string<\/span> |<\/span> undefined<\/span>,<\/span>\r\n inputB<\/span>: string<\/span> |<\/span> undefined<\/span>,<\/span>\r\n shouldDoExtraWork<\/span>: boolean<\/span>,<\/span>\r\n)<\/span> {<\/span>\r\n let<\/span> mustDoWork<\/span> =<\/span> inputA<\/span> &&<\/span> inputB<\/span> &&<\/span> shouldDoExtraWork<\/span>;<\/span>\r\n if<\/span> (<\/span>mustDoWork<\/span>)<\/span> {<\/span>\r\n \/\/ Can access 'string' properties on both 'inputA' and 'inputB'!<\/span>\r\n const<\/span> upperA<\/span> =<\/span> inputA<\/span>.<\/span>toUpperCase<\/span>(<\/span>)<\/span>;<\/span>\r\n const<\/span> upperB<\/span> =<\/span> inputB<\/span>.<\/span>toUpperCase<\/span>(<\/span>)<\/span>;<\/span>\r\n \/\/ ...<\/span>\r\n }<\/span>\r\n}<\/span><\/pre>\n<\/div>\ninputA<\/code>\u00a0and\u00a0inputB<\/code>\u00a0are both present if\u00a0mustDoWork<\/code>\u00a0is\u00a0true<\/code>. That means we don’t have to write a non-null assertion like\u00a0inputA!<\/code>\u00a0to convince TypeScript that\u00a0inputA<\/code>\u00a0isn’t\u00a0undefined<\/code>.<\/p>\nfunction<\/span> f<\/span>(<\/span>