TypeScript 2.7 adds support for declaring const-named properties on types including ECMAScript symbols.
\n\nts// Lib\nexport const SERIALIZE = Symbol(\"serialize-method-key\");\n\nexport interface Serializable {\n [SERIALIZE](obj: {}): string;\n}
\nts// consumer\n\nimport { SERIALIZE, Serializable } from \"lib\";\n\nclass JSONSerializableItem implements Serializable {\n [SERIALIZE](obj: {}) {\n return JSON.stringify(obj);\n }\n}
This also applies to numeric and string literals.
\n\ntsconst Foo = \"Foo\";\nconst Bar = \"Bar\";\n\nlet x = {\n [Foo]: 100,\n [Bar]: \"hello\",\n};\n\nlet a = x[Foo]; // has type 'number'\nlet b = x[Bar]; // has type 'string'
unique symbolTo enable treating symbols as unique literals a new type unique symbol is available.\nunique symbol is a subtype of symbol, and are produced only from calling Symbol() or Symbol.for(), or from explicit type annotations.\nThe new type is only allowed on const declarations and readonly static properties, and in order to reference a specific unique symbol, you’ll have to use the typeof operator.\nEach reference to a unique symbol implies a completely unique identity that’s tied to a given declaration.
\nts// Works\ndeclare const Foo: unique symbol;\n\n// Error! 'Bar' isn't a constant.\nlet Bar: unique symbol = Symbol();\n\n// Works - refers to a unique symbol, but its identity is tied to 'Foo'.\nlet Baz: typeof Foo = Foo;\n\n// Also works.\nclass C {\n static readonly StaticSymbol: unique symbol = Symbol();\n}
Because each unique symbol has a completely separate identity, no two unique symbol types are assignable or comparable to each other.
\ntsconst Foo = Symbol();\nconst Bar = Symbol();\n\n// Error: can't compare two unique symbols.\nif (Foo === Bar) {\n // ...\n}
TypeScript 2.7 introduces a new flag called --strictPropertyInitialization.\nThis flag performs checks to ensure that each instance property of a class gets initialized in the constructor body, or by a property initializer.\nFor example
\ntsclass C {\n foo: number;\n bar = \"hello\";\n baz: boolean;\n// ~~~\n// Error! Property 'baz' has no initializer and is not definitely assigned in the\n// constructor.\n\n constructor() {\n this.foo = 42;\n }\n}
In the above, if we truly meant for baz to potentially be undefined, we should have declared it with the type boolean | undefined.
There are certain scenarios where properties can be initialized indirectly (perhaps by a helper method or dependency injection library), in which case you can use the new definite assignment assertion modifiers for your properties (discussed below).
\n\ntsclass C {\n foo!: number;\n // ^\n // Notice this '!' modifier.\n // This is the \"definite assignment assertion\"\n\n constructor() {\n this.initialize();\n }\n\n initialize() {\n this.foo = 0;\n }\n}
Keep in mind that --strictPropertyInitialization will be turned on along with other --strict mode flags, which can impact your project.\nYou can set the strictPropertyInitialization setting to false in your tsconfig.json’s compilerOptions, or --strictPropertyInitialization false on the command line to turn off this checking.
The definite assignment assertion is a feature that allows a ! to be placed after instance property and variable declarations to relay to TypeScript that a variable is indeed assigned for all intents and purposes, even if TypeScript’s analyses cannot detect so.
\ntslet x: number;\ninitialize();\nconsole.log(x + x);\n// ~ ~\n// Error! Variable 'x' is used before being assigned.\n\nfunction initialize() {\n x = 10;\n}
With definite assignment assertions, we can assert that x is really assigned by appending an ! to its declaration:
\nts// Notice the '!'\nlet x!: number;\ninitialize();\n\n// No error!\nconsole.log(x + x);\n\nfunction initialize() {\n x = 10;\n}
In a sense, the definite assignment assertion operator is the dual of the non-null assertion operator (in which expressions are post-fixed with a !), which we could also have used in the example.
\ntslet x: number;\ninitialize();\n\n// No error!\nconsole.log(x! + x!);\n\nfunction initialize() {\n x = 10;
In our example, we knew that all uses of x would be initialized so it makes more sense to use definite assignment assertions than non-null assertions.
In TypeScript 2.6 and earlier, [number, string, string] was considered a subtype of [number, string].\nThis was motivated by TypeScript’s structural nature; the first and second elements of a [number, string, string] are respectively subtypes of the first and second elements of [number, string].\nHowever, after examining real world usage of tuples, we noticed that most situations in which this was permitted was typically undesirable.
In TypeScript 2.7, tuples of different arities are no longer assignable to each other.\nThanks to a pull request from Tycho Grouwstra, tuple types now encode their arity into the type of their respective length property.\nThis is accomplished by leveraging numeric literal types, which now allow tuples to be distinct from tuples of different arities.
Conceptually, you might consider the type [number, string] to be equivalent to the following declaration of NumStrTuple:
\ntsinterface NumStrTuple extends Array<number | string> {\n 0: number;\n 1: string;\n length: 2; // using the numeric literal type '2'\n}
Note that this is a breaking change for some code.\nIf you need to resort to the original behavior in which tuples only enforce a minimum length, you can use a similar declaration that does not explicitly define a length property, falling back to number.
\ntsinterface MinimumNumStrTuple extends Array<number | string> {\n 0: number;\n 1: string;\n}
Note that this does not imply tuples represent immutable arrays, but it is an implied convention.
\nTypeScript 2.7 improves type inference for multiple object literals occurring in the same context.\nWhen multiple object literal types contribute to a union type, we now normalize the object literal types such that all properties are present in each constituent of the union type.
\nConsider:
\n\ntsconst obj = test ? { text: \"hello\" } : {}; // { text: string } | { text?: undefined }\nconst s = obj.text; // string | undefined
Previously type {} was inferred for obj and the second line subsequently caused an error because obj would appear to have no properties.\nThat obviously wasn’t ideal.
\nts// let obj: { a: number, b: number } |\n// { a: string, b?: undefined } |\n// { a?: undefined, b?: undefined }\nlet obj = [{ a: 1, b: 2 }, { a: \"abc\" }, {}][0];\nobj.a; // string | number | undefined\nobj.b; // number | undefined
Multiple object literal type inferences for the same type parameter are similarly collapsed into a single normalized union type:
\n\ntsdeclare function f<T>(...items: T[]): T;\n// let obj: { a: number, b: number } |\n// { a: string, b?: undefined } |\n// { a?: undefined, b?: undefined }\nlet obj = f({ a: 1, b: 2 }, { a: \"abc\" }, {});\nobj.a; // string | number | undefined\nobj.b; // number | undefined
instanceof expressionsTypeScript 2.7 improves the handling of structurally identical classes in union types and instanceof expressions:
instanceof operator is now based on whether the type of the left operand derives from the type indicated by the right operand (as opposed to a structural subtype check).This means that union types and instanceof properly distinguish between structurally identical classes.
\ntsclass A {}\nclass B extends A {}\nclass C extends A {}\nclass D extends A { c: string }\nclass E extends D {}\n\nlet x1 = !true ? new A() : new B(); // A\nlet x2 = !true ? new B() : new C(); // B | C (previously B)\nlet x3 = !true ? new C() : new D(); // C | D (previously C)\n\nlet a1 = [new A(), new B(), new C(), new D(), new E()]; // A[]\nlet a2 = [new B(), new C(), new D(), new E()]; // (B | C | D)[] (previously B[])\n\nfunction f1(x: B | C | D) {\n if (x instanceof B) {\n x; // B (previously B | D)\n }\n else if (x instanceof C) {\n x; // C\n }\n else {\n x; // D (previously never)\n }\n}
in operatorThe in operator now acts as a narrowing expression for types.
For a n in x expression, where n is a string literal or string literal type and x is a union type, the “true” branch narrows to types which have an optional or required property n, and the “false” branch narrows to types which have an optional or missing property n.
\ntsinterface A { a: number };\ninterface B { b: string };\n\nfunction foo(x: A | B) {\n if (\"a\" in x) {\n return x.a;\n }\n return x.b;\n}
import d from \"cjs\" from CommonJS modules with --esModuleInteropTypeScript 2.7 updates CommonJS/AMD/UMD module emit to synthesize namespace records based on the presence of an __esModule indicator under --esModuleInterop.\nThe change brings the generated output from TypeScript closer to that generated by Babel.
Previously CommonJS/AMD/UMD modules were treated in the same way as ES6 modules, resulting in a couple of problems. Namely:
\nimport * as foo from \"foo\") for a CommonJS/AMD/UMD module as equivalent to const foo = require(\"foo\").Things are simple here, but they don’t work out if the primary object being imported is a primitive or a class or a function. ECMAScript spec stipulates that a namespace record is a plain object, and that a namespace import (foo in the example above) is not callable, though allowed by TypeScriptimport d from \"foo\") for a CommonJS/AMD/UMD module as equivalent to const d = require(\"foo\").default.Most of the CommonJS/AMD/UMD modules available today do not have a default export, making this import pattern practically unusable to import non-ES modules (i.e. CommonJS/AMD/UMD). For instance import fs from \"fs\" or import express from \"express\" are not allowed.Under the new --esModuleInterop these two issues should be addressed:
import * as foo from \"foo\") is now correctly flagged as uncallable. Calling it will result in an error.import fs from \"fs\"), and should work as expected.\n\nNote: The new behavior is added under a flag to avoid unwarranted breaks to existing code bases. We highly recommend applying it both to new and existing projects.\nFor existing projects, namespace imports (
\nimport * as express from \"express\"; express();) will need to be converted to default imports (import express from \"express\"; express();).
With --esModuleInterop two new helpers are generated __importStar and __importDefault for import * and import default respectively.\nFor instance input like:
\ntsimport * as foo from \"foo\";\nimport b from \"bar\";
Will generate:
\n\njs\"use strict\";\nvar __importStar = (this && this.__importStar) || function (mod) {\n if (mod && mod.__esModule) return mod;\n var result = {};\n if (mod != null) for (var k in mod) if (Object.hasOwnProperty.call(mod, k)) result[k] = mod[k];\n result[\"default\"] = mod;\n return result;\n}\nvar __importDefault = (this && this.__importDefault) || function (mod) {\n return (mod && mod.__esModule) ? mod : { \"default\": mod };\n}\nexports.__esModule = true;\nvar foo = __importStar(require(\"foo\"));\nvar bar_1 = __importDefault(require(\"bar\"));
TypeScript 2.7 brings support for ES Numeric Separators.\nNumeric literals can now be separated into segments using _.
\ntsconst million = 1_000_000;\nconst phone = 555_734_2231;\nconst bytes = 0xFF_0C_00_FF;\nconst word = 0b1100_0011_1101_0001;
--watch modeTypeScript’s --watch mode now clears the screen after a re-compilation is requested.
--pretty outputTypeScript’s --pretty flag can make error messages easier to read and manage.\n--pretty now uses colors for file names, diagnostic codes, and line numbers.\nFile names and positions are now also formatted to allow navigation in common terminals (e.g. Visual Studio Code terminal).