-
Notifications
You must be signed in to change notification settings - Fork 13.2k
Description
🔎 Search Terms
Promise.withResolvers
🕗 Version & Regression Information
- This is the behavior in every version I tried, and I reviewed the FAQ for entries about this and number of parameters and the dogs thing but they did not quite match (I searched for
voidthere)
⏯ Playground Link
💻 Code
console.log("init")
// withResolvers
const { promise: withResolvers, resolve: resolvingFunction } = Promise.withResolvers();
withResolvers.then((payload) => {
console.log("promise Promise.withResolvers suceeded", payload)
}).catch((error) => {
console.warn("promise Promise.withResolvers errored", error)
});
resolvingFunction();
// ^ Expected 1 arguments, but got 0.(2554)
// lib.es2024.promise.d.ts(21, 15): An argument for 'value' was not provided.
// see https://github.com/microsoft/TypeScript/blob/e6fac66a7225a1c5976025e6377a2a4b06b3b85a/src/lib/es2024.promise.d.ts#L3
// ________
// contrasted with: Promise.resolve()
const resolvedPromise = Promise.resolve();
resolvedPromise.then((payload) => {
console.log("promise Promise.resolve suceeded", payload)
}).catch((error) => {
console.warn("promise Promise.resolve errored", error)
});
// ________
// contrasted with: new Promise()
let customPromiseResolve;
const customPromise = new Promise((resolve) => {
customPromiseResolve = resolve;
});
customPromise.then((payload) => {
console.log("promise new Promise() suceeded", payload)
}).catch((error) => {
console.warn("promise new Promise() errored", error)
});
if (customPromiseResolve != undefined) {
customPromiseResolve();
// ^ This expression is not callable.
// Type 'never' has no call signatures.(2349)
// let customPromiseResolve: never
}🙁 Actual behavior
Expected 1 arguments, but got 0.(2554)
lib.es2024.promise.d.ts(21, 15): An argument for 'value' was not provided.
const resolvingFunction: (value: unknown) => void
For some reason, it seems to expect unknown as a function parameter here thus requiring a function.
🙂 Expected behavior
As you can see when compared to Promise.resolve() or the manual pre-ES2024 implementation (that shows a different issue), they do not show the issue. And the important thing is: The code works as is (aka it shows all promises are properly called/resolved) in the browser, so the type-checking of TS did not catch a valid typing issue here, it's perfectly fine to call it like this.
I do not see why this should be different.
MDN does not mention this example but AFAIK you can use and there is nothing wrong with using the resolving Promise function (as e.g. returned from Promise.withResolvers) without any argument.
You can though "fix" the issue by explicitly stating Promise.withResolvers<void>(); must not accept any value aka the value the accept function returns/provides is really void. But why would you?
If I write it without any generic type, is not the default to assume void? Only if I were to provide a custom type, like with Promise.resolve<number>(1) I could specify it, but if none is provided, it also assumes void, does not it?
Additional information about the issue
Note the issue actually occurs in JS code (see downstream https://github.com/rugk/awesome-emoji-picker/pull/189/changes#diff-1402e6d2d65a300089b226dbfd589c0fc74ec00de6f618e3c1b6a4c1bf24c57f), and as type-casting there is really not simple, I would prefer not to do it. The "custom" implementation (aka with new Promise()) there worked, however.
Also, note the "custom" implementation before resulted in This expression is not callable. in the TS implementation. I did not see it in production, but this is also strange given this, again, is a valid JS code, too.
In JavaScript, the "old" "custom" implementation worked without special casting though.
#56483 introduced withResolvers.