To get started using TypeScript 4.4, you can get it through 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 value in different ways, and do something different once we know more about its type.\nTypeScript understands these checks and calls them type guards<\/em>.\nInstead of having to convince TypeScript of a variable’s type whenever we use it, the type-checker leverages something called control flow analysis<\/em> to see if we’ve used a type guard before a given piece of code.<\/p>\n For example, we can write something like<\/p>\n In this example, we checked whether However, what would happen if we moved the condition out to a constant called In previous versions of TypeScript, this would be an error – even though In TypeScript 4.4, that is no longer the case.\nThe above example works with no errors!\nWhen 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.\nIf that type guard operates on a Different sorts of type guard conditions are preserved – not just Analysis on discriminants in 4.4 also goes a little bit deeper – we can now extract out discriminants and TypeScript can narrow the original object.<\/p>\n As another example, here’s a function that checks whether two of its inputs have contents.<\/p>\n TypeScript can understand that both One neat feature here is that this analysis works transitively.\nTypeScript will hop through constants to understand what sorts of checks you’ve already performed.<\/p>\n Note that there’s a cutoff – TypeScript doesn’t go arbitrarily deep when checking these conditions, but its analysis is deep enough for most checks.<\/p>\n This feature should make a lot of intuitive JavaScript code “just work” in TypeScript without it getting in your way.\nFor more details, check out the implementation on GitHub<\/a>!<\/p>\n TypeScript lets us describe objects where every property has to have a certain type using index signatures<\/em>.\nThis allows us to use these objects as dictionary-like types, where we can use string keys to index into them with square brackets.<\/p>\n For example, we can write a type with an index signature that takes While a Similarly, Index signatures are very useful to express lots of code out in the wild;\nhowever, until now they’ve been limited to TypeScript 4.4 addresses these limitations, and allows index signatures for For example, TypeScript now allows us to declare a type that can be keyed on arbitrary Similarly, we can write an index signature with template string pattern type.\nOne use of this might be to exempt properties starting with A final note on index signatures is that they now permit union types, as long as they’re a union of infinite-domain primitive types – specifically:<\/p>\n An index signature whose argument is a union of these types will de-sugar into several different index signatures.<\/p>\n For more details, read up on the pull request<\/a><\/p>\n In JavaScript, any type of value can be thrown with Once TypeScript added the That’s why TypeScript 4.4 introduces a new flag called This flag is enabled under the In cases where we don’t want to deal with an For more information, take a look at the implementing pull request<\/a>.<\/p>\n In JavaScript, reading a missing<\/em> property on an object produces the value was considered equivalent to<\/p>\n What this meant is that a user could explicitly write So by default, TypeScript doesn’t distinguish between a present property with the value In TypeScript 4.4, the new flag This flag is not part of the For more information, you can take a look at the implementing pull request here<\/a>.<\/p>\n TypeScript 4.4 brings support for These static blocks allow you to write a sequence of statements with their own scope that can access private fields within the containing class.\nThat means that we can write initialization code with all the capabilities of writing statements, no leakage of variables, and full access to our class’s internals.<\/p>\n Without Note that a class can have multiple We’d like to extend our thanks to Wenlu Wang<\/a> for TypeScript’s implementation of this feature.\nFor more details, you can see that pull request here<\/a>.<\/p>\n TypeScript’s You can read more on the original proposal thread<\/a>.<\/p>\n TypeScript now caches whether internal symbols are accessible in different contexts, along with how specific types should be printed.\nThese changes can improve TypeScript’s general performance in code with fairly complex types, and is especially observed when emitting npm install typescript\r\n<\/code><\/pre>\n\n
\n
unknown<\/code> Type in Catch Variables (--useUnknownInCatchVariables<\/code>)<\/a><\/li>\n--exactOptionalPropertyTypes<\/code>)<\/a><\/li>\nstatic<\/code> Blocks<\/a><\/li>\ntsc --help<\/code> Updates and Improvements<\/a><\/li>\n<\/a> Control Flow Analysis of Aliased Conditions and Discriminants<\/h2>\n
function foo(arg: unknown) {\r\n if (typeof arg === \"string\") {\r\n \/\/ We know 'arg' is a string now.\r\n console.log(arg.toUpperCase());\r\n }\r\n}\r\n<\/code><\/pre>\narg<\/code> was a string<\/code>.\nTypeScript recognized the typeof arg === \"string\"<\/code> check, which it considered a type guard, and knew that arg<\/code> was a string<\/code> inside the body of the if<\/code> block.\nThat let us access string<\/code> methods like toUpperCase()<\/code> without getting an error.<\/p>\nargIsString<\/code>?<\/p>\nfunction foo(arg: unknown) {\r\n const argIsString = typeof arg === \"string\";\r\n if (argIsString) {\r\n console.log(arg.toUpperCase());\r\n \/\/ ~~~~~~~~~~~\r\n \/\/ Error! Property 'toUpperCase' does not exist on type 'unknown'.\r\n }\r\n}\r\n<\/code><\/pre>\nargIsString<\/code> was assigned the value of a type guard, TypeScript simply lost that information.\nThat’s unfortunate since we might want to re-use the same check in several places.\nTo get around that, users often have to repeat themselves or use type assertions (a.k.a. casts).<\/p>\nconst<\/code>, a readonly<\/code> property, or an un-modified parameter, then TypeScript is able to narrow that value appropriately.<\/p>\ntypeof<\/code> checks.\nFor example, checks on discriminated unions work like a charm.<\/p>\ntype Shape =\r\n | { kind: \"circle\", radius: number }\r\n | { kind: \"square\", sideLength: number };\r\n\r\nfunction area(shape: Shape): number {\r\n const isCircle = shape.kind === \"circle\";\r\n if (isCircle) {\r\n \/\/ We know we have a circle here!\r\n return Math.PI * shape.radius ** 2;\r\n }\r\n else {\r\n \/\/ We know we're left with a square here!\r\n return shape.sideLength ** 2;\r\n }\r\n}\r\n<\/code><\/pre>\ntype Shape =\r\n | { kind: \"circle\", radius: number }\r\n | { kind: \"square\", sideLength: number };\r\n\r\nfunction area(shape: Shape): number {\r\n \/\/ Extract out the 'kind' field first.\r\n const { kind } = shape;\r\n\r\n if (kind === \"circle\") {\r\n \/\/ We know we have a circle here!\r\n return Math.PI * shape.radius ** 2;\r\n }\r\n else {\r\n \/\/ We know we're left with a square here!\r\n return shape.sideLength ** 2;\r\n }\r\n}\r\n<\/code><\/pre>\nfunction doSomeChecks(\r\n inputA: string | undefined,\r\n inputB: string | undefined,\r\n shouldDoExtraWork: boolean,\r\n) {\r\n let mustDoWork = inputA && inputB && shouldDoExtraWork;\r\n if (mustDoWork) {\r\n \/\/ We can access 'string' properties on both 'inputA' and 'inputB'!\r\n const upperA = inputA.toUpperCase();\r\n const upperB = inputB.toUpperCase();\r\n \/\/ ...\r\n }\r\n}\r\n<\/code><\/pre>\ninputA<\/code> and inputB<\/code> are both present if mustDoWork<\/code> is true<\/code>.\nThat means we don’t have to write a non-null assertion like inputA!<\/code> to convince TypeScript that inputA<\/code> isn’t undefined<\/code>.<\/p>\nfunction f(x: string | number | boolean) {\r\n const isString = typeof x === \"string\";\r\n const isNumber = typeof x === \"number\";\r\n const isStringOrNumber = isString || isNumber;\r\n if (isStringOrNumber) {\r\n x; \/\/ Type of 'x' is 'string | number'.\r\n }\r\n else {\r\n x; \/\/ Type of 'x' is 'boolean'.\r\n }\r\n}\r\n<\/code><\/pre>\n<\/a> Symbol and Template String Pattern Index Signatures<\/h2>\n
string<\/code> keys and maps to boolean<\/code> values.\nIf we try to assign anything other than a boolean<\/code> value, we’ll get an error.<\/p>\ninterface BooleanDictionary {\r\n [key: string]: boolean;\r\n}\r\n\r\ndeclare let myDict: BooleanDictionary;\r\n\r\n\/\/ Valid to assign boolean values\r\nmyDict[\"foo\"] = true;\r\nmyDict[\"bar\"] = false;\r\n\r\n\/\/ Error, \"oops\" isn't a boolean\r\nmyDict[\"baz\"] = \"oops\";\r\n<\/code><\/pre>\nMap<\/code> might be a better data structure here<\/a> (specifically, a Map<string, boolean><\/code>), JavaScript objects are often more convenient to use or just happen to be what we’re given to work with.<\/p>\nArray<T><\/code> already defines a number<\/code> index signature that lets us insert\/retrieve values of type T<\/code>.<\/p>\n\/\/ This is part of TypeScript's definition of the built-in Array type.\r\ninterface Array<T> {\r\n [index: number]: T;\r\n\r\n \/\/ ...\r\n}\r\n\r\nlet arr = new Array<string>();\r\n\r\n\/\/ Valid\r\narr[0] = \"hello!\";\r\n\r\n\/\/ Error, expecting a 'string' value here\r\narr[1] = 123;\r\n<\/code><\/pre>\nstring<\/code> and number<\/code> keys (and string<\/code> index signatures have an intentional quirk where they can accept number<\/code> keys since they’ll be coerced to strings anyway).\nThat means that TypeScript didn’t allow indexing objects with symbol<\/code> keys.\nTypeScript also couldn’t model an index signature of some subset<\/em> of string<\/code> keys – for example, an index signature which describes just properties whose names start with the text data-<\/code>.<\/p>\nsymbol<\/code>s and template string patterns.<\/p>\nsymbol<\/code>s.<\/p>\ninterface Colors {\r\n [sym: symbol]: number;\r\n}\r\n\r\nconst red = Symbol(\"red\");\r\nconst green = Symbol(\"green\");\r\nconst blue = Symbol(\"blue\");\r\n\r\nlet colors: Colors = {};\r\n\r\ncolors[red] = 255; \/\/ Assignment of a number is allowed\r\nlet redVal = colors[red]; \/\/ 'redVal' has the type 'number'\r\n\r\ncolors[blue] = \"da ba dee\"; \/\/ Error: Type 'string' is not assignable to type 'number'.\r\n<\/code><\/pre>\ndata-<\/code> from TypeScript’s excess property checking.\nWhen we pass an object literal to something with an expected type, TypeScript will look for excess properties that weren’t declared in the expected type.<\/p>\ninterface Options {\r\n width?: number;\r\n height?: number;\r\n}\r\n\r\nlet a: Options = {\r\n width: 100,\r\n height: 100,\r\n \"data-blah\": true, \/\/ Error! 'data-blah' wasn't declared in 'Options'.\r\n};\r\n\r\ninterface OptionsWithDataProps extends Options {\r\n \/\/ Permit any property starting with 'data-'.\r\n [optName: `data-${string}`]: unknown;\r\n}\r\n\r\nlet b: OptionsWithDataProps = {\r\n width: 100,\r\n height: 100,\r\n \"data-blah\": true, \/\/ Works!\r\n\r\n \"unknown-property\": true, \/\/ Error! 'unknown-property' wasn't declared in 'OptionsWithDataProps'.\r\n};\r\n<\/code><\/pre>\n\n
string<\/code><\/li>\nnumber<\/code><\/li>\nsymbol<\/code><\/li>\n`hello-${string}`<\/code>)<\/li>\n<\/ul>\ninterface Data {\r\n [optName: string | symbol]: any;\r\n}\r\n\r\n\/\/ Equivalent to\r\n\r\ninterface Data {\r\n [optName: string]: any;\r\n [optName: symbol]: any;\r\n}\r\n<\/code><\/pre>\n<\/a> Defaulting to the
unknown<\/code> Type in Catch Variables (--useUnknownInCatchVariables<\/code>)<\/h2>\nthrow<\/code> and caught in a catch<\/code> clause.\nBecause of this, TypeScript historically typed catch clause variables as any<\/code>, and would not allow any other type annotation:<\/p>\ntry {\r\n \/\/ Who knows what this might throw...\r\n executeSomeThirdPartyCode();\r\n}\r\ncatch (err) { \/\/ err: any\r\n console.error(err.message); \/\/ Allowed, because 'any'\r\n err.thisWillProbablyFail(); \/\/ Allowed, because 'any' :(\r\n}\r\n<\/code><\/pre>\nunknown<\/code> type, it became clear that unknown<\/code> was a better choice than any<\/code> in catch<\/code> clause variables for users who want the highest degree of correctness and type-safety, since it narrows better and forces us to test against arbitrary values.\nEventually TypeScript 4.0 allowed users to specify an explicit type annotation of unknown<\/code> (or any<\/code>) on each catch<\/code> clause variable so that we could opt into stricter types on a case-by-case basis;\nhowever, for some, manually specifying : unknown<\/code> on every catch<\/code> clause was a chore.<\/p>\n--useUnknownInCatchVariables<\/code>.\nThis flag changes the default type of catch<\/code> clause variables from any<\/code> to unknown<\/code>.<\/p>\ntry {\r\n executeSomeThirdPartyCode();\r\n}\r\ncatch (err) { \/\/ err: unknown\r\n\r\n \/\/ Error! Property 'message' does not exist on type 'unknown'.\r\n console.error(err.message);\r\n\r\n \/\/ Works! We can narrow 'err' from 'unknown' to 'Error'.\r\n if (err instanceof Error) {\r\n console.error(err.message);\r\n }\r\n}\r\n<\/code><\/pre>\n--strict<\/code> family of options.\nThat means that if you check your code using --strict<\/code>, this option will automatically be turned on.\nYou may end up with errors in TypeScript 4.4 such as<\/p>\nProperty 'message' does not exist on type 'unknown'.\r\nProperty 'name' does not exist on type 'unknown'.\r\nProperty 'stack' does not exist on type 'unknown'.\r\n<\/code><\/pre>\nunknown<\/code> variable in a catch<\/code> clause, we can always add an explicit : any<\/code> annotation so that we can opt out<\/em> of stricter types.<\/p>\ntry {\r\n executeSomeThirdPartyCode();\r\n}\r\ncatch (err: any) {\r\n console.error(err.message); \/\/ Works again!\r\n}\r\n<\/code><\/pre>\n<\/a> Exact Optional Property Types (
--exactOptionalPropertyTypes<\/code>)<\/h2>\nundefined<\/code>.\nIt’s also possible to have<\/em> an actual property with the value undefined<\/code>.\nA lot of code in JavaScript tends to treat these situations the same way, and so initially TypeScript just interpreted every optional property as if a user had written undefined<\/code> in the type.\nFor example,<\/p>\ninterface Person {\r\n name: string,\r\n age?: number;\r\n}\r\n<\/code><\/pre>\ninterface Person {\r\n name: string,\r\n age?: number | undefined;\r\n}\r\n<\/code><\/pre>\nundefined<\/code> in place of age<\/code>.<\/p>\nconst p: Person = {\r\n name: \"Daniel\",\r\n age: undefined, \/\/ This is okay by default.\r\n};\r\n<\/code><\/pre>\nundefined<\/code> and a missing property.\nWhile this works most of the time, not all code in JavaScript makes the same assumptions.\nFunctions and operators like Object.assign<\/code>, Object.keys<\/code>, object spread ({ ...obj }<\/code>), and for<\/code>–in<\/code> loops behave differently depending on whether or not a property actually exists on an object.\nIn the case of our Person<\/code> example, this could potentially lead to runtime errors if the age<\/code> property was observed in a context where its presence was important.<\/p>\n--exactOptionalPropertyTypes<\/code> specifies that optional property types should be interpreted exactly as written, meaning that | undefined<\/code> is not added to the type:<\/p>\n\/\/ With 'exactOptionalPropertyTypes' on:\r\nconst p: Person = {\r\n name: \"Daniel\",\r\n age: undefined, \/\/ Error! undefined isn't a number\r\n};\r\n<\/code><\/pre>\n--strict<\/code> family and needs to be turned on explicitly if you’d like this behavior.\nIt also requires --strictNullChecks<\/code> to be enabled as well.\nWe’ll be making updates to DefinitelyTyped and other definitions to try to make the transition as straightforward as possible, but you may encounter some friction with this depending on how your code is structured.<\/p>\n<\/a>
static<\/code> Blocks in Classes<\/h2>\nstatic<\/code> blocks in classes<\/a>, an upcoming ECMAScript feature that can help you write more-complex initialization code for static members.<\/p>\nclass Foo {\r\n static count = 0;\r\n\r\n \/\/ This is a static block:\r\n static {\r\n if (someCondition()) {\r\n Foo.count++;\r\n }\r\n }\r\n}\r\n<\/code><\/pre>\nclass Foo {\r\n static #count = 0;\r\n\r\n get count() {\r\n return Foo.#count;\r\n }\r\n\r\n static {\r\n try {\r\n const lastInstances = loadLastInstances();\r\n Foo.#count += lastInstances.length;\r\n }\r\n catch {}\r\n }\r\n}\r\n<\/code><\/pre>\nstatic<\/code> blocks, writing the code above was possible, but often involved several different types of hacks that had to compromise in some way.<\/p>\nstatic<\/code> blocks, and they’re run in the same order in which they’re written.<\/p>\n\/\/ Prints:\r\n\/\/ 1\r\n\/\/ 2\r\n\/\/ 3\r\nclass Foo {\r\n static prop = 1\r\n static {\r\n console.log(Foo.prop++);\r\n }\r\n static {\r\n console.log(Foo.prop++);\r\n }\r\n static {\r\n console.log(Foo.prop++);\r\n }\r\n}\r\n<\/code><\/pre>\n<\/a>
tsc --help<\/code> Updates and Improvements<\/h2>\n--help<\/code> option has gotten a refresh!\nThanks to work in part by Song Gao<\/a>, we’ve brought in changes to update the descriptions of our compiler options<\/a> and restyle the --help<\/code> menu<\/a> with colors and other visual separation.<\/p>\n![\"The](\"https:\/\/devblogs.microsoft.com\/typescript\/wp-content\/uploads\/sites\/11\/2021\/08\/tsc-help-ps-wt-4-4.png\")
<\/p>\n<\/a> Performance Improvements<\/h2>\n
Faster Declaration Emit<\/h3>\n
.d.ts<\/code> files under the --declaration<\/code> flag.<\/p>\n