The latest updates on your projects. Learn more aboutVercel for GitHub.

2 Skipped Deployments

Project	Deployment	Preview	Comments	Updated (UTC)
discord-js	Ignored	Preview		Oct 30, 2025 3:16pm
discord-js-guide	Ignored	Preview		Oct 30, 2025 3:16pm

I'd say the better fix would be to move all the READY event handling into READY.js, not the other way around. Or at least the checkReady() call

I'd say the better fix would be to move all the READY event handling into READY.js, not the other way around. Or at least the checkReady() call

I just noticed that the Ready event is async
None of the packet handlers are async, so calling this function won't be awaitable
While this can easily be fixed by adding "await" before "PacketHandlers[packet.t](this, packet, shardId);", but is it necessary?

I'd say the better fix would be to move all the READY event handling into READY.js, not the other way around. Or at least the checkReady() call

I believe this was not added to READY.js on purpose because the handler is async

I'd say the better fix would be to move all the READY event handling into READY.js, not the other way around. Or at least the checkReady() call

I believe this was not added to READY.js on purpose because the handler is async

Since I was the one who wrote that I can assure you that's not the reason. In v14 the checkReady check is in READY.js; this was simply an oversight when adapting to the direct use of /ws and should be reverted to check in READY.js

adding await would be a good idea however, and then the checkReady check for READY event could be added to handlePacket instead. Similar to how it checks for GUILD_CREATE and _DELETE.

In v14 the checkReady check is in READY.js

Then checkReady() was not async

was a little later than "tonight", but I got to it. we should be good :)