Have event handler callbacks support both async/sync methods about discord.js HOT 3 CLOSED

They do support that. The issue is within your linter config here disallowing something that‘s perfectly valid typescript. See https://www.typescriptlang.org/docs/handbook/2/functions.html#return-type-void
See #10017 for details on why this was changed.

from discord.js.

Hi! This rule serves in spotting plenty of difficult bugs to deal with. In this case, when a callback is typed with an expected return type of void, it implies that, if a Promise were to be returned, it wouldn't be awaited, which is absolutely correct. The event handling in discord.js is standard EventEmitter (in some subpackages Vlad's async emitters).

One side effect you may not be aware of, is that multiple callback calls can be in effect in parallel. Think of this (pseudo-code) web example:

let someState;
htmlElement.on('click', async () => {
  someState = await someAsyncFetchCall();
});

This is a disaster! If the user clicks multiple times on the button, the JS engine leaves each invocation waiting for the hypothetical HTTP call to end, and it's possible they finish in an order different than 1->2->3, causing broken state in your application.

If you find it hard to envision how this affects a Discord bot, it generally does not. One case I can think of is when you build "UX" using buttons and dropdowns, naively assigning event handlers to your collectors means I can break your implementation by just clicking a bunch of stuff in quick succession.

To summarize, us changing the type is not only incorrect from a typing perspective (because the return type of a callback first and firemost implies what we do with the return type, and the absence of Promise means we leave them dangling), but it's also bad in the context of this rule.

My personal recommendation is to leave it enabled globally, and whenever you find it erroring think twice if you're gonna be running state updates in the callback that depend on previous invocations. If not, disable it for that line.

from discord.js.

Fair enough. Thank you to both of you. I did manage to find another solution that resolves the lint error AND looks good. I'll put it here for anyone who finds this issue thread in the future.

// Set the client application commands and then exit the client
async function deployCommands(c: Client<true>) {
  await c.application.commands.set(commands);
  await c.destroy();
}
client.once('ready', c => void deployCommands(c));

Moving the logic into a separate method and using the void keyword explicitly ignores whether the Promise is fulfilled, which tells @typescript-eslint that it is intentional.

This way, I don't need to use eslint-disable-next-line, promise chaining, or an async IIFE method wrapper.

from discord.js.