null<\/code> and undefined<\/code>, and more.\nBecause TypeScript code just looks like JavaScript with types, everything you know about JavaScript still applies.\nWhen you need, your types can be stripped out, leaving you with clean, readable, runnable JavaScript that works anywhere.\nTo learn more about TypeScript, you can visit our website<\/a>.<\/p>\nTo get started using TypeScript 4.2, you can get it through NuGet<\/a>, or use npm with the following command:<\/p>\nnpm install typescript\r\n<\/code><\/pre>\nYou can also get editor support by<\/p>\n
\n- Downloading for Visual Studio 2019\/2017<\/a><\/li>\n
- Installing the Insiders Version of Visual Studio Code<\/a> or following directions to use a newer version of TypeScript<\/a><\/li>\n<\/ul>\n
\n- Sublime Text 3 via Package Control<\/a>.<\/li>\n<\/ul>\n
Let’s take a look at what’s in store for TypeScript 4.2!<\/p>\n
Smarter Type Alias Preservation<\/h2>\n
TypeScript has a way to declare new names for types called type aliases.\nIf you’re writing a set of functions that all work on string | number | boolean<\/code>, you can write a type alias to avoid repeating yourself over and over again.<\/p>\ntype BasicPrimitive = number | string | boolean;\r\n<\/code><\/pre>\nTypeScript has always used a set of rules and guesses for when to reuse type aliases when printing out types.\nFor example, take the following code snippet.<\/p>\n
export type BasicPrimitive = number | string | boolean;\r\n\r\nexport function doStuff(value: BasicPrimitive) {\r\n let x = value;\r\n return x;\r\n}\r\n<\/code><\/pre>\nIf we hover our mouse over x<\/code> in an editor like Visual Studio, Visual Studio Code, or the TypeScript Playground<\/a>, we’ll get a quick info panel that shows the type BasicPrimitive<\/code>.\nLikewise, if we get the declaration file output (.d.ts<\/code> output) for this file, TypeScript will say that doStuff<\/code> returns BasicPrimitive<\/code>.<\/p>\nHowever, what happens if we return a BasicPrimitive<\/code> or undefined<\/code>?<\/p>\nexport type BasicPrimitive = number | string | boolean;\r\n\r\nexport function doStuff(value: BasicPrimitive) {\r\n if (Math.random() < 0.5) {\r\n return undefined;\r\n }\r\n\r\n return value;\r\n}\r\n<\/code><\/pre>\nWe can see what happens in the TypeScript playground<\/a>.\nWhile we might want TypeScript to display the return type of doStuff<\/code> as BasicPrimitive | undefined<\/code>, it instead displays string | number | boolean | undefined<\/code>!\nWhat gives?<\/p>\nWell this has to do with how TypeScript represents types internally.\nWhen creating a union type out of one or more union types, it will always normalize<\/em> those types into a new flattened union type – but doing that loses information.\nThe type-checker would have to find every combination of types from string | number | boolean | undefined<\/code> to see what type aliases could have been used, and even then, there might be multiple type aliases to string | number | boolean<\/code>.<\/p>\nIn TypeScript 4.2, our internals are a little smarter.\nWe keep track of how types were constructed by keeping around parts of how they were originally written and constructed over time.\nWe also keep track of, and differentiate, type aliases to instances of other aliases!<\/p>\n
Being able to print back the types based on how you used them in your code means that as a TypeScript user, you can avoid some unfortunately humongous types getting displayed, and that often translates to getting better .d.ts<\/code> file output, error messages, and in-editor type displays in quick info and signature help.\nThis can help TypeScript feel a little bit more approachable for newcomers.<\/p>\nFor more information, check out the first pull request that improves various cases around preserving union type aliases<\/a>, along with a second pull request that preserves indirect aliases<\/a>.<\/p>\nLeading\/Middle Rest Elements in Tuple Types<\/h2>\n
In TypeScript, tuple types are meant to model arrays with specific lengths and element types.<\/p>\n
\/\/ A tuple that stores a pair of numbers\r\nlet a: [number, number] = [1, 2];\r\n\r\n\/\/ A tuple that stores a string, a number, and a boolean\r\nlet b: [string, number, boolean] = [\"hello\", 42, true];\r\n<\/code><\/pre>\nOver time, TypeScript’s tuple types have become more and more sophisticated, since they’re also used to model things like parameter lists in JavaScript.\nAs a result, they can have optional elements and rest elements, and can even have labels for tooling and readability.<\/p>\n
\/\/ A tuple that has either one or two strings.\r\nlet c: [string, string?] = [\"hello\"];\r\nc = [\"hello\", \"world\"];\r\n\r\n\/\/ A labeled tuple that has either one or two strings.\r\nlet d: [first: string, second?: string] = [\"hello\"];\r\nd = [\"hello\", \"world\"];\r\n\r\n\/\/ A tuple with a *rest element* - holds at least 2 strings at the front,\r\n\/\/ and any number of booleans at the back.\r\nlet e: [string, string, ...boolean[]];\r\n\r\ne = [\"hello\", \"world\"];\r\ne = [\"hello\", \"world\", false];\r\ne = [\"hello\", \"world\", true, false, true];\r\n<\/code><\/pre>\nIn TypeScript 4.2, rest elements specifically been expanded in how they can be used.\nIn prior versions, TypeScript only allowed ...rest<\/code> elements at the very last position of a tuple type.<\/p>\nHowever, now rest elements can occur anywhere<\/em> within a tuple – with only a few restrictions.<\/p>\nlet foo: [...string[], number];\r\n\r\nfoo = [123];\r\nfoo = [\"hello\", 123];\r\nfoo = [\"hello!\", \"hello!\", \"hello!\", 123];\r\n\r\nlet bar: [boolean, ...string[], boolean];\r\n\r\nbar = [true, false];\r\nbar = [true, \"some text\", false];\r\nbar = [true, \"some\", \"separated\", \"text\", false];\r\n<\/code><\/pre>\nThe only restriction is that a rest element can be placed anywhere in a tuple, so long as it’s not followed by another optional element or rest element.\nIn other words, only one rest element per tuple, and no optional elements after rest elements.<\/p>\n
interface Clown { \/*...*\/ }\r\ninterface Joker { \/*...*\/ }\r\n\r\nlet StealersWheel: [...Clown[], \"me\", ...Joker[]];\r\n\/\/ ~~~~~~~~~~ Error!\r\n\/\/ A rest element cannot follow another rest element.\r\n\r\nlet StringsAndMaybeBoolean: [...string[], boolean?];\r\n\/\/ ~~~~~~~~ Error!\r\n\/\/ An optional element cannot follow a rest element.\r\n<\/code><\/pre>\nThese non-trailing rest elements can be used to model functions that take any number of leading arguments, followed by a few fixed ones.<\/p>\n
declare function doStuff(...args: [...names: string[], shouldCapitalize: boolean]): void;\r\n\r\ndoStuff(\/*shouldCapitalize:*\/ false)\r\ndoStuff(\"fee\", \"fi\", \"fo\", \"fum\", \/*shouldCapitalize:*\/ true);\r\n<\/code><\/pre>\nEven though JavaScript doesn’t have any syntax to model leading rest parameters, we were still able to declare doStuff<\/code> as a function that takes leading arguments by declaring the ...args<\/code> rest parameter with a tuple type that uses a leading rest element<\/em>.\nThis can help model lots of existing JavaScript out there!<\/p>\nFor more details, see the original pull request<\/a>.<\/p>\nStricter Checks For The in<\/code> Operator<\/h2>\nIn JavaScript, it is a runtime error to use a non-object type on the right side of the in<\/code> operator.\nTypeScript 4.2 ensures this can be caught at design-time.<\/p>\n\"foo\" in 42\r\n\/\/ ~~\r\n\/\/ error! The right-hand side of an 'in' expression must not be a primitive.\r\n<\/code><\/pre>\nThis check is fairly conservative for the most part, so if you have received an error about this, it is likely an issue in the code.<\/p>\n
A big thanks to our external contributor Jonas H\u00fcbotter<\/a> for their pull request<\/a>!<\/p>\n--noPropertyAccessFromIndexSignature<\/code><\/h2>\nBack when TypeScript first introduced index signatures, you could only get properties declared by them with “bracketed” element access syntax like person[\"name\"]<\/code>.<\/p>\ninterface SomeType {\r\n \/** This is an index signature. *\/\r\n [propName: string]: any;\r\n}\r\n\r\nfunction doStuff(value: SomeType) {\r\n let x = value[\"someProperty\"];\r\n}\r\n<\/code><\/pre>\nThis ended up being cumbersome in situations where we need to work with objects that have arbitrary properties.\nFor example, imagine an API where it’s common to misspell a property name by adding an extra s<\/code> character at the end.<\/p>\ninterface Options {\r\n \/** File patterns to be excluded. *\/\r\n exclude?: string[];\r\n\r\n \/**\r\n * It handles any extra properties that we haven't declared as type 'any'.\r\n *\/\r\n [x: string]: any;\r\n}\r\n\r\nfunction processOptions(opts: Options) {\r\n \/\/ Notice we're *intentionally* accessing `excludes`, not `exclude`\r\n if (opts.excludes) {\r\n console.error(\"The option `excludes` is not valid. Did you mean `exclude`?\");\r\n }\r\n}\r\n<\/code><\/pre>\nTo make these types of situations easier, a while back, TypeScript made it possible to use “dotted” property access syntax like person.name<\/code> when a type had a string index signature.\nThis also made it easier to transition existing JavaScript code over to TypeScript.<\/p>\nHowever, loosening the restriction also meant that misspelling an explicitly declared property became much easier.<\/p>\n
function processOptions(opts: Options) {\r\n \/\/ ...\r\n\r\n \/\/ Notice we're *accidentally* accessing `excludes` this time.\r\n \/\/ Oops! Totally valid.\r\n for (const excludePattern of opts.excludes) {\r\n \/\/ ...\r\n }\r\n}\r\n<\/code><\/pre>\nIn some cases, users would prefer to explicitly opt into the index signature – they would prefer to get an error message when a dotted property access doesn’t correspond to a specific property declaration.<\/p>\n
That’s why TypeScript introduces a new flag called --noPropertyAccessFromIndexSignature<\/code>.\nUnder this mode, you’ll be opted in to TypeScript’s older behavior that issues an error.\nThis new setting is not under the strict<\/code> family of flags, since we believe users will find it more useful on certain codebases than others.<\/p>\nYou can understand this feature in more detail by reading up on the corresponding pull request<\/a>.\nWe’d also like to extend a big thanks to Wenlu Wang<\/a> who sent us this pull request!<\/p>\nabstract<\/code> Construct Signatures<\/h2>\nTypeScript allows us to mark a class as abstract<\/em>.\nThis tells TypeScript that the class is only meant to be extended from, and that certain members need to be filled in by any subclass to actually create an instance.<\/p>\nabstract class Shape {\r\n abstract getArea(): number;\r\n}\r\n\r\n\/\/ Error! Can't instantiate an abstract class.\r\nnew Shape();\r\n\r\nclass Square extends Shape {\r\n #sideLength: number;\r\n\r\n constructor(sideLength: number) {\r\n this.#sideLength = sideLength;\r\n }\r\n\r\n getArea() {\r\n return this.#sideLength ** 2;\r\n }\r\n}\r\n\r\n\/\/ Works fine.\r\nnew Square(42);\r\n<\/code><\/pre>\nTo make sure this restriction in new<\/code>-ing up abstract<\/code> classes is consistently applied, you can’t assign an abstract<\/code> class to anything that expects a construct signature.<\/p>\ninterface HasArea {\r\n getArea(): number;\r\n}\r\n\r\n\/\/ Error! Cannot assign an abstract constructor type to a non-abstract constructor type.\r\nlet Ctor: new () => HasArea = Shape;\r\n<\/code><\/pre>\nThis does the right thing in case we intend to run code like new Ctor<\/code>, but it’s overly-restrictive in case we want to write a subclass of Ctor<\/code>.<\/p>\nfuncton makeSubclassWithArea(Ctor: new () => HasArea) {\r\n return class extends Ctor {\r\n getArea() {\r\n \/\/ ...\r\n }\r\n }\r\n}\r\n\r\nlet MyShape = makeSubclassWithArea(Shape);\r\n<\/code><\/pre>\nIt also doesn’t work well with built-in helper types like InstanceType<\/code>.<\/p>\n\/\/ Error!\r\n\/\/ Type 'typeof Shape' does not satisfy the constraint 'new (...args: any) => any'.\r\n\/\/ Cannot assign an abstract constructor type to a non-abstract constructor type.\r\ntype MyInstance = InstanceType<typeof Shape>;\r\n<\/code><\/pre>\nThat’s why TypeScript 4.2 allows you to specify an abstract<\/code> modifier on constructor signatures.<\/p>\ninterface HasArea {\r\n getArea(): number;\r\n}\r\n\r\n\/\/ Works!\r\nlet Ctor: abstract new () => HasArea = Shape;\r\n\/\/ ^^^^^^^^\r\n<\/code><\/pre>\nAdding the abstract<\/code> modifier to a construct signature signals that you can pass in abstract<\/code> constructors.\nIt doesn’t stop you from passing in other classes\/constructor functions that are “concrete” – it really just signals that there’s no intent to run the constructor directly, so it’s safe to pass in either class type.<\/p>\nThis feature allows us to write mixin factories<\/em> in a way that supports abstract classes.\nFor example, in the following code snippet, we’re able to use the mixin function withStyles<\/code> with the abstract<\/code> class SuperClass<\/code>.<\/p>\nabstract class SuperClass {\r\n abstract someMethod(): void;\r\n badda() {}\r\n}\r\n\r\ntype AbstractConstructor<T> = abstract new (...args: any[]) => T\r\n\r\nfunction withStyles<T extends AbstractConstructor<object>>(Ctor: T) {\r\n abstract class StyledClass extends Ctor {\r\n getStyles() {\r\n \/\/ ...\r\n }\r\n }\r\n return StyledClass;\r\n}\r\n\r\nclass SubClass extends withStyles(SuperClass) {\r\n someMethod() {\r\n this.someMethod()\r\n }\r\n}\r\n<\/code><\/pre>\nNote that withStyles<\/code> is demonstrating a specific rule, where a class (like StyledClass<\/code>) that extends a value that’s generic and bounded by an abstract constructor (like Ctor<\/code>) has to also be declared abstract<\/code>.\nThis is because there’s no way to know if a class with more<\/em> abstract members was passed in, and so it’s impossible to know whether the subclass implements all the abstract members.<\/p>\nYou can read up more on abstract construct signatures on its pull request<\/a>.<\/p>\nUnderstanding Your Project Structure With --explainFiles<\/code><\/h2>\nA surprisingly common scenario for TypeScript users is to ask “why is TypeScript including this file?”.\nInferring the files of your program turns out to be a complicated process, and so there are lots of reasons why a specific combination of lib.d.ts<\/code> got used, why certain files in node_modules<\/code> are getting included, and why certain files are being included even though we thought specifying exclude<\/code> would keep them out.<\/p>\nThat’s why TypeScript now provides an --explainFiles<\/code> flag.<\/p>\ntsc --explainFiles\r\n<\/code><\/pre>\nWhen using this option, the TypeScript compiler will give some very verbose output about why a file ended up in your program.\nTo read it more easily, you can forward the output to a file, or pipe it to a program that can easily view it.<\/p>\n
# Forward output to a text file\r\ntsc --explainFiles > expanation.txt\r\n\r\n# Pipe output to a utility program like `less`, or an editor like VS Code\r\ntsc --explainFiles | less\r\n\r\ntsc --explainFiles | code -\r\n<\/code><\/pre>\nTypically, the output will start out by listing out reasons for including lib.d.ts<\/code> files, then for local files, and then node_modules<\/code> files.<\/p>\nTS_Compiler_Directory\/4.2.2\/lib\/lib.es5.d.ts\r\n Library referenced via 'es5' from file 'TS_Compiler_Directory\/4.2.2\/lib\/lib.es2015.d.ts'\r\nTS_Compiler_Directory\/4.2.2\/lib\/lib.es2015.d.ts\r\n Library referenced via 'es2015' from file 'TS_Compiler_Directory\/4.2.2\/lib\/lib.es2016.d.ts'\r\nTS_Compiler_Directory\/4.2.2\/lib\/lib.es2016.d.ts\r\n Library referenced via 'es2016' from file 'TS_Compiler_Directory\/4.2.2\/lib\/lib.es2017.d.ts'\r\nTS_Compiler_Directory\/4.2.2\/lib\/lib.es2017.d.ts\r\n Library referenced via 'es2017' from file 'TS_Compiler_Directory\/4.2.2\/lib\/lib.es2018.d.ts'\r\nTS_Compiler_Directory\/4.2.2\/lib\/lib.es2018.d.ts\r\n Library referenced via 'es2018' from file 'TS_Compiler_Directory\/4.2.2\/lib\/lib.es2019.d.ts'\r\nTS_Compiler_Directory\/4.2.2\/lib\/lib.es2019.d.ts\r\n Library referenced via 'es2019' from file 'TS_Compiler_Directory\/4.2.2\/lib\/lib.es2020.d.ts'\r\nTS_Compiler_Directory\/4.2.2\/lib\/lib.es2020.d.ts\r\n Library referenced via 'es2020' from file 'TS_Compiler_Directory\/4.2.2\/lib\/lib.esnext.d.ts'\r\nTS_Compiler_Directory\/4.2.2\/lib\/lib.esnext.d.ts\r\n Library 'lib.esnext.d.ts' specified in compilerOptions\r\n\r\n... More Library References...\r\n\r\nfoo.ts\r\n Matched by include pattern '**\/*' in 'tsconfig.json'\r\n<\/code><\/pre>\nRight now, we make no guarantees about the output format – it might change over time.\nOn that note, we’re interested in improving this format if you have any suggestions!<\/p>\n
For more information, check out the original pull request<\/a>!<\/p>\nImproved Uncalled Function Checks in Logical Expressions<\/h2>\n
Thanks to further improvements from Alex Tarasyuk<\/a>, TypeScript’s uncalled function checks now apply within &&<\/code> and ||<\/code> expressions.<\/p>\nUnder --strictNullChecks<\/code>, the following code will now error.<\/p>\nfunction shouldDisplayElement(element: Element) {\r\n \/\/ ...\r\n return true;\r\n}\r\n\r\nfunction getVisibleItems(elements: Element[]) {\r\n return elements.filter(e => shouldDisplayElement && e.children.length)\r\n \/\/ ~~~~~~~~~~~~~~~~~~~~\r\n \/\/ This condition will always return true since the function is always defined.\r\n \/\/ Did you mean to call it instead.\r\n}\r\n<\/code><\/pre>\nFor more details, check out the pull request here<\/a>.<\/p>\nDestructured Variables Can Be Explicitly Marked as Unused<\/h2>\n
Thanks to another pull request from Alex Tarasyuk<\/a>, you can now mark destructured variables as unused by prefixing them with an underscore (the _<\/code> character).<\/p>\nlet [_first, second] = getValues();\r\n<\/code><\/pre>\nPreviously, if _first<\/code> was never used later on, TypeScript would issue an error under noUnusedLocals<\/code>.\nNow, TypeScript will recognize that _first<\/code> was intentionally named with an underscore because there was no intent to use it.<\/p>\nFor more details, take a look at the full change<\/a>.<\/p>\nRelaxed Rules Between Optional Properties and String Index Signatures<\/h2>\n
String index signatures are a way of typing dictionary-like objects, where you want to allow access with arbitrary keys:<\/p>\n
const movieWatchCount: { [key: string]: number } = {};\r\n\r\nfunction watchMovie(title: string) {\r\n movieWatchCount[title] = (movieWatchCount[title] ?? 0) + 1;\r\n}\r\n<\/code><\/pre>\nOf course, for any movie title not yet in the dictionary, movieWatchCount[title]<\/code> will be undefined<\/code> (TypeScript 4.1 added the option --noUncheckedIndexedAccess<\/code><\/a> to include undefined<\/code> when reading from an index signature like this).\nEven though it’s clear that there must be some strings not present in movieWatchCount<\/code>, previous versions of TypeScript treated optional object properties as unassignable to otherwise compatible index signatures, due to the presence of undefined<\/code>.<\/p>\ntype WesAndersonWatchCount = {\r\n \"Fantastic Mr. Fox\"?: number;\r\n \"The Royal Tenenbaums\"?: number;\r\n \"Moonrise Kingdom\"?: number;\r\n \"The Grand Budapest Hotel\"?: number;\r\n};\r\n\r\ndeclare const wesAndersonWatchCount: WesAndersonWatchCount;\r\nconst movieWatchCount: { [key: string]: number } = wesAndersonWatchCount;\r\n\/\/ ~~~~~~~~~~~~~~~ error!\r\n\/\/ Type 'WesAndersonWatchCount' is not assignable to type '{ [key: string]: number; }'.\r\n\/\/ Property '\"Fantastic Mr. Fox\"' is incompatible with index signature.\r\n\/\/ Type 'number | undefined' is not assignable to type 'number'.\r\n\/\/ Type 'undefined' is not assignable to type 'number'. (2322)\r\n<\/code><\/pre>\nTypeScript 4.2 allows this assignment. However, it does not<\/em> allow the assignment of non-optional properties with undefined<\/code> in their types, nor does it allow writing undefined<\/code> to a specific key:<\/p>\ntype BatmanWatchCount = {\r\n \"Batman Begins\": number | undefined;\r\n \"The Dark Knight\": number | undefined;\r\n \"The Dark Knight Rises\": number | undefined;\r\n};\r\n\r\ndeclare const batmanWatchCount: BatmanWatchCount;\r\n\r\n\/\/ Still an error in TypeScript 4.2.\r\n\/\/ `undefined` is only ignored when properties are marked optional.\r\nconst movieWatchCount: { [key: string]: number } = batmanWatchCount;\r\n\r\n\/\/ Still an error in TypeScript 4.2.\r\n\/\/ Index signatures don't implicitly allow explicit `undefined`.\r\nmovieWatchCount[\"It's the Great Pumpkin, Charlie Brown\"] = undefined;\r\n<\/code><\/pre>\nThe new rule also does not apply to number index signatures, since they are assumed to be array-like and dense:<\/p>\n
declare let sortOfArrayish: { [key: number]: string };\r\ndeclare let numberKeys: { 42?: string };\r\n\r\n\/\/ Error! Type '{ 42?: string | undefined; }' is not assignable to type '{ [key: number]: string; }'.\r\nsortOfArrayish = numberKeys;\r\n<\/code><\/pre>\nYou can get a better sense of this change by reading up on the original PR<\/a>.<\/p>\nDeclare Missing Helper Function<\/h2>\n
Thanks to a community pull request<\/a> from Alexander Tarasyuk<\/a>, we now have a quick fix for declaring new functions and methods based on the call-site!<\/p>\n![\"An](\"https:\/\/devblogs.microsoft.com\/typescript\/wp-content\/uploads\/sites\/11\/2021\/01\/addMissingFunction-4.2.gif\")
<\/p>\n
Breaking Changes<\/h2>\n
We always strive to minimize breaking changes in a release.\nTypeScript 4.2 contains some breaking changes, but we believe they should be manageable in an upgrade.<\/p>\n
lib.d.ts<\/code> Updates<\/h3>\nAs with every TypeScript version, declarations for lib.d.ts<\/code> (especially the declarations generated for web contexts), have changed.\nThere are various changes, though Intl<\/code> and ResizeObserver<\/code>‘s may end up being the most disruptive.<\/p>\nnoImplicitAny<\/code> Errors Apply to Loose yield<\/code> Expressions<\/h3>\nWhen the value of a yield<\/code> expression is captured, but TypeScript can’t immediately figure out what type you intend for it to receive (i.e. the yield<\/code> expression isn’t contextually typed), TypeScript will now issue an implicit any<\/code> error.<\/p>\nfunction* g1() {\r\n const value = yield 1;\r\n \/\/ ~~~~~~~\r\n \/\/ Error!\r\n \/\/ 'yield' expression implicitly results in an 'any' type\r\n \/\/ because its containing generator lacks a return-type annotation.\r\n}\r\n\r\nfunction* g2() {\r\n \/\/ No error.\r\n \/\/ The result of `yield 1` is unused.\r\n yield 1;\r\n}\r\n\r\nfunction* g3() {\r\n \/\/ No error.\r\n \/\/ `yield 1` is contextually typed by 'string'.\r\n const value: string = yield 1;\r\n}\r\n\r\nfunction* g3(): Generator<number, void, string> {\r\n \/\/ No error.\r\n \/\/ TypeScript can figure out the type of `yield 1`\r\n \/\/ from the explicit return type of `g3`.\r\n const value = yield 1;\r\n}\r\n<\/code><\/pre>\nSee more details in the corresponding changes<\/a>.<\/p>\nExpanded Uncalled Function Checks<\/h3>\n
As described above, uncalled function checks will now operate consistently within &&<\/code> and ||<\/code> expressions when using --strictNullChecks<\/code>.\nThis can be a source of new breaks, but is typically an indication of a logic error in existing code.<\/p>\nType Arguments in JavaScript Are Not Parsed as Type Arguments<\/h3>\n
Type arguments were already not allowed in JavaScript, but in TypeScript 4.2, the parser will parse them in a more spec-compliant way.\nSo when writing the following code in a JavaScript file:<\/p>\n
f<T>(100)\r\n<\/code><\/pre>\nTypeScript will parse it as the following JavaScript:<\/p>\n
(f < T) > (100)\r\n<\/code><\/pre>\nThis may impact you if you were leveraging TypeScript’s API to parse type constructs in JavaScript files, which may have occurred when trying to parse Flow files.<\/p>\n
The in<\/code> Operator No Longer Allows Primitive Types on the Right Side<\/h3>\nAs mentioned, it is an error to use a primitive on the right side of an in<\/code> operator, and TypeScript 4.2 is stricter about this sort of code.<\/p>\n\"foo\" in 42\r\n\/\/ ~~\r\n\/\/ error! The right-hand side of an 'in' expression must not be a primitive.\r\n<\/code><\/pre>\n