Dynamic import expressions are a new feature and part of ECMAScript that allows users to asynchronously request a module at any arbitrary point in your program.
This means that you can conditionally and lazily import other modules and libraries.\nFor example, here’s an async function that only imports a utility library when it’s needed:
\ntsasync function getZipFile(name: string, files: File[]): Promise<File> {\n const zipUtil = await import('./utils/create-zip-file');\n const zipContents = await zipUtil.getContentAsBlob(files);\n return new File(zipContents, name);\n}
Many bundlers have support for automatically splitting output bundles based on these import expressions, so consider using this new feature with the esnext module target.
TypeScript 2.4 now allows enum members to contain string initializers.
\n\ntsenum Colors {\n Red = \"RED\",\n Green = \"GREEN\",\n Blue = \"BLUE\",\n}
The caveat is that string-initialized enums can’t be reverse-mapped to get the original enum member name.\nIn other words, you can’t write Colors[\"RED\"] to get the string \"Red\".
TypeScript 2.4 introduces a few wonderful changes around the way generics are inferred.
\nFor one, TypeScript can now make inferences for the return type of a call.\nThis can improve your experience and catch errors.\nSomething that now works:
\n\ntsfunction arrayMap<T, U>(f: (x: T) => U): (a: T[]) => U[] {\n return a => a.map(f);\n}\n\nconst lengths: (a: string[]) => number[] = arrayMap(s => s.length);
As an example of new errors you might spot as a result:
\n\ntslet x: Promise<string> = new Promise(resolve => {\n resolve(10);\n // ~~ Error!\n});
Prior to TypeScript 2.4, in the following example
\n\ntslet f: <T>(x: T) => T = y => y;
y would have the type any.\nThis meant the program would type-check, but you could technically do anything with y, such as the following:
\ntslet f: <T>(x: T) => T = y => y() + y.foo.bar;
That last example isn’t actually type-safe.
\nIn TypeScript 2.4, the function on the right side implicitly gains type parameters, and y is inferred to have the type of that type-parameter.
If you use y in a way that the type parameter’s constraint doesn’t support, you’ll correctly get an error.\nIn this case, the constraint of T was (implicitly) {}, so the last example will appropriately fail.
TypeScript now tries to unify type parameters when comparing two single-signature types.\nAs a result, you’ll get stricter checks when relating two generic signatures, and may catch some bugs.
\n\ntstype A = <T, U>(x: T, y: U) => [T, U];\ntype B = <S>(x: S, y: S) => [S, S];\n\nfunction f(a: A, b: B) {\n a = b; // Error\n b = a; // Ok\n}
TypeScript has always compared parameters in a bivariant way.\nThere are a number of reasons for this, but by-and-large this was not been a huge issue for our users until we saw some of the adverse effects it had with Promises and Observables.
TypeScript 2.4 introduces tightens this up when relating two callback types. For example:
\n\ntsinterface Mappable<T> {\n map<U>(f: (x: T) => U): Mappable<U>;\n}\n\ndeclare let a: Mappable<number>;\ndeclare let b: Mappable<string | number>;\n\na = b;\nb = a;
Prior to TypeScript 2.4, this example would succeed.\nWhen relating the types of map, TypeScript would bidirectionally relate their parameters (i.e. the type of f).\nWhen relating each f, TypeScript would also bidirectionally relate the type of those parameters.
When relating the type of map in TS 2.4, the language will check whether each parameter is a callback type, and if so, it will ensure that those parameters are checked in a contravariant manner with respect to the current relation.
In other words, TypeScript now catches the above bug, which may be a breaking change for some users, but will largely be helpful.
\nTypeScript 2.4 introduces the concept of “weak types”.\nAny type that contains nothing but a set of all-optional properties is considered to be weak.\nFor example, this Options type is a weak type:
\ntsinterface Options {\n data?: string,\n timeout?: number,\n maxRetries?: number,\n}
In TypeScript 2.4, it’s now an error to assign anything to a weak type when there’s no overlap in properties.\nFor example:
\n\ntsfunction sendMessage(options: Options) {\n // ...\n}\n\nconst opts = {\n payload: \"hello world!\",\n retryOnFail: true,\n}\n\n// Error!\nsendMessage(opts);\n// No overlap between the type of 'opts' and 'Options' itself.\n// Maybe we meant to use 'data'/'maxRetries' instead of 'payload'/'retryOnFail'.
You can think of this as TypeScript “toughening up” the weak guarantees of these types to catch what would otherwise be silent bugs.
\nSince this is a breaking change, you may need to know about the workarounds which are the same as those for strict object literal checks:
\n[propName: string]: {}).opts as Options).