Optional chaining is issue #16 on our issue tracker. For context, there have been over 23,000 issues on the TypeScript issue tracker since then.
\nAt its core, optional chaining lets us write code where TypeScript can immediately stop running some expressions if we run into a null or undefined.\nThe star of the show in optional chaining is the new ?. operator for optional property accesses.\nWhen we write code like
\ntslet x = foo?.bar.baz();
this is a way of saying that when foo is defined, foo.bar.baz() will be computed; but when foo is null or undefined, stop what we’re doing and just return undefined.”
More plainly, that code snippet is the same as writing the following.
\n\ntslet x = foo === null || foo === undefined ? undefined : foo.bar.baz();
Note that if bar is null or undefined, our code will still hit an error accessing baz.\nLikewise, if baz is null or undefined, we’ll hit an error at the call site.\n?. only checks for whether the value on the left of it is null or undefined - not any of the subsequent properties.
You might find yourself using ?. to replace a lot of code that performs repetitive nullish checks using the && operator.
\nts// Before\nif (foo && foo.bar && foo.bar.baz) {\n // ...\n}\n\n// After-ish\nif (foo?.bar?.baz) {\n // ...\n}
Keep in mind that ?. acts differently than those && operations since && will act specially on “falsy” values (e.g. the empty string, 0, NaN, and, well, false), but this is an intentional feature of the construct.\nIt doesn’t short-circuit on valid data like 0 or empty strings.
Optional chaining also includes two other operations.\nFirst there’s the optional element access which acts similarly to optional property accesses, but allows us to access non-identifier properties (e.g. arbitrary strings, numbers, and symbols):
\n\nts/**\n * Get the first element of the array if we have an array.\n * Otherwise return undefined.\n */\nfunction tryGetFirstElement<T>(arr?: T[]) {\n return arr?.[0];\n // equivalent to\n // return (arr === null || arr === undefined) ?\n // undefined :\n // arr[0];\n}
There’s also optional call, which allows us to conditionally call expressions if they’re not null or undefined.
\ntsasync function makeRequest(url: string, log?: (msg: string) => void) {\n log?.(`Request started at ${new Date().toISOString()}`);\n // roughly equivalent to\n // if (log != null) {\n // log(`Request started at ${new Date().toISOString()}`);\n // }\n\n const result = (await fetch(url)).json();\n\n log?.(`Request finished at at ${new Date().toISOString()}`);\n\n return result;\n}
The “short-circuiting” behavior that optional chains have is limited property accesses, calls, element accesses - it doesn’t expand any further out from these expressions.\nIn other words,
\n\ntslet result = foo?.bar / someComputation();
doesn’t stop the division or someComputation() call from occurring.\nIt’s equivalent to
\ntslet temp = foo === null || foo === undefined ? undefined : foo.bar;\n\nlet result = temp / someComputation();
That might result in dividing undefined, which is why in strictNullChecks, the following is an error.
\ntsfunction barPercentage(foo?: { bar: number }) {\n return foo?.bar / 100;\n // ~~~~~~~~\n // Error: Object is possibly undefined.\n}
More more details, you can read up on the proposal and view the original pull request.
\nThe nullish coalescing operator is another upcoming ECMAScript feature that goes hand-in-hand with optional chaining, and which our team has been involved with championing in TC39.
\nYou can think of this feature - the ?? operator - as a way to “fall back” to a default value when dealing with null or undefined.\nWhen we write code like
\ntslet x = foo ?? bar();
this is a new way to say that the value foo will be used when it’s “present”;\nbut when it’s null or undefined, calculate bar() in its place.
Again, the above code is equivalent to the following.
\n\ntslet x = foo !== null && foo !== undefined ? foo : bar();
The ?? operator can replace uses of || when trying to use a default value.\nFor example, the following code snippet tries to fetch the volume that was last saved in localStorage (if it ever was);\nhowever, it has a bug because it uses ||.
\ntsfunction initializeAudio() {\n let volume = localStorage.volume || 0.5;\n\n // ...\n}
When localStorage.volume is set to 0, the page will set the volume to 0.5 which is unintended.\n?? avoids some unintended behavior from 0, NaN and \"\" being treated as falsy values.
We owe a large thanks to community members Wenlu Wang and Titian Cernicova Dragomir for implementing this feature!\nFor more details, check out their pull request and the nullish coalescing proposal repository.
\nThere’s a specific set of functions that throw an error if something unexpected happened.\nThey’re called “assertion” functions.\nAs an example, Node.js has a dedicated function for this called assert.
\njsassert(someValue === 42);
In this example if someValue isn’t equal to 42, then assert will throw an AssertionError.
Assertions in JavaScript are often used to guard against improper types being passed in.\nFor example,
\n\njsfunction multiply(x, y) {\n assert(typeof x === \"number\");\n assert(typeof y === \"number\");\n\n return x * y;\n}
Unfortunately in TypeScript these checks could never be properly encoded.\nFor loosely-typed code this meant TypeScript was checking less, and for slightly conservative code it often forced users to use type assertions.
\n\ntsfunction yell(str) {\n assert(typeof str === \"string\");\n\n return str.toUppercase();\n // Oops! We misspelled 'toUpperCase'.\n // Would be great if TypeScript still caught this!\n}
The alternative was to instead rewrite the code so that the language could analyze it, but this isn’t convenient.
\n\ntsfunction yell(str) {\n if (typeof str !== \"string\") {\n throw new TypeError(\"str should have been a string.\");\n }\n // Error caught!\n return str.toUppercase();\n}
Ultimately the goal of TypeScript is to type existing JavaScript constructs in the least disruptive way.\nFor that reason, TypeScript 3.7 introduces a new concept called “assertion signatures” which model these assertion functions.
\nThe first type of assertion signature models the way that Node’s assert function works.\nIt ensures that whatever condition is being checked must be true for the remainder of the containing scope.
\ntsfunction assert(condition: any, msg?: string): asserts condition {\n if (!condition) {\n throw new AssertionError(msg);\n }\n}
asserts condition says that whatever gets passed into the condition parameter must be true if the assert returns (because otherwise it would throw an error).\nThat means that for the rest of the scope, that condition must be truthy.\nAs an example, using this assertion function means we do catch our original yell example.
\ntsfunction yell(str) {\n assert(typeof str === \"string\");\n\n return str.toUppercase();\n // ~~~~~~~~~~~\n // error: Property 'toUppercase' does not exist on type 'string'.\n // Did you mean 'toUpperCase'?\n}\n\nfunction assert(condition: any, msg?: string): asserts condition {\n if (!condition) {\n throw new AssertionError(msg);\n }\n}
The other type of assertion signature doesn’t check for a condition, but instead tells TypeScript that a specific variable or property has a different type.
\n\ntsfunction assertIsString(val: any): asserts val is string {\n if (typeof val !== \"string\") {\n throw new AssertionError(\"Not a string!\");\n }\n}
Here asserts val is string ensures that after any call to assertIsString, any variable passed in will be known to be a string.
\ntsfunction yell(str: any) {\n assertIsString(str);\n\n // Now TypeScript knows that 'str' is a 'string'.\n\n return str.toUppercase();\n // ~~~~~~~~~~~\n // error: Property 'toUppercase' does not exist on type 'string'.\n // Did you mean 'toUpperCase'?\n}
These assertion signatures are very similar to writing type predicate signatures:
\n\ntsfunction isString(val: any): val is string {\n return typeof val === \"string\";\n}\n\nfunction yell(str: any) {\n if (isString(str)) {\n return str.toUppercase();\n }\n throw \"Oops!\";\n}
And just like type predicate signatures, these assertion signatures are incredibly expressive.\nWe can express some fairly sophisticated ideas with these.
\n\ntsfunction assertIsDefined<T>(val: T): asserts val is NonNullable<T> {\n if (val === undefined || val === null) {\n throw new AssertionError(\n `Expected 'val' to be defined, but received ${val}`\n );\n }\n}
To read up more about assertion signatures, check out the original pull request.
\nnever-Returning FunctionsAs part of the work for assertion signatures, TypeScript needed to encode more about where and which functions were being called.\nThis gave us the opportunity to expand support for another class of functions: functions that return never.
The intent of any function that returns never is that it never returns.\nIt indicates that an exception was thrown, a halting error condition occurred, or that the program exited.\nFor example, process.exit(...) in @types/node is specified to return never.
In order to ensure that a function never potentially returned undefined or effectively returned from all code paths, TypeScript needed some syntactic signal - either a return or throw at the end of a function.\nSo users found themselves return-ing their failure functions.
\ntsfunction dispatch(x: string | number): SomeType {\n if (typeof x === \"string\") {\n return doThingWithString(x);\n } else if (typeof x === \"number\") {\n return doThingWithNumber(x);\n }\n return process.exit(1);\n}
Now when these never-returning functions are called, TypeScript recognizes that they affect the control flow graph and accounts for them.
\ntsfunction dispatch(x: string | number): SomeType {\n if (typeof x === \"string\") {\n return doThingWithString(x);\n } else if (typeof x === \"number\") {\n return doThingWithNumber(x);\n }\n process.exit(1);\n}
As with assertion functions, you can read up more at the same pull request.
\nType aliases have always had a limitation in how they could be “recursively” referenced.\nThe reason is that any use of a type alias needs to be able to substitute itself with whatever it aliases.\nIn some cases, that’s not possible, so the compiler rejects certain recursive aliases like the following:
\n\ntstype Foo = Foo;
This is a reasonable restriction because any use of Foo would need to be replaced with Foo which would need to be replaced with Foo which would need to be replaced with Foo which… well, hopefully you get the idea!\nIn the end, there isn’t a type that makes sense in place of Foo.
This is fairly consistent with how other languages treat type aliases, but it does give rise to some slightly surprising scenarios for how users leverage the feature.\nFor example, in TypeScript 3.6 and prior, the following causes an error.
\n\ntstype ValueOrArray<T> = T | Array<ValueOrArray<T>>;\n// ~~~~~~~~~~~~\n// error: Type alias 'ValueOrArray' circularly references itself.
This is strange because there is technically nothing wrong with any use users could always write what was effectively the same code by introducing an interface.
\n\ntstype ValueOrArray<T> = T | ArrayOfValueOrArray<T>;\n\ninterface ArrayOfValueOrArray<T> extends Array<ValueOrArray<T>> {}
Because interfaces (and other object types) introduce a level of indirection and their full structure doesn’t need to be eagerly built out, TypeScript has no problem working with this structure.
\nBut workaround of introducing the interface wasn’t intuitive for users.\nAnd in principle there really wasn’t anything wrong with the original version of ValueOrArray that used Array directly.\nIf the compiler was a little bit “lazier” and only calculated the type arguments to Array when necessary, then TypeScript could express these correctly.
That’s exactly what TypeScript 3.7 introduces.\nAt the “top level” of a type alias, TypeScript will defer resolving type arguments to permit these patterns.
\nThis means that code like the following that was trying to represent JSON…
\n\ntstype Json = string | number | boolean | null | JsonObject | JsonArray;\n\ninterface JsonObject {\n [property: string]: Json;\n}\n\ninterface JsonArray extends Array<Json> {}
can finally be rewritten without helper interfaces.
\n\ntstype Json =\n | string\n | number\n | boolean\n | null\n | { [property: string]: Json }\n | Json[];
This new relaxation also lets us recursively reference type aliases in tuples as well.\nThe following code which used to error is now valid TypeScript code.
\n\ntstype VirtualNode = string | [string, { [key: string]: any }, ...VirtualNode[]];\n\nconst myNode: VirtualNode = [\n \"div\",\n { id: \"parent\" },\n [\"div\", { id: \"first-child\" }, \"I'm the first child\"],\n [\"div\", { id: \"second-child\" }, \"I'm the second child\"]\n];
For more information, you can read up on the original pull request.
\n--declaration and --allowJsThe --declaration flag in TypeScript allows us to generate .d.ts files (declaration files) from TypeScript source files (i.e. .ts and .tsx files).\nThese .d.ts files are important for a couple of reasons.
First of all, they’re important because they allow TypeScript to type-check against other projects without re-checking the original source code.\nThey’re also important because they allow TypeScript to interoperate with existing JavaScript libraries that weren’t built with TypeScript in mind.\nFinally, a benefit that is often underappreciated: both TypeScript and JavaScript users can benefit from these files when using editors powered by TypeScript to get things like better auto-completion.
\nUnfortunately, --declaration didn’t work with the --allowJs flag which allows mixing TypeScript and JavaScript input files.\nThis was a frustrating limitation because it meant users couldn’t use the --declaration flag when migrating codebases, even if they were JSDoc-annotated.\nTypeScript 3.7 changes that, and allows the two options to be used together!
The most impactful outcome of this feature might a bit subtle: with TypeScript 3.7, users can write libraries in JSDoc annotated JavaScript and support TypeScript users.
\nThe way that this works is that when using allowJs, TypeScript has some best-effort analyses to understand common JavaScript patterns; however, the way that some patterns are expressed in JavaScript don’t necessarily look like their equivalents in TypeScript.\nWhen declaration emit is turned on, TypeScript figures out the best way to transform JSDoc comments and CommonJS exports into valid type declarations and the like in the output .d.ts files.
As an example, the following code snippet
\n\njsconst assert = require(\"assert\");\n\nmodule.exports.blurImage = blurImage;\n\n/**\n * Produces a blurred image from an input buffer.\n *\n * @param input {Uint8Array}\n * @param width {number}\n * @param height {number}\n */\nfunction blurImage(input, width, height) {\n const numPixels = width * height * 4;\n assert(input.length === numPixels);\n const result = new Uint8Array(numPixels);\n\n // TODO\n\n return result;\n}
Will produce a .d.ts file like
\nts/**\n * Produces a blurred image from an input buffer.\n *\n * @param input {Uint8Array}\n * @param width {number}\n * @param height {number}\n */\nexport function blurImage(\n input: Uint8Array,\n width: number,\n height: number\n): Uint8Array;
This can go beyond basic functions with @param tags too, where the following example:
\njs/**\n * @callback Job\n * @returns {void}\n */\n\n/** Queues work */\nexport class Worker {\n constructor(maxDepth = 10) {\n this.started = false;\n this.depthLimit = maxDepth;\n /**\n * NOTE: queued jobs may add more items to queue\n * @type {Job[]}\n */\n this.queue = [];\n }\n /**\n * Adds a work item to the queue\n * @param {Job} work\n */\n push(work) {\n if (this.queue.length + 1 > this.depthLimit) throw new Error(\"Queue full!\");\n this.queue.push(work);\n }\n /**\n * Starts the queue if it has not yet started\n */\n start() {\n if (this.started) return false;\n this.started = true;\n while (this.queue.length) {\n /** @type {Job} */ (this.queue.shift())();\n }\n return true;\n }\n}
will be transformed into the following .d.ts file:
\nts/**\n * @callback Job\n * @returns {void}\n */\n/** Queues work */\nexport class Worker {\n constructor(maxDepth?: number);\n started: boolean;\n depthLimit: number;\n /**\n * NOTE: queued jobs may add more items to queue\n * @type {Job[]}\n */\n queue: Job[];\n /**\n * Adds a work item to the queue\n * @param {Job} work\n */\n push(work: Job): void;\n /**\n * Starts the queue if it has not yet started\n */\n start(): boolean;\n}\nexport type Job = () => void;
Note that when using these flags together, TypeScript doesn’t necessarily have to downlevel .js files.\nIf you simply want TypeScript to create .d.ts files, you can use the --emitDeclarationOnly compiler option.
For more details, you can check out the original pull request.
\nuseDefineForClassFields Flag and The declare Property ModifierBack when TypeScript implemented public class fields, we assumed to the best of our abilities that the following code
\n\ntsclass C {\n foo = 100;\n bar: string;\n}
would be equivalent to a similar assignment within a constructor body.
\n\ntsclass C {\n constructor() {\n this.foo = 100;\n }\n}
Unfortunately, while this seemed to be the direction that the proposal moved towards in its earlier days, there is an extremely strong chance that public class fields will be standardized differently.\nInstead, the original code sample might need to de-sugar to something closer to the following:
\n\ntsclass C {\n constructor() {\n Object.defineProperty(this, \"foo\", {\n enumerable: true,\n configurable: true,\n writable: true,\n value: 100\n });\n Object.defineProperty(this, \"bar\", {\n enumerable: true,\n configurable: true,\n writable: true,\n value: void 0\n });\n }\n}
While TypeScript 3.7 isn’t changing any existing emit by default, we’ve been rolling out changes incrementally to help users mitigate potential future breakage.\nWe’ve provided a new flag called useDefineForClassFields to enable this emit mode with some new checking logic.
The two biggest changes are the following:
\nObject.defineProperty.undefined, even if they have no initializer.This can cause quite a bit of fallout for existing code that use inheritance. First of all, set accessors from base classes won’t get triggered - they’ll be completely overwritten.
\ntsclass Base {\n set data(value: string) {\n console.log(\"data changed to \" + value);\n }\n}\n\nclass Derived extends Base {\n // No longer triggers a 'console.log'\n // when using 'useDefineForClassFields'.\n data = 10;\n}
Secondly, using class fields to specialize properties from base classes also won’t work.
\n\ntsinterface Animal {\n animalStuff: any;\n}\ninterface Dog extends Animal {\n dogStuff: any;\n}\n\nclass AnimalHouse {\n resident: Animal;\n constructor(animal: Animal) {\n this.resident = animal;\n }\n}\n\nclass DogHouse extends AnimalHouse {\n // Initializes 'resident' to 'undefined'\n // after the call to 'super()' when\n // using 'useDefineForClassFields'!\n resident: Dog;\n\n constructor(dog: Dog) {\n super(dog);\n }\n}
What these two boil down to is that mixing properties with accessors is going to cause issues, and so will re-declaring properties with no initializers.
\nTo detect the issue around accessors, TypeScript 3.7 will now emit get/set accessors in .d.ts files so that in TypeScript can check for overridden accessors.
Code that’s impacted by the class fields change can get around the issue by converting field initializers to assignments in constructor bodies.
\n\ntsclass Base {\n set data(value: string) {\n console.log(\"data changed to \" + value);\n }\n}\n\nclass Derived extends Base {\n constructor() {\n data = 10;\n }\n}
To help mitigate the second issue, you can either add an explicit initializer or add a declare modifier to indicate that a property should have no emit.
\ntsinterface Animal {\n animalStuff: any;\n}\ninterface Dog extends Animal {\n dogStuff: any;\n}\n\nclass AnimalHouse {\n resident: Animal;\n constructor(animal: Animal) {\n this.resident = animal;\n }\n}\n\nclass DogHouse extends AnimalHouse {\n declare resident: Dog;\n // ^^^^^^^\n // 'resident' now has a 'declare' modifier,\n // and won't produce any output code.\n\n constructor(dog: Dog) {\n super(dog);\n }\n}
Currently useDefineForClassFields is only available when targeting ES5 and upwards, since Object.defineProperty doesn’t exist in ES3.\nTo achieve similar checking for issues, you can create a seperate project that targets ES5 and uses --noEmit to avoid a full build.
For more information, you can take a look at the original pull request for these changes.
\nWe strongly encourage users to try the useDefineForClassFields flag and report back on our issue tracker or in the comments below.\nThis includes feedback on difficulty of adopting the flag so we can understand how we can make migration easier.
TypeScript’s project references provide us with an easy way to break codebases up to give us faster compiles.\nUnfortunately, editing a project whose dependencies hadn’t been built (or whose output was out of date) meant that the editing experience wouldn’t work well.
\nIn TypeScript 3.7, when opening a project with dependencies, TypeScript will automatically use the source .ts/.tsx files instead.\nThis means projects using project references will now see an improved editing experience where semantic operations are up-to-date and “just work”.\nYou can disable this behavior with the compiler option disableSourceOfProjectReferenceRedirect which may be appropriate when working in very large projects where this change may impact editing performance.
You can read up more about this change by reading up on its pull request.
\nA common and dangerous error is to forget to invoke a function, especially if the function has zero arguments or is named in a way that implies it might be a property rather than a function.
\n\ntsinterface User {\n isAdministrator(): boolean;\n notify(): void;\n doNotDisturb?(): boolean;\n}\n\n// later...\n\n// Broken code, do not use!\nfunction doAdminThing(user: User) {\n // oops!\n if (user.isAdministrator) {\n sudo();\n editTheConfiguration();\n } else {\n throw new AccessDeniedError(\"User is not an admin\");\n }\n}
Here, we forgot to call isAdministrator, and the code incorrectly allows non-adminstrator users to edit the configuration!
In TypeScript 3.7, this is identified as a likely error:
\n\ntsfunction doAdminThing(user: User) {\n if (user.isAdministrator) {\n // ~~~~~~~~~~~~~~~~~~~~\n // error! This condition will always return true since the function is always defined.\n // Did you mean to call it instead?
This check is a breaking change, but for that reason the checks are very conservative.\nThis error is only issued in if conditions, and it is not issued on optional properties, if strictNullChecks is off, or if the function is later called within the body of the if:
\ntsinterface User {\n isAdministrator(): boolean;\n notify(): void;\n doNotDisturb?(): boolean;\n}\n\nfunction issueNotification(user: User) {\n if (user.doNotDisturb) {\n // OK, property is optional\n }\n if (user.notify) {\n // OK, called the function\n user.notify();\n }\n}
If you intended to test the function without calling it, you can correct the definition of it to include undefined/null, or use !! to write something like if (!!user.isAdministrator) to indicate that the coercion is intentional.
We owe a big thanks to GitHub user @jwbay who took the initiative to create a proof-of-concept and iterated to provide us with with the current version.
\n// @ts-nocheck in TypeScript FilesTypeScript 3.7 allows us to add // @ts-nocheck comments to the top of TypeScript files to disable semantic checks.\nHistorically this comment was only respected in JavaScript source files in the presence of checkJs, but we’ve expanded support to TypeScript files to make migrations easier for all users.
TypeScript’s built-in formatter now supports semicolon insertion and removal at locations where a trailing semicolon is optional due to JavaScript’s automatic semicolon insertion (ASI) rules. The setting is available now in Visual Studio Code Insiders, and will be available in Visual Studio 16.4 Preview 2 in the Tools Options menu.
\n![\"New](\"https://user-images.githubusercontent.com/3277153/65913194-10066e80-e395-11e9-8a3a-4f7305c397d5.png\")
\nChoosing a value of “insert” or “remove” also affects the format of auto-imports, extracted types, and other generated code provided by TypeScript services. Leaving the setting on its default value of “ignore” makes generated code match the semicolon preference detected in the current file.
\nTypes in lib.dom.d.ts have been updated.\nThese changes are largely correctness changes related to nullability, but impact will ultimately depend on your codebase.
As mentioned above, TypeScript 3.7 emits get/set accessors in .d.ts files which can cause breaking changes for consumers on older versions of TypeScript like 3.5 and prior.\nTypeScript 3.6 users will not be impacted, since that version was future-proofed for this feature.
While not a breakage per se, opting in to the useDefineForClassFields flag can cause breakage when:
To understand the full impact, read the section above on the useDefineForClassFields flag.
As mentioned above, TypeScript now errors when functions appear to be uncalled within if statement conditions.\nAn error is issued when a function type is checked in if conditions unless any of the following apply:
strictNullChecks is disabledifDue to a bug, the following construct was previously allowed in TypeScript:
\n\nts// ./someOtherModule.ts\ninterface SomeType {\n y: string;\n}\n\n// ./myModule.ts\nimport { SomeType } from \"./someOtherModule\";\nexport interface SomeType {\n x: number;\n}\n\nfunction fn(arg: SomeType) {\n console.log(arg.x); // Error! 'x' doesn't exist on 'SomeType'\n}
Here, SomeType appears to originate in both the import declaration and the local interface declaration.\nPerhaps surprisingly, inside the module, SomeType refers exclusively to the imported definition, and the local declaration SomeType is only usable when imported from another file.\nThis is very confusing and our review of the very small number of cases of code like this in the wild showed that developers usually thought something different was happening.
In TypeScript 3.7, this is now correctly identified as a duplicate identifier error.\nThe correct fix depends on the original intent of the author and should be addressed on a case-by-case basis.\nUsually, the naming conflict is unintentional and the best fix is to rename the imported type.\nIf the intent was to augment the imported type, a proper module augmentation should be written instead.
\nTo enable the recursive type alias patterns described above, the typeArguments property has been removed from the TypeReference interface. Users should instead use the getTypeArguments function on TypeChecker instances.