data.connection.playStream(ytdl(data.queue[0].url, {filter: "audioonly"}));
TypeError: secretbox.methods.close is not a function
When running discord.js under webpack, it fails to resolve the secretbox libraies
Is there a known workaround?
By modifying secreatbox to import libsodium-wrappers without the loop, it works.
Further details:
we don't support voice in browser
Hi @devsnek
Forgot to mention, this not being ran under a browser.
Webpack is being used so that we can have a single file for deployments, (and to load unsupported es version code)
our webpack builds leave out all the voice code (or should, it might be slightly out of sync) so even in a node environment, this is expected.
May I know what is up with the ES version code? You could fork discord.js and run babel on it if your hosting service does not support [email protected] (which has been LTS for over a year!). Using webpack builds is a terrible idea for back-end because we skip many dependencies (voice support...), as its name says, __web__pack builds are supposed to be only used for the browser. If this is too bothersome, discord.js stable/11.4-dev require Node.js 6.0.0 which is in maintenance mode.
As a side note, having single-file builds of packages is a terrible idea in backend as it makes development much harder.
Our projects use a combination of TypeScript and ES version code,
Therefore, we use webpack + babel/ts-loader to transpile to something node will run on our servers
Furthermore, having a single file makes the self updating side of things simpler.
It's the way we've been doing things for ~18 months, and has worked for everything else
In webpack's description:
_webpack is a module bundler. Its main purpose is to bundle JavaScript files for usage in a browser, yet it is also capable of transforming, bundling, or packaging just about any resource or asset._
This means, the generated code is meant for browser usage, not for Node.js usage, it's not simpler, nor easier. Our webpack builds __do not include__ the resource maps, therefore, when an error occurs, the stack is going to be pretty hard to read, and the code from upstream hard to find (due to everything being minified and obfuscated).
Another reason for webpack to exist is because browsers normally can't fetch many files (in HTTP/1.1, browsers can only download 4-6 scripts at the same time, making the loading very slow when the dependency tree is large), thus we compress everything to a single file and make it much easier to deliver.
However, this does not matter for back-end, you should not use webpack for this, TypeScript is already able to compile modern code to very old versions of ECMAScript that even Node.js 6.x can support, as for discord.js itself, stable is compatible with Node.js 6.x too, unless you're using an EOL (End-of-Life) version of Node.js which is not suggested as it's not updated. Babel is the correct solution for your issue, not webpack.
Also, why don't you just use pure TypeScript? Or pure JS. In my own experience, it's a little of a mess to mix both in large cuantities.
Most helpful comment
our webpack builds leave out all the voice code (or should, it might be slightly out of sync) so even in a node environment, this is expected.