Deno / Websocket error
To start with, as I understand it, Deno is not officially supported.
That said, from what I have been reading, it seemed like there was a reasonable chance of djs working with Deno since it added support for npm packages.
I would really like to use Deno for my bot, so I gave it a go...
Unfortunately, no dice -- I'm getting an error when djs is attempting to construct a WebSocket.
I'm wondering if this is a familiar problem, or if anyone has an idea for what may be a fix for this.
Here is the error when I attempt to run (I use "deno task simple" to run it):
deno.json
simple_main.ts
The error is pointing at index.js in djs, which is doing this:
The tooltip is telling me arg2 should be a
string | string[] | undefined
which is probably why the underlying code is throwing the error.
Again, I understand there isn't any official support, but if there's a workaround for this that allows me to continue using Deno, I would appreciate any ideas.
In case it matters, deno --version
:
14 Replies
- What's your exact discord.js
npm list discord.js
and node node -v
version?
- Not a discord.js issue? Check out #other-js-ts.
- Consider reading #how-to-get-help to improve your question!
- Explain what exactly your issue is.
- Post the full error stack trace, not just the top part!
- Show your code!
- Issue solved? Press the button!TBH I can't point at a particularly rational reason.
I'm new to the node ecosystem, and Deno's selling points seemed pretty good - built-in TS, a touch more security, built in KV store, lower memory footprint, etc.
Of course, none of this technically actually matters for the project I'm experimenting with.
Thought process kind of went: "Let's try out Deno, what could I build with it", then "Hey a Discord bot seems like a good idea". Discord.js seemed like the best option if I didn't want to write it all myself. Since the thought process started with Deno, that is likely where my resistance to ditching it comes from 😅 It's certainly not the end of the world if I can't get it working, but it would be nice if I could.
Thought process kind of went: "Let's try out Deno, what could I build with it", then "Hey a Discord bot seems like a good idea". Discord.js seemed like the best option if I didn't want to write it all myself. Since the thought process started with Deno, that is likely where my resistance to ditching it comes from 😅 It's certainly not the end of the world if I can't get it working, but it would be nice if I could.
Unknown User•5mo ago
Message Not Public
Sign In & Join Server To View
yeah it is, except some native node.js modules may not work
Hi, I suddenly encountered the same issue on an application that has worked for several months. I believe the issue has to do with the wrapper deno uses for nodejs ws calls. What worked for me was downgrading deno to version 1.32.2 (something newer might work, but this works so i dont question it). You can set this as your deno version by running
deno upgrade --version 1.32.2
oh interesting, thanks for this update!
Also, I'll have a closer look at Bun, I hadn't looked at it too much to date.
Having the same issue on a deeply Deno project (using their KV store, custom flags for workers...) and I'm searching for a solution
Things I know:
- This happened after a package code purge. Did a
ws
update break this?
- Deno was not updated when it broke, Deno is not the issue here
What if I pin it to use 1.0.2
ok no it doesn't pin to 1.0.2, likely a ws update broke it
FOUND IT
this was previously
wait no
wait, all old versions had void 0, nevermind dead end
OK now I know half what I'm doing here
const connection = new WebSocketConstructor(url, {
handshakeTimeout: this.strategy.options.handshakeTimeout ?? void 0
});
deno recently made a change (?) that made arg #2 the protocol, in line with web standards. arg #3 should be ops now
node, by the looks of it, uses the ws
module which... well, doesn't do that
bun has no API documentation whatsoever so we will ignore it
from what I see:
- Deno is following web specifications which @discordjs/ws doesn't implement right
- Node uses something nonstandard (?) [the ws
module] that doesn't include the protocol value, which is what causes the issues here
- Bun is idkah lovely
thanks for this! I wish this thread was brought to my attention earlier
I think we can reasonably work on fixing this, since as far as I'm aware, d.js otherwise mostly works on deno
we purposefully did the whole thing of trying to use the global WS constructor when available to help compat... it's unfortunate deno did this stuff after we implemented it
but I do understand their reasoning re web standards
I thiiink all we have to do is dynamically build the args array based off of env (special case for deno) and then just
new WebSocketConstructor(...args as any)
it'll make it quite hacky and generally not type-sound because we're literally dealing with multiple envs at once but.. it's a cost I think we're willing to pay, these APIs should be stable (well, deno did just break it, but ignoring that; they're comforming to webspec now)alright, awesome! I'll keep an eye on @discordjs/ws and once the patch is in I'll just make my project use dev somehow. thanks for keeping us informed!
yeah, there's just a minor console spam issue since Deno didn't implement a certain Websocket function yet, but there's a fallback it uses instead so it still works just fine
imo I dont mind the spam, it's nice to see to know my project is still running
well!
I just wasted 30 minutes writing a clean fix for this
I didn't need to do any of this, the package we use in node just supports the overload
assuming the bun impl also does this was like a one-line diff
so it's fixed™️ now?
once the pr is merged, yes
Oh sweet, thanks!
I had switched over to using Bun, and had no problems thereafter. I'll eventually switch back to try Deno again. It looks like it was merged May 13th 🎉
'Twas merged and works well!