#archive-library-discussion | discord.js - imagine an app | Page 2

tacit crypt Apr 8, 2020, 4:49 PM

#

ik the issue nvm

frozen bridge Apr 8, 2020, 4:57 PM

#

Does djs use the Server Members Intent when using guild.members.cache.get() etc ?

slate nacelle Apr 8, 2020, 4:58 PM

#

No, that's just cache, it does not interact with anything outside of your ram.

frozen bridge Apr 8, 2020, 4:59 PM

#

ah ok thx

lofty birch Apr 8, 2020, 6:26 PM

#

Just want to point out that the api seems to now show public_flags on a user object, you may want to look into that as this seems new

slate nacelle Apr 8, 2020, 6:27 PM

#

Once this gets documented on Discord's end (https://github.com/discord/discord-api-docs), this should be a simple thing to add.

Here we go, a PR: https://github.com/discord/discord-api-docs/pull/1490

tacit crypt Apr 8, 2020, 10:31 PM

#

OWO

#

fucking

#

FINALLY

clever crypt Apr 9, 2020, 2:43 AM

#

Consider yourself PR'd kappa
https://github.com/discordjs/discord.js/pull/4060

keen cosmos Apr 9, 2020, 2:56 AM

#

Doesn't the data come in with a regular fetch? instead of needing a separate utility function couldn't users just use User#fetch

thorny cosmos Apr 9, 2020, 5:01 AM

#

For User#fetch(), you would need the user object to call fetch() on them, and assuming you don't have any user object, in that case what will you do?

rigid trail Apr 9, 2020, 5:01 AM

#

fetch from the users manager

thorny cosmos Apr 9, 2020, 5:02 AM

#

Of course there is a method User#fetch, but it is used on Partial User Objects. Assuming you don't have that also, then how would you use? Hence you need UserManager#fetch(), i.e., a separate function exists for it @keen cosmos

copper laurel Apr 9, 2020, 5:47 AM

#

I dont think that was the point being made

#

Are flags not included in a User payload - do they have a separate endpoint that requires User#fetchFlags() instead of just User#fetch()?

copper laurel Apr 9, 2020, 6:09 AM

#

Tested - not part of the data you get about users when you identify but it is the same fetch endpoint

keen cosmos Apr 9, 2020, 7:03 AM

#

yeah, I meant that the data comes in from the same fetch endpoint

#

@thorny cosmos also you're not restricted to using fetch() on partial options

thorny cosmos Apr 9, 2020, 7:04 AM

#

yes I meant that it can be used on any valid User object, it is mostly used for partial user objects but Ok

ornate topaz Apr 9, 2020, 7:19 AM

#

mostly used does not in any way limit it to that functionality or use case

#

guild.fetch() also exists, but did you ever had a need to fetch a guild? tmk you would use it only if you would at any point need maximumPresences or maximumMembers

real jetty Apr 9, 2020, 9:54 AM

#

@keen cosmos if the User isn't partial then User#fetch() will just return the cached user, so it would never end up patching the user and updating the flags

#

and the reason y Guild#fetch() will always patch the props mentioned above is cus it will always make the api call and call _patch() (https://github.com/discordjs/discord.js/blob/stable/src/structures/Guild.js#L588-L596)

vivid field Apr 9, 2020, 10:04 AM

#

is there a reason why bulkDelete didn't move to the MessageManager?

ornate topaz Apr 9, 2020, 11:25 AM

#

it was never under MessageStore

snow crypt Apr 9, 2020, 2:26 PM

#

i think the question is more like why isn't it on messagemanager?

vivid field Apr 9, 2020, 6:19 PM

#

exactly, with "moving" i meant v11 -> v12 and not old v12 -> new v12

rigid trail Apr 9, 2020, 9:05 PM

#

i just didnt think about moving it when implementing managers, i think its fine and its not a big deal but i do see why you would expect it to be on the manager, unfortunately the switch cannot be made as it is semver major

#

i kept all methods the same from dataStores to managers with the exception of renaming MessageStore#remove to MessageManager#delete for clarity

#

@vivid field

loud moat Apr 9, 2020, 9:15 PM

#

So v13 soon

rigid trail Apr 9, 2020, 9:16 PM

#

i wouldnt exactly say soon lol, its a full rewrite and we dont even have a gateway yet, id expect the basic things like rest/gateway/ some of the core to be done by the end of 2020

undone ravine Apr 9, 2020, 10:19 PM

#

the method could still be moved and leave the old one in place as a shortcut to it and deprecated

rigid trail Apr 9, 2020, 10:19 PM

#

i find this useless personally

undone ravine Apr 9, 2020, 10:20 PM

#

if the method would be more appropriate in the new location, it is absolutely not useless

ornate topaz Apr 9, 2020, 10:23 PM

#

at that point it would be more of a change just for the sake of a change

undone ravine Apr 9, 2020, 10:24 PM

#

no, it'd be a change for the sake of logical consistency

#

is there any functional difference? no, of course not

#

but if that is where that method should be, then that is where it should be

#

no reason to hold it back in an improper place because "meh, it doesn't change anything"

rigid trail Apr 9, 2020, 10:25 PM

#

meh i just think there is no need

undone ravine Apr 9, 2020, 10:25 PM

#

you yourself have already essentially admitted that it makes sense to be on the manager

#

therefore there is a need

rigid trail Apr 9, 2020, 10:25 PM

#

it does, i still dont think the change should be made

undone ravine Apr 9, 2020, 10:26 PM

#

you're making that decision from a purely emotional standpoint with no logic behind it

rigid trail Apr 9, 2020, 10:27 PM

#

for all we know bulkDelete could be renamed/moved somewhere else in djs-next, and managers could not exist either, i think deprecating it is not really the right move

undone ravine Apr 9, 2020, 10:27 PM

#

deprecation doesn't guarantee removal

#

it is not a commitment

ornate topaz Apr 9, 2020, 10:28 PM

#

but if it's deprecated, devs should start to look into new way, which literally does not exist now

undone ravine Apr 9, 2020, 10:29 PM

#

the new way is the correct location for the method

#

which would exist at the time of deprecation

raven juniper Apr 11, 2020, 7:44 PM

#

@real jetty that sort of question belongs in #archive-commando-deprecated not in this channel

#

commando is a framework for d.js it's not part of the library

rigid trail Apr 11, 2020, 9:00 PM

#

you might want to read #3485 to get an idea of why things changed, its mostly to separate the API and cache methods. im not quite sure what you mean added to the client class, would you mind elaborating on that?

#

there are no new classes by the way, they only replaced the data store classes

#

while yes, they do break code significantly and many users may not see the need, which is unfortunate, the changes greatly benefitted the maintainability of the library for the future

#

and where would the api methods go? that would be the same as datastores but with a different name

#

the point of managers was to separate the cache and api, you cant quite do that without breaking users code

#

but what you are describing are data stores

wild flax Apr 11, 2020, 9:04 PM

#

though maybe actually extending the class into type-specific subclasses (guildcollection, channelcollection, etc) would have been a better move to avoid breaking existing code
this is essentially what was happening with stores and why we moved away from it

rigid trail Apr 11, 2020, 9:05 PM

#

this would still have all of the downsides of datastores

rigid trail Apr 11, 2020, 9:24 PM

#

add is an internal method to add to the cache and remove is an artifact with a pr to remove it from typings

#

yes

#

the GuildMemberRoleManager is a pseudomanager, its add/set methods call the api

#

no problem

slate nacelle Apr 12, 2020, 4:23 PM

#

Would this work?

#

Looks good, on a first glance.

#

sure

topaz mango Apr 12, 2020, 4:35 PM

#

Don't think it's a breaking change.

rigid trail Apr 12, 2020, 4:36 PM

#

This is a breaking change tho real_eyes

#

at least thats what it looks like to me, im not sure if private things like the data resolver count

snow crypt Apr 12, 2020, 4:40 PM

#

it is like changing the rest manager

#

you're not supposed to touch it

#

hold up, wouldn't it break things that call if it they are not also changed?

#

because in resolveBase64 it still checks for buffer

rigid trail Apr 12, 2020, 4:52 PM

#

it seems to me that this isnt a clean change and that it could silently affect other things that call it, and that more tests need to be written

rigid trail Apr 12, 2020, 5:19 PM

#

Wouldnt that just nullify the point of the pr monkaHMM

opal mauve Apr 12, 2020, 5:20 PM

#

technically, APIMessage doesn't document files as anything other than "Object", so I don't think this would qualify as breaking.

#

honestly a bit of an oversight in documentation, but i think it would serve our purposes here if we wanted to make this change

lofty birch Apr 13, 2020, 11:23 AM

#

I do think a separate method for uploading local files as streams would be helpful though, I do quite a bit of sending images and my ram usage jumps up when doing so

warped crater Apr 13, 2020, 11:23 AM

#

Doesn't this entirely contradict past changes, however

#

with time all of the send* (e.g. sendEmbed, sendFile) methods were removed in favor of the universal send

snow crypt Apr 13, 2020, 12:02 PM

#

@drowsy niche you can still make separate DataResolver methods

#

like, a different resolving for local / remote that will then be called accordingly

snow crypt Apr 13, 2020, 3:47 PM

#

Regarding patterns in MessageMentions, can't IDs be 16-character long?

ornate topaz Apr 13, 2020, 4:30 PM

#

considering they are being somewhat increased, and that Discord was released in may, no snowflake from after may can be 16 characters long

snow crypt Apr 13, 2020, 4:31 PM

#

so it will be 17,19 for now, and 17,20 after there can't be no more 19digit ids?

ornate topaz Apr 13, 2020, 4:34 PM

#

yes

#

we're already at 699296380694429736

#

so theoretically

wild flax Apr 14, 2020, 12:25 PM

#

What of all of this do you actually send to discord?

keen cosmos Apr 14, 2020, 7:47 PM

#

@drowsy niche I messed around with your test code and it seems like the files property of the json response from httpbin is being reset when sending a stream, maybe that's the issue?

tribal slate Apr 15, 2020, 2:58 AM

#

setSelfDeaf literally does not work

#

Not sure if I'm doing something wrong or if its because of the library itself

#

It shouldn't return anything

wispy harbor Apr 15, 2020, 2:59 AM

#

(actually it should)

tribal slate Apr 15, 2020, 2:59 AM

#

Yeah but like

#

yikers

rigid trail Apr 15, 2020, 3:00 AM

#

the return type is documented so im not sure what the problem is

tribal slate Apr 15, 2020, 3:00 AM

#

Its supposed to self deafen the bot

#

But its not doing that, and just returning false

rigid trail Apr 15, 2020, 3:01 AM

#

well, thats not something for this channel

tribal slate Apr 15, 2020, 3:01 AM

#

I thought this was a problem with the library

#

Which is why I posted here

#

Is it a problem with the docs? I'm really not sure

snow crypt Apr 15, 2020, 8:16 AM

#

not sure what should I do now tho, the form-data repo is pretty dead
@drowsy niche create @discordjs/form-data?

tacit crypt Apr 15, 2020, 2:06 PM

#

@drowsy niche ```ts
declare const body: import('node-fetch').Body;

body.body```

#

Per their docs, this is totally valid

#

Since res.body is a Body class, it has a body property (stupid, I know)

#

Do you think that might fix it? (so we don't have the issue where form-data is..borked)

#

In this case, body.body is a NodeJS Readable Stream, instead of a WHATWG ReadableStream

#

Wait the hell?

#

Am I seeing this wrong

#

Oh I totally did see this wrong, fricking docs

#

Well this might explain why it doesn't work without that form-data PR

tacit crypt Apr 15, 2020, 2:30 PM

#

oh, gotcha

keen cosmos Apr 16, 2020, 6:57 AM

#

@drowsy niche so the issue is that form-data doesn't like anything that's not a regular Readable stream, right?

wild flax Apr 16, 2020, 10:13 AM

#

@drowsy niche if you want we can probably keep a fork and keep it up to date with upstream

wild flax Apr 16, 2020, 10:47 AM

#

well, I'd rather have a fork with the PR merged (in our fork) than rely on someone else fork, if you know what I mean

#

yes, but we have to fork form-data first is what im saying

#

have a fork that is under our control, in case the original PR author deletes his or whatever

#

probably

#

anything is better than relying on some 3rd party fork here.

#

Or installing a commit from a PR

wild flax Apr 16, 2020, 11:07 AM

#

published under @discordjs/form-data

#

3.0.1

#

youll have to make it a non-draft

#

👍

fallen arrow Apr 16, 2020, 11:45 AM

#

Are partial guildChannels supported? This throws errors in the ChannelManager if the channel is not cached but the guild is, i was wondering if it would make sense to provide a partial channel or to simply return if either of them are not available instead: ```js
class InviteCreateAction extends Action {
handle(data) {
const client = this.client;
const channel = client.channels.cache.get(data.channel_id);
const guild = client.guilds.cache.get(data.guild_id);
if (!channel && !guild) return false;

const inviteData = Object.assign(data, { channel, guild });
const invite = new Invite(client, inviteData);

warped crater Apr 16, 2020, 12:44 PM

#

this doesn't seem quite right

#

normally all guilds should be cached when they are received via the GUILD_CREATE packet, which provides all channels

#

there should never be a case where a channel is not cached

#

same with roles & guilds

fallen arrow Apr 16, 2020, 12:53 PM

#

yes i am aware of that, the only use case for this is when the developer uncaches channels to save memory, which is more common than one would think

#

hence why the question if it would make sense to support such use cases since we already have partials in many other scenarios, or if this is out of the scope of the library

warped crater Apr 16, 2020, 1:00 PM

#

as stated in other places & conversations related to cache, going by

uncaches channels to save memory, which is more common than one would think
would cause a lot of changes and checks all over the place for no particular reason

The client options provide various ways of keeping cache smaller for things that are not needed by the core library.

A pretty good summary of it can be seen here: https://github.com/discordjs/discord.js/pull/3995#issuecomment-604441660

#

Channels are data discord.js absolutely depends on internally at the moment, not just in the situation that you pointed out just now

On top of that, I honestly doubt this is "more common than one would think", given that channels are the least of your problems when thinking about cache.

The only real place you can save actual valuable memory in is the messages cache & potentially the members.

wild flax Apr 16, 2020, 1:05 PM

#

We currently only really use or support partials whenever discord gives us partials. And channels dont fall under that category

fallen arrow Apr 16, 2020, 1:08 PM

#

alright thanks

frozen bridge Apr 18, 2020, 2:58 PM

#

@wild flax not sure if this is ping important but people have been having the issue on v12. Is there a fix on that version as well? https://github.com/discordjs/discord.js/issues/3956

wild flax Apr 18, 2020, 2:59 PM

#

@tacit crypt

#

do we not trigger ready even if not all guilds are ready?

#

Im pretty sure we do, or do we only do that on internal sharding?

tacit crypt Apr 18, 2020, 3:00 PM

#

we do, but the timeout waits 15 seconds before doing that

wild flax Apr 18, 2020, 3:00 PM

#

ok but what if you use the sharding manager

tacit crypt Apr 18, 2020, 3:00 PM

#

..same?

wild flax Apr 18, 2020, 3:00 PM

#

doesnt look like it

#

lol

tacit crypt Apr 18, 2020, 3:00 PM

#

The default sharding manager timeout is probably too small by default

#

I mean the cycle is:

Bot gets Discord READY, we set a 15s timeout
For each GUILD_CREATE, we refresh the timeout
If there's still unavailable guilds, the 15s timeout will trigger, marking the client as READY

#

Sooo

#

TL;DR: increase your sharding manager timeout and it should be fine

lofty birch Apr 18, 2020, 3:04 PM

#

Using a sharding manager I get the error it took to long to ready sometimes

tacit crypt Apr 18, 2020, 3:04 PM

#

..As I said

#

Increase the timeout

lofty birch Apr 18, 2020, 3:05 PM

#

According to what you said it should just mark as ready after the timeout with the remaining guilds being unavailable

tacit crypt Apr 18, 2020, 3:05 PM

#

Yes, but the default timeout is too short in the manager

#

Speaking of, @lofty birch do you have any of the optional deps installed? (zlib-sync, bufferutil & utf-8-validate)?

lofty birch Apr 18, 2020, 3:07 PM

#

I don't believe I do

tacit crypt Apr 18, 2020, 3:08 PM

#

Can you try installing those and seeing if that helps?

#

Otherwise, try increasing the timeout on the shardingmanager to say, a minute

#

(manager.spawn(undefined, undefined, 60000)

lofty birch Apr 18, 2020, 3:12 PM

#

Will do in a bit

frozen bridge Apr 19, 2020, 12:18 AM

#

Will User#Flags ever be supported in v11?

copper laurel Apr 19, 2020, 1:08 AM

#

No, v11 will not receive new features

snow crypt Apr 19, 2020, 4:41 PM

#

https://github.com/discordjs/discord.js/blob/master/src/structures/Guild.js#L468
get nameAcronym() {
  return this.name.replace(/\w+/g, name => name[0]).replace(/\s/g, '');
}

Where does the regex come from?

#

I am asking as it gives incorrect results, and I can't find the source for it.

ornate topaz Apr 19, 2020, 5:23 PM

#

probably from nowhere, as acronym is generated by client from usually first letters

snow crypt Apr 19, 2020, 5:29 PM

#

so the acronym-ing is done somewhere in the client js?

ornate topaz Apr 19, 2020, 5:30 PM

#

by client i meant the discord app

wild flax Apr 19, 2020, 5:30 PM

#

Yeah its not an API thing

snow crypt Apr 19, 2020, 5:32 PM

#

by client i meant the discord app
that's what i meant

#

like, in the js of the app

#

there https://raw.githubusercontent.com/DJScias/Discord-Datamining/master/2020/2020-04-18/40abc31adc473eefed44.js

#

@opaque robin that's not how you deprecate

#

And you don't resolve the promise

opaque robin Apr 19, 2020, 5:34 PM

#

@snow crypt tbh I searched the server for util.deprecate and afaik from what I've seen, it returns the function with the deprecation warning.
But if you say I'm incorrect, I'll take that

snow crypt Apr 19, 2020, 5:35 PM

#

Currently the method returns a function

opaque robin Apr 19, 2020, 5:36 PM

#

Oh, so I should be calling the function it returns

slate nacelle Apr 19, 2020, 5:36 PM

#

This is what we did in v11: https://github.com/discordjs/discord.js/blob/v11/src/structures/Guild.js#L1693

snow crypt Apr 19, 2020, 5:36 PM

#

was about to say, do it at the bottom of the file with the prototype

opaque robin Apr 19, 2020, 5:36 PM

#

Ah

#

Thanks space,

#

that makes more sense

snow crypt Apr 19, 2020, 5:37 PM

#

yeah, thanks, space 😞

opaque robin Apr 19, 2020, 5:38 PM

#

I should still be using const util = require('util') instead of directly requiring in the prototype I presume.

snow crypt Apr 19, 2020, 5:38 PM

#

or destructure deprecate from it

opaque robin Apr 19, 2020, 5:44 PM

#

Alright 👍

#

@snow crypt Wouldn't the async await mean it wouldn't be returning a promise anymore

snow crypt Apr 19, 2020, 5:49 PM

#

nope, just the opposite

opaque robin Apr 19, 2020, 5:52 PM

#

ah right, mb

#

@vernal atlas What would be the more appropriate tag to use for that?

I think <info> would be appropriate, not too sure.

snow crypt Apr 19, 2020, 5:55 PM

#

No, just an actual description of the typedef

opaque robin Apr 19, 2020, 5:56 PM

#

  /**
   * An object containing information about a guild's vanity url.
   * @typedef {Object} VanityData
   * @property {?string} code Vanity URL invite code, not the full url
   * @property {?number} uses How many times this invite has been used, must be fetched at least once
   */

snow crypt Apr 19, 2020, 5:56 PM

#

or just vanity, remove url

#

or data

vernal atlas Apr 19, 2020, 5:59 PM

#

not sure what would be better (as to info or warn tag)

snow crypt Apr 19, 2020, 6:00 PM

#

i think just vanity is enough

#

if someone would want to correct it later it's an ez pr

opaque robin Apr 19, 2020, 6:01 PM

#

Might as well get everything done in the one PR tbh

#

so @typedef {Object} Vanity

#

remove URL in Vanity URL invite code

#

and that should be good yeah?

snow crypt Apr 19, 2020, 6:27 PM

#

by client i meant the discord app
do you think ```js
t.getAcronym = function(e) {
return null != e ? e.replace(/'s /g, " ").replace(/\w+/g, (function(e) {
return e[0]
})).replace(/\s/g, "") : ""
}

#

I think it is

#

so yea, it should be name.replace(/'s /g, " ").replace(/\w+/g, e => e[0]).replace(/\s/g, "")

snow crypt Apr 19, 2020, 6:50 PM

#

pr'd it

snow crypt Apr 19, 2020, 7:51 PM

#

What prevents #2910 from being merged?

deft holly Apr 19, 2020, 7:55 PM

#

I'd like to know about ^ as well, left a comment two weeks ago and haven't gotten a response :P

snow crypt Apr 20, 2020, 6:37 AM

#

@clever crypt I found that piece of code with the raw website, didn't need to actually download it

#

looked for "acronym", found uses of "getAcronym", searched its definition and got the actual one

copper laurel Apr 20, 2020, 7:40 AM

#

User#flags doesn't seem to be documented, not sure if it's missing or the docgen for 12.2.0 didn't work properly or something

#

I'm mobile so not checking or PRing myself

snow crypt Apr 20, 2020, 7:40 AM

#

on master it's there

#

https://discord.js.org/#/docs/main/master/class/User?scrollTo=flags

#

oh, you're correct

#

a PR to document it was merged after 12.2.0

#

copper laurel Apr 20, 2020, 7:47 AM

#

Ahh it's after, all good

#

In mobile and didn't check

vapid echo Apr 20, 2020, 12:07 PM

#

hey, any idea how long it takes for v12 bug fixes to get ported to v11? please let me know if this is wrong channel for this

#

i'm specifically looking for this bugfix: fix up WebSocketShard errors. it was released with v12.2.0 a few days back

lofty birch Apr 20, 2020, 5:57 PM

#

new api feature: https://github.com/discord/discord-api-docs/pull/1528

#

was announced in discord dev server also

ornate root Apr 20, 2020, 7:18 PM

#

@vivid field but client.channels gives you a ChannelManager

#

and you can use .fetch on it

vivid field Apr 20, 2020, 7:19 PM

#

oh wait, i thought they used Guild#channels

#

also unrelated to this channel

ornate root Apr 20, 2020, 7:21 PM

#

it was about djs

copper laurel Apr 20, 2020, 10:21 PM

#

@vapid echo v11 is no longer maintained and will not receive further non-critical fixes. v12 is the stable branch which will receive maintenance patches and releases

vapid echo Apr 21, 2020, 4:10 AM

#

Oh. I still see v11 releases though. Are you saying v11.6.4 (released 15 days ago) was the last one? @copper laurel

rigid trail Apr 21, 2020, 4:11 AM

#

if there are significant bugs which can be fixed pretty easily then a quick patch to v11 may be done, but feature updates are out the window

vapid echo Apr 21, 2020, 4:12 AM

#

Right, I am looking for a bugfix. Like I mentioned above, specifically this one: fix up WebSocketShard errors. it was released with v12.2.0 a few days back

#

Just wondering if it will make it to v11

copper laurel Apr 21, 2020, 4:12 AM

#

Can you please reference the PR you're referring to

vapid echo Apr 21, 2020, 4:12 AM

#

Sure

#

https://github.com/discordjs/discord.js/pull/3722

rigid trail Apr 21, 2020, 4:13 AM

#

iirc that was a pretty big change, and the websocket from v11 to v12 has changed a lot, so fixes on v12 can completely break v11

copper laurel Apr 21, 2020, 4:13 AM

#

Its highly unlikely because the websocket was signficantly changed in the v12 release

#

So these changes wouldnt even apply to v11

rigid trail Apr 21, 2020, 4:13 AM

#

yeah its pretty significant

vapid echo Apr 21, 2020, 4:13 AM

#

Oh

#

Okay, we can explore the possibility of moving to v12 then

proven heron Apr 21, 2020, 7:04 AM

#

I feel like displayAvatarURL’s dynamic key should be true by default. It seems like it would be more beneficial as more people will probably be after the gif instead of the webp

wild flax Apr 21, 2020, 7:06 AM

#

Sadly thats a breaking change and wont happen

proven heron Apr 21, 2020, 7:08 AM

#

Explain breaking change. Almost everything you change will break pre-existing code?

wild flax Apr 21, 2020, 7:16 AM

#

https://semver.org/

#

Changing a default to be something else falls under MAJOR

fickle flare Apr 22, 2020, 2:36 AM

#

Has anybody reported any issues with this promise hanging?

#

https://github.com/discordjs/discord.js/blob/master/src/client/websocket/WebSocketShard.js#L176

#

It doesn't reject, it doesn't resolve... just dies 😫

tough geode Apr 22, 2020, 6:11 AM

#

it adds listeners which either resolve or reject the Promise

real jetty Apr 22, 2020, 9:40 AM

#

I was looking for a library to write a Bot in and when looking at the discord.js Github, i've found this: https://github.com/discordjs/discord.js-next, what should anyone expect from it? Will any bot written in the current Discord.js work in next or would i have to write the my Bot again?

wild flax Apr 22, 2020, 9:41 AM

#

The next version, no, yes

real jetty Apr 22, 2020, 9:43 AM

#

I know it seems to be in a pretty early stage to say anything but you have any ETA planned? I wonder how long i could expect my bot to work using the current version.

#

Or you plan to support the current version in some sort of LTS?

spice lava Apr 22, 2020, 1:05 PM

#

So I found a typings issues. With the following code: ts msg.channel.delete().catch() where channel is TextChannel | DMChannel | NewsChannel fails with ```
TS2349: This expression is not callable.
Each member of the union type '(<TResult = never>(onrejected?: (reason: any) => TResult | PromiseLike<TResult>) => Promise<DMChannel | TResult>) | (<TResult = never>(onrejected?: (reason: any) => TResult | PromiseLike<...>) => Promise<...>) | (<TResult = never>(onrejected?: (reason: any) => TResult | PromiseLike<...>) => Promise<...>)' has signatures, but none of those signatures are compatible with each other.


Seems to be an issue introduced with v12 as the Channel typings changed from `public delete(): Promise<Channel>;` to `public delete(reason?: string): Promise<this>;`

Granted this would be an easy fix if you cast a type like `(msg.channel as TextChannel).delete().catch()` but I thought that this issue shouldn't appear in the first place. On the other hand I am not sure on if this should even be fixed as typings in general would be fucked if you just return `Promise<Channel>` there as this wouldnt be very detailed. 

Introducing types on the top level classes like `TextChannel` would introduce the same issue. So I would like to know some comments on this one as I would say all approaches are not perfect because there are actually cases where `channel` could be both, `DMChannel` and `TextChannel`

vernal atlas Apr 22, 2020, 1:26 PM

#

interesting

#

there was something similar to this with the channel union types right?

spice lava Apr 22, 2020, 1:48 PM

#

The issue is the same with channel.fetch().catch() btw, exact same reason as above

slate nacelle Apr 22, 2020, 2:32 PM

#

This is the same issue as the union types, I mean it is an union type after all.

spice lava Apr 22, 2020, 2:33 PM

#

So this is a known issue/problem?

slate nacelle Apr 22, 2020, 2:35 PM

#

Not in this context, but I guess?
I don't think we can do much about this except using Channel instead of the union and let you assert / instanceof concrete types.

spice lava Apr 22, 2020, 2:35 PM

#

That's what I thought. Is there already a PR for it? (will look myself but maybe you know more)

slate nacelle Apr 22, 2020, 2:35 PM

#

I don't think so.

spice lava Apr 22, 2020, 2:36 PM

#

time to get into 2+ 2- PRs again

tacit crypt Apr 22, 2020, 4:23 PM

#

It doesn't reject, it doesn't resolve... just dies 😫
@fickle flare thats..impossible, theres always at least ONE event that runs

fickle flare Apr 22, 2020, 4:25 PM

#

What can I do to help diagnose the problem?

#

or track the source

#

I'm not using standard Node, but until v11 it was working flawlessly

tacit crypt Apr 22, 2020, 4:26 PM

#

Wait, what

fickle flare Apr 22, 2020, 4:44 PM

#

Yes, Its running from inside FiveM's compilation of Node

#

I know there was some history and people here didn't like it, but they actually solved the "window" global parameter pollution and it was working as it should

#

.... until I tried to update to v12 yesterday 😢

vernal atlas Apr 23, 2020, 6:12 PM

#

the data.embed_enabled here is deprecated, in favour of data.widget_enabled, im going to do a PR, assuming it would it be better to deprecate Guild#embedEnabled, in favour of Guild#widgetEnabled, is deprecating a property as simple as just adding the @deprecated tag?

#

https://github.com/discordjs/discord.js/blob/67a74c33e1b124d609bee65f82656e7bf5b09764/src/structures/Guild.js#L208

#

(relevent API docs PR to show its deprecated, https://github.com/discord/discord-api-docs/pull/1536/files)

copper laurel Apr 23, 2020, 8:34 PM

#

You use util.deprecate iirc, @deprecate only JSDocs it

tacit crypt Apr 23, 2020, 11:55 PM

#

I'm pretty sure that's only for functions

snow crypt Apr 24, 2020, 5:48 PM

#

no

#

also props

#

Permissions#_member on v11

opaque vessel Apr 24, 2020, 5:49 PM

#

Is this a bug in the client? Whenever I deleted an uncached message but listening to it as partial, the .system property is always true, but that's not correct?

real jetty Apr 24, 2020, 7:33 PM

#

Suggestion to add field inline limiter, so you can use two values each line if you want to

#

That's quite easy to implement, but really not a feature for D.JS imo

#

Especially since .addBlankField has also been removed

real jetty Apr 24, 2020, 8:14 PM

#

smugshh

ornate topaz Apr 24, 2020, 8:15 PM

#

addBlankField was just a shortcut for addField('\u200b', '\u200b'), that's why it was removed. You can still do it on your own, adding that as 3rd inline field will "fill" the 3rd inline space

However, that will render badly on devices that do not have ability to render any form of inline fields inline. Additionally, embed rendering is purely up to discord - as example can be not-that-recent embed update that allowed to have 3 inline fields and a thumbnail.

vernal atlas Apr 25, 2020, 3:02 AM

#

so i was actually looking around trying to figure out why user#flags can be undefined, found this, kinda odd? how the API sends it but its not picked up?

fiery geyser Apr 25, 2020, 8:05 AM

#

Seems that the API only gives information about public_flags for some users on startup for some reason, manually fetching the user will return the property
I don't think the library can do anything about this
https://github.com/discord/discord-api-docs/pull/1490#issuecomment-613546566

snow crypt Apr 25, 2020, 8:23 AM

#

There is still User#fetchFlags

vernal atlas Apr 25, 2020, 1:24 PM

#

ah, assumed that it was just being lost somewhere

vernal atlas Apr 26, 2020, 1:28 AM

#

Message#suppressEmbeds seems to be broken when using the allowedMentions client option
(suppressEmbeds calls Message#edit, which uses APIMessage.resolveData and adds in the allowedMentions default option)

would the best way be to just call the endpoint directly in suppressEmbeds rather than calling this.edit?

i feel like theres a better way but maybe thats just because its 2:30am and i haven't slept GWrjkKappaLUL

copper laurel Apr 26, 2020, 1:39 AM

#

broken in that it will unintentionally also edit the allowedMentions?

tacit crypt Apr 26, 2020, 2:07 AM

#

Reminder: message edits do not ping the user/role(s)

snow crypt Apr 26, 2020, 12:39 PM

#

would ids be bigints in djs@next?

wild flax Apr 26, 2020, 12:45 PM

#

possibly, not much is set in stone yet for djs 13

vernal atlas Apr 26, 2020, 12:55 PM

#

broken as in the API returns an error (if said message is authored by another user)

(i thought i mentioned that but must've slipped my mind lul) @copper laurel

copper laurel Apr 26, 2020, 1:07 PM

#

Ahh right, makes sense

#

As for BigInt - why? I don't see any value in them being handled as integers, strings works perfectly well.

wild flax Apr 26, 2020, 1:10 PM

#

tbf most sensible languages handle them as a numbers

#

there isnt any particular reason why we couldnt

tacit crypt Apr 26, 2020, 3:46 PM

#

Except we have the constant conversion between BigInt<->String for REST

timid pewter Apr 26, 2020, 4:58 PM

#

Not sure if I should make a new issue for this so I am just gonna try asking here first.

https://github.com/discordjs/discord.js/pull/4087#issuecomment-619242608

I didn't get a response from any of the lib devs on this besides a reaction which doesn't help clarify to me what you guys plan on doing for this? Should TS developers expect breaking changes without warning in the future on what should be a stable branch?

surreal geode Apr 26, 2020, 5:37 PM

#

No, updating typings is not a breaking change

timid pewter Apr 26, 2020, 5:40 PM

#

if it breaks projects it is a breaking change, and this broke projects aka breaking change

#

If DJS doesn't want to properly support TS devs then thats different, but any TS dev using TS properly the way it was intended broke from this PR

#

All im asking is to just give a proper bump to the semver, im fine with the change ill make the changes to my code but dont implement a change that can break projects in a minor bump plz

#

npm i on the vps and projects breaks RIP!

surreal geode Apr 26, 2020, 5:42 PM

#

You don't bump major because you want to, you bump it because it should be bumped. Typings are non-code changes

timid pewter Apr 26, 2020, 5:43 PM

#

When a PR breaks a project it should be bumped

#

the question is whether or not DJS is wanting to properly support TS developers

#

If DJS wants to properly support TS, then it should enforce proper warnings of breaking changes that DO break TS projects. If it doesnt then thats the devs choice and right to choose and myself to live with

#

But come one folks, this is a pretty simple ask to not introducing breaking changes for TS devs in a non-major bump 🙏

warped crater Apr 26, 2020, 5:48 PM

#

This is not how things work

surreal geode Apr 26, 2020, 5:48 PM

#

This is not a breaking change. If you're extending the functionality of D.js, that's on you

warped crater Apr 26, 2020, 5:48 PM

#

You don't bump the major version because X gets messed up by it

#

I highly advise you read this webpage: https://semver.org/

timid pewter Apr 26, 2020, 5:48 PM

#

a major version is bumped when an incompatible api change is made

#

🎉

warped crater Apr 26, 2020, 5:49 PM

#

correct, yet the API wasn't changed.

timid pewter Apr 26, 2020, 5:49 PM

#

this is incompatible with the previous commit aka breaking

warped crater Apr 26, 2020, 5:49 PM

#

just typings behaivour

timid pewter Apr 26, 2020, 5:49 PM

#

yes it was

warped crater Apr 26, 2020, 5:49 PM

#

this does not fall under semver major

surreal geode Apr 26, 2020, 5:49 PM

#

@timid pewter How was this a breaking change

warped crater Apr 26, 2020, 5:49 PM

#

no parameters were moved/removed, no methods were removed

timid pewter Apr 26, 2020, 5:49 PM

#

The API was clearly changed, it prevents a lot of behavior

#

it prevents emitting events that arent listed in those types

#

anyone that was using that behavior which was supported by DJS broke

ornate topaz Apr 26, 2020, 5:50 PM

#

Api didn't change. It was typings file that changed, it's not exactly part of library source code

warped crater Apr 26, 2020, 5:50 PM

#

this, typings changes alone will never fall under anything that isnt semver patch

timid pewter Apr 26, 2020, 5:50 PM

#

the typings are what provide the api to ts

surreal geode Apr 26, 2020, 5:50 PM

#

It doesn't prevent anything. tsc now tells you types don't match

timid pewter Apr 26, 2020, 5:50 PM

#

aka the api did change for ts devs

#

It doesn't prevent anything. tsc now tells you types don't match
No it prevents it. Bots wont start

warped crater Apr 26, 2020, 5:51 PM

#

once again, this is not how semver works, also see what Daro said

timid pewter Apr 26, 2020, 5:51 PM

#

TBH daro i was just hoping for a answer from a lib dev and then ill be on my way

ornate topaz Apr 26, 2020, 5:51 PM

#

You can launch compiled code anyway, so nothing broke

timid pewter Apr 26, 2020, 5:52 PM

#

I don't think you guys understand how working on a TS project works and how massively this PR effected end users

strange igloo Apr 26, 2020, 6:37 PM

#

Hey, I'm implementing support for chunk_count, chunk_index and nonce properties in GUILD_MEMBERS_CHUNK on discord.js. In the event emit, should I better put count and index into an object or leave them as two separate parameters?
Like... (members, guild, { count, index }, nonce) or (members, guild, count, index, nonce) ?

slate nacelle Apr 26, 2020, 6:40 PM

#

I think one single object would be good, in case they add more props.

wild flax Apr 26, 2020, 6:40 PM

#

^

#

id also be on board with that

#

generally more in support of objects in all cases almost

strange igloo Apr 26, 2020, 6:41 PM

#

One single object containing the three properties so?

wild flax Apr 26, 2020, 6:41 PM

#

yup

strange igloo Apr 26, 2020, 6:41 PM

#

Fine 👌

snow crypt Apr 26, 2020, 7:45 PM

#

as for the bigints, i just wanted to know if they'll be used as they exist now, not insisting they should / must be used, but just showing the possibility

rigid trail Apr 26, 2020, 7:45 PM

#

for snowflakes? there is no real reason to

#

the library has functions for extracting data out of snowflakes without using a bigint, and dapi gives snowflakes as strings

snow crypt Apr 26, 2020, 7:52 PM

#

@rigid trail read above (like, really)

#

https://discordapp.com/channels/222078108977594368/682166281826598932/703948421614272523

#

that conversion everytime seems unnecessary when thinking about it, but wouldn't it actually fit it better?

rigid trail Apr 26, 2020, 7:54 PM

#

i agree with monbrey in saying its a useless conversion, most users dont have to do any integer things on ids, and if they do its an easy construction of a bigint

snow crypt Apr 26, 2020, 7:54 PM

#

this is true

#

i also see no need to do math on ids

#

but the data type exists now, why not use it?

rigid trail Apr 26, 2020, 7:55 PM

#

just because something exists doesnt mean its a good idea to use it

strange igloo Apr 26, 2020, 7:55 PM

#

BigInt may also confuse begineers (it's already complicated sometimes as strings so I don't imagine...)

rigid trail Apr 26, 2020, 7:55 PM

#

all the math you have to do on snowflakes theres a deconstruct method for it

#

there really is not much math u can do on snowflakes

snow crypt Apr 26, 2020, 7:56 PM

#

(should there even be in the first place?)

rigid trail Apr 26, 2020, 7:56 PM

#

what

snow crypt Apr 26, 2020, 7:56 PM

#

forget it

rigid trail Apr 26, 2020, 7:56 PM

#

the deconstruct is used internally too

snow crypt Apr 26, 2020, 7:56 PM

#

timestamps, right?

rigid trail Apr 26, 2020, 7:57 PM

#

making it a bigint is quite frankly, pretty useless for most if not all users, and detrimental, as it will be a pretty gigantic change

#

also inconsistent with dapi as snowflakes are strings when sent, not integers

snow crypt Apr 26, 2020, 7:59 PM

#

aren't they strings to support languages that dont have support for 64b ints?

#

which now, js isn't

rigid trail Apr 26, 2020, 8:01 PM

#

yes, but the support isnt as seamless as other languages like python, it really serves no purpose yielding a bigint, instead of a string which can easily be converted to a bigint if somebody needs it, which again, 99% of users wont need bigint snowflakes

snow crypt Apr 26, 2020, 8:03 PM

#

actually, yeah probably

rigid trail Apr 26, 2020, 8:04 PM

#

so this change would be:

Gigantic (most bots rely on the id property)
Pretty useless
Mostly just an annoyance
Thats my take on it

snow crypt Apr 26, 2020, 8:06 PM

#

well yeah, useless - probably

#

anyway, v13 would be a gigantic change on its own, so bigint snowflakes shouldn't be the thing we're afraid is going to break alot

rigid trail Apr 26, 2020, 8:07 PM

#

just because other breaking changes will happen doesnt mean we should break things just because

#

realistically, what use will this bring, for most users, absolutely nothing lol, it will just be annoying

#

and unlike something like managers, it doesnt really have a purpose for the library itself either

snow crypt Apr 26, 2020, 8:10 PM

#

again, just a possibility ¯\_(ツ)_/¯

lofty birch Apr 26, 2020, 8:11 PM

#

There's absolutely no point to use bigints here, it's like making a change for the point of making a change which is really rather stupid

ornate topaz Apr 26, 2020, 8:12 PM

#

aren't they strings to support languages that dont have support for 64b ints?
which now, js isn't
Note that BigInt wasn't "merged" into native number

rigid trail Apr 26, 2020, 8:14 PM

#

number is still a primitive, and it still has the same size, bigint is a specialty object if you need to deal with large numbers

alpine pier Apr 26, 2020, 8:33 PM

#

I mean people accidentally use numbers for ids already and it's causing them errors everywhere... and while you could argue that that's a beginner level problem, you can't deny that it will just bring more errors when people are trying to handle them like number, forgetting that yes, bigints are sth different

copper laurel Apr 26, 2020, 10:07 PM

#

The fact that the language has BigInts does not make them a good or well supported option and it will do nothing to address people who use IDs as numbers. There is no use case I can think of for making the switch, and as Vlad pointed out, they need to be sent as strings to the API anyway

tacit crypt Apr 26, 2020, 10:17 PM

#

I mean can we use BigInts? Totally! Should we? nah

alpine pier Apr 26, 2020, 10:22 PM

#

Monbrey that's not what I meant. Messing up Bigints and numbers is even easier than Strings and numbers. And using bigints is also needlessly complicated judging by this mdn doc. So the few places where you'd want to have ids as numbers (which I can't think of rn) wouldn't benefit from it in the slightest anyways

copper laurel Apr 26, 2020, 10:34 PM

#

Yeah I know, I was agreeing with you, or I meant to be. BigInts are not a useful implementation for us to be using

real jetty Apr 27, 2020, 5:53 PM

#

This is a snippet from the discord.js sharding manager. Can someone tell me why the await statement is not outside the for loop? (github link: https://github.com/discordjs/discord.js/blob/026691702da7d1fcf9a959f00082f07f1e14b13d/src/sharding/ShardingManager.js#L209)

vernal atlas Apr 27, 2020, 5:54 PM

#

because the promises array is defined in the for loop?

exotic flicker Apr 27, 2020, 5:54 PM

#

if you look at it, there are delays getting pushed into the promises array to delay the next loop run

real jetty Apr 27, 2020, 5:58 PM

#

I get that. But this way the shards would spawn serially. I'm just wondering if it would be better if they spawn async?

#

Or am I missing something?

slate nacelle Apr 27, 2020, 6:00 PM

#

There is a 1/5 rate limit for identifying, this avoid failing attempts at such.

real jetty Apr 27, 2020, 6:06 PM

#

Got it. Thanks!

tawny warren Apr 27, 2020, 7:27 PM

#

i wanted to know if the owner of a guild is always cached or not, because intents are giving me an headache with this

raven juniper Apr 27, 2020, 8:05 PM

#

no, also a question for support channels not here @tawny warren

#

guild owners are guildmembers same as any other member and are subject to cache, use guild.ownerID instead

umbral aspen Apr 28, 2020, 8:06 PM

#

Wouldn't it be logical for the GuildDelete action to use a typing method in it's condition (for example, ClientUser#typingIn()) to return a value to determine whether or not the client user is typing in the provided channel to not call TextChannel#stopTyping redundantly? Or am I missing the point here?

real jetty Apr 28, 2020, 9:01 PM

#

TextChannel#stopTyping() already has a check for this https://github.com/discordjs/discord.js/blob/stable/src/structures/interfaces/TextBasedChannel.js#L234 (which is pretty much the same to how ClientUser#typingIn() does it)

dusk dagger Apr 29, 2020, 9:46 AM

#

Hey, hope it's the good channel to ask. I'm wondering if the fetch function is of any use in the RoleManager. As of my understanding, the cache should basically always be up-to-date, so is there a reason the method exist?

Source of what I'm talking about is there: https://github.com/discordjs/discord.js/blob/stable/src/managers/RoleManager.js#L48

tacit crypt Apr 29, 2020, 9:55 AM

#

Not everyone keeps everything cached and there's no issues having a fetch method just in case

dusk dagger Apr 29, 2020, 10:00 AM

#

What do you mean by "not everyone keeps everything cached"? Is the cache opt-out? And so, would you recommend using fetch() over cache.get()? That was my understanding that is was the preferred approach but wanted to be sure.

tacit crypt Apr 29, 2020, 10:42 AM

#

No, the cache isn't "opt-out" but some people might manually clear the cache

dusk dagger Apr 29, 2020, 10:45 AM

#

Alright. But either way, the best practice would be to use fetch, right?

tough geode Apr 29, 2020, 10:51 AM

#

not unless you modify cache. cache should always be up-to-date, as you said earlier, too.

dusk dagger Apr 29, 2020, 11:01 AM

#

I know I'm exaggerating, but is there any way that the cache would somehow miss roles? Packet loss, problem with the Discord API, or whatever? A very rare occurrence, but still possible?

copper laurel Apr 29, 2020, 11:04 AM

#

not really no

dusk dagger Apr 29, 2020, 11:11 AM

#

So fetch is only there as a short-hand and if we manually remove entries from the cache, then. Got it, thank y'all

rigid trail Apr 29, 2020, 12:09 PM

#

its also there for api coverage

#

just like guild manager and channel manager's fetch, its not much use to most people but some people may use it and the library should allow users to be able to use the whole api

umbral aspen Apr 29, 2020, 2:50 PM

#

Ah, I didn't notice that. Thanks for informing me, @real jetty. \👍

snow crypt Apr 29, 2020, 10:28 PM

#

what is the reason for dynamic in image options being false by default?

copper laurel Apr 29, 2020, 10:33 PM

#

breaking changes most likely

snow crypt Apr 29, 2020, 10:36 PM

#

thought of that, but why wouldn't it be true by default in the first place?

orchid stirrup Apr 29, 2020, 11:42 PM

#

When was discord.js made?

outer night Apr 29, 2020, 11:51 PM

#

This isn't a question exactly appropriate for this channel, but the first commit of discord.js was Aug 9, 2015

#

If you have more questions about the history of discord.js please ask in #archive-offtopic

ornate topaz Apr 30, 2020, 6:27 AM

#

@snow crypt well, because it would be breaking. before dynamic you would always get an image in format you wanted ({ format: 'png' }). Since png is not gif, you get png.
To get a gif when person has it, and a png when person doesn't have it, you would have to check if avatar hash starts with a_ and pass format appropiatelly. That's exactly what dynamic does.
if it would be true by default, you would have exactly 0 idea why the hell you pass { format: 'png' } and get a gif, but only for few people.

snow crypt Apr 30, 2020, 6:47 AM

#

didn't know dynamic didn't exist when the initial switch to functions was done, makes sense

drifting knot Apr 30, 2020, 8:13 PM

#

discord.js-next/pull/24 is just updating a lockfile and adding 2 empty typescript files

surreal geode Apr 30, 2020, 9:32 PM

#

It's a WIP PR. It's to track changes by that contributor

ornate topaz Apr 30, 2020, 10:34 PM

#

Draft PRs exist, and this one isn't marked as one. is your #25 also wip for tracking, or is it somewhat ready?

rigid trail Apr 30, 2020, 10:36 PM

#

there isnt even much you can do with the pr when there is no rest, no client, and no gateway lol

copper laurel Apr 30, 2020, 10:51 PM

#

I should also point out that any PRs which are nothing more than a copy-pasting or port of existing code with some type annotation slapped on are unlikely to be accepted

surreal geode May 1, 2020, 5:31 PM

#

@ornate topaz It's for tracking. @copper laurel I know it might not be accepted

ornate topaz May 1, 2020, 10:14 PM

#

@surreal geode If it's for tracking, why is it not marked as draft? Draft PRs are unmergable until marked as ready

surreal geode May 1, 2020, 11:55 PM

#

Oops sorry. It's marked as draft now

topaz mango May 2, 2020, 12:16 PM

#

Should docstrings for Collection mention that sort and sorted are stable starting with Node 12?

snow crypt May 4, 2020, 8:10 AM

#

Shouldn't there be a clone method for MessageEmbeds?

#

also freeze

#

more like permissions handle it

#

that would also prevent actual embeds from actual message be changed

topaz mango May 4, 2020, 8:14 AM

#

You can already do new MessageEmbed(embedToClone)

lofty birch May 4, 2020, 8:16 AM

#

I've seen this, and seen that the default method is process, just wondering what would be better about using process vs worker? https://discord.js.org/#/docs/main/stable/typedef/ShardingManagerMode

topaz mango May 4, 2020, 8:17 AM

#

Also, worker threads are not experimental anymore since Node 12.x

snow crypt May 4, 2020, 8:26 AM

#

@topaz mango i know, but you can also do new Permissions(permissionsToClone), but as they can be frozen, the methods check for it and operate on clone if frozen

#

shouldn't this be done with embeds too?

#

also, it's non-breaking to update

topaz mango May 4, 2020, 8:29 AM

#

What's the use case?

snow crypt May 4, 2020, 8:30 AM

#

same as for permissions

#

making Message#embeds array elements to be frozen

#

see as GuildChannel#permissionsFor returns a Readonly<Permissions>, because both memberPermissions and rolePermissions (internal) call .freeze() on the permission before returning

slate nacelle May 4, 2020, 8:32 AM

#

Making Message#embeds contain frozen elements is breaking.
As much as I'd like them to be frozen.

snow crypt May 4, 2020, 8:37 AM

#

@slate nacelle how is it?

#

the interface would be the same

#

but MessageEmbed methods would check if it is frozen, and if it is - return a modified clone

#

again, like bitfields do

slate nacelle May 4, 2020, 9:07 AM

#

They'd no longer return this but a new embed, changing it's behaviour in a non backwards compatible way.

topaz mango May 4, 2020, 11:26 AM

#

Does https://github.com/discordjs/collection have a minimum Node requirement?

#

Context for the question: I want to either clarify (if Node below 12 is supported) or remove the mention of sort being not necessarily stable.
Because in Node 12+ it should be stable.

snow crypt May 4, 2020, 12:09 PM

#

@slate nacelle oof

#

well

#

can we have a branch for breaking changes on v12?

raven juniper May 4, 2020, 12:10 PM

#

That's v13, aka next

snow crypt May 4, 2020, 12:33 PM

#

but next is gonna be ts

#

and unit tested

#

and more

#

i mean a branch parallel to master, but that accepts breaking changes

rigid trail May 4, 2020, 12:34 PM

#

but semantically that would be v13, which is djs next

topaz mango May 4, 2020, 12:35 PM

#

So no further breaking changes are expected to the current codebase? Even if Discord does something unexpected to the API that needs them?

rigid trail May 4, 2020, 12:35 PM

#

it is highly unlikely discord will make unexpected breaking changes to the api and require people to bump to the new api version

#

but no, v12 will not have breaking changes

topaz mango May 4, 2020, 12:38 PM

#

By definition, yes. My question is "can there be a v13 before d.js-next gets ready".

rigid trail May 4, 2020, 12:39 PM

#

im no dev but for that to happen djs-next would have to be made v14, @slate nacelle would that be acceptable in the unlikely event discord required breaking changes

slate nacelle May 4, 2020, 12:43 PM

#

No clue, we'll see it if it comes.

snow crypt May 4, 2020, 1:20 PM

#

@rigid trail can't it just be pre-v13-dev or something?

rigid trail May 4, 2020, 1:20 PM

#

wtf its still v13

#

semantically its v13 and djs next would be v14

snow crypt May 4, 2020, 1:24 PM

#

still feels like it should exist

copper laurel May 4, 2020, 1:47 PM

#

If there is a need for a breaking change, then PR it to master and a v13 will have to be released

#

The one being discussed here however is really not worth a semver major bump on its own

humble wyvern May 4, 2020, 2:07 PM

#

I saw, by doing a mistake in my code, that GuildMember.hasPermission(permission) doesn't throw any error when the permission isn't in the good format (for example, a typo in the permission flags).
The execution just stop silently.
I wonder if it's useful to open a PR to fix that or if it's just done on purpose? I hope it's the good channel for, if not, really sorry (don't hesitate to @ me)

lofty birch May 4, 2020, 2:16 PM

#

doesn't occur for me

#

(owner and admins will always return true unless you specify to discount that)

humble wyvern May 4, 2020, 2:18 PM

#

My precise mistake was :

message.guild.me.hasPermission("VIEW_AUDIT_LOG,MANAGE_WEBHOOKS", {checkAdmin : true})```
In guild where the bot didn't get admin permission, the execution just silently stopped without any message error (don't ask my why I did add it this way...)

lofty birch May 4, 2020, 2:20 PM

#

humble wyvern May 4, 2020, 2:20 PM

#

It's most probably an edge case

#

Strange

topaz mango May 4, 2020, 2:20 PM

#

Probably you're eating exceptions somehow without displaying

humble wyvern May 4, 2020, 2:22 PM

#

I log all unhandledRejection, but I will take a better look. Happy to see it's not due to d.js, and my bad k3llyOK

#

Thanks and sorry Sweat

surreal geode May 4, 2020, 2:55 PM

#

I don't think that's how bitfields work

#

Pass in an array ['VIEW_AUDIT_LOG', 'MANAGE_WEBHOOKS'] instead

frozen bridge May 4, 2020, 8:53 PM

#

Are Discord API endpoint changes going to be added to v11?

unique axle May 4, 2020, 8:56 PM

#

Oct 7th: intents are required - will not be happening for v11
Nov 7th: domain changes are required - doesn't really matter as v11 is already not usable anymore

drifting knot May 5, 2020, 12:18 AM

#

in djs 12 Manager#fetch is typed as Promise<Thing>, where Thing could be a user/channel/whatever. this is assuming that the fetch operation always succeeds and finds something. is this by design or a mistake?

rigid trail May 5, 2020, 12:22 AM

#

its not assuming that, the promise could reject

drifting knot May 5, 2020, 12:29 AM

#

does the promise reject when the snowflake isn't found

#

looking at source code, no

#

god i can't wait until djs next is released and i can bathe in first class ts support

opal mauve May 5, 2020, 12:32 AM

#

not sure what specific manager you're referring to, but at least the channel manager seems to have the appropriate logic

copper laurel May 5, 2020, 1:01 AM

#

Yeah not seeing the issue, most will include a call like this: const data = await this.client.api.users(id).get()
That handles and throws DiscordAPIErrors, so the fetch call, which is just an async function, would reject

snow crypt May 5, 2020, 8:59 AM

#

Shouldn't channel type group be removed?
bots can't be added to group dms, so kinda seems like a weird choice to keep it

lofty birch May 5, 2020, 9:02 AM

#

They could be added to group dms before iirc, so some still may be there

slate nacelle May 5, 2020, 9:03 AM

#

Bots can fetch invites to group dms, which yields you such a channel.

snow crypt May 5, 2020, 9:04 AM

#

oh, ok

snow crypt May 5, 2020, 2:37 PM

#

@slate nacelle continuing the embed discussion, what if we added .clone() that just returns a new this.constructor(this)

#

or add freezing, but not freeze current non-frozen stuff

copper laurel May 5, 2020, 11:16 PM

#

.clone() would be redundant, just construct it normally. The whole thing is currently non-frozen so you can't add freezing to it

snow crypt May 6, 2020, 6:16 AM

#

Why is https://github.com/discordjs/discord.js/pull/2910 not being merged?

snow crypt May 6, 2020, 12:42 PM

#

@slate nacelle why do you check if the max listeners are not zero?

slate nacelle May 6, 2020, 12:43 PM

#

Because 0 is used as "no limit", incrementing would set the limit to 1, decrementing it would throw.

snow crypt May 6, 2020, 12:43 PM

#

and what about #2910?

real jetty May 6, 2020, 6:43 PM

#

Would a pr that set the default id of fetch to 0 be useful ? I say that because when you do not provide anything it returns a 404 instead of 'uknown user'

rigid trail May 6, 2020, 6:44 PM

#

it would be a breaking change

real jetty May 6, 2020, 6:45 PM

#

Why ? 🤔

rigid trail May 6, 2020, 6:45 PM

#

it changes the response

real jetty May 6, 2020, 6:46 PM

#

yes I see 🤔

snow crypt May 6, 2020, 9:04 PM

#

@opaque robin could you add what space requested in #4103? I really wanna see it merged

#

also, the d.js error is not imported

loud moat May 6, 2020, 10:02 PM

#

Why doesn't it throw an argument error if you call fetch without passing an user object instead of doing a bad request?

copper laurel May 6, 2020, 10:05 PM

#

This seems more like a support question, but you'd really need to be more specific about which fetch endpoint at least, there are a lot

rigid trail May 6, 2020, 10:06 PM

#

that would be breaking btw, so that could not be changed either ways

loud moat May 6, 2020, 10:08 PM

#

I was replying to the thing above

obsidian copper May 7, 2020, 1:27 AM

#

https://github.com/discordjs/discord.js/issues/4151 any ideas on the situation with this?

#

Causing major problems with one of my shards right now, sending 3 messages per command

copper laurel May 7, 2020, 1:29 AM

#

There's an open PR aiming to fix it

obsidian copper May 7, 2020, 1:31 AM

#

Alright ^ ty

opaque robin May 7, 2020, 5:42 AM

#

@snow crypt k I’ve just been busy with other stuff

tawny warren May 7, 2020, 7:57 AM

#

i have a suggestion for a future version: a user/guildmember hybrid object without an user property

#

my reasoning: intents can get messy and sometimes member.user can return undefined and everything goes downhill

copper laurel May 7, 2020, 8:52 AM

#

There's a few issues with that. First of all, the User and GuildMember objects/endpoints are completely different in the Discord API - they aren't a hybrid and as an API wrapper, it wouldn't be a correct implementation.
Second, while in theory a GuildMember object could extend User and include those properties, its not a good design pattern. It means we'd have to update every GuildMember hybrid object whenever a shared User property changes, instead of just the single User object which is referenced by member.user

#

In a broader sense about your concern with intents - I agree. The way discord.js is currently built does rely a lot on its internal caches for a lot of things, and those need specific intents in order to be filled and for that functionality to work. Making any changes to that behaviour would be huge, and almost definitely breaking. It'll be considered as part of the discord.js-next / v13 rewrite

snow crypt May 7, 2020, 1:59 PM

#

@slate nacelle how is it cached?

tawny warren May 7, 2020, 7:27 PM

#

isn't it there a way to iterate through getters/setters and peoperties and attach them to an object so the references are kept? or i just understand the core of references wrong?

snow crypt May 7, 2020, 7:37 PM

#

you could use what is called delegation

#

so when you access member.tag it will actually be member.user.tag

#

?npm delegates

rich iglooBOT May 7, 2020, 7:38 PM

#

snow crypt May 7, 2020, 7:38 PM

#

but there's really no reason for that

drifting knot May 8, 2020, 6:55 AM

#

i was going to write up some TS enums with pretty comments for gateway opcodes, where would those files belong in the ideal djs@next repo?

snow crypt May 8, 2020, 8:36 AM

#

@drifting knot i guess it will be the types package

drifting knot May 8, 2020, 8:43 AM

#

thought so

#

will open PR in a day or so

digital hawk May 8, 2020, 10:39 AM

#

would this affect d.js https://github.com/npm/rfcs/blob/latest/accepted/0025-install-peer-deps.md

#

npm v7 looks like it will install peerdeps automatically

#

and I know d.js has peerdeps which might conflict like sodium and libsodium

snow crypt May 8, 2020, 11:40 AM

#

sounds critical

#

maybe opening an issue would raise more attention

exotic flicker May 8, 2020, 11:41 AM

#

there are some solutions in the file, I guess we would need to do some of those

snow crypt May 8, 2020, 3:02 PM

#

are private props in WebSocketShard intentionally not shown in the docs?

exotic flicker May 8, 2020, 3:02 PM

#

what props are you referring to?

snow crypt May 8, 2020, 3:03 PM

#

anything defined with Object.defineProperty

#

https://github.com/discordjs/discord.js/blob/master/src/client/websocket/WebSocketShard.js#L118

slate nacelle May 8, 2020, 3:05 PM

#

Probably not

snow crypt May 8, 2020, 3:07 PM

#

pr incoming blobreach

tacit crypt May 8, 2020, 4:16 PM

#

All of those are private props you don't need access to

#

I guess they're missing an @name although then again; you won't need those variables ever

vernal atlas May 8, 2020, 5:07 PM

#

@snow crypt i think both would be the better option

#

the fix i suggested also fixes another issue i mentioned here a couple days ago

snow crypt May 8, 2020, 5:09 PM

#

which one?

vernal atlas May 8, 2020, 5:09 PM

#

to where calling suppressEmbeds throws an API Error if you have the allowedMentions client option enabled, and said message is authored by another user

tacit crypt May 8, 2020, 6:06 PM

#

If the content isn't present

#

👀

vernal atlas May 8, 2020, 6:06 PM

#

well, i tested passing undefined, but that removed the mentions

#

instead of keeping them

tacit crypt May 8, 2020, 6:07 PM

#

That sounds like an API bug

vernal atlas May 8, 2020, 6:07 PM

#

could be

tacit crypt May 8, 2020, 6:08 PM

#

~~aka test it and report tbh~~

vernal atlas May 8, 2020, 6:14 PM

#

ah, no i was mistaken before, both null and undefined do the same

thorny copper May 9, 2020, 8:57 AM

#

I don't know if it's already been asked, but it'd be awesome to have a property User#nitroType which returns either 0, 1 or 2, as API returns, or <null>, NITRO_CLASSIC or NITRO

unique axle May 9, 2020, 9:04 AM

#

nitroType requires an authenticated request (through oauth2, with the identify scope). As we do not provide any utility for oauth2 requests having such a field would not bring much if any benefit
All the information a API request from a bot for a user returns:

{
  id: '83886770768314368',
  username: 'Souji',
  avatar: 'c97d04911a8bc6f059900e913649fd1b',
  discriminator: '0001',
  public_flags: 640
}

ref(oauth2): https://discord.com/developers/docs/topics/oauth2

thorny copper May 9, 2020, 9:09 AM

#

GET /users/{user.id} doesn't require oath. Otherwise, how could you return User#locale?

copper laurel May 9, 2020, 9:24 AM

#

That endpoint doesn't, but when requested by a bot token, it does not return information such as locale and nitroType. Retrieving that data does require full OAuth, as Souji said

thorny copper May 9, 2020, 9:26 AM

#

Then how do you return User#locale?

unique axle May 9, 2020, 9:29 AM

#

the full return from that endpoint is in my initial response.
we also can not provide the locale, despite it being documented it will always be null, there used to be a dummy value for bots which was provided, however this is no longer true
the property still existing in the library is an oversight

thorny copper May 9, 2020, 9:34 AM

#

Sad :c

#

Thanks

#

Can we hope that, one day, we can have support for oauth2 requests?

lofty birch May 9, 2020, 9:44 AM

#

That requires a web server, which is not the purpose of djs.

unique axle May 9, 2020, 9:47 AM

#

unlikely, discord.js is a wrapper for the Discord bot API
the purpose of oauth2 is to grant a token to do requests as the user, which is no longer part of the bot API
the request also requires an endpoint for the redirect

thorny copper May 9, 2020, 9:48 AM

#

ok, thanks

digital hawk May 9, 2020, 1:57 PM

#

maybe opening an issue would raise more attention
@snow crypt i'll open an issue when npm v7 is close to release as rn the latest seems to be 6.14.5

snow crypt May 9, 2020, 1:58 PM

#

@digital hawk open it now so we can fix it ahead of time

digital hawk May 9, 2020, 2:01 PM

#

ok

strange igloo May 9, 2020, 5:25 PM

#

Hey, quick question regarding one of the library dependencies
The choice of node-fetch for > 12.x has any particular reason beside snekfetch being deprecated?

#

Okay, thanks 👌

lofty birch May 10, 2020, 1:09 PM

#

Either way one that works some of the time would be better than none at all

real jetty May 10, 2020, 1:09 PM

#

A fix really isn't that hard, it just seems like they made a mistake while implementing

#

I can PR one, I just wanted to know the reason why it got removed before I open one

tacit crypt May 10, 2020, 1:16 PM

#

There will be proper rest stack traces once I get to actually re-doing my REST PR

#

space pls

real jetty May 10, 2020, 1:17 PM

#

Ahh great! Then I won't open a PR

wild flax May 10, 2020, 6:03 PM

#

It's nice that you can, but please don't be overconfident and think we didn't have internal discussions and trials before reverting it.

#

It wasn't "just" a silly mistake. Also theres performance implications with async stacktraces on top.

lofty birch May 10, 2020, 6:05 PM

#

could be nice to have an option to use async stacktraces then, so it's off by default, but can be enabled

wild flax May 10, 2020, 6:06 PM

#

No such thing without a working implementation

ornate topaz May 10, 2020, 6:07 PM

#

why have a feature that doesn't work all the time? you would explicitly enable async traces, just to get that [object Object] when you least expect it

tacit crypt May 10, 2020, 6:31 PM

#

Altering the stack trace isn't the solution

#

And it only works in v8 and not in any browsers that don't run v8b(like Mozilla or Safari)

#

The solution is implementing something that doesn't mess with the stack

tender field May 11, 2020, 9:06 AM

#

In which case there can be multiple activities to a presence ? (=> Why is it an array (GuildMember.presence.activities) ?)

lofty birch May 11, 2020, 9:08 AM

#

Custom Status + Other presence

unique axle May 11, 2020, 9:09 AM

#

many more cases actually, discord just sends all activities, no matter which are displayed in the client GUI
spotify, games, code editors, custom status, etc.
this used to not be the case, but was added as feature (by discord) around the time when v12 neared end of development

tender field May 11, 2020, 9:11 AM

#

oh ok thanks... ^^

#

maybe that should be written in the docs, because it is not really clear when this can happen ^^

tacit crypt May 11, 2020, 9:25 AM

#

Simplest example would be rich presence and spotify

real jetty May 12, 2020, 1:28 AM

#

has something been done about this, bots can ping roles now

#

i'm in a bit of a panic since this is going to lead to some serious abuse

#

disabledmentions doesnt seem to have anything to stop role pings right now

#

other then not formatting them at all

#

or maybe i'm just stupid

ornate topaz May 12, 2020, 1:29 AM

#

https://canary.discordapp.com/channels/222078108977594368/222078108977594368/693190178965159956

real jetty May 12, 2020, 1:31 AM

#

Shouldn't that mean it's off by default?

#

I updated discord.js quite recently so something seems off

ornate topaz May 12, 2020, 1:33 AM

#

yes, by default it's not set

#

just like disableMentions is

real jetty May 12, 2020, 1:33 AM

#

So should I just set allowedMentions to 'none' in the client

#

Docs said it's the default value but maybe I'm just reading it wrong

#

I tested and other bots seem to be able to ping as well

#

Oh - I figured it out. Sorry to bother aquaDerp

real jetty May 12, 2020, 7:19 PM

#

Hi there, I was wondering about support for the new js runtime, deno. It hasn't hit its 1.0 release yet, so i understand if development hasn't started yet, but I think it would be interesting to see a d.js module for deno

#

If not, i'd be happy to help when deno gets released. good learning opportunity for me :P

vernal atlas May 13, 2020, 6:50 AM

#

regarding the issue #4284, this seems to be the problem, https://github.com/discordjs/discord.js/blob/2583ad5da7db5ab92dfa357909f9c713db0a2981/src/structures/Message.js#L479-L484, but why was that even done in the first place? seeing as it causes the event to be emitted twice

#

or at least, done in a way that emits the event

vernal atlas May 13, 2020, 9:13 AM

#

g#4121

rich iglooBOT May 13, 2020, 9:13 AM

#

real jetty May 13, 2020, 11:11 AM

#

@vernal atlas methods that cause an event to be emitted called the handler itself as a fallback (for cases when the ws wasn't connected or w/e), the handler then has some logic that checks if its alr been handled but that seems to be missing on MessageReactionAdd. there was a discussion a while ago about always assuming the ws event would come thru and not call the handler itself but instead handle the response within the method itself to avoid double emissions (which was done on Message#delete() / TextBasedChannel#bulkDelete() a couple of months ago iirc) so #4285's approach seems fine except it needs to call MessageReaction#_add

vernal atlas May 13, 2020, 11:12 AM

#

KidThumbsUp

opaque vessel May 13, 2020, 1:44 PM

#

Hi hi! Would I be right in stating this thrown TypeError is improper?
https://github.com/discordjs/discord.js/blob/master/src/managers/GuildMemberRoleManager.js#L93

It has a grammatical error: TypeError [INVALID_TYPE]: Supplied roles is not an Role, Snowflake or Array or Collection of Roles or Snowflakes..

The other TypeError just above on line 85 seems fine though! In comparison, the latter TypeError includes all possiblities of the accepted types, but the former TypeError doesn't include them all which I'm not sure is intentional 😅

snow crypt May 13, 2020, 1:46 PM

#

I have no idea why it would say an role and not a role

opaque vessel May 13, 2020, 1:46 PM

#

The boolean adds the "n" here >:

snow crypt May 13, 2020, 1:47 PM

#

thonk

#

ok another pr incoming

#

are there any other places where this happens?

opaque vessel May 13, 2020, 1:48 PM

#

I'm not sure sorry 😅 I just came across this one

topaz mango May 13, 2020, 2:32 PM

#

@snow crypt There are multiple cases where it's erroneously before "User"

snow crypt May 13, 2020, 2:33 PM

#

@topaz mango you mean "an user" and not "a user"

topaz mango May 13, 2020, 2:33 PM

#

Yes

snow crypt May 13, 2020, 2:33 PM

#

where

topaz mango May 13, 2020, 2:33 PM

#

2x GuildChannel.js, 1x PermissionOverwrites.js

#

And 2x in GuildMemberRoleManager.js as mentioned

#

Checked all other instances of 'INVALID_TYPE'

snow crypt May 13, 2020, 2:39 PM

#

thanks!

#

updated

real jetty May 13, 2020, 9:16 PM

#

hey another weird question, is there any planned support for guild video? or can bots not use that feature?

#

it would make sense if bots cant use it lol

#

I remember seeing a while back though that someone was working on VP9 support for d.js. Not sure if that's still happening

snow crypt May 14, 2020, 5:51 AM

#

would djs@next have oauth built-in?

ornate topaz May 14, 2020, 6:05 AM

#

https://canary.discordapp.com/channels/222078108977594368/682166281826598932/708615479689740349

snow crypt May 14, 2020, 6:08 AM

#

👌

#

maybe we could have a separate library (similar to how discord-rpc is handled) for oauth?

ornate topaz May 14, 2020, 6:11 AM

#

https://www.npmjs.com/package/passport-discord

snow crypt May 14, 2020, 6:17 AM

#

ornate topaz May 14, 2020, 6:17 AM

#

i don't remember discord's oauth changing much since then

#

also, it's a module for passport-oauth2, which is a module for Passport, which is not a small project anyway, and actually made around auth

copper laurel May 14, 2020, 6:18 AM

#

it hasnt, its also just a tiny number of endpoints

snow crypt May 14, 2020, 6:19 AM

#

but js' interface has

ornate topaz May 14, 2020, 6:19 AM

#

ok?

#

doesn't mean we have to fork and rewrite everything every year

snow crypt May 14, 2020, 7:01 AM

#

Is there a way to type bitfield flags better than having public static FLAGS: Record<BitFieldString, number>; in every bitfield class?

#

if it was not static maybe we could have public static FLAGS: Record<S, number>; on the base bitfield class, but i'm not sure typescript would allow that

vernal atlas May 14, 2020, 7:34 AM

#

like this? yeah thats not a thing

snow crypt May 14, 2020, 7:40 AM

#

👍

noble magnet May 14, 2020, 8:22 AM

#

Will discord.js be compatible with deno ?

copper laurel May 14, 2020, 8:23 AM

#

We don't know. We haven't tried. If it isnt compatible at this stage we have no plans for it

strange igloo May 14, 2020, 8:26 AM

#

Having a deno-compatible library would require discord.js to get rid entierly of the "CommonJS" module format (require/module.exports) so I'd say that it's dead already for v12
However, I think v13 would be deno-ready with some tweaks (there could be a community fork ??)
But anyway it's not recommended to run production apps with Deno yet as it is still young
This also assumes all dependencies used by discord.js would be deno-ready too

warped crater May 14, 2020, 8:34 AM

#

v13 is being built on Typescript either way

#

so Deno support should be much less of a hustle there

copper laurel May 14, 2020, 8:47 AM

#

The current answer is still very much "no plans, hasnt been discussed"

lofty birch May 14, 2020, 8:14 PM

#

Saw this message from night so may want to take note https://cdn.discordapp.com/attachments/569679825988485130/710583619462365364/unknown.png

outer night May 14, 2020, 8:16 PM

#

yeah we were aware, a patch will be released

deep heart May 15, 2020, 9:25 PM

#

I am currently on discord.js version 11.6.4, does version 12 have any must have improvements in speed or something for me to try refactoring ?

exotic flicker May 15, 2020, 9:26 PM

#

not a topic for this channel
there are improvments, but d.js 11 will break anyway as soon as discord enforces intents

deep heart May 15, 2020, 9:35 PM

#

so i am forced to refactor it, fluck !

ornate topaz May 15, 2020, 9:37 PM

#

also there are features which v11 simply doesn't have

fallen arrow May 16, 2020, 11:07 PM

#

is there a reason for not implementing GET guilds/:id/channels?

real jetty May 16, 2020, 11:16 PM

#

All channels (except for DM, which is user.createDM()) are always cached, so there is no need to fetch them

#

But client.channels.fetch(id) is a method on V12

fallen arrow May 16, 2020, 11:18 PM

#

yes, but for the sake of api coverage

real jetty May 16, 2020, 11:24 PM

#

That could be said about more stuff, kicking a member with ID directly and editing an uncached message with channel and message ID for example

fallen arrow May 16, 2020, 11:47 PM

#

fair enough

vernal atlas May 17, 2020, 7:22 AM

#

~~you could always use the (private) client.api for making requests to endpoints not covered

eg: client.api.channels(id).get(), or client.api.guilds(id).members(id).delete(); (kicks a member)~~

mb, read below

unique axle May 17, 2020, 7:29 AM

#

do note however that you should not use (or suggest) the use of private apis for production applications as they are not part of the guarantees semver provides.
even a patch level update to the library may heavily change behaviour of or even move or fully remove private properties and methods without documenting the change in any changelogs

simple veldt May 17, 2020, 7:48 AM

#

Hello
Is someone working on the templates? I see there is a PR for discordpy

copper laurel May 17, 2020, 9:27 AM

#

No, bots do not have access to that endpoint

tacit crypt May 17, 2020, 1:18 PM

#

Bots can only fetch templates via /guilds/templates/:id

unique axle May 17, 2020, 2:31 PM

#

the PR in question (probably https://github.com/Rapptz/discord.py/pull/2652) does just that, for us that'd be accept a "template" field in guild creation options, fetching the template data and posting it with the guild creation (maybe allowing overwrites through other options so you can adapt and build on top of the template)

calm garnet May 18, 2020, 1:46 AM

#

What does discord.js use for caching?

rigid trail May 18, 2020, 1:47 AM

#

collections (extended maps) managed by managers

calm garnet May 18, 2020, 1:47 AM

#

Hmm, alright.

#

Same for previous versions? v11, etc?

rigid trail May 18, 2020, 1:47 AM

#

no, v11 and earlier didnt have managers

calm garnet May 18, 2020, 1:47 AM

#

What did they use?

rigid trail May 18, 2020, 1:47 AM

#

just collections

calm garnet May 18, 2020, 1:48 AM

#

Ah, alright.

broken oak May 18, 2020, 9:20 AM

#

Any updates as to when https://github.com/discord/discord-api-docs/pull/1577 is going to be implimented?
Or rather when https://github.com/discordjs/discord.js/pull/4154 is going to be merged?

loud moat May 18, 2020, 9:45 AM

#

I don't think it's going to make it to the API. It isnt't solving issue it's supposed to solve (https://github.com/discord/discord-api-docs/issues/1574)

unique axle May 18, 2020, 10:49 AM

#

As per usual discord.js merges upstream changes once their documentation is finalized and merged
That's a misconception on your or that other persons end. This endpoint is not supposed to solve a global lookup, but make a guild member lookup work without requiring intents as per nights reply

strange igloo May 18, 2020, 12:34 PM

#

Hey, got a little question about the constructor for WebSocketShard
Why having set WebSocketShard#connectedAt's default using Object.defineProperty instead of just doing this.connectedAt = 0 ? thinkEyes
https://github.com/discordjs/discord.js/blob/master/src/client/websocket/WebSocketShard.js#L159
I may miss a point that I clearly don't see here

warped crater May 18, 2020, 12:36 PM

#

mdn, object.defineProperty

rich iglooBOT May 18, 2020, 12:36 PM

#

warped crater May 18, 2020, 12:37 PM

#

you'll see this used very often, it can allow for special behaivour, like making the property actually readonly writable: false (Which even results in an error if you try assigning in strict mode! otherwise just wont let you mutate), perhaps ennumerable, or just about anything

#

It is generally a good practice.

strange igloo May 18, 2020, 12:37 PM

#

Yes I know but in that case we just set its value to 0 and set it writable (aren't this.props things writable already... ?)

warped crater May 18, 2020, 12:39 PM

#

Please see the mdn page, this does have a positive effect as with the passed options connectedAt is configurable: false & enumerable: false implicitly

#

probably few other defaults im forgetting about

#

otherwise its probably just for consistency in the said constructor, d.js likes doing things the same way across the board (which is great)

strange igloo May 18, 2020, 12:41 PM

#

Oops my bad I didn't see the default values
I understand now

#

Thanks 😅

warped crater May 18, 2020, 12:41 PM

#

blobcatthumbsup

tacit crypt May 18, 2020, 2:23 PM

#

TL;DR: Almost anything that is set via defineProperty is done that way to be non-enumerable

vernal atlas May 18, 2020, 3:12 PM

#

why doesnt allowedMentions use UserResolvables?

slate nacelle May 18, 2020, 3:13 PM

#

It wasn't reliably possible to reference an isntance of UserManager (I think for WebhookClient).
Maybe it would be possible to refactor those (*Manager) to offer a static method to resolve to ID.

vernal atlas May 18, 2020, 3:13 PM

#

ah right

#

what about accepting user / guildmember objects?

slate nacelle May 18, 2020, 3:14 PM

#

The same reason, I'd rather not duplicate resolving logic (further).

vernal atlas May 18, 2020, 3:14 PM

#

oki

lofty birch May 20, 2020, 11:12 AM

#

https://canary.discordapp.com/channels/222078108977594368/682166281826598932/709031126605365288 In the meantime, does anyone know how I could go about doing this myself? I could really use proper stack traces atm

raven juniper May 21, 2020, 5:06 PM

#

Afaik the API does not provide that sort of data. You can parse it yourself by looking at the file extension

cunning flint May 21, 2020, 5:43 PM

#

hm okay, then it would be like Message#cleanContent method for example. It's not an information provided by API, but a method used to make things easier for developers.

#

But I understand your choice ^^

ornate topaz May 21, 2020, 6:02 PM

#

file extenstion in no way represents actual file type, yyou can take an .mp3 file, rename it to .pdf, but it doesn't magically make it a pdf.
Only way library could do that would be looking on extension, which from this reason could be inaccurate and misleading.

snow crypt May 21, 2020, 7:44 PM

#

@wild flax removing the change from my pr to avoid the conflict would just be removing it from package.json, right?

wild flax May 21, 2020, 7:44 PM

#

yes

#

well

#

just dont change the package.json is what i mean

snow crypt May 21, 2020, 7:45 PM

#

okay

#

done

snow crypt May 22, 2020, 7:41 AM

#

can we maybe expose the regexp in DataResolver#resolveInviteCode somehow?

#

such as Invite.PATTERN similar to MessageMentions'

viscid wasp May 22, 2020, 8:16 AM

#

Do you think we'd ever get a Deno version of Discord.js?

unique axle May 22, 2020, 8:27 AM

#

ctrl + f -> in:#library-discussion deno

snow crypt May 23, 2020, 1:57 PM

#

my question got buried :(, can anyone give an opinion?

simple veldt May 23, 2020, 2:15 PM

#

Hello
I'm using Discord.js with a jsdoc project, and I was getting the following error:

#

I added raw: [any]; to the ClientEvents interface, and it worked. Can I open a pull request to fix this or is that normal?

unique axle May 23, 2020, 2:16 PM

#

raw is an internal, unsupported and undocumented API and should not be included in typings

simple veldt May 23, 2020, 2:16 PM

#

All right
So it means we can't use this event using typescript... (or jsdoc in my case)?

unique axle May 23, 2020, 2:18 PM

#

you should not be using raw at all, the library provides a public and supported interface to deal with uncached reactions, partial structures https://discordjs.guide/popular-topics/partials.html

simple veldt May 23, 2020, 2:23 PM

#

I'm using this event in a package published on npm, and it's hard to tell people to pass a partials array when instantiating their Client class + if they are using the messageReactionAdd event somewhere, to check if the received param is not a partial object... it's a regret that it is not documented because it was still quite useful to me but I understand, thank you for your answer 👍

unique axle May 23, 2020, 2:24 PM

#

making third party packages that heavily rely on private and unsupported apis might not have been a good idea to begin with, they're not part of semver promises and might even be removed in path releases

simple veldt May 23, 2020, 2:28 PM

#

Yep
telling people to enable partials for the messageReactionAdd and messageReactionRemove event would probably be a better solution

real jetty May 23, 2020, 6:37 PM

#

https://github.com/discordjs/discord.js/pull/4162

what is the reason for the negative feedback on this PR? I personally like the idea, as it would make using custom events much simpler. Of course extending the interface is pretty simple but an inconvenience and as appellation said IDE auto complete should still work even after merging this

snow crypt May 23, 2020, 7:02 PM

#

@real jetty https://discordapp.com/channels/222078108977594368/682166281826598932/694116735422562344

wild flax May 25, 2020, 6:02 AM

#

I don’t understand the question. The reasons why are commented on the PR?

crimson harbor May 25, 2020, 10:16 PM

#

tl;dr: It has little to do with IDE autocompletion, they just want to discourage people from emitting custom events at all.
But since the PR is still open, you can leave your comments there and it might convince some more of the devs.

copper laurel May 25, 2020, 10:21 PM

#

That's a bold assumption which is mostly conjecture. Its not a discouragement - it just forces people to strictly type their custom events by extending the ClientEvents interface themselves, rather than add an openly weak typing to the interface.

halcyon field May 26, 2020, 10:12 PM

#

Discord current fetch message method isnt practical, there should be another option (like the limit: x) that allows you to only fetch messages from a specific user.
the issue with using the method as it is nowt is that you're limited by the messages fetched, that includes messages sent by another user so the messages the max messages fetched sent by the user you want is actually inferior to the max amount of messages fetched, on the other hand (mabye) having a specific option would allow us to have a limitation of fetched messages, yes, but all those messages are by the user you want them from.. no unnecessary messages, so there is no loss in max fetched - correct return

ornate topaz May 26, 2020, 10:13 PM

#

as far as i know, API does not give a way to fetch this way

merry python May 26, 2020, 10:13 PM

#

yes, this is an api limitation which discord.js on its own can not solve

#

you'll have to request that feature from discord itself

halcyon field May 26, 2020, 10:14 PM

#

I see, thanks for the advice

opaque copper May 26, 2020, 10:14 PM

#

this is the endpoint fetch uses, for reference @halcyon field https://discord.com/developers/docs/resources/channel#get-channel-messages

vernal atlas May 27, 2020, 3:54 PM

#

why is the CommandoMessage class in commando typed incorrectly? (https://github.com/discordjs/Commando/blob/bdbd84e2a978322f3af12c21e729eb7b7cd4a3dc/typings/index.d.ts#L150) shouldn't it extend Message and not take a message parameter in the constructor, as well as not have a message property

undone ravine May 27, 2020, 3:55 PM

#

Look at the master branch

vernal atlas May 27, 2020, 3:55 PM

#

im looking at the master branch?

#

undone ravine May 27, 2020, 3:56 PM

#

Ok, yes it should

vernal atlas May 27, 2020, 3:56 PM

#

but, why is it like that?

undone ravine May 27, 2020, 3:57 PM

#

Because it used to be like that

vernal atlas May 27, 2020, 3:57 PM

#

so the typings just havent been updated when the class itself was?

undone ravine May 27, 2020, 3:57 PM

#

Correct

vernal atlas May 27, 2020, 3:57 PM

#

ah

drifting knot May 29, 2020, 2:24 AM

#

will commando get the cool typescript rewrite when djs next is out

alpine pier May 29, 2020, 5:37 AM

#

Why is there no way to give a reason for a bulkdelete (https://discord.js.org/#/docs/main/master/class/TextChannel?scrollTo=bulkDelete) when theres one for the normal message.delete function (https://discord.js.org/#/docs/main/master/class/Message?scrollTo=delete) ? Is there none? is it just missing?

#

await this.client.api.channels[this.id].messages['bulk-delete'].post({ data: { messages: messageIDs } }); it calls this and im wondering if just putting a reason into data would do the trick.

ornate topaz May 29, 2020, 5:48 AM

#

doesn't look like

alpine pier May 29, 2020, 5:49 AM

#

Doesnt seem like it, as its merging these into one big entry in the audit logs so 5 and 5 deletes get 10 there

thorny cosmos May 29, 2020, 5:49 AM

#

I don't see any reason field in api docs, so that would be a no

alpine pier May 29, 2020, 5:50 AM

#

Well thats a bummer but ill have to live with it then. Thanks anyways

ornate topaz May 29, 2020, 5:51 AM

#

well, those also don't really mention it

#

however, blindly putting reason into data for bulk deleting does not give any reason in audit log no matter if it's new entry or not

deft elbow May 29, 2020, 5:33 PM

#

Channel name and topic updates are now ratelimited to 2/10m without headers.

ornate topaz May 29, 2020, 6:18 PM

#

We don't hardcode ratelimits though

rigid trail May 29, 2020, 6:19 PM

#

"without headers" 🤔, are you sure about this? discord enforcing ratelimits without a ratelimit header would be a pretty big change @deft elbow

slate nacelle May 29, 2020, 6:20 PM

#

They send headers, the usual PATCH /channels/:id headers.
If you hit the name limit you get your usual 429 still reporting the regular headers blobupsidedown

#

Smells like a Discord "bug".

rigid trail May 29, 2020, 6:20 PM

#

notLikeCat

slate nacelle May 29, 2020, 6:20 PM

#

Don't know what we use for the backoff limit

#

But telling "retry in 537s" AND "retry in 13s" seems bad.

rigid trail May 29, 2020, 6:21 PM

#

yeah i dont see discord doing this intentionally KEK

snow crypt May 30, 2020, 7:44 AM

#

Is v13 going to be more async, as less is going to be cached?

wild flax May 30, 2020, 9:08 AM

#

What does that even mean

snow crypt May 30, 2020, 9:18 AM

#

as per #3924, not specifying some intents would break discord.js

#

so is v13 going to be less cache reliant?

warped crater May 30, 2020, 9:19 AM

#

don't see why this is a concern atm

#

we don't even have the required components done (gateway & rest) to even put together a lib interface

wild flax May 30, 2020, 9:33 AM

#

It probably isn’t now

#

Because discord still wants libs to cache as much as possible

#

The main “discord.js” package will probably be not be fundamentally different

#

You’ll just have more control if you want to do your own thing

#

But that’s not a concern for us or the common user

harsh sage May 30, 2020, 1:58 PM

#

are there any plans to move the logic that handles REST requests to a separate module?

I've been trying to make my own request handler to deal with Discord's dynamic rate limits. It's so complex with the combination of bucket combined with global limits, alongside the number of remaining requests and the time to reset. i have no doubt my forehead creases have multiplied.

thought maybe I could just look at how the lib did it so well and found that it's quite tightly coupled to the client unfortunately

warped crater May 30, 2020, 2:08 PM

#

for v13 yes

lofty birch May 30, 2020, 10:04 PM

#

It's interesting how there is a method to eval something in the context of other shards, via client#shard#broadcastEval, but there's not a way to do so in terms of the manager. Was this done for a specific reason?

ornate topaz May 30, 2020, 10:09 PM

#

What? What would you eval on manager?

#

Or you mean sharding manager

lofty birch May 30, 2020, 10:10 PM

#

Sharding manager

ornate topaz May 30, 2020, 10:11 PM

#

Even then, sharding manager acts as a bridge between shards, There is not much you could do with it on its own

lofty birch May 30, 2020, 10:11 PM

#

I'd find it useful personally

ornate topaz May 30, 2020, 10:12 PM

#

For?

#

Again, what would having eval on sharding manager allow you to do that is impossible to achieve without it

lofty birch May 30, 2020, 10:15 PM

#

I use another service which I connect to via websocket. Currently each shard has to establish its own connection to fetch information. If I was able to just use one connection, on the manager, that would be very helpful to me in terms of reducing bandwidth and memory usage

surreal geode May 30, 2020, 11:31 PM

#

@ornate topaz I talked to space about about manager eval too. There isn't a way to get the Shard instances themselves or check if all shards are ready

ornate topaz May 30, 2020, 11:32 PM

#

technically, looking on v11 sharding manager, there is an message event, which apparently isn't on v12 one, yet there still is client.shard.send()

lofty birch May 31, 2020, 10:39 AM

#

I'm just wondering what is the purpose of Idle and Nearly, here? https://discord.js.org/#/docs/main/stable/typedef/Status

copper laurel May 31, 2020, 10:55 AM

#

Shards are constructed with the IDLE status. They get set to NEARLY during the checkShardsReady() function while fetching all members, if you have that enabled, and in the Shard#onOpen() function

lofty birch May 31, 2020, 10:56 AM

#

ah

thorn arch May 31, 2020, 11:54 AM

#

@unique axle So the official stance is that it should be impossible for a channel/user/etc to not exist in their respective cache, and therefore fetch() should never be necessary for a user to perform -- and if an object is somehow not already in the cache by the time someone attempts to access it, that's the bug

#

Did I get that correct?

snow crypt May 31, 2020, 11:55 AM

#

some structures are always cached

unique axle May 31, 2020, 11:55 AM

#

no, not etc.
guilds and channels are the only applicable cases
as the guilds are received on ready and updated as the websocket events come in and with them arrive the roles - also updated at the specific websocket events

thorn arch May 31, 2020, 11:55 AM

#

Ok, so guilds and channels should always be in cache

#

So then, for users, we should hit cache and then as a fallback use fetch?

snow crypt May 31, 2020, 11:56 AM

#

fetch will automatically check cache first, but yes

thorn arch May 31, 2020, 11:56 AM

#

Right ^^ this is what I was trying to point out earlier

#

that's the typical caching pattern

#

Attempt a fetch, and the fetch internally checks cache

#

Users (as in, programmers) going directly to cache is ... awkward? But ignoring that for a sec...

#

That means that for [discord] users specifically, you would recommend NOT using cache.get() but would recommend using fetch instead?

unique axle May 31, 2020, 12:01 PM

#

i don't really know why you make such a fuss about this

Manger#fetch tries to retrieve from cache, if not cached hits the api
Manager#cache#get retrieves from cache

there are some inconsistencies with structures that all arrive at once - guilds and channels - which do not need to be fetched
(unless you manually invalidate/update/sweep their cache)
but apart from that both hitting the api and not doing so have their respective use cases, you use what is right for the use case at hand

thorn arch May 31, 2020, 12:02 PM

#

The fuss is that the docs are misleading for people who don't fully understand the internals like you do, and I was trying to recommend updating them -- so now that you've explained it more, it seems like maybe the docs should recommend cache.get for guilds/channels and fetch for users? Though that is admittedly inconsistent

#

Though I will admit, in truth it seems like the docs barely "recommend" anything for how to get channels/guilds... So probably the more constructive thing now that I understand is to make a guide PR

unique axle May 31, 2020, 12:04 PM

#

if you have any suggestions as to what a cache guide should cover there is an issue on the guide https://github.com/discordjs/guide/issues/403 regarding this, of course feel free to pr something to resolve it as well
i'm not too sure how this should be reflected on the docs, as it is just a technical manual for the api exposed by the library

thorn arch May 31, 2020, 12:05 PM

#

Ha, yeah sounds like I should get along with Clemens-E 😄

#

Thanks for the issue pointer

unique axle May 31, 2020, 12:06 PM

#

cache access also has other implications that fetch just doesn't provide - our caches are Collections (a custom structure that builds on top of base js Map with additional array and set-like functionality)
if you were to just always recommend fetching you'd remove use cases of finding by name or other properties entirely

thorn arch May 31, 2020, 12:07 PM

#

There's not really anything wrong with the code here, it's really more of a style issue, or a "how is this supposed to be done" recommendation for newbies

unique axle May 31, 2020, 12:08 PM

#

so the entire fetch vs. get discussion really only comes up if you know the respective ids - which for a lot of users is not the use case they want to cover

thorn arch May 31, 2020, 12:08 PM

#

Yeah, so having a FAQ/guide page specifically for dealing with channels and users and such, where it details things like maybe "fetch if you have an ID you know you want" but also goes into like "here's an example of how to take advantage of the cache to do searching" would really resolve this

#

I can look at that

#

Because I searched for a while on that topic and it seems like an obvious one that people want to know (multiple people have asked me how to do this, which is why I started looking into it at all) and it wasn't even obvious to me at first what was going on

#

It was also the first thing I wanted to do -- create a hello world bot, that would simply connect to my server and send a message to a channel that said "hello" -- and it was surprisingly difficult to figure out how any of that worked

#

(the current guide is all about responding to messages where you already have all the objects handed to you from a message)

#

I'm about to sleep now, but in the morning I'll look at making a section for this in the guide -- maybe handling enough to close #403

#

though I might still be lacking on some of the specifics to answer the cache questions in TOO MUCH detail

#

But, ya'll could correct me in a PR if I get it wrong 😉

unique axle May 31, 2020, 12:15 PM

#

alright, this is going off topic again, these channels are for development discussion not experience reports of trying to write a bot
as said, feel free to PR changes you deem necessary, that's what github is for

real jetty May 31, 2020, 9:01 PM

#

I noticed a minor inconsistency with the type names for the image options:
The possible formats are called AllowedImageFormat while the possible sizes are called ImageSize when they should be called AllowedImageSize

Should I open a PR adjusting this?

copper laurel May 31, 2020, 10:06 PM

#

I mean... I guess. We don't treat typings as breaking changes because its a JS lib, but this would be breaking for TS users

tender field Jun 1, 2020, 12:35 PM

#

Is there any reason why there is no "BanManager" in the Guild class ? With its own fetch methods, a cache etc (instead of fetchBan and fetchBans)

tough geode Jun 1, 2020, 12:50 PM

#

it was planned as far as I know, but it would be a breaking change to introduce

rigid trail Jun 1, 2020, 12:56 PM

#

cache would be too unreliable

#

ban add events dont send the reason, and an accurate cache wouldnt exist unless you first fetch, rendering cache kinda useless

#

I actually implemented it but then scrapped it due to that reason

tender field Jun 1, 2020, 1:00 PM

#

oh ok thanks

oak quail Jun 2, 2020, 4:11 AM

#

how does discord.js handle content-specific ratelimits ("sub limits") like the new limit that's only on editing channel names and topics?

#

apparently there have been issues with libraries hitting the ratelimit then blocking all reqs to that endpoint/bucket

#

although other reqs to the endpoint will actually still work, as long as they aren't changing the channel name or topic

#

looks like there was a bit of discussion about it earlier here https://advaith.is-in-hyper.space/5dd8056d9a.png

#

basically, the retry_after in the response body and the retry-after header have the limit for the specific request, and the X-RateLimit- headers have the info for the whole endpoint/bucket

harsh sage Jun 2, 2020, 12:47 PM

#

are there plans to support distributed rate limiting? I saw https://github.com/spec-tacles/rest.js by appellation which looks perfect, but not sure if its related to future djs. Right now I have a bot running, and I'm pretty uneasy/paranoid about doing anything API-related with the same auth in a different application where I have no knowledge about the API limits that the running bot may be hitting

lofty birch Jun 2, 2020, 12:57 PM

#

iirc it uses the ratelimit headers so that's not needed

harsh sage Jun 2, 2020, 1:00 PM

#

I mean distributed rate limiting

#

d.js handles rate limits well in-house (in application memory), but outside applications have no knowledge about them - outside applications being other processes

lofty birch Jun 2, 2020, 1:03 PM

#

If you follow the headers also you should be fine

harsh sage Jun 2, 2020, 1:05 PM

#

well obviously - but my question is if discord.js plans to support distributed rate limiting in the future so if two bots login with discord.js with some central cache for store rate limit information like the link I put above

#

or even better, a modularized design like rest.js where we can send our own requests with our own routes into such a system so we can interact with the API ourselves without having to deal with the header logic ourselves

#

I'm not even sure exactly what routes djs may be hitting behind the scenes with a simple login and the events from intents (with nothing more), so just running with two bots of the same auth at the same time could result in constant 429 responses which in the past I have had terrible experience with

#

namely Discord blocking my IP for several hours

#

which makes me realize that even if you "follow the headers" but consistently get 429 by discord in two concurrent processes, you're still likely to get IP-blocked like I was

warped crater Jun 2, 2020, 1:19 PM

#

yep v13 is packaging it apart

#

@discordjs/rest will take care of rate limits probably

#

assuming some form of redis(?) store support is added for the current state than it should be ez pz to do cross app

harsh sage Jun 2, 2020, 1:27 PM

#

do you happen to know if the cached data that djs so selfishly keeps in its own process (a joke :P) will be accessible by others by Redis or any other way? this way, I won't even have to hit the API myself if it's available nevermind, I think this is what you meant by "current state", thanks. let the 5-year wait begin

snow crypt Jun 2, 2020, 3:36 PM

#

start contributing, it would take less time ;)

tacit crypt Jun 2, 2020, 4:07 PM

#

basically, the retry_after in the response body and the retry-after header have the limit for the specific request, and the X-RateLimit- headers have the info for the whole endpoint/bucket
@oak quail ...really? fan-fucking-tastic if so

snow crypt Jun 2, 2020, 5:10 PM

#

Why does GuildEmoji#fetchAuthor check the permissions?
https://github.com/discordjs/discord.js/blob/master/src/structures/GuildEmoji.js#L62
This is kind-of inconsistent with other methods, that just let your request fail.

#

"Fixing" this would probably be breaking, but why was it like that in the first place?

oak quail Jun 2, 2020, 6:33 PM

#

@tacit crypt yeah

#

and I tested it to figure out what the limit was the night before they sent the announcement lol, because night mentioned they added a limit

tacit crypt Jun 2, 2020, 6:37 PM

#

...grr

harsh sage Jun 2, 2020, 9:29 PM

#

I can look at contributing, though I can't seem to find anything about where v13 is

vivid field Jun 2, 2020, 9:32 PM

#

https://github.com/discordjs/discord.js-next is the current v13 repo

harsh sage Jun 2, 2020, 9:42 PM

#

ahh gotcha thanks

deft elbow Jun 2, 2020, 11:25 PM

#

Referring to https://discordapp.com/channels/222078108977594368/682166281826598932/717424966953336882, why dosen't discord.js do permission checks before sending most API requests?

ornate topaz Jun 2, 2020, 11:30 PM

#

Would mean that we would have to hardcode the permissions, and every day check if discord changed something

snow crypt Jun 3, 2020, 5:26 AM

#

but then again, why does GuildEmoji#fetchAuthor check?

ornate topaz Jun 3, 2020, 5:56 AM

#

https://github.com/discordjs/discord.js/pull/2788 i guess?

snow crypt Jun 3, 2020, 6:23 AM

#

doesn't this defeat not hard coding perms?

ornate topaz Jun 3, 2020, 8:20 AM

#

as far as i understand it wasn't put there just because it could, but because (as far as i understand from quick glance on code and pr description) api wasn't throwing but just didn't give the user object.
This was linked in the pr description:

we consider the uploader of emoji to be private data, which is why it is not exposed to anyone but users in a guild with MANAGE_EMOJIS permission via the API.
(https://github.com/discord/discord-api-docs/issues/593#issuecomment-386477863)

#

also note that i linked the pr not just to show that it happened then, but that it also included informations in description which would answer you.

snow crypt Jun 3, 2020, 9:09 AM

#

oh well, thanks for clarifying

#

discord, oh discord

snow crypt Jun 3, 2020, 7:35 PM

#

@tough geode in your last pr, the js .then(emoji => this._patch(emoji) || this.author); part is like doing ```js
.then(emoji => {
this._patch(emoji);
return this.author;
});

#

shouldn't that also be the latter for consistency?

#

   async fetchFlags() {
    if (this.flags) return this.flags;
    const data = await this.client.api.users(this.id).get();
    this._patch(data);
    return this.flags;
  }

tough geode Jun 3, 2020, 7:45 PM

#

right, and I should also probably return this.author if present

snow crypt Jun 3, 2020, 7:52 PM

#

you do

#

but just, less readable

tough geode Jun 3, 2020, 8:21 PM

#

I meant before making the request.

snow crypt Jun 3, 2020, 8:44 PM

#

oh yeah, good thought

vernal atlas Jun 3, 2020, 11:27 PM

#

#4329 seems be to be causes by these new channel edit ratelimits

#

i made 3 patch requests to a channel, and the 3rd one hit a 429

#

not actually sure if thats the exact cause but thats just something i found

#

perhaps a ratelimit header isnt being acknowledged properly? im not really sure exactly so that could be wrong

#

there seens to be an 'x-ratelimit-bucket' header that isnt ackknowledged? could that be it, prob being stupid but never really dealt with ratelimits and such

raven juniper Jun 4, 2020, 12:28 AM

#

iirc from discord developer server discussion, there's a bug with the headers not being sent or something

snow crypt Jun 4, 2020, 11:42 AM

#

4288 is sort of urgent

#

github does set redirects from old users and orgs, but i have no idea how much time they'd last before the links would be borked

warped crater Jun 4, 2020, 11:51 AM

#

It is mentioned somewhere, read it about a few weeks ago.

#

Github claims that the redirects never, under any circumstance, get borked, unless something else takes the name.

#

so for instance, didinele/x -> didinele/y will always work until I make a new repo with the name x, same for moving repo from a user to an org, same for renaming users/orgs

snow crypt Jun 4, 2020, 11:53 AM

#

ok, so not as urgent, if urgent at all

warped crater Jun 4, 2020, 11:54 AM

#

yup, unless someone somehow takes over discordapp that isnt the company and makes a new repo called erlpack it'll never bork

snow crypt Jun 4, 2020, 11:54 AM

#

because looks like @discordapp it also claimed by discord

oak quail Jun 4, 2020, 1:51 PM

#

@vernal atlas looks like 4329 is on sending messages, not editing a channel

#

and discord limited changing a channel name/topic to twice in 10 mins

#

discord.js might incorrectly limit editing the whole channel though

vernal atlas Jun 4, 2020, 4:28 PM

#

yeah, i tested and hit 429s on channel patch requests

#

consistently 5 or 6 times

#

mark said he recalls hearing the headers not being sent by the api

slate nacelle Jun 4, 2020, 4:46 PM

#

On the tests I made a few days ago 2 succeeding requests were made, a third 429'd (Discord does not tell us about this specific rate limit until it's too late), waited it out, and finally made the succeeding third request.

vivid field Jun 4, 2020, 6:02 PM

#

Is there a reason why https://github.com/discordjs/discord.js/blob/stable/src/structures/MessageMentions.js#L167 shows GuildMember separately even though it is already contained in UserResolvable? Also, why does it list Role | GuildChannel instead of their respective RoleResolvable / GuildChannelResolvable forms?

vernal atlas Jun 4, 2020, 11:55 PM

#

it doesn't seem like it accepts the resolvables at all, at least it doesn't resolve them using XManager#resolve

#

it would seem the docs are slightly incorrect there

#

typings could be too

copper laurel Jun 5, 2020, 12:23 AM

#

const id = data.id || data; this is how it resolves it

#

Because thats all Resolvables really are - the ID, or the object with the ID property

vernal atlas Jun 5, 2020, 12:37 AM

#

well

#

a UserResolvable type includes a Message

#

so passing a Message object in, according to the docs, should resolve into the author of that message

#

however, instead it would just always return false because it's checking for a message ID, not a user / role / channel id

#

(https://github.com/discordjs/discord.js/blob/d827544fbd12e827fb4b6ff99d8894ecd79ede02/src/managers/UserManager.js#L39)

copper laurel Jun 5, 2020, 9:42 AM

#

True

vivid field Jun 5, 2020, 10:33 AM

#

wouldn't changing it to js const id = (data.author && data.author.id) || data.id || data; make a message resolve to its author correctly?

slate nacelle Jun 5, 2020, 10:45 AM

#

Considering there is a reference to Client, UserManager#resolve would make more sense than more 🍝 resolving logic.

vivid field Jun 5, 2020, 10:48 AM

#

fair

#

so i guess this would look better? js const id = this.client.users.resolveID(data) || data.id || data;

snow crypt Jun 5, 2020, 12:32 PM

#

no need for that || data.id || data

#

resolveID takes care of that

vivid field Jun 5, 2020, 12:51 PM

#

it's still needed for roles and guildchannels

snow crypt Jun 5, 2020, 12:59 PM

#

shouldn't they also just use the respective resolvers?

vivid field Jun 5, 2020, 1:26 PM

#

GuildChannelResolvable and RoleResolvable are only the object and id, so it'd be kinda pointless

vernal atlas Jun 6, 2020, 8:08 AM

#

well you wouldn't need || data

#

since the resolveID method would return it if it was a string

ornate topaz Jun 6, 2020, 2:37 PM

#

except not really? if i'd pass a guildchannel object, UserManager.resolveID will call BaseManager.resolveID as guildchannel is not guildmember or message, and BaseManager.resolveID will check if idOrInstance instenceof this.holds, where idOrInstance would be my guildchannel object, and this.holds would be User class.
Since that if failed, we move to next one, which checks if typeof idOrInstance === 'string' (which returns from this cache using passed string - so again only user - or null if not in cache), but since this check is again falsy, BaseManager.resolveID returns null.

vernal atlas Jun 6, 2020, 7:07 PM

#

hm?

#

if you passed any string into XManager#resolveID it would return that string

#

which from my understanding is what || data is covering,

- const id = XManager.resolveID(data) || data.id || data;
+ const id = XManager.resolveID(data) || data.id```

#

https://github.com/discordjs/discord.js/blob/1c275afd7cee4b3663a04f77b0271ac80e927a5e/src/managers/BaseManager.js#L72

#

the resolve method returns from cache, but resolveID just returns the string

#

vivid field Jun 6, 2020, 7:13 PM

#

yeah, the || data is redundant here

#

i think that just using the resolvers for all three XResolvable types would actually be better to 1. make it more consistent and 2. make it accept changes to the XResolvable types without needing to change any code

vernal atlas Jun 6, 2020, 7:19 PM

#

yea

snow crypt Jun 6, 2020, 7:25 PM

#

p👏r 👏 it

real jetty Jun 7, 2020, 2:24 PM

#

can we expect bot's different activity per each guid as the option in future?

slate nacelle Jun 7, 2020, 2:25 PM

#

If Discord decides to implement such a feature, sure.

indigo nimbus Jun 9, 2020, 3:09 PM

#

May I suggest a modification to the current way you handle limits within Discord.js

Currently if I understood right, the way Discord.JS handle limits is that it try to make a call, then wait to see if it is rate limited then make another one if it is not limited, then if it is limited waits the replied amount of time then try again then send all the other calls in the queue in the same manner until it is rate limited therefor hitting the limits a lot if you make a lot of calls.

They way it could work would be to prevent hitting those limit by using the information in the reply header to limit the rate at which is sends call in a specific route to avoid hitting the limits. Therefor respecting what the API documentation request : https://discord.com/developers/docs/topics/rate-limits

Because we may change rate limits at any time and rate limits can be different per application, rate limits should not be hard coded into your bot/application. In order to properly support our dynamic rate limits, your bot/application should parse for our rate limits in response headers and locally prevent exceeding the limits as they change.

A warning could also be logged if the queue exceed a reasonable number of requests.

It is currently impossible for someone using Discord.JS as their wrapper to know what the limits are before hitting one. Which makes larger request impossible to do without hitting the limits or making them very slowly.

I believe that this change would improve the overall usability of Discord.JS as well as make it more friendly to that API.

somber moon Jun 9, 2020, 3:14 PM

#

So the current mode of operation is that the queue is thrown all at once once the rate-limiting is over?

indigo nimbus Jun 9, 2020, 3:14 PM

#

yes and no.

#

there's no delay between calls until it hits the limit.

tacit crypt Jun 9, 2020, 3:16 PM

#

Right now, the queue is not a leaky bucket one, but rather a sequential "burst". If we see you have 5 remaining, we'll send those 5, and then wait it out till it resets. (preventing 429s because that can get you banned). With a leaky bucket implementation, say we had a bucket of 5/5 (5 req per 5 seconds), we'd send a request a second, something that might be good in the long run, however doesn't that mean you then have a general slowdown? We couuuuld make it an option in v13 to switch between leaky and sequential "burst"

wild flax Jun 9, 2020, 3:17 PM

#

We already tried that in the past, and it went terribly wrong.

#

Also we already do this:

They way it could work would be to prevent hitting those limit by using the information in the reply header to limit the rate at which is sends call in a specific route to avoid hitting the limits.

indigo nimbus Jun 9, 2020, 3:19 PM

#

I'm not 100% sure about that, but does the reply header of each call contains the remaining request and delay before the eventual timeout ? If so is there a way to use that information to prevent hitting the upcoming limit ?

wild flax Jun 9, 2020, 3:19 PM

#

I think the terminology you use can not be applied here.

#

You are not hitting any limit here.

#

We prevent you from hitting the limit on discords API before you do.

tacit crypt Jun 9, 2020, 3:19 PM

#

it doesn't have a delay between eventual timeout, you get a retry-after if you hit a 429, otherwise you get just the total limit, remaining, and when the bucket resets

#

Which is what we use to..well, what Crawl said

indigo nimbus Jun 9, 2020, 3:20 PM

#

I must have interpreted the code wrong then... mmm I'll read it again.

tacit crypt Jun 9, 2020, 3:20 PM

#

Also, Crawl, not that kind of burst. RN if you have a 5/5 bucket and queue 5 requests, say all 5 requests send in the first 2 seconds, now you're waiting 3 extra seconds; a leaky bucket would send a request per second, theoretically never hitting a 429 while also staying consistently fast (although possibly slower overall due to well, waiting that whole second; that is of course assuming your requests go well)

#

Well, we're waiting the 3 seconds for you, so you don't hit a 429

#

point stands

indigo nimbus Jun 9, 2020, 3:22 PM

#

Ok so the rate-limit event is sent by discord.js and it's not an actual response from the API ?

tacit crypt Jun 9, 2020, 3:23 PM

#

yeah! the rateLimit event we emit means we're basically waiting that time due to ratelimits

#

An actual unexpected 429 is emitted in the debug event, but that should never™️ happen

indigo nimbus Jun 9, 2020, 3:24 PM

#

ok thanks

glossy epoch Jun 9, 2020, 11:47 PM

#

@tacit crypt does tha mean we don't need to worry about rate limits? and can we access the headers sent from Discord API?

tacit crypt Jun 9, 2020, 11:50 PM

#

1st question: yes;
2nd: no

glossy epoch Jun 9, 2020, 11:54 PM

#

ok thanks

tender field Jun 11, 2020, 10:13 AM

#

https://github.com/discordjs/discord.js/pull/4349/files#r438675819
I'll gladly accept the formatting here as i originally planned on applying it, if i can get a confirmation that the warn event value is not part of semver classifications, as technically the : means a change in public facing behavior which (very very technically) is a breaking change upping this to major

Why is the : a breaking change?

unique axle Jun 11, 2020, 10:16 AM

#

technically the event right now emits with the the string
Discord sent a typing packet to a voice channel 222078108977594369
if the : is added the event for the exact same channel emits with
Discord sent a typing packet to a voice channel: 222078108977594369
now if said warning message is considered part of the public facing api that is a different value and might make the handling of this string break for someone parsing it
part of the public facing API -> subject to semver -> changing the return value under the same condition is breaking
so all comes down to if we consider warning event values (strings) to be part of the public facing API, thus subject to semver.

#

if that is the case i will not apply the : formatting change, as that's definitely not worth holding back a bug fix for

#

the decision about that has to be made by our core devs
edit: see https://github.com/discordjs/discord.js/pull/4349#discussion_r441024399 for a full explanation

tender field Jun 11, 2020, 1:49 PM

#

oooh ok i understand ! thanks 🙂

lofty birch Jun 11, 2020, 4:59 PM

#

I know that changing the displayAvatarURL format would be breaking (even though iOS clients don't support webp), however would a default displayAvatarURL options in the client options be breaking? I'd just personally find it really helpful

vivid field Jun 11, 2020, 5:07 PM

#

when adding a feature without modifying or removing current features that would only be semver minor

ornate topaz Jun 11, 2020, 5:12 PM

#

you can also just provide actual options to the displayAvatarURL to get png instead of webm

lofty birch Jun 11, 2020, 5:36 PM

#

I'm just thinking that the ability to set default avatar options would be nice

snow crypt Jun 11, 2020, 5:44 PM

#

pr it

lofty birch Jun 11, 2020, 5:52 PM

#

Alright

opaque copper Jun 12, 2020, 5:34 AM

#

Elaborating on ChannelTypes discussion from #archive-site-discussion as its now involved with library methods, should we re-introduce number as a possible channel type, or stay with strings as the only parseable for channel types

snow crypt Jun 15, 2020, 5:41 PM

#

Why is the application not attached to the Team that owns it?

tacit crypt Jun 15, 2020, 7:17 PM

#

https://discord.js.org/#/docs/main/master/class/ClientApplication?scrollTo=owner Sure looks like it is to me

keen cosmos Jun 15, 2020, 7:28 PM

#

@tacit crypt he means the other way around, why doesn't Team have an application property that points to said application

#

probably for consistency

unique axle Jun 15, 2020, 7:31 PM

#

where would the benefit in that be exactly?
you need the app to get the team/owner anyways
it's also not like you can just reference it through a cache

snow crypt Jun 15, 2020, 8:43 PM

#

a lot of the structures are circular

#

also, for the same thing you could say "why would we need TeamMemer#team when you would get the team anyway"

#

yet it exists

snow crypt Jun 16, 2020, 5:37 PM

#

@unique axle you still change voice to category in some cases

unique axle Jun 16, 2020, 5:37 PM

#

no

snow crypt Jun 16, 2020, 5:38 PM

#

yeah, you changed literal voice to ${channel.type}

unique axle Jun 16, 2020, 5:57 PM

#

I wrote the post on the PR, going into much more detail on semver and the application of this specific case, to not have to further discuss any of that. But alas, I guess that was insufficient.

The behaviour does not change. i do not change "voice" to "category" in any instance, whatsoever.
If this emits for a voice channel you will receive the exact same event data as you would before this change
It will now additionally emit for other channel types, this does however not change the behaviour for any instance where it before had a defined behaviour.

In fact, before, if typing was sent to any other channel that was not of type "voice" it would've thrown an internal error. After this change it will not do so anymore and, once again, feature the exact same behaviour for the instances it covered before. This is not a breaking change without the style addition of the ":" . And no, i will not ever consider an internal error being thrown as a behaviour that can not be changed due to semver.

This is - without the style addition of the ":" in the emitted information a semver patch.

snow crypt Jun 16, 2020, 5:58 PM

#

okay, perfect 👌

fallen arrow Jun 17, 2020, 12:51 PM

#

using the fetchAllMembers option without the GUILD_MEMBERS intent will cause the client to take a long time to get ready because its waiting for members that will never arrive. Should an intent check be added to the GUILD_CREATE handler or would an additional warning under fetchAllMembers suffice?

copper laurel Jun 17, 2020, 12:52 PM

#

Theres a lot of work we can do to handle intents better since not specifying them causes various incompatibility, but I kinda feel like trying to fetch all members without subscribing to members is a pretty silly mistake to make.

fallen arrow Jun 17, 2020, 12:53 PM

#

agreed, hence why the question, if its even worth handling such mistakes on behalf of users

fallen arrow Jun 17, 2020, 8:26 PM

#

another question, is there a reason for the emojiManager to only be initialized in guild._patch and not in the guild constructor?

vernal atlas Jun 17, 2020, 8:45 PM

#

https://github.com/discordjs/discord.js/blob/master/src/structures/Guild.js#L413-L426 i think its so this here knows if data.emojis is from the original GUILD_CREATE or from an emojis update event

#

thats just a guess though