In prior versions of TypeScript, unions of callable types could only be invoked if they had identical parameter lists.
\n\ntstype Fruit = \"apple\" | \"orange\";\ntype Color = \"red\" | \"orange\";\n\ntype FruitEater = (fruit: Fruit) => number; // eats and ranks the fruit\ntype ColorConsumer = (color: Color) => string; // consumes and describes the colors\n\ndeclare let f: FruitEater | ColorConsumer;\n\n// Cannot invoke an expression whose type lacks a call signature.\n// Type 'FruitEater | ColorConsumer' has no compatible call signatures.ts(2349)\nf(\"orange\");
However, in the above example, both FruitEaters and ColorConsumers should be able to take the string \"orange\", and return either a number or a string.
In TypeScript 3.3, this is no longer an error.
\n\ntstype Fruit = \"apple\" | \"orange\";\ntype Color = \"red\" | \"orange\";\n\ntype FruitEater = (fruit: Fruit) => number; // eats and ranks the fruit\ntype ColorConsumer = (color: Color) => string; // consumes and describes the colors\n\ndeclare let f: FruitEater | ColorConsumer;\n\nf(\"orange\"); // It works! Returns a 'number | string'.\n\nf(\"apple\"); // error - Argument of type '\"apple\"' is not assignable to parameter of type '\"orange\"'.\n\nf(\"red\"); // error - Argument of type '\"red\"' is not assignable to parameter of type '\"orange\"'.
In TypeScript 3.3, the parameters of these signatures are intersected together to create a new signature.
\nIn the example above, the parameters fruit and color are intersected together to a new parameter of type Fruit & Color.\nFruit & Color is really the same as (\"apple\" | \"orange\") & (\"red\" | \"orange\") which is equivalent to (\"apple\" & \"red\") | (\"apple\" & \"orange\") | (\"orange\" & \"red\") | (\"orange\" & \"orange\").\nEach of those impossible intersections reduces to never, and we’re left with \"orange\" & \"orange\" which is just \"orange\".
This new behavior only kicks in when at most one type in the union has multiple overloads, and at most one type in the union has a generic signature.\nThat means methods on number[] | string[] like map (which is generic) still won’t be callable.
On the other hand, methods like forEach will now be callable, but under noImplicitAny there may be some issues.
\ntsinterface Dog {\n kind: \"dog\"\n dogProp: any;\n}\ninterface Cat {\n kind: \"cat\"\n catProp: any;\n}\n\nconst catOrDogArray: Dog[] | Cat[] = [];\n\ncatOrDogArray.forEach(animal => {\n // ~~~~~~ error!\n // Parameter 'animal' implicitly has an 'any' type.\n});
This is still strictly more capable in TypeScript 3.3, and adding an explicit type annotation will work.
\n\ntsinterface Dog {\n kind: \"dog\"\n dogProp: any;\n}\ninterface Cat {\n kind: \"cat\"\n catProp: any;\n}\n\nconst catOrDogArray: Dog[] | Cat[] = [];\ncatOrDogArray.forEach((animal: Dog | Cat) => {\n if (animal.kind === \"dog\") {\n animal.dogProp;\n // ...\n }\n else if (animal.kind === \"cat\") {\n animal.catProp;\n // ...\n }\n});
--build --watchTypeScript 3.0 introduced a new feature for structuring builds called “composite projects”.\nPart of the goal here was to ensure users could break up large projects into smaller parts that build quickly and preserve project structure, without compromising the existing TypeScript experience.\nThanks to composite projects, TypeScript can use --build mode to recompile only the set of projects and dependencies.\nYou can think of this as optimizing inter-project builds.
TypeScript 2.7 also introduced --watch mode builds via a new incremental “builder” API.\nIn a similar vein, the entire idea is that this mode only re-checks and re-emits changed files or files whose dependencies might impact type-checking.\nYou can think of this as optimizing intra-project builds.
Prior to 3.3, building composite projects using --build --watch actually didn’t use this incremental file watching infrastructure.\nAn update in one project under --build --watch mode would force a full build of that project, rather than determining which files within that project were affected.
In TypeScript 3.3, --build mode’s --watch flag does leverage incremental file watching as well.\nThat can mean signficantly faster builds under --build --watch.\nIn our testing, this functionality has resulted in a reduction of 50% to 75% in build times of the original --build --watch times.\nYou can read more on the original pull request for the change to see specific numbers, but we believe most composite project users will see significant wins here.