In TypeScript 3.1, mapped object types[1] over tuples and arrays now produce new tuples/arrays, rather than creating a new type where members like push(), pop(), and length are converted.\nFor example:
\ntstype MapToPromise<T> = { [K in keyof T]: Promise<T[K]> };\n\ntype Coordinate = [number, number]\n\ntype PromiseCoordinate = MapToPromise<Coordinate>; // [Promise<number>, Promise<number>]
MapToPromise takes a type T, and when that type is a tuple like Coordinate, only the numeric properties are converted.\nIn [number, number], there are two numerically named properties: 0 and 1.\nWhen given a tuple like that, MapToPromise will create a new tuple where the 0 and 1 properties are Promises of the original type.\nSo the resulting type PromiseCoordinate ends up with the type [Promise<number>, Promise<number>].
TypeScript 3.1 brings the ability to define properties on function declarations and const-declared functions, simply by assigning to properties on these functions in the same scope.\nThis allows us to write canonical JavaScript code without resorting to namespace hacks.\nFor example:
\ntsfunction readImage(path: string, callback: (err: any, image: Image) => void) {\n // ...\n}\n\nreadImage.sync = (path: string) => {\n const contents = fs.readFileSync(path);\n return decodeImageSync(contents);\n}
Here, we have a function readImage which reads an image in a non-blocking asynchronous way.\nIn addition to readImage, we’ve provided a convenience function on readImage itself called readImage.sync.
While ECMAScript exports are often a better way of providing this functionality, this new support allows code written in this style to “just work” TypeScript.\nAdditionally, this approach for property declarations allows us to express common patterns like defaultProps and propTypes on React function components (formerly known as SFCs).
\n\ntsexport const FooComponent = ({ name }) => (\n <div>Hello! I am {name}</div>\n);\n\nFooComponent.defaultProps = {\n name: \"(anonymous)\",\n};
[1] More specifically, homomorphic mapped types like in the above form.
\ntypesVersionsFeedback from our community, as well as our own experience, has shown us that leveraging the newest TypeScript features while also accommodating users on the older versions are difficult.\nTypeScript introduces a new feature called typesVersions to help accommodate these scenarios.
When using Node module resolution in TypeScript 3.1, when TypeScript cracks open a package.json file to figure out which files it needs to read, it first looks at a new field called typesVersions.\nA package.json with a typesVersions field might look like this:
\njson{\n \"name\": \"package-name\",\n \"version\": \"1.0\",\n \"types\": \"./index.d.ts\",\n \"typesVersions\": {\n \">=3.1\": { \"*\": [\"ts3.1/*\"] }\n }\n}
This package.json tells TypeScript to check whether the current version of TypeScript is running.\nIf it’s 3.1 or later, it figures out the path you’ve imported relative to the package, and reads from the package’s ts3.1 folder.\nThat’s what that { \"*\": [\"ts3.1/*\"] } means - if you’re familiar with path mapping today, it works exactly like that.
So in the above example, if we’re importing from \"package-name\", we’ll try to resolve from [...]/node_modules/package-name/ts3.1/index.d.ts (and other relevant paths) when running in TypeScript 3.1.\nIf we import from package-name/foo, we’ll try to look for [...]/node_modules/package-name/ts3.1/foo.d.ts and [...]/node_modules/package-name/ts3.1/foo/index.d.ts.
What if we’re not running in TypeScript 3.1 in this example?\nWell, if none of the fields in typesVersions get matched, TypeScript falls back to the types field, so here TypeScript 3.0 and earlier will be redirected to [...]/node_modules/package-name/index.d.ts.
The way that TypeScript decides on whether a version of the compiler & language matches is by using Node’s semver ranges.
\ntypesVersions can support multiple fields where each field name is specified by the range to match on.
\njson{\n \"name\": \"package-name\",\n \"version\": \"1.0\",\n \"types\": \"./index.d.ts\",\n \"typesVersions\": {\n \">=3.2\": { \"*\": [\"ts3.2/*\"] },\n \">=3.1\": { \"*\": [\"ts3.1/*\"] }\n }\n}
Since ranges have the potential to overlap, determining which redirect applies is order-specific.\nThat means in the above example, even though both the >=3.2 and the >=3.1 matchers support TypeScript 3.2 and above, reversing the order could have different behavior, so the above sample would not be equivalent to the following.
","headings":[{"value":"Mapped types on tuples and arrays","depth":2},{"value":"Properties declarations on functions","depth":2},{"value":"Version selection with typesVersions","depth":2},{"value":"Matching behavior","depth":2},{"value":"Multiple fields","depth":2}],"frontmatter":{"permalink":"/docs/handbook/release-notes/typescript-3-1.html","title":"TypeScript 3.1"}}},"pageContext":{"slug":"/docs/handbook/release-notes/typescript-3-1.html","isOldHandbook":true}}}json{\n \"name\": \"package-name\",\n \"version\": \"1.0\",\n \"types\": \"./index.d.ts\",\n \"typesVersions\": {\n // NOTE: this doesn't work!\n \">=3.1\": { \"*\": [\"ts3.1/*\"] },\n \">=3.2\": { \"*\": [\"ts3.2/*\"] }\n }\n}