On: Node.js 16 Available Now

[motogpjimbo]

You don't need `async` here, since your function explicitly returns a promise.

[coding123 → motogpjimbo]

I do that too. In ts, it helps a tiny bit - it enforces that the function will return a promise. So if that ever changes, the function TS compiler will be your backup anchor.

[whatl3y → motogpjimbo]

While this is true, I've found over time it's easier for me to quickly see in my code if I need to `await` on something if the function is an `async` function and not just that it returns a Promise.

I prefer

async function foo() { return await new Promise(...) }

as opposed to

function foo() { return new Promise(...) }

They're the same thing for the most part but the latter I have to potentially dig deeper into the function to confirm it returns a promise compared to the former.

[junon → whatl3y]

The problem is that this is more than just a syntactic difference. There's a chance it will take two ticks to resolve instead of one.

For documentation purposes, I recommend block-commenting the `async`:

const foo = /async/ () => new Promise(...);

[whatl3y → junon]

I did not know this and appreciate the insight! Will definitely store this back of mind and try and remember to use block comments when needing to explicitly return a promise.

[slashdev → junon]

That's not true if you just return the promise instead of using return await, right?

[junon → slashdev]

No. `async` on a function automatically defers it even if the return value is immediate.

> async function foo() { return "hello"; } foo().then(console.log); console.log("after")

after hello