TypeScript 3.5 introduces several optimizations around type-checking and incremental builds.
\nTypeScript 3.5 contains certain optimizations over TypeScript 3.4 for type-checking more efficiently.\nThese improvements are significantly more pronounced in editor scenarios where type-checking drives operations like code completion lists.
\n--incremental improvementsTypeScript 3.5 improves on 3.4’s --incremental build mode, by saving information about how the state of the world was calculated - compiler settings, why files were looked up, where files were found, etc.\nIn scenarios involving hundreds of projects using TypeScript’s project references in --build mode, we’ve found that the amount of time rebuilding can be reduced by as much as 68% compared to TypeScript 3.4!
For more details, you can see the pull requests to
\n\nOmit helper typeTypeScript 3.5 introduces the new Omit helper type, which creates a new type with some properties dropped from the original.
\ntstype Person = {\n name: string;\n age: number;\n location: string;\n};\n\ntype QuantumPerson = Omit<Person, \"location\">;\n\n// equivalent to\ntype QuantumPerson = {\n name: string;\n age: number;\n};
Here we were able to copy over all the properties of Person except for location using the Omit helper.
For more details, see the pull request on GitHub to add Omit, as well as the change to use Omit for object rest.
In TypeScript 3.4 and earlier, certain excess properties were allowed in situations where they really shouldn’t have been.\nFor instance, TypeScript 3.4 permitted the incorrect name property in the object literal even though its types don’t match between Point and Label.
\ntstype Point = {\n x: number;\n y: number;\n};\n\ntype Label = {\n name: string;\n};\n\nconst thing: Point | Label = {\n x: 0,\n y: 0,\n name: true // uh-oh!\n};
Previously, a non-disciminated union wouldn’t have any excess property checking done on its members, and as a result, the incorrectly typed name property slipped by.
In TypeScript 3.5, the type-checker at least verifies that all the provided properties belong to some union member and have the appropriate type, meaning that the sample above correctly issues an error.
\nNote that partial overlap is still permitted as long as the property types are valid.
\n\ntsconst pl: Point | Label = {\n x: 0,\n y: 0,\n name: \"origin\" // okay\n};
--allowUmdGlobalAccess flagIn TypeScript 3.5, you can now reference UMD global declarations like
\nexport as namespace foo;\nfrom anywhere - even modules - using the new --allowUmdGlobalAccess flag.
This mode adds flexibility for mixing and matching the way 3rd party libraries, where globals that libraries declare can always be consumed, even from within modules.
\nFor more details, see the pull request on GitHub.
\nIn TypeScript 3.4 and prior, the following example would fail:
\n\ntstype S = { done: boolean, value: number }\ntype T =\n | { done: false, value: number }\n | { done: true, value: number };\n\ndeclare let source: S;\ndeclare let target: T;\n\ntarget = source;
That’s because S isn’t assignable to { done: false, value: number } nor { done: true, value: number }.\nWhy?\nBecause the done property in S isn’t specific enough - it’s boolean whereas each constituent of T has a done property that’s specifically true or false.\nThat’s what we meant by each constituent type being checked in isolation: TypeScript doesn’t just union each property together and see if S is assignable to that.\nIf it did, some bad code could get through like the following:
\ntsinterface Foo {\n kind: \"foo\";\n value: string;\n}\n\ninterface Bar {\n kind: \"bar\";\n value: number;\n}\n\nfunction doSomething(x: Foo | Bar) {\n if (x.kind === \"foo\") {\n x.value.toLowerCase();\n }\n}\n\n// uh-oh - luckily TypeScript errors here!\ndoSomething({\n kind: \"foo\",\n value: 123,\n});
However, this was a bit overly strict for the original example.\nIf you figure out the precise type of any possible value of S, you can actually see that it matches the types in T exactly.
In TypeScript 3.5, when assigning to types with discriminant properties like in T, the language actually will go further and decompose types like S into a union of every possible inhabitant type.\nIn this case, since boolean is a union of true and false, S will be viewed as a union of { done: false, value: number } and { done: true, value: number }.
For more details, you can see the original pull request on GitHub.
\nIn TypeScript 3.4, we improved inference for when generic functions that return functions like so:
\n\ntsfunction compose<T, U, V>(\n f: (x: T) => U, g: (y: U) => V): (x: T) => V {\n \n return x => g(f(x))\n}
took other generic functions as arguments, like so:
\n\ntsfunction arrayify<T>(x: T): T[] {\n return [x];\n}\n\ntype Box<U> = { value: U }\nfunction boxify<U>(y: U): Box<U> {\n return { value: y };\n}\n\nlet newFn = compose(arrayify, boxify);
Instead of a relatively useless type like (x: {}) => Box<{}[]>, which older versions of the language would infer, TypeScript 3.4’s inference allows newFn to be generic.\nIts new type is <T>(x: T) => Box<T[]>.
TypeScript 3.5 generalizes this behavior to work on constructor functions as well.
\n\ntsclass Box<T> {\n kind: \"box\";\n value: T;\n constructor(value: T) {\n this.value = value;\n }\n}\n\nclass Bag<U> {\n kind: \"bag\";\n value: U;\n constructor(value: U) {\n this.value = value;\n }\n}\n\n\nfunction composeCtor<T, U, V>(\n F: new (x: T) => U, G: new (y: U) => V): (x: T) => V {\n \n return x => new G(new F(x))\n}\n\nlet f = composeCtor(Box, Bag); // has type '<T>(x: T) => Bag<Box<T>>'\nlet a = f(1024); // has type 'Bag<Box<number>>'
In addition to compositional patterns like the above, this new inference on generic constructors means that functions that operate on class components in certain UI libraries like React can more correctly operate on generic class components.
\n\ntstype ComponentClass<P> = new (props: P) => Component<P>;\ndeclare class Component<P> {\n props: P;\n constructor(props: P);\n}\n\ndeclare function myHoc<P>(C: ComponentClass<P>): ComponentClass<P>;\n\ntype NestedProps<T> = { foo: number, stuff: T };\n\ndeclare class GenericComponent<T> extends Component<NestedProps<T>> {\n}\n\n// type is 'new <T>(props: NestedProps<T>) => Component<NestedProps<T>>'\nconst GenericComponent2 = myHoc(GenericComponent);
To learn more, check out the original pull request on GitHub.
","headings":[{"value":"Speed improvements","depth":2},{"value":"Type-checking speed-ups","depth":3},{"value":"--incremental improvements","depth":3},{"value":"The Omit helper type","depth":2},{"value":"Improved excess property checks in union types","depth":3},{"value":"The --allowUmdGlobalAccess flag","depth":2},{"value":"Smarter union type checking","depth":2},{"value":"Higher order type inference from generic constructors","depth":2}],"frontmatter":{"permalink":"/docs/handbook/release-notes/typescript-3-5.html","title":"TypeScript 3.5"}}},"pageContext":{"slug":"/docs/handbook/release-notes/typescript-3-5.html","isOldHandbook":true}}}