Today we are excited to announce the availability of TypeScript 5.2 Beta.<\/p>\n
To get started using the beta, you can get it through NuGet<\/a>, or through npm with the following command:<\/p>\n Here’s a quick list of what’s new in TypeScript 5.2!<\/p>\n TypeScript 5.2 adds support for the upcoming Explicit Resource Management<\/a> feature in ECMAScript.\nLet’s explore some of the motivations and understand what the feature brings us.<\/p>\n It’s common to need to do some sort of "clean-up" after creating an object.\nFor example, you might need to close network connections, delete temporary files, or just free up some memory.<\/p>\n Let’s imagine a function that creates a temporary file, reads and writes to it for various operations, and then closes and deletes it.<\/p>\n This is fine, but what happens if we need to perform an early exit?<\/p>\n We’re starting to see some duplication of clean-up which can be easy to forget.\nWe’re also not guaranteed to close and delete the file if an error gets thrown.\nThis could be solved by wrapping this all in a While this is more robust, it’s added quite a bit of "noise" to our code.\nThere are also other foot-guns we can run into if we start adding more clean-up logic to our This starts by adding a new built-in Later on we can call those methods.<\/p>\n Moving the clean-up logic to That brings us to the first star of the feature: So we could simply have written our code like this:<\/p>\n Check it out \u2014 no You might be familiar with But what happens if both the logic before and during disposal throws an error?\nFor those cases, You might have noticed that we’re using synchronous methods in these examples.\nHowever, lots of resource disposal involves asynchronous<\/em> operations, and we need to wait for those to complete before we continue running any other code.<\/p>\n That’s why there is also a new Defining types in terms of Now maybe this all sounds great for libraries, but a little bit heavy-weight for your scenarios.\nIf you’re doing a lot of ad-hoc clean-up, creating a new type might introduce a lot of over-abstraction and questions about best-practices.\nFor example, take our All we wanted was to remember to call two functions \u2014 but was this the best way to write it?\nShould we be calling That brings us to the final stars of the feature: Here, the The Because this feature is so recent, most runtimes will not support it natively.\nTo use it, you will need runtime polyfills for the following:<\/p>\n However, if all you’re interested in is You will also need to set your compilation For more information on this feature, take a look at the work on GitHub<\/a>!<\/p>\n TypeScript 5.2 implements an upcoming ECMAScript feature called decorator metadata<\/a>.<\/p>\n The key idea of this feature is to make it easy for decorators to create and consume metadata on any class they’re used on or within.<\/p>\n Whenever decorator functions are used, they now have access to a new This can be useful in a number of different scenarios.\nMetadata could possibly be attached for lots of uses like debugging, serialization, or performing dependency injection with decorators.\nSince metadata objects are created per decorated class, frameworks can either privately use them as keys into a For example, let’s say we wanted to use decorators to keep track of which properties and accessors are serializable when using Here, the intent is that only Here’s an example of how the module This module has a local Using a As a note, these implementations don’t handle subclassing and inheritance.\nThat’s left as an exercise to you (and you might find that it is easier in one version of the file than the other!).<\/p>\n Because this feature is still fresh, most runtimes will not support it natively.\nTo use it, you will need a polyfill for You will also need to set your compilation We’d like to thank Oleksandr Tarasiuk<\/a> for contributing the implementation of decorator metadata<\/a> for TypeScript 5.2!<\/p>\n <\/p>\n Tuple types have supported optional labels or names for each element.<\/p>\n These labels don’t change what you’re allowed to do with them \u2014 they’re solely to help with readability and tooling.<\/p>\n However, TypeScript previously had a rule that tuples could not mix and match between labeled and unlabeled elements.\nIn other words, either no element could have a label in a tuple, or all elements needed one.<\/p>\n This could be annoying for rest elements where we’d be forced to just add a label like It also meant that this restriction had to be enforced internally in the type system, meaning TypeScript would lose labels.<\/p>\n In TypeScript 5.2, the all-or-nothing restriction on tuple labels has been lifted.\nThe language can now also preserve labels when spreading into an unlabeled tuple.<\/p>\n We’d like to extend our thanks to Josh Goldberg<\/a> and Mateusz Burzy\u0144ski<\/a> who collaborated to lift this restriction<\/a>.<\/p>\n In previous versions on TypeScript, calling a method on a union of arrays could end in pain.<\/p>\n In this example, TypeScript would try to see if each version of In TypeScript 5.2, before giving up in these cases, unions of arrays are treated as a special case.\nA new array type is constructed out of each member’s element type, and then the method is invoked on that.<\/p>\n Taking the above example, This means lots of methods like You can read up more details on the implementing pull request<\/a>.<\/p>\nnpm install -D typescript@beta\r\n<\/code><\/pre>\n\n
using<\/code> Declarations and Explicit Resource Management<\/a><\/li>\nusing<\/code> Declarations and Explicit Resource Management<\/h2>\nimport * as fs from "fs";\r\n\r\nexport function doSomeWork() {\r\n const path = ".some_temp_file";\r\n const file = fs.openSync(path, "w+");\r\n\r\n \/\/ use file...\r\n\r\n \/\/ Close the file and delete it.\r\n fs.closeSync(file);\r\n fs.unlinkSync(path);\r\n}\r\n<\/code><\/pre>\nexport function doSomeWork() {\r\n const path = ".some_temp_file";\r\n const file = fs.openSync(path, "w+");\r\n\r\n \/\/ use file...\r\n if (someCondition()) {\r\n \/\/ do some more work...\r\n\r\n \/\/ Close the file and delete it.\r\n fs.closeSync(file);\r\n fs.unlinkSync(path);\r\n return;\r\n }\r\n\r\n \/\/ Close the file and delete it.\r\n fs.closeSync(file);\r\n fs.unlinkSync(path);\r\n}\r\n<\/code><\/pre>\ntry<\/code>\/finally<\/code> block.<\/p>\nexport function doSomeWork() {\r\n const path = ".some_temp_file";\r\n const file = fs.openSync(path, "w+");\r\n\r\n try {\r\n \/\/ use file...\r\n\r\n if (someCondition()) {\r\n \/\/ do some more work...\r\n return;\r\n }\r\n }\r\n finally {\r\n \/\/ Close the file and delete it.\r\n fs.closeSync(file);\r\n fs.unlinkSync(path);\r\n }\r\n}\r\n<\/code><\/pre>\nfinally<\/code> block \u2014 for example, exceptions preventing other resources from being disposed.\nThis is what the explicit resource management<\/a> proposal aims to solve.\nThe key idea of the proposal is to support resource disposal \u2014 this clean-up work we’re trying to deal with \u2014 as a first class idea in JavaScript.<\/p>\nsymbol<\/code> called Symbol.dispose<\/code>, and we can create objects with methods named by Symbol.dispose<\/code>.\nFor convenience, TypeScript defines a new global type called Disposable<\/code> which describes these.<\/p>\nclass TempFile implements Disposable {\r\n #path: string;\r\n #handle: number;\r\n\r\n constructor(path: string) {\r\n this.#path = path;\r\n this.#handle = fs.openSync(path, "w+");\r\n }\r\n\r\n \/\/ other methods\r\n\r\n [Symbol.dispose]() {\r\n \/\/ Close the file and delete it.\r\n fs.closeSync(this.#handle);\r\n fs.unlinkSync(this.#path);\r\n }\r\n}\r\n<\/code><\/pre>\nexport function doSomeWork() {\r\n const file = new TempFile(".some_temp_file");\r\n\r\n try {\r\n \/\/ ...\r\n }\r\n finally {\r\n file[Symbol.dispose]();\r\n }\r\n}\r\n<\/code><\/pre>\nTempFile<\/code> itself doesn’t buy us much;\nwe’ve basically just moved all the clean-up work from the finally<\/code> block into a method, and that’s always been possible.\nBut having a well-known "name" for this method means that JavaScript can build other features on top of it.<\/p>\nusing<\/code> declarations!\nusing<\/code> is a new keyword that lets us declare new fixed bindings, kind of like const<\/code>.\nThe key difference is that variables declared with using<\/code> get their Symbol.dispose<\/code> method called at the end of the scope!<\/p>\nexport function doSomeWork() {\r\n using file = new TempFile(".some_temp_file");\r\n\r\n \/\/ use file...\r\n\r\n if (someCondition()) {\r\n \/\/ do some more work...\r\n return;\r\n }\r\n}\r\n<\/code><\/pre>\ntry<\/code>\/finally<\/code> blocks!\nAt least, none that we see.\nFunctionally, that’s exactly what using<\/code> declarations will do for us, but we don’t have to deal with that.<\/p>\nusing<\/code> declarations in C#<\/a>, with<\/code> statements in Python<\/a>, or try<\/code>-with-resource declarations in Java<\/a>.\nThese are all similar to JavaScript’s new using<\/code> keyword, and provide a similar explicit way to perform a "tear-down" of an object at the end of a scope.<\/p>\nusing<\/code> declarations do this clean-up at the very end of their containing scope or right before an "early return" like a return<\/code> or a throw<\/code>n error.\nThey also dispose in a first-in-last-out order like a stack.<\/p>\nfunction loggy(id: string): Disposable {\r\n console.log(`Creating ${id}`);\r\n\r\n return {\r\n [Symbol.dispose]() {\r\n console.log(`Disposing ${id}`);\r\n }\r\n }\r\n}\r\n\r\nfunction func() {\r\n using a = loggy("a");\r\n using b = loggy("b");\r\n {\r\n using c = loggy("c");\r\n using d = loggy("d");\r\n }\r\n using e = loggy("e");\r\n return;\r\n\r\n \/\/ Unreachable.\r\n \/\/ Never created, never disposed.\r\n using f = loggy("f");\r\n}\r\n\r\nfunc();\r\n\/\/ Creating a\r\n\/\/ Creating b\r\n\/\/ Creating c\r\n\/\/ Creating d\r\n\/\/ Disposing d\r\n\/\/ Disposing c\r\n\/\/ Creating e\r\n\/\/ Disposing e\r\n\/\/ Disposing b\r\n\/\/ Disposing a\r\n<\/code><\/pre>\nusing<\/code> declarations are supposed to be resilient to exceptions;\nif an error is thrown, it’s rethrown after disposal.\nOn the other hand, the body of your function might execute as expected, but the Symbol.dispose<\/code> might throw.\nIn that case, that exception is rethrown as well.<\/p>\nSuppressedError<\/code> has been introduced as a new subtype of Error<\/code>.\nIt features a suppressed<\/code> property that holds the last-thrown error, and an error<\/code> property for the most-recently thrown error.<\/p>\nclass ErrorA extends Error {\r\n name = "ErrorA";\r\n}\r\nclass ErrorB extends Error {\r\n name = "ErrorB";\r\n}\r\n\r\nfunction throwy(id: string) {\r\n return {\r\n [Symbol.dispose]() {\r\n throw new ErrorA(`Error from ${id}`);\r\n }\r\n };\r\n}\r\n\r\nfunction func() {\r\n using a = throwy("a");\r\n throw new ErrorB("oops!")\r\n}\r\n\r\ntry {\r\n func();\r\n}\r\ncatch (e: any) {\r\n console.log(e.name); \/\/ SuppressedError\r\n console.log(e.message); \/\/ An error was suppressed during disposal.\r\n\r\n console.log(e.error.name); \/\/ ErrorA\r\n console.log(e.error.message); \/\/ Error from a\r\n\r\n console.log(e.suppressed.name); \/\/ ErrorB\r\n console.log(e.suppressed.message); \/\/ oops!\r\n}\r\n<\/code><\/pre>\nSymbol.asyncDispose<\/code>, and it brings us to the next star of the show \u2014 await using<\/code> declarations.\nThese are similar to using<\/code> declarations, but the key is that they look up whose disposal must be await<\/code>ed.\nThey use a different method named by Symbol.asyncDispose<\/code>, though they can operate on anything with a Symbol.dispose<\/code> as well.\nFor convenience, TypeScript also introduces a global type called AsyncDisposable<\/code> that describes any object with an asynchronous dispose method.<\/p>\nasync function doWork() {\r\n \/\/ Do fake work for half a second.\r\n await new Promise(resolve => setTimeout(resolve, 500));\r\n}\r\n\r\nfunction loggy(id: string): AsyncDisposable {\r\n console.log(`Constructing ${id}`);\r\n return {\r\n async [Symbol.asyncDispose]() {\r\n console.log(`Disposing (async) ${id}`);\r\n await doWork();\r\n },\r\n }\r\n}\r\n\r\nasync function func() {\r\n await using a = loggy("a");\r\n await using b = loggy("b");\r\n {\r\n await using c = loggy("c");\r\n await using d = loggy("d");\r\n }\r\n await using e = loggy("e");\r\n return;\r\n\r\n \/\/ Unreachable.\r\n \/\/ Never created, never disposed.\r\n await using f = loggy("f");\r\n}\r\n\r\nfunc();\r\n\/\/ Constructing a\r\n\/\/ Constructing b\r\n\/\/ Constructing c\r\n\/\/ Constructing d\r\n\/\/ Disposing (async) d\r\n\/\/ Disposing (async) c\r\n\/\/ Constructing e\r\n\/\/ Disposing (async) e\r\n\/\/ Disposing (async) b\r\n\/\/ Disposing (async) a\r\n<\/code><\/pre>\nDisposable<\/code> and AsyncDisposable<\/code> can make your code much easier to work with if you expect others to do tear-down logic consistently.\nIn fact, lots of existing types exist in the wild which have a dispose()<\/code> or close()<\/code> method.\nFor example, the Visual Studio Code APIs even define their own Disposable<\/code> interface<\/a>.\nAPIs in the browser and in runtimes like Node.js, Deno, and Bun might also choose to use Symbol.dispose<\/code> and Symbol.asyncDispose<\/code> for objects which already have clean-up methods, like file handles, connections, and more.<\/p>\nTempFile<\/code> example again.<\/p>\nclass TempFile implements Disposable {\r\n #path: string;\r\n #handle: number;\r\n\r\n constructor(path: string) {\r\n this.#path = path;\r\n this.#handle = fs.openSync(path, "w+");\r\n }\r\n\r\n \/\/ other methods\r\n\r\n [Symbol.dispose]() {\r\n \/\/ Close the file and delete it.\r\n fs.closeSync(this.#handle);\r\n fs.unlinkSync(this.#path);\r\n }\r\n}\r\n\r\nexport function doSomeWork() {\r\n using file = new TempFile(".some_temp_file");\r\n\r\n \/\/ use file...\r\n\r\n if (someCondition()) {\r\n \/\/ do some more work...\r\n return;\r\n }\r\n}\r\n<\/code><\/pre>\nopenSync<\/code> in the constructor, create an open()<\/code> method, or pass in the handle ourselves?\nShould we expose a method for every possible operation we need to perform, or should we just make the properties public?<\/p>\nDisposableStack<\/code> and AsyncDisposableStack<\/code>.\nThese objects are useful for doing both one-off clean-up, along with arbitrary amounts of cleanup.\nA DisposableStack<\/code> is an object that has several methods for keeping track of Disposable<\/code> objects, and can be given functions for doing arbitrary clean-up work.\nWe can also assign them to using<\/code> variables because \u2014 get this \u2014 they’re also Disposable<\/code><\/em>!\nSo here’s how we could’ve written the original example.<\/p>\nfunction doSomeWork() {\r\n const path = ".some_temp_file";\r\n const file = fs.openSync(path, "w+");\r\n\r\n using cleanup = new DisposableStack();\r\n cleanup.defer(() => {\r\n fs.closeSync(file);\r\n fs.unlinkSync(path);\r\n });\r\n\r\n \/\/ use file...\r\n\r\n if (someCondition()) {\r\n \/\/ do some more work...\r\n return;\r\n }\r\n\r\n \/\/ ...\r\n}\r\n<\/code><\/pre>\ndefer()<\/code> method just takes a callback, and that callback will be run once cleanup<\/code> is disposed of.\nTypically, defer<\/code> (and other DisposableStack<\/code> methods like use<\/code> and adopt<\/code>)\nshould be called immediately after creating a resource.\nAs the name suggests, DisposableStack<\/code> disposes of everything it keeps track of like a stack, in a first-in-last-out order, so defer<\/code>ing immediately after creating a value helps avoid odd dependency issues.\nAsyncDisposable<\/code> works similarly, but can keep track of async<\/code> functions and AsyncDisposable<\/code>s, and is itself an AsyncDisposable.<\/code><\/p>\ndefer<\/code> method is similar in many ways to the defer<\/code> keyword in Go<\/a>, Swift<\/a>, Zig<\/a>, Odin<\/a>, and others, where the conventions should be similar.<\/p>\n\n
Symbol.dispose<\/code><\/li>\nSymbol.asyncDispose<\/code><\/li>\nDisposableStack<\/code><\/li>\nAsyncDisposableStack<\/code><\/li>\nSuppressedError<\/code><\/li>\n<\/ul>\nusing<\/code> and await using<\/code>, you should be able to get away with only polyfilling the built-in symbol<\/code>s.\nSomething as simple as the following should work for most cases:<\/p>\nSymbol.dispose ??= Symbol("Symbol.dispose");\r\nSymbol.asyncDispose ??= Symbol("Symbol.asyncDispose");\r\n<\/code><\/pre>\ntarget<\/code> to es2022<\/code> or below, and configure your lib<\/code> setting to either include "esnext"<\/code> or "esnext.disposable"<\/code>.<\/p>\n{\r\n "compilerOptions": {\r\n "target": "es2022",\r\n "lib": ["es2022", "esnext.disposable", "dom"]\r\n }\r\n}\r\n<\/code><\/pre>\nDecorator Metadata<\/h2>\n
metadata<\/code> property on their context object.\nThe metadata<\/code> property just holds a simple object.\nSince JavaScript lets us add properties arbitrarily, it can be used as a dictionary that is updated by each decorator.\nAlternatively, since every metadata<\/code> object will be identical for each decorated portion of a class, it can be used as a key into a Map<\/code>.\nAfter all decorators on or in a class get run, that object can be accessed on the class via Symbol.metadata<\/code>.<\/p>\ninterface Context {\r\n name: string;\r\n metadata: Record<PropertyKey, unknown>;\r\n}\r\n\r\nfunction setMetadata(_target: any, context: Context) {\r\n context.metadata[context.name] = true;\r\n}\r\n\r\nclass SomeClass {\r\n @setMetadata\r\n foo = 123;\r\n\r\n @setMetadata\r\n accessor bar = "hello!";\r\n\r\n @setMetadata\r\n baz() { }\r\n}\r\n\r\nconst ourMetadata = SomeClass[Symbol.metadata];\r\n\r\nconsole.log(JSON.stringify(ourMetadata));\r\n\/\/ { "bar": true, "baz": true, "foo": true }\r\n<\/code><\/pre>\nMap<\/code> or WeakMap<\/code>, or tack properties on as necessary.<\/p>\nJSON.stringify<\/code> like so:<\/p>\nimport { serialize, jsonify } from ".\/serializer";\r\n\r\nclass Person {\r\n firstName: string;\r\n lastName: string;\r\n\r\n @serialize\r\n age: number\r\n\r\n @serialize\r\n get fullName() {\r\n return `${this.firstName} ${this.lastName}`;\r\n }\r\n\r\n toJSON() {\r\n return jsonify(this)\r\n }\r\n\r\n constructor(firstName: string, lastName: string, age: number) {\r\n \/\/ ...\r\n }\r\n}\r\n<\/code><\/pre>\nage<\/code> and fullName<\/code> should be serialized because they are marked with the @serialize<\/code> decorator.\nWe define a toJSON<\/code> method for this purpose, but it just calls out to jsonify<\/code> which uses the metadata that @serialize<\/code> created.<\/p>\n.\/serialize.ts<\/code> might be defined:<\/p>\nconst serializables = Symbol();\r\n\r\ntype Context =\r\n | ClassAccessorDecoratorContext\r\n | ClassGetterDecoratorContext\r\n | ClassFieldDecoratorContext\r\n ;\r\n\r\nexport function serialize(_target: any, context: Context): void {\r\n if (context.static || context.private) {\r\n throw new Error("Can only serialize public instance members.")\r\n }\r\n if (typeof context.name === "symbol") {\r\n throw new Error("Cannot serialize symbol-named properties.");\r\n }\r\n\r\n const propNames =\r\n (context.metadata[serializables] as string[] | undefined) ??= [];\r\n propNames.push(context.name);\r\n}\r\n\r\nexport function jsonify(instance: object): string {\r\n const metadata = instance.constructor[Symbol.metadata];\r\n const propNames = metadata?.[serializables] as string[] | undefined;\r\n if (!propNames) {\r\n throw new Error("No members marked with @serialize.");\r\n }\r\n\r\n const pairStrings = propNames.map(key => {\r\n const strKey = JSON.stringify(key);\r\n const strValue = JSON.stringify((instance as any)[key]);\r\n return `${strKey}: ${strValue}`;\r\n });\r\n\r\n return `{ ${pairStrings.join(", ")} }`;\r\n}\r\n<\/code><\/pre>\nsymbol<\/code> called serializables<\/code> to store and retrieve the names of properties marked @serializable<\/code>.\nIt stores a list of these property names on the metadata on each invocation of @serializable<\/code>.\nWhen jsonify<\/code> is called, the list of properties is fetched off of the metadata and used to retrieve the actual values from the instance, eventually serializing those names and values.<\/p>\nsymbol<\/code> technically makes this data accessible to others.\nAn alternative might be to use a WeakMap<\/code> using the metadata object as a key.\nThis keeps data private and happens to use fewer type assertions in this case, but is otherwise similar.<\/p>\nconst serializables = new WeakMap<object, string[]>();\r\n\r\ntype Context =\r\n | ClassAccessorDecoratorContext\r\n | ClassGetterDecoratorContext\r\n | ClassFieldDecoratorContext\r\n ;\r\n\r\nexport function serialize(_target: any, context: Context): void {\r\n if (context.static || context.private) {\r\n throw new Error("Can only serialize public instance members.")\r\n }\r\n if (typeof context.name !== "string") {\r\n throw new Error("Can only serialize string properties.");\r\n }\r\n\r\n let propNames = serializables.get(context.metadata);\r\n if (propNames === undefined) {\r\n serializables.set(context.metadata, propNames = []);\r\n }\r\n propNames.push(context.name);\r\n}\r\n\r\nexport function jsonify(instance: object): string {\r\n const metadata = instance.constructor[Symbol.metadata];\r\n const propNames = metadata && serializables.get(metadata);\r\n if (!propNames) {\r\n throw new Error("No members marked with @serialize.");\r\n }\r\n const pairStrings = propNames.map(key => {\r\n const strKey = JSON.stringify(key);\r\n const strValue = JSON.stringify((instance as any)[key]);\r\n return `${strKey}: ${strValue}`;\r\n });\r\n\r\n return `{ ${pairStrings.join(", ")} }`;\r\n}\r\n<\/code><\/pre>\nSymbol.metadata<\/code>.\nSomething as simple as the following should work for most cases:<\/p>\nSymbol.metadata ??= Symbol("Symbol.metadata");\r\n<\/code><\/pre>\ntarget<\/code> to es2022<\/code> or below, and configure your lib<\/code> setting to either include "esnext"<\/code> or "esnext.decorators"<\/code>.<\/p>\n{\r\n "compilerOptions": {\r\n "target": "es2022",\r\n "lib": ["es2022", "esnext.decorators", "dom"]\r\n }\r\n}\r\n<\/code><\/pre>\nNamed and Anonymous Tuple Elements<\/h2>\n
type Pair<T> = [first: T, second: T];\r\n<\/code><\/pre>\n\/\/ \u2705 fine - no labels\r\ntype Pair1<T> = [T, T];\r\n\r\n\/\/ \u2705 fine - all fully labeled\r\ntype Pair2<T> = [first: T, second: T];\r\n\r\n\/\/ \u274c previously an error\r\ntype Pair3<T> = [first: T, T];\r\n\/\/ ~\r\n\/\/ Tuple members must all have names\r\n\/\/ or all not have names.\r\n<\/code><\/pre>\nrest<\/code> or tail<\/code>.<\/p>\n\/\/ \u274c previously an error\r\ntype TwoOrMore_A<T> = [first: T, second: T, ...T[]];\r\n\/\/ ~~~~~~\r\n\/\/ Tuple members must all have names\r\n\/\/ or all not have names.\r\n\r\n\/\/ \u2705\r\ntype TwoOrMore_B<T> = [first: T, second: T, rest: ...T[]];\r\n<\/code><\/pre>\ntype HasLabels = [a: string, b: string];\r\ntype HasNoLabels = [number, number];\r\ntype Merged = [...HasNoLabels, ...HasLabels];\r\n\/\/ ^ [number, number, string, string]\r\n\/\/\r\n\/\/ 'a' and 'b' were lost in 'Merged'\r\n<\/code><\/pre>\nEasier Method Usage for Unions of Arrays<\/h2>\n
declare let array: string[] | number[];\r\n\r\narray.filter(x => !!x);\r\n\/\/ ~~~~~~ error!\r\n\/\/ This expression is not callable.\r\n\/\/ Each member of the union type '...' has signatures,\r\n\/\/ but none of those signatures are compatible\r\n\/\/ with each other.\r\n<\/code><\/pre>\nfilter<\/code> is compatible across string[]<\/code> and number[]<\/code>.\nWithout a coherent strategy, TypeScript threw its hands in the air and said "I can’t make it work".<\/p>\nstring[] | number[]<\/code> is transformed into (string | number)[]<\/code> (or Array<string | number><\/code>), and filter<\/code> is invoked on that type.\nThere is a slight caveat which is that filter<\/code> will produce an Array<string | number><\/code> instead of a string[] | number[]<\/code>;\nbut for a freshly produced value there is less risk of something "going wrong".<\/p>\nfilter<\/code>, find<\/code>, some<\/code>, every<\/code>, and reduce<\/code> should all be invokable on unions of arrays in cases where they were not previously.<\/p>\n