Today we’re excited to announce the availability of TypeScript 4.3!<\/p>\n
If you’re not yet familiar with TypeScript, it’s a language that builds on JavaScript by adding syntax for static types.\nTools like the TypeScript compiler can just erase TypeScript syntax, leaving you with clean readable JavaScript that works anywhere.\nSo what’s that syntax adding if it just gets erased away?\nWell, when you add types throughout your code, you’re making your intentions explicit, and TypeScript can type-check<\/em> your code to catch mistakes like typos, logic errors, and more!\nTypeScript also uses those types to power editor tooling, giving you nice features like accurate code-completion, rename, and go-to-definition!\nYou can learn more on the TypeScript website<\/a>.<\/p>\n To start using TypeScript 4.3, 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 Let’s dive in to what TypeScript 4.3 brings!<\/p>\n In JavaScript, it’s pretty common for APIs to convert values that are passed in before storing them.\nThis often happens with getters and setters too.\nFor example, let’s imagine we’ve got a class with a setter that always converts a value into a How would we type this JavaScript code in TypeScript?\nWell, technically we don’t have to do anything special here – TypeScript can look at this with no explicit types and can figure out that The problem is that But that’s no good – That’s why TypeScript 4.3 allows you to specify types for reading and writing to properties.<\/p>\n In the above example, our When considering how two properties with the same name relate to each other, TypeScript will only use the “reading” type (e.g. the type on the Keep in mind, this isn’t a pattern that’s limited to classes.\nYou can write getters and setters with different types in object literals.<\/p>\n In fact, we’ve added syntax to interfaces\/object types to support different reading\/writing types on properties.<\/p>\n One limitation of using different types for reading and writing properties is that the type for reading a property has to be assignable to the type that you’re writing.\nIn other words, the getter type has to be assignable to the setter.\nThis ensures some level of consistency, so that a property is always assignable to itself.<\/p>\n For more information on this feature, take a look at the implementing pull request<\/a>.<\/p>\n When extending classes in JavaScript, the language makes it super easy (pun intended) to override methods – but unfortunately, there are some mistakes that you can run into.<\/p>\n One big one is missing renames.\nFor example, take the following classes:<\/p>\n Oh no!<\/em>\nOur Part of the issue here is that a user can’t make it clear whether they meant to add a new method, or to override an existing one.\nThat’s why TypeScript 4.3 adds the When a method is marked with This is a big improvement, but it doesn’t help if you forget<\/em> to write For example, you might accidentally “trample over” a method that exists in a base class without realizing it.<\/p>\n That’s why TypeScript 4.3 also<\/em> provides a new We’d like to extend our thanks to our community for the implementation here.\nThe work for these items was implemented in a pull request<\/a> by Wenlu Wang<\/a>, though an earlier pull request implementing only the In recent versions, TypeScript introduced a new type construct: template string types.\nThese are types that either construct new string-like types by concatenating…<\/p>\n …or match patterns of other string-like types.<\/p>\n The first change we made is just in when TypeScript will infer a template string type.\nWhen a template string is contextually typed<\/em> by a string-literal-like type (i.e. when TypeScript sees we’re passing a template string to something that takes a literal type) it will try to give that expression a template type.<\/p>\n This also kicks in when inferring types, and the type parameter The second major change here is that TypeScript can now better-relate, and infer between<\/em>, different template string types.<\/p>\n To see this, take the following example code:<\/p>\n When checking against a string literal type like on TypeScript now actually does the work to prove whether or not each part of a template string can successfully match.\nYou can now mix and match template strings with different substitutions and TypeScript will do a good job to figure out whether they’re really compatible.<\/p>\n In doing this work, we were also sure to add better inference capabilities.\nYou can see an example of these in action:<\/p>\n For more information, see the original pull request on leveraging contextual types<\/a>, along with the pull request that improved inference and checking between template types<\/a>.<\/p>\n TypeScript 4.3 expands which elements in a class can be given Even more broadly, static members can now also have private names.<\/p>\n This feature was authored in a pull request<\/a> from our friends at Bloomberg – written by Titian Cernicova-Dragomir<\/a>and Kubilay Kahveci<\/a>, with support and expertise from Joey Watts<\/a>, Rob Palmer<\/a>, and Tim McClure<\/a>.\nWe’d like to extend our thanks to all of them!<\/p>\n In TypeScript 4.3, the This is thanks to work done in TypeScript 4.2, where construct signatures can be marked as abstract:<\/p>\n You can see the change in more detail on GitHub<\/a>.<\/p>\n TypeScript 4.3 now includes some slightly smarter type-narrowing logic on generic values.\nThis allows TypeScript to accept more patterns, and sometimes even catch mistakes.<\/p>\n For some motivation, let’s say we’re trying to write a function called Let’s leave questions about this function’s implementation aside, and assume it arose from the requirements of a broader application.\nSomething that you might notice is that the signature doesn’t capture the original type of In TypeScript 4.2 and earlier, you’d end up with a bunch of errors as soon as you tried this.<\/p>\n Ew, errors!\nWhy is TypeScript being so mean to us?<\/p>\n The issue is that when we perform our It’s a very subtle distinction, but it makes a difference.\nTypeScript can’t just grab the constraint of So how does TypeScript 4.3 change things?\nWell, basically in a few key places when writing code, all the type system really cares about is the constraint of a type.\nFor example, when we write In cases like this, TypeScript will grab the narrowed type of the constraint because that will give you the data you care about;\nhowever, in any other case, we’ll just try to narrow the original generic type (and often end up with the original generic type).<\/p>\n In other words, based on how you use a generic value, TypeScript will narrow it a little differently.\nThe end result is that the entire above example compiles with no type-checking errors.<\/p>\n For more details, you can look at the original pull request on GitHub<\/a>.<\/p>\n Under This change<\/a> was contributed by Jack Works<\/a>, and we extend our thanks to them!<\/p>\n Index signatures allow us set more properties on a value than a type explicitly declares.<\/p>\n Up until now, an index signature could only be declared on the instance side of a class.\nThanks to a pull request<\/a> from Wenlu Wang<\/a>, index signatures can now be declared as npm install typescript\r\n<\/code><\/pre>\n\n
\n
override<\/code> and the --noImplicitOverride<\/code> Flag<\/a><\/li>\n#private<\/code> Class Elements<\/a><\/li>\nConstructorParameters<\/code> Works on Abstract Classes<\/a><\/li>\nstatic<\/code> Index Signatures<\/a><\/li>\n.tsbuildinfo<\/code> Size Improvements<\/a><\/li>\n--incremental<\/code> and --watch<\/code> Compilations<\/a><\/li>\n@link<\/code> Tags<\/a><\/li>\n<\/a> Separate Write Types on Properties<\/h2>\n
number<\/code> before saving it in a private field.<\/p>\nclass Thing {\r\n #size = 0;\r\n\r\n get size() {\r\n return this.#size;\r\n }\r\n set size(value) {\r\n let num = Number(value);\r\n\r\n \/\/ Don't allow NaN and stuff.\r\n if (!Number.isFinite(num)) {\r\n this.#size = 0;\r\n return;\r\n }\r\n\r\n this.#size = num;\r\n }\r\n}\r\n<\/code><\/pre>\nsize<\/code> is a number.<\/p>\nsize<\/code> allows you to assign more than just number<\/code>s to it.\nWe could get around this by saying that size<\/code> has the type unknown<\/code> or any<\/code> like in this snippet:<\/p>\nclass Thing {\r\n \/\/ ...\r\n get size(): unknown {\r\n return this.#size;\r\n }\r\n}\r\n<\/code><\/pre>\nunknown<\/code> forces people reading size<\/code> to do a type assertion, and any<\/code> won’t catch any mistakes.\nIf we really want to model APIs that convert values, previous versions of TypeScript forced us to pick between being precise (which makes reading values easier, and writing harder) and being permissive (which makes writing values easier, and reading harder).<\/p>\nclass Thing {\r\n #size = 0;\r\n\r\n get size(): number {\r\n return this.#size;\r\n }\r\n\r\n set size(value: string | number | boolean) {\r\n let num = Number(value);\r\n\r\n \/\/ Don't allow NaN and stuff.\r\n if (!Number.isFinite(num)) {\r\n this.#size = 0;\r\n return;\r\n }\r\n\r\n this.#size = num;\r\n }\r\n}\r\n<\/code><\/pre>\nset<\/code> accessor takes a broader set of types (string<\/code>s, boolean<\/code>s, and number<\/code>s), but our get<\/code> accessor always guarantees it will be a number<\/code>.\nNow we can finally assign other types to these properties with no errors!<\/p>\nlet thing = new Thing();\r\n\r\n\/\/ Assigning other types to `thing.size` works!\r\nthing.size = \"hello\";\r\nthing.size = true;\r\nthing.size = 42;\r\n\r\n\/\/ Reading `thing.size` always produces a number!\r\nlet mySize: number = thing.size;\r\n<\/code><\/pre>\nget<\/code> accessor above).\n“Writing” types are only considered when directly writing to a property.<\/p>\nfunction makeThing(): Thing {\r\n let size = 0;\r\n return {\r\n get size(): number {\r\n return size;\r\n },\r\n set size(value: string | number | boolean) {\r\n let num = Number(value);\r\n\r\n \/\/ Don't allow NaN and stuff.\r\n if (!Number.isFinite(num)) {\r\n size = 0;\r\n return;\r\n }\r\n\r\n size = num;\r\n }\r\n }\r\n}\r\n<\/code><\/pre>\n\/\/ Now valid!\r\ninterface Thing {\r\n get size(): number\r\n set size(value: number | string | boolean);\r\n}\r\n<\/code><\/pre>\n<\/a>
override<\/code> and the --noImplicitOverride<\/code> Flag<\/h2>\nclass SomeComponent {\r\n show() {\r\n \/\/ ...\r\n }\r\n hide() {\r\n \/\/ ...\r\n }\r\n}\r\n\r\nclass SpecializedComponent extends SomeComponent {\r\n show() {\r\n \/\/ ...\r\n }\r\n hide() {\r\n \/\/ ...\r\n }\r\n}\r\n<\/code><\/pre>\nSpecializedComponent<\/code> subclasses SomeComponent<\/code>, and overrides the show<\/code> and hide<\/code> methods.\nWhat happens if someone decides to rip out show<\/code> and hide<\/code> and replace them with a single method?<\/p>\n class SomeComponent {\r\n- show() {\r\n- \/\/ ...\r\n- }\r\n- hide() {\r\n- \/\/ ...\r\n- }\r\n+ setVisible(value: boolean) {\r\n+ \/\/ ...\r\n+ }\r\n }\r\n class SpecializedComponent extends SomeComponent {\r\n show() {\r\n \/\/ ...\r\n }\r\n hide() {\r\n \/\/ ...\r\n }\r\n }\r\n<\/code><\/pre>\nSpecializedComponent<\/code> didn’t get updated.\nNow it’s just adding these two useless show<\/code> and hide<\/code> methods that probably won’t get called.<\/p>\noverride<\/code> keyword.<\/p>\nclass SpecializedComponent extends SomeComponent {\r\n override show() {\r\n \/\/ ...\r\n }\r\n override hide() {\r\n \/\/ ...\r\n }\r\n}\r\n<\/code><\/pre>\noverride<\/code>, TypeScript will always make sure that a method with the same name exists in a the base class.<\/p>\nclass SomeComponent {\r\n setVisible(value: boolean) {\r\n \/\/ ...\r\n }\r\n}\r\nclass SpecializedComponent extends SomeComponent {\r\n override show() {\r\n\/\/ ~~~~~~~~\r\n\/\/ Error! This method can't be marked with 'override' because it's not declared in 'SomeComponent'.\r\n \/\/ ...\r\n }\r\n\r\n \/\/ ...\r\n}\r\n<\/code><\/pre>\noverride<\/code> on a method – and that’s a big mistake users can run into also.<\/p>\nclass Base {\r\n someHelperMethod() {\r\n \/\/ ...\r\n }\r\n}\r\n\r\nclass Derived extends Base {\r\n \/\/ Oops! We weren't trying to override here,\r\n \/\/ we just needed to write a local helper method.\r\n someHelperMethod() {\r\n \/\/ ...\r\n }\r\n}\r\n<\/code><\/pre>\n--noImplicitOverride<\/code> flag.\nWhen this option is turned on, it becomes an error to override any method from a superclass unless you explicitly use an override<\/code> keyword.\nIn that last example, TypeScript would error under --noImplicitOverride<\/code>, and give us a clue that we probably need to rename our method inside of Derived<\/code>.<\/p>\noverride<\/code> keyword by Paul Cody Johnston<\/a> served as a basis for direction and discussion.\nWe extend our gratitude for putting in the time for these features.<\/p>\n<\/a> Template String Type Improvements<\/h2>\n
type Color = \"red\" | \"blue\";\r\ntype Quantity = \"one\" | \"two\";\r\n\r\ntype SeussFish = `${Quantity | Color} fish`;\r\n\/\/ same as\r\n\/\/ type SeussFish = \"one fish\" | \"two fish\"\r\n\/\/ | \"red fish\" | \"blue fish\";\r\n<\/code><\/pre>\ndeclare let s1: `${number}-${number}-${number}`;\r\ndeclare let s2: `1-2-3`;\r\n\r\n\/\/ Works!\r\ns1 = s2;\r\n<\/code><\/pre>\nfunction bar(s: string): `hello ${string}` {\r\n \/\/ Previously an error, now works!\r\n return `hello ${s}`;\r\n}\r\n<\/code><\/pre>\nextends string<\/code><\/p>\ndeclare let s: string;\r\ndeclare function f<T extends string>(x: T): T;\r\n\r\n\/\/ Previously: string\r\n\/\/ Now : `hello-${string}`\r\nlet x2 = f(`hello ${s}`);\r\n<\/code><\/pre>\ndeclare let s1: `${number}-${number}-${number}`;\r\ndeclare let s2: `1-2-3`;\r\ndeclare let s3: `${number}-2-3`;\r\n\r\ns1 = s2;\r\ns1 = s3;\r\n<\/code><\/pre>\ns2<\/code>, TypeScript could match against the string contents and figure out that s2<\/code> was compatible with s1<\/code> in the first assignment;\nhowever, as soon as it saw another template string, it just gave up.\nAs a result, assignments like s3<\/code> to s1<\/code> just didn’t work.<\/p>\ndeclare let s1: `${number}-${number}-${number}`;\r\ndeclare let s2: `1-2-3`;\r\ndeclare let s3: `${number}-2-3`;\r\ndeclare let s4: `1-${number}-3`;\r\ndeclare let s5: `1-2-${number}`;\r\ndeclare let s6: `${number}-2-${number}`;\r\n\r\n\/\/ Now *all of these* work!\r\ns1 = s2;\r\ns1 = s3;\r\ns1 = s4;\r\ns1 = s5;\r\ns1 = s6;\r\n<\/code><\/pre>\ndeclare function foo<V extends string>(arg: `*${V}*`): V;\r\n\r\nfunction test<T extends string>(s: string, n: number, b: boolean, t: T) {\r\n let x1 = foo(\"*hello*\"); \/\/ \"hello\"\r\n let x2 = foo(\"**hello**\"); \/\/ \"*hello*\"\r\n let x3 = foo(`*${s}*` as const); \/\/ string\r\n let x4 = foo(`*${n}*` as const); \/\/ `${number}`\r\n let x5 = foo(`*${b}*` as const); \/\/ \"true\" | \"false\"\r\n let x6 = foo(`*${t}*` as const); \/\/ `${T}`\r\n let x7 = foo(`**${s}**` as const); \/\/ `*${string}*`\r\n}\r\n<\/code><\/pre>\n<\/a> ECMAScript
#private<\/code> Class Elements<\/h2>\n#private<\/code> #names<\/code> to make them truly private at run-time.\nIn addition to properties, methods and accessors can also be given private names.<\/p>\nclass Foo {\r\n #someMethod() {\r\n \/\/...\r\n }\r\n\r\n get #someValue() {\r\n return 100;\r\n }\r\n\r\n publicMethod() {\r\n \/\/ These work.\r\n \/\/ We can access private-named members inside this class.\r\n this.#someMethod();\r\n return this.#someValue;\r\n }\r\n}\r\n\r\nnew Foo().#someMethod();\r\n\/\/ ~~~~~~~~~~~\r\n\/\/ error!\r\n\/\/ Property '#someMethod' is not accessible\r\n\/\/ outside class 'Foo' because it has a private identifier.\r\n\r\nnew Foo().#someValue;\r\n\/\/ ~~~~~~~~~~\r\n\/\/ error!\r\n\/\/ Property '#someValue' is not accessible\r\n\/\/ outside class 'Foo' because it has a private identifier.\r\n<\/code><\/pre>\nclass Foo {\r\n static #someMethod() {\r\n \/\/ ...\r\n }\r\n}\r\n\r\nFoo.#someMethod();\r\n\/\/ ~~~~~~~~~~~\r\n\/\/ error!\r\n\/\/ Property '#someMethod' is not accessible\r\n\/\/ outside class 'Foo' because it has a private identifier.\r\n<\/code><\/pre>\n<\/a>
ConstructorParameters<\/code> Works on Abstract Classes<\/h2>\nConstructorParameters<\/code> type helper now works on abstract<\/code> classes.<\/p>\nabstract class C {\r\n constructor(a: string, b: number) {\r\n \/\/ ...\r\n }\r\n}\r\n\r\n\/\/ Has the type '[a: string, b: number]'.\r\ntype CParams = ConstructorParameters<typeof C>;\r\n<\/code><\/pre>\ntype MyConstructorOf<T> = {\r\n abstract new(...args: any[]): T;\r\n}\r\n\r\n\/\/ or using the shorthand syntax:\r\n\r\ntype MyConstructorOf<T> = abstract new (...args: any[]) => T;\r\n<\/code><\/pre>\n<\/a> Contextual Narrowing for Generics<\/h2>\n
makeUnique<\/code>.\nIt’ll take a Set<\/code> or an Array<\/code> of elements, and if it’s given an Array<\/code>, it’ll sort that Array<\/code> remove duplicates according to some comparison function.\nAfter all that, it will return the original collection.<\/p>\nfunction makeUnique<T>(collection: Set<T> | T[], comparer: (x: T, y: T) => number): Set<T> | T[] {\r\n \/\/ Early bail-out if we have a Set.\r\n \/\/ We assume the elements are already unique.\r\n if (collection instanceof Set) {\r\n return collection;\r\n }\r\n\r\n \/\/ Sort the array, then remove consecutive duplicates.\r\n collection.sort(comparer);\r\n for (let i = 0; i < collection.length; i++) {\r\n let j = i;\r\n while (j < collection.length && comparer(collection[i], collection[j + 1]) === 0) {\r\n j++;\r\n }\r\n collection.splice(i + 1, j - i);\r\n }\r\n return collection;\r\n}\r\n<\/code><\/pre>\ncollection<\/code>.\nWe can do that by adding a type parameter called C<\/code> in place of where we’ve written Set<T> | T[]<\/code>.<\/p>\n- function makeUnique<T>(collection: Set<T> | T[], comparer: (x: T, y: T) => number): Set<T> | T[]\r\n+ function makeUnique<T, C extends Set<T> | T[]>(collection: C, comparer: (x: T, y: T) => number): C\r\n<\/code><\/pre>\nfunction makeUnique<T, C extends Set<T> | T[]>(collection: C, comparer: (x: T, y: T) => number): C {\r\n \/\/ Early bail-out if we have a Set.\r\n \/\/ We assume the elements are already unique.\r\n if (collection instanceof Set) {\r\n return collection;\r\n }\r\n\r\n \/\/ Sort the array, then remove consecutive duplicates.\r\n collection.sort(comparer);\r\n \/\/ ~~~~\r\n \/\/ error: Property 'sort' does not exist on type 'C'.\r\n for (let i = 0; i < collection.length; i++) {\r\n \/\/ ~~~~~~\r\n \/\/ error: Property 'length' does not exist on type 'C'.\r\n let j = i;\r\n while (j < collection.length && comparer(collection[i], collection[j + 1]) === 0) {\r\n \/\/ ~~~~~~\r\n \/\/ error: Property 'length' does not exist on type 'C'.\r\n \/\/ ~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~\r\n \/\/ error: Element implicitly has an 'any' type because expression of type 'number'\r\n \/\/ can't be used to index type 'Set<T> | T[]'.\r\n j++;\r\n }\r\n collection.splice(i + 1, j - i);\r\n \/\/ ~~~~~~\r\n \/\/ error: Property 'splice' does not exist on type 'C'.\r\n }\r\n return collection;\r\n}\r\n<\/code><\/pre>\ncollection instanceof Set<\/code> check, we’re expecting that to act as a type guard that narrows the type from Set<T> | T[]<\/code> to Set<T><\/code> and T[]<\/code> depending on the branch we’re in;\nhowever, we’re not dealing with a Set<T> | T[]<\/code>, we’re trying to narrow the generic value collection<\/code>, whose type is C<\/code>.<\/p>\nC<\/code> (which is Set<T> | T[]<\/code>) and narrow that.\nIf TypeScript did<\/em> try to narrow from Set<T> | T[]<\/code>, it would forget that collection<\/code> is also a C<\/code> in each branch because there’s no easy way to preserve that information.\nIf hypothetically TypeScript tried that approach, it would break the above example in a different way.\nAt the return positions, where the function expects values with the type C<\/code>, we would instead get a Set<T><\/code> and a T[]<\/code> in each branch, which TypeScript would reject.<\/p>\nfunction makeUnique<T>(collection: Set<T> | T[], comparer: (x: T, y: T) => number): Set<T> | T[] {\r\n \/\/ Early bail-out if we have a Set.\r\n \/\/ We assume the elements are already unique.\r\n if (collection instanceof Set) {\r\n return collection;\r\n \/\/ ~~~~~~~~~~\r\n \/\/ error: Type 'Set<T>' is not assignable to type 'C'.\r\n \/\/ 'Set<T>' is assignable to the constraint of type 'C', but\r\n \/\/ 'C' could be instantiated with a different subtype of constraint 'Set<T> | T[]'.\r\n }\r\n\r\n \/\/ ...\r\n\r\n return collection;\r\n \/\/ ~~~~~~~~~~\r\n \/\/ error: Type 'T[]' is not assignable to type 'C'.\r\n \/\/ 'T[]' is assignable to the constraint of type 'C', but\r\n \/\/ 'C' could be instantiated with a different subtype of constraint 'Set<T> | T[]'.\r\n }\r\n<\/code><\/pre>\ncollection.length<\/code>, TypeScript doesn’t care about the fact that collection<\/code> has the type C<\/code>, it only cares about the properties available, which are determined by the constraint T[] | Set<T><\/code>.<\/p>\n<\/a> Always-Truthy Promise Checks<\/h2>\n
strictNullChecks<\/code>, checking whether a Promise<\/code> is “truthy” in a conditional will trigger an error.<\/p>\nasync function foo(): Promise<boolean> {\r\n return false;\r\n}\r\n\r\nasync function bar(): Promise<string> {\r\n if (foo()) {\r\n \/\/ ~~~~~\r\n \/\/ Error!\r\n \/\/ This condition will always return true since\r\n \/\/ this 'Promise<boolean>' appears to always be defined.\r\n \/\/ Did you forget to use 'await'?\r\n return \"true\";\r\n }\r\n return \"false\";\r\n}\r\n<\/code><\/pre>\n<\/a>
static<\/code> Index Signatures<\/h2>\nclass Foo {\r\n hello = \"hello\";\r\n world = 1234;\r\n\r\n \/\/ This is an index signature:\r\n [propName: string]: string | number | undefined;\r\n}\r\n\r\nlet instance = new Foo();\r\n\r\n\/\/ Valid assigment\r\ninstance[\"whatever\"] = 42;\r\n\r\n\/\/ Has type 'string | number | undefined'.\r\nlet x = instance[\"something\"];\r\n<\/code><\/pre>\nstatic<\/code>.<\/p>\nclass Foo {\r\n static hello = \"hello\";\r\n static world = 1234;\r\n\r\n static [propName: string]: string | number | undefined;\r\n}\r\n\r\n\/\/ Valid.\r\nFoo[\"whatever\"] = 42;\r\n\r\n\/\/ Has type 'string | number | undefined'\r\nlet x = Foo[\"something\"];\r\n<\/code><\/pre>\n