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

vagrant holly Oct 29, 2020, 10:14 PM

#

but yeah, unless a process exits via an error, a shard wont respawn in 12.4.x at present

vernal atlas Oct 29, 2020, 10:15 PM

#

creating 2 bugs from the same PR FeelsBadMan

tacit crypt Oct 29, 2020, 10:15 PM

#

2?

vernal atlas Oct 29, 2020, 10:15 PM

#

yes

vagrant holly Oct 29, 2020, 10:15 PM

#

Oh was 12.4.1 a regression from that PR too?

#

f

vernal atlas Oct 29, 2020, 10:15 PM

#

yes

vagrant holly Oct 29, 2020, 10:16 PM

#

what the shit is github actions doing

tacit crypt Oct 29, 2020, 10:16 PM

#

Apparently not working...and it should be working...

vernal atlas Oct 29, 2020, 10:16 PM

#

i think because it was changed to npm ci its borked

#

idk i saw someone say that was the issue, but im not sure

tacit crypt Oct 29, 2020, 10:17 PM

#

no..the git cmd is erroring

#

even though it shouldn't..

vagrant holly Oct 29, 2020, 10:17 PM

#

lemme npm i locally

vernal atlas Oct 29, 2020, 10:17 PM

#

i think i actually made a branch to test around with it but got distracted

vagrant holly Oct 29, 2020, 10:17 PM

#

ah yeah the lock file is cucked

tacit crypt Oct 29, 2020, 10:18 PM

#

can you uncuck it

#

how is it even cucked

vagrant holly Oct 29, 2020, 10:20 PM

#

yah 2 secs

vernal atlas Oct 29, 2020, 10:20 PM

#

does my v8 pr just need (extensive) testing now? or is there more i need to add

oak quail Oct 29, 2020, 10:22 PM

#

i'll see if i can test it sometime

#

looking at the or desc, it's pretty much just drop-in right? no major breaking changes?

vernal atlas Oct 29, 2020, 10:26 PM

#

Permissions uses bigints and not numbers

#

so that would be a breaking change there

tacit crypt Oct 29, 2020, 10:26 PM

#

well yeah but no

#

since its the internals, the user facing funcs still work the same

vernal atlas Oct 29, 2020, 10:27 PM

#

Permissions#bitfield is public though

tacit crypt Oct 29, 2020, 10:27 PM

#

well yeah THAT would be breaking

oak quail Oct 29, 2020, 10:27 PM

#

yeah ik bitfield is a breaking change but like, I doubt many people are using it lol

tacit crypt Oct 29, 2020, 10:27 PM

#

Directly? Most people fail .has kappapride (obv /s)

vagrant holly Oct 29, 2020, 10:28 PM

#

Hm

#

So the current lock file is v2

vernal atlas Oct 29, 2020, 10:28 PM

#

it would be the only way to check if a role had no permissions right?

vagrant holly Oct 29, 2020, 10:28 PM

#

I guess I should retain that right

oak quail Oct 29, 2020, 10:28 PM

#

ah someone was using node 15 I see

vernal atlas Oct 29, 2020, 10:28 PM

#

thats what i use it for

oak quail Oct 29, 2020, 10:28 PM

#

pre node 15 uses v1

tacit crypt Oct 29, 2020, 10:29 PM

#

Just push updated file

#

dw about version

vagrant holly Oct 29, 2020, 10:29 PM

#

Yeah, package.json says node 12+

oak quail Oct 29, 2020, 10:29 PM

#

node 15 with lockfile v2 broke del's gh actions too lol

vagrant holly Oct 29, 2020, 10:30 PM

#

probs cause actions node is 14 lts by default

vernal atlas Oct 29, 2020, 10:32 PM

#

options.ws.intents is also removed in favour of options.intents & options.intents is required

#

so yea def a breaking change

oak quail Oct 29, 2020, 10:33 PM

#

ah, missed that

vernal atlas Oct 29, 2020, 10:33 PM

#

i should also add an error actually if intents arent passed

oak quail Oct 29, 2020, 10:34 PM

#

what does it do rn

#

gateway connection error or something?

vernal atlas Oct 29, 2020, 10:35 PM

#

yeah it just leaves it for the gateway to error

#

also setPresence and the helpers using it no longer return promises

#

because there wasnt a need for them to return one anymore

oak quail Oct 29, 2020, 10:36 PM

#

isn't that kinda inconsistent tho

copper laurel Oct 29, 2020, 10:36 PM

#

that confused me, are they not API calls?

oak quail Oct 29, 2020, 10:36 PM

#

gateway commands

vernal atlas Oct 29, 2020, 10:37 PM

#

theres not really anything it waits for

#

the only reason it was async is so the application could be fetched if you provided assets for the presence

#

which according to the docs you cant do anymore

#

only through rpc

oak quail Oct 29, 2020, 10:38 PM

#

that was never possible 🤔

vernal atlas Oct 29, 2020, 10:38 PM

#

well idk why it was even added then

#

but theres not really anything it actually waits for so idk what the point is in it returning a promise

vagrant holly Oct 30, 2020, 12:24 PM

#

Just as an aside, 12.4.x had some nice memory usage improvements (I was running 12.3.1 w/ my message edit limit patched in). No idea what else changed w.r.t to mem usage, but something seems to have done.

copper laurel Oct 30, 2020, 12:34 PM

#

12.4 specifically or discords intent changes?

vagrant holly Oct 30, 2020, 1:02 PM

#

I was using intents prior, so it seems like 12.4 -- the drop in mem usage & the associated annotation is me rolling out 12.4.1 to the bot

tacit crypt Oct 30, 2020, 2:48 PM

#

that's.. odd

#

but always welcomed

tender field Oct 30, 2020, 5:45 PM

#

Hey, using djs 12.4.1, i'm not supposed to have a more complete error thanks to the new async queue? This is after a failed guild.fetchBan(id) (i'm not asking for help, this is a genuine question, because i thought the async queue would give more descriptive error when a promise fails)

DiscordAPIError: Unknown Ban
    at RequestHandler.execute (/bot/node_modules/discord.js/src/rest/RequestHandler.js:154:13)
    at processTicksAndRejections (internal/process/task_queues.js:93:5)
    at RequestHandler.push (/bot/node_modules/discord.js/src/rest/RequestHandler.js:39:14)```

tacit crypt Oct 30, 2020, 6:09 PM

#

are you sure you're on v12.4.1? (odd question i know, check the code itself)

vernal atlas Oct 30, 2020, 7:45 PM

#

looks alright for me

tender field Oct 30, 2020, 7:49 PM

#

are you sure you're on v12.4.1? (odd question i know, check the code itself)
yep, checked on the node_modules folder...

vernal atlas Oct 30, 2020, 7:49 PM

#

are you sure your bot is using 12.4.1?

#

perhaps try evaling / logging require('discord.js').version

tender field Oct 30, 2020, 7:50 PM

#

well it is in the package.json and on the node_module folder

#

ok

#

yep it prints 12.4.1

#

it is transpiled with babel btw, idk if it changes anything

#

but i'm not sure if it comes from .fetchBan(id) or .unban(id), because the try/catch is the same for both and... you know i don't have the line ^^

#

~~well i can't reproduce this because it being called was a bug anyway, and i fixed it... but it is still weird that it did that~~
I managed to reproduce it, and yep, still a small stack trace

#

Same result with Node 14.15.0 and 12.18.3

vernal atlas Oct 30, 2020, 8:23 PM

#

could it be because the request is being retried?

tender field Oct 30, 2020, 8:49 PM

#

wdym?

#

wait was it for me or for the team? 😂

real jetty Oct 30, 2020, 8:53 PM

#

Why does https://discord.js.org/#/docs/main/master/class/GuildChannel?scrollTo=viewable exist ? It doesn't have any sense imo as you can just check if the bot has the VIEW_CHANNEL permission on this channel

tacit crypt Oct 30, 2020, 8:59 PM

#

That's..the point

#

We have a bunch of those shortcuts (most are just mere permission checks)

real jetty Oct 30, 2020, 9:04 PM

#

I proposed a getter to know if a channel is set as 'private' with the private icon but it was denied as it is an easy check... Will some getters diseapear in v13 ?

vernal atlas Oct 30, 2020, 9:07 PM

#

yeah i believe that some of the getters will be removedf

#

https://github.com/discordjs/discord.js/pull/4955#issuecomment-718565480

frank turret Oct 30, 2020, 11:23 PM

#

Referring to this: https://github.com/discordjs/discord.js/blob/stable/src/managers/RoleManager.js#L55

Should we remove the id option from RoleManager#fetch? Since under the hood it just grabs from cache if it's there, otherwise just fetches all roles from the guild. This seems misleading, since the doc's description and example make it seem like you're just fetching one role only

frank turret Oct 30, 2020, 11:44 PM

#

@vivid field for your pr (#4935), why don’t you just return the cache itself instead of creating another collection?

vivid field Oct 30, 2020, 11:45 PM

#

because the roles aren't on the cache in case cache is set to false

frank turret Oct 30, 2020, 11:45 PM

#

Good point

vivid field Oct 30, 2020, 11:46 PM

#

that's also what every other manager does meguFace

vagrant holly Nov 1, 2020, 1:39 PM

#

Is a release gonna be cut soon given the regression fix was merged?

unique axle Nov 1, 2020, 1:41 PM

#

as per usual: no ETA on releases

tender field Nov 2, 2020, 11:38 AM

#

Will djs 13 provide some mocks or a testing api ?

real jetty Nov 2, 2020, 11:50 AM

#

I would doubt it:
If you are PRing the lib, chances are you are only providing fixes or extending support to a specific endpoint, writing your own tests should be easy enough

tender field Nov 2, 2020, 11:53 AM

#

no i meant as a djs user, not a djs contributor. To create tests for your bot

#

because there are some issues that have been opened and provide some snippets but it feels a bit ""cheap"" imo. I would prefer an official API or something, not creating the mocks myself you know https://github.com/discordjs/discord.js/issues/3576

unique axle Nov 2, 2020, 12:55 PM

#

no

storm igloo Nov 2, 2020, 2:37 PM

#

@tender field You can try something like this library
https://www.npmjs.com/package/talkback

#

Unoffical blabla, but it's very useful in recreating behaviour of a 3rd party api (like discord)

tender field Nov 2, 2020, 2:39 PM

#

thanks

surreal dagger Nov 2, 2020, 3:11 PM

#

hey, when v13 is coming?

unique axle Nov 2, 2020, 3:11 PM

#

as per usual: no ETA on releases

real rivet Nov 2, 2020, 7:01 PM

#

right, that's how it is
decent ways of implementing pagination will probably be a thing of the far future

copper laurel Nov 2, 2020, 8:54 PM

#

Things which exist as complex concepts / multi-step processes (such as pagination) rather than wrapping singular API calls will likely never be a part of discord.js

real jetty Nov 3, 2020, 2:50 AM

#

@oak quail yeah your right, its in there but not in the code

empty viper Nov 3, 2020, 8:26 AM

#

Hi, I have question, when does the v11 will stop working ?

On the guide I says October 2020, but we are in November and my bot stills run on v11 (it's a test bot) 👀

oak quail Nov 3, 2020, 8:59 AM

#

probably sometime in 2021

#

but people are already having some issues with it

ornate topaz Nov 3, 2020, 9:27 AM

#

Did discord reschedule domain change?

cold basin Nov 3, 2020, 9:28 AM

#

domain change did happen iirc

ornate topaz Nov 3, 2020, 9:40 AM

#

Not exactly what i asked about

#

For now both domains work - that's what i asked about

unique axle Nov 3, 2020, 9:46 AM

#

https://camo.githubusercontent.com/23247e3cecd7ebae83e19b345d5df526a36cbc39/68747470733a2f2f616476616974682e69732d696e2d68797065722e73706163652f663065663062636362342e706e67

#

https://camo.githubusercontent.com/fb9b13e078b4df8d8378180d5b11bebf936f8ac4/68747470733a2f2f616476616974682e69732d696e2d68797065722e73706163652f623336633833376232322e706e67

ornate topaz Nov 3, 2020, 9:47 AM

#

So most likely in few days, not in 2021

unique axle Nov 3, 2020, 9:48 AM

#

These are the statements, requiring the new domain later this year for third party developers on November the 7th 2020.
While there have been talks about re-directing and keeping discordapp.com alive, that is the public facing information.

#

In the end: we'll have to wait and see

#

You definitely should be updating to v12, not only because v11 might break due to the domain change but also because it does not receive new features or bug fixes anymore.
We have moved on from v11, it's an old version, we do not maintain or support it any longer. Please update at your earliest convenience catThumbsUp

empty viper Nov 3, 2020, 7:59 PM

#

Okay I see now.
(PS : As I say it is just a test bot, it doesn't even have commands x))

drifting knot Nov 4, 2020, 9:29 PM

#

node 15.1 just dropped and has some interesting new features https://github.com/nodejs/node/releases/tag/v15.1.0

#

first off is the diagnostics channels, could this change the debug event in the future? djs next?

#

there's also an event emitter when a child process spawns successfully, maybe relevant to sharding??

copper laurel Nov 4, 2020, 10:21 PM

#

Not sure I see the benefit of the diagnostic channel over the existing debug event, unless it happens to be more performant. The spawn event definitely looks useful but again, I'd be hesitant to enforce a minimum Node version of 15.1

thorny tree Nov 5, 2020, 12:54 PM

#

why can't the shard resume the connection, if the internet fails, and the connection closes with a 1000 code?
isn't this the point of resuming connections, if the internet fails?

If I normally connect:

[WS => Shard 0] [IDENTIFY] Shard 0/1
[WS => Shard 0] [READY] Session 49b63190f****************** (censored)
[WS => Shard 0] Shard received all its guilds. Marking as fully ready.

if I turn off the network:

[WS => Shard 0] [HeartbeatTimer] Sending a heartbeat.
[WS => Shard 0] [CLOSE]
    Event Code: 1006
    Clean     : false
    Reason    : No reason received
[WS => Shard 0] Clearing the heartbeat interval.
[WS => Shard 0] Session ID is present, attempting an immediate reconnect...
[WS => Shard 0] A connection object was found. Cleaning up before continuing.
    State: CLOSED
[WS => Shard 0] [DESTROY]
    Close Code    : 1000
    Reset         : false
    Emit DESTROYED: false
[WS => Shard 0] WS State: CLOSED

and activate it again after more than 30secs, it doesn't resume the connection, but makes a new identify call, which is very expensive

[WS => Shard 0] [CONNECT]
    Gateway    : wss://gateway.discord.gg/
    Version    : 6
    Encoding   : json
    Compression: none
[WS => Shard 0] Setting a HELLO timeout for 20s.
[WS => Shard 0] [CONNECTED] wss://gateway.discord.gg/?v=6&encoding=json in 1489ms
[WS => Shard 0] Clearing the HELLO timeout.
[WS => Shard 0] Setting a heartbeat interval for 41250ms.
[WS => Shard 0] [IDENTIFY] Shard 0/1
...

shards would've been destroyed within 30 seconds, afaik.
because of that, the shard gets destroyed with its sessionID and it does a new identify call (rather than resuming the connection)
is this a bug or a feature?

surreal geode Nov 5, 2020, 1:14 PM

#

It looks like the socket closed with 1006 (without close frame), d.js was going to try to reconnect and resume but the socket was closed, so it reconnected and started a new session.

#

@thorny tree Why do you think starting a new session is expensive?

thorny tree Nov 5, 2020, 1:19 PM

#

@surreal geode
because there is a 5s rate limit for identify calls and it needs to build the whole djs structure again

surreal geode Nov 5, 2020, 1:22 PM

#

The 5s identify ratelimit applies to resume identify calls, too

#

The internal d.js structure is already "built" before you log in; the caches are filled but that isn't very expensive

thorny tree Nov 5, 2020, 1:23 PM

#

The 5s identify ratelimit applies to resume identify calls, too
@surreal geode no I asked on the offical discord developer, and they said, it doesn't have a rate limit, and I can indeed confirm it after some tests

surreal geode Nov 5, 2020, 1:24 PM

#

Huh. Sorry about that. I guess the 5s limit could be a problem ~~but it seems you are only starting a single shard~~

thorny tree Nov 5, 2020, 1:25 PM

#

30 shards reconnect in a few seconds rather than 2,5minutes
(or more extreme: 400 shards reconnect in a few seconds rather than 33minutes)

ornate topaz Nov 5, 2020, 1:49 PM

#

(at 400 shards you would have higher max concurrency, but that doesn't change much here)

tacit crypt Nov 5, 2020, 3:50 PM

#

Your session would expire anyways if you don't resume in time

#

There's like a very short window in which you CAN resume

old hill Nov 5, 2020, 8:54 PM

#

Hi all. I was looking through the code recently, more specifically the rateLimiting things, and found that (iirc) the ‘rateLimit’ event is called when an event is delayed to avoid ratelimits, rather than when an actual ratelimit is hit - in which case a debug is sent. To me, this seems kind of counterintuitive, and I feel like at least the documentation should clarify this. Is there any particular reason it’s set up this way?

ornate topaz Nov 5, 2020, 8:56 PM

#

when an event is delayed, you have hit a ratelimit

old hill Nov 5, 2020, 8:59 PM

#

I can understand that, but I feel like the behaviour should be clarified in some way

thorny tree Nov 5, 2020, 11:24 PM

#

There's like a very short window in which you CAN resume
@tacit crypt its more than 5 minutes, so it should be possible to resume all shards in a few seconds

tacit crypt Nov 5, 2020, 11:25 PM

#

No it's not

#

Sessions that are DCd last max around 1 minute

#

Otherwise you'll get an invalid session

thorny tree Nov 5, 2020, 11:25 PM

#

wait I'll test it

#

oh you are right, but a minute should be enough right? @tacit crypt

tacit crypt Nov 6, 2020, 7:50 AM

#

Without a proper example/test, I don't see how it's a problem
We tried reconnecting with the session ID, failed, so now we're reidentifying since session is aasumed to be expired

oak quail Nov 7, 2020, 4:01 AM

#

https://advaith.is-in-hyper.space/285bb2330b.png

#

why does ClientPresence have all of this when bots can only set name, type, and url

drifting knot Nov 7, 2020, 9:03 AM

#

fellas we have got to have a discord js method that implements the formula at https://discord.com/developers/docs/topics/gateway#sharding-sharding-formula

shard_id = (guild_id >> 22) % num_shards

#

i have the typescript code written and commented n everything

#

function findShardIDByGuildID(guildID: Snowflake, shardCount: bigint): number

#

where should i pr this method into

#

it could make sense to make it a method on Guild, however 99% of the use cases are for finding a shard for a guild where the only data you have is the id

#

so maybe it should be a static method on Guild or Util or Client???

warped crater Nov 7, 2020, 9:24 AM

#

fellas we have got to have a discord js method that implements the formula ...

#

no..? we.. don't?

#

you never specified the need for it 🤔

#

if you want to find what shard a guild is on you can simply use an if condition inside of broadcastEval

#

this isn't really particularly useful besides avoiding the use of broadcast and just running the code straight on the target shard (if that's even possible atm)

#

and I see no need for it inside the library itself.

drifting knot Nov 7, 2020, 10:22 AM

#

ok imagine this

#

imagine i'm mee6 and for whatever reason i'm using discord.js to run my 8660 shards

#

now imagine im caching data in redis that uses the guild and shard id

#

now every time i want to fetch that data execute 8660 eval statements to find the 1 shard that matters

#

this is literally a thing mee6 does, only not with discord.js

#

tada https://zws.im/‍‍‍‍‍‍‍‍‍‍‌‍‌‌‍‌

#

it makes sense for the discord library to implement the formula discord gives us to use the discord api

lofty birch Nov 7, 2020, 10:36 AM

#

You could just create the function yourself?

drifting knot Nov 7, 2020, 10:36 AM

#

i did

lofty birch Nov 7, 2020, 10:36 AM

#

Given how it's so simple

drifting knot Nov 7, 2020, 10:36 AM

#

and i am offering to PR it

#

it is easy to make mistakes in the implementation

#

you could argue that everyone could make their own discord api wrapper and discord.js doesnt need to exist but that is stupid

#

we are here to make the discord api more accesible to javascript developers

#

why not make this formula part of that

lofty birch Nov 7, 2020, 10:38 AM

#

The purpose of the library is to interact with the api. Using the formula doesn't do that in any way

drifting knot Nov 7, 2020, 10:38 AM

#

and yet it is listed on the discord api docs

#

discordjs has methods for escaping markdown, that isnt api related

#

is it even really your place to decide if this should or shouldnt be in the library

#

just tell me where to put the function, i'll pr it, and someone will approve or reject it

unique axle Nov 7, 2020, 10:46 AM

#

ShardClientUtil or the general purpose Util shibaThinking
i personally feel like the first represents the area of use better
though i'm unsure i understand the use case. if i'm not mistaken (possible, i'm not very involved in sharding internals) you'll need to #broadcastEval it anyways and returning if a guild is on the respective shard or by applying a formula doesn't seem to make much of a difference

drifting knot Nov 7, 2020, 10:46 AM

#

the use case is to remove the need to evaluate code on all your shards

#

it uses a formula thats the inverse of what discord uses for sharding (not big bot sharding)

unique axle Nov 7, 2020, 10:47 AM

#

i understand that. the question is: do we even allow to address a single shard at this time

drifting knot Nov 7, 2020, 10:47 AM

#

ehhhh not easily

#

but having the function in whatever util class would be good

#

its simple enough its like 20 lines to implement, 20 lines to test, and then forget it forever

#

ooh and 1 use real world use case i actually have for this is to see how many guilds each shard is allocated for me, where my bot uses each cpu core to handle a bunch of shard IDs

sage owl Nov 7, 2020, 6:06 PM

#

So, I was working on my bot today and when going to test the messageReactionAdd and messageReactionRemove event portion of the code, i am not getting anything that would suggest this event firing. This event has been working for over a month and then all of a sudden stopped working.

I am using partials to grab the message that wasn't cached but the important fact is i am not seeing a console output that i specifically placed at the top of the function. Any ideas what could be causing this?

unique axle Nov 7, 2020, 6:06 PM

#

bughunter Bug:
• MessageReactionAdd does not fire despite proper partials enabled

PR in the works,
Temporary fix is to ensure the addition of GUILD_MEMBER partial in the client definition
new Discord.Client({ partials: ['USER', 'GUILD_MEMBER', 'CHANNEL', 'MESSAGE', 'REACTION'] });

(copy from #769862166131245066)

sage owl Nov 7, 2020, 6:10 PM

#

How long has this been going on, because this is the first i have seen this?

#

Is this bug due to discord changes or is this specifically a Discord.js bug?

#

Ok, that makes sense! Yeah, probably should too. Thanks for the info. I just found the discord after searching the net for this issue. IS this going be the best place for announcement and changes?

unique axle Nov 7, 2020, 6:15 PM

#

well yes, this is our (discord.js) discord server

sage owl Nov 7, 2020, 6:18 PM

#

Yeah, I just looking or the place where I will get the announcements first. Some API devs like their website to be the front page, others like GitLab or GitHub. I work in the industry, so was just curious where the best place to go is. I appreciate the help!

#

btw, I think you all are doing a stand up job with Discord.Js...keep up the hard work!!

unique axle Nov 7, 2020, 6:21 PM

#

GitHub is where the issues and new features will be discussed, if we spot things happening regularly in support they'll go into #769862166131245066 , feature releases happen in #announcements
both you can follow if you prefer to get notified on your own server catThumbsUp

oak quail Nov 7, 2020, 11:27 PM

#

btw re the sharding formula, I use it sometimes to see what shard a guild is on when the bot is offline in it

drifting knot Nov 8, 2020, 10:47 AM

#

that too

vagrant holly Nov 8, 2020, 12:46 PM

#

There isn't currently a way to broadcast to a single shard, but that seems like it'd be a super useful change

#

Will take a look shortly

wide sand Nov 8, 2020, 3:45 PM

#

I have come across a very weird issue i think it;s djs issue.
the clientOption for fetchAllMember get timeout even when server member intent is enabled and bot is in 600 servers with 100K members

#

to test it properly i tried manually adding all intent double check server member intent

#

tried on different vps too

#

this is the error u will get: https://sourceb.in/nZ3b0Nvszj

#

make sure to on warn and debug event to see it

#

once it timedout the client will go in ready state but no commands will work

vagrant holly Nov 8, 2020, 3:49 PM

#

🤔 The websocket is closing

wide sand Nov 8, 2020, 3:49 PM

#

yes which should not be happening

tacit crypt Nov 8, 2020, 3:49 PM

#

So you're using intents and you have server member intents enabled in the dev portal?

wide sand Nov 8, 2020, 3:49 PM

#

yes

#

https://media.discordapp.net/attachments/402150235071184918/774996146724536340/unknown.png

tacit crypt Nov 8, 2020, 3:51 PM

#

and whats your intent bitfield?

wide sand Nov 8, 2020, 3:53 PM

#

i am using flags: 'GUILDS','GUILD_MEMBERS','GUILD_MESSAGES','GUILD_MESSAGE_REACTIONS'

#

    fetchAllMembers:true,
    ws: { intents: ['GUILDS','GUILD_MEMBERS','GUILD_MESSAGES','GUILD_MESSAGE_REACTIONS'] }    
});```

tacit crypt Nov 8, 2020, 3:54 PM

#

d.js version?

wide sand Nov 8, 2020, 3:54 PM

#

12.4.1

tacit crypt Nov 8, 2020, 3:54 PM

#

ALSO, I'm pretty sure, on recent versions, it was moved outside of ws

vagrant holly Nov 8, 2020, 3:54 PM

#

Intents doesn't take strings?

#

It takes a bitfield

tacit crypt Nov 8, 2020, 3:54 PM

#

it does

#

oh

vagrant holly Nov 8, 2020, 3:54 PM

#

🤔

tacit crypt Nov 8, 2020, 3:54 PM

#

that too

#

also this is less lib discussion and more djs-help but I'll give you a pass

You forgot the constructor for the Intents class

vagrant holly Nov 8, 2020, 3:55 PM

#

        ws: {
            intents: (new Intents()).add(
                Intents.FLAGS.GUILDS,
                Intents.FLAGS.GUILD_MEMBERS,
                Intents.FLAGS.GUILD_MESSAGES,
                Intents.FLAGS.GUILD_MESSAGE_REACTIONS,
            ),
        },

tacit crypt Nov 8, 2020, 3:55 PM

#

new Intents([])```*

lofty birch Nov 8, 2020, 3:55 PM

#

you can use an array of strings

#

I do

unique axle Nov 8, 2020, 3:55 PM

#

what...

#

vlad, pls

#

no, 12.4.1 is still under the ws key

tacit crypt Nov 8, 2020, 3:55 PM

#

I thought we moved it what

#

oh

unique axle Nov 8, 2020, 3:56 PM

#

new Intents() is exactly equal to new Intents(template) where template is an Intentsresolvable representing 0 (including empty array)
ws > intents https://discord.js.org/#/docs/main/stable/typedef/WebsocketOptions takes https://discord.js.org/#/docs/main/stable/typedef/IntentsResolvable can be IntentsResolvable[], can be flag => can be array of flags

vagrant holly Nov 8, 2020, 3:57 PM

#

Nice, TIL it can take strings

#

@wide sand Long story short, ws: { intents: new Intents(['GUILDS','GUILD_MEMBERS','GUILD_MESSAGES','GUILD_MESSAGE_REACTIONS']) }

tacit crypt Nov 8, 2020, 3:59 PM

#

No..thats fine

#

Doesn't NEED new Intents

#

since we resolve them

#

Well.. leaving aside that (@unique axle wasn't it a PR for moving intents up), it should work... Can you log client.options.ws.intents after you create the client instance (aka before logging in)?

wide sand Nov 8, 2020, 3:59 PM

#

tried that too before

unique axle Nov 8, 2020, 3:59 PM

#

Can you log client.options.ws.intents
that one - on the other hand currently doesn't work

vagrant holly Nov 8, 2020, 3:59 PM

#

Oh wait, does intents itself get resolved too?

wide sand Nov 8, 2020, 3:59 PM

#

same this:

Error [GUILD_MEMBERS_TIMEOUT]: Members didn't arrive in time.
    at /root/Node Apps/Menhera Chan/node_modules/discord.js/src/managers/GuildMemberManager.js:317:16
    at Timeout._onTimeout (/root/Node Apps/Menhera Chan/node_modules/discord.js/src/client/BaseClient.js:83:7)
    at listOnTimeout (internal/timers.js:554:17)
    at processTimers (internal/timers.js:497:7)

tacit crypt Nov 8, 2020, 4:00 PM

#

yes, Matt

vagrant holly Nov 8, 2020, 4:00 PM

#

So much resolving

wide sand Nov 8, 2020, 4:02 PM

#

it works fine for bot that is small in less number of server. but don't for slightly bigger bot. this error i am getting is in 600 server bot

#

with 100K members

#

so it's djs issue?

vagrant holly Nov 8, 2020, 4:15 PM

#

It seems like the library gives a guild 120s to return some members, or that error is thrown

#

Which feels like it should be given a setting

#

But also from your logs the WS was dying, so the timeout doesn't seem to be the issue

#

I assume if you disable fetchAllMembers the bot starts fine without the WS dying?

wide sand Nov 8, 2020, 4:24 PM

#

yes

#

if fetchAllMember is false(default) bot starts just fine

#

but when it's set to true the WS closes

#

and get timeout

#

so there is no solution right now?

vagrant holly Nov 8, 2020, 4:51 PM

#

I defer to someone who knows the internals of intents better than I

#

My only suggestion would be, as the docs note, to avoid using the fetchAllMembers client option

wide sand Nov 8, 2020, 5:08 PM

#

but then i can't cache all members and members.fetch takes time

#

when the server is huge

lofty birch Nov 8, 2020, 5:09 PM

#

you should avoid caching all members

real jetty Nov 8, 2020, 5:20 PM

#

Why does Message#member returns null even if the message is sent in a guild ? Why doesn't it return a partial member if it can't find it ?

keen cosmos Nov 8, 2020, 5:21 PM

#

it searches the cache for the member, and if it's not found it returns null

This is also technically a question, and belongs in a help channel, not here

real jetty Nov 8, 2020, 5:22 PM

#

I'm talking about how the library behavior that seems weird imo

#

why doesn't it add automatically the member to the cache if it can't find it (at its creation) ?

#

With new intents if you disable guild members intents Message#member will be null if you don't fetch it, it's a problem imo

vagrant holly Nov 8, 2020, 5:28 PM

#

Imo it'd make sense for it to return a partial

keen cosmos Nov 8, 2020, 5:28 PM

#

Then you'd have to have a partial guild member in the cache

#

Message#member is a getter

#

which retrieves from the cache

real jetty Nov 8, 2020, 5:28 PM

#

It is not a problem

#

I'll make a PR

ornate topaz Nov 8, 2020, 5:29 PM

#

There already is one regarding that

real jetty Nov 8, 2020, 5:29 PM

#

oops didn't see it

#

sry

vagrant holly Nov 8, 2020, 5:30 PM

#

Am I going mad cause I don't see it, unless it was already merged

real jetty Nov 8, 2020, 5:30 PM

#

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

#

But it is only for events

vagrant holly Nov 8, 2020, 5:31 PM

#

Yeah, that doesn't actually ensure Message#member can be a partial

#

Just does a better job of populating the cache with partials

slate nacelle Nov 8, 2020, 5:31 PM

#

Incoming members from the message payload are already being taken care of: https://github.com/discordjs/discord.js/blob/master/src/structures/Message.js#L195-L199

vagrant holly Nov 8, 2020, 5:32 PM

#

Right, but if the member/user had since been purged, Message#member will return null, not a partial, I think?

#

Message itself could store the raw ID, and could then repopulate the partial when Message#member is called

tacit crypt Nov 8, 2020, 5:36 PM

#

Which feels like it should be given a setting
It is

It seems like the library gives a guild 120s to return some members, or that error is thrown
We refresh the timeout every time we get a GUILD_MEMBERS_CHUNK payload

As for WHY it errors... I don't know...Make triple sure your d.js is at the version you said, try different bot tokens, etc

vagrant holly Nov 8, 2020, 5:37 PM

#

Which feels like it should be given a setting
It is

https://github.com/discordjs/discord.js/blob/master/src/client/websocket/handlers/GUILD_CREATE.js#L12-L16 no setting, uses the default 120s

tacit crypt Nov 8, 2020, 5:38 PM

#

~~doesn't mean we don't provide the option to change it~~ and let's be honest... if payloads don't come in 120 seconds.. We have an issue

vagrant holly Nov 8, 2020, 5:38 PM

#

Yeah, agreed it shouldn't affect anything, but there isn't a setting for it 😛

tacit crypt Nov 8, 2020, 5:38 PM

#

ALSO

#

peculiar notice

#

..are..we..

#

double requesting all members

vagrant holly Nov 8, 2020, 5:39 PM

#

double requesting all members
@tacit crypt Where?

ornate topaz Nov 8, 2020, 5:39 PM

#

(that wasn't the pr i was talking about btw)

tacit crypt Nov 8, 2020, 5:39 PM

#

I mean the error Chota reported comes from the WS manager

#

oh

#

my god

#

I think we are

vagrant holly Nov 8, 2020, 5:40 PM

#

GUILD_MEMBERS_TIMEOUT emits from https://github.com/discordjs/discord.js/blob/master/src/managers/GuildMemberManager.js#L317

tacit crypt Nov 8, 2020, 5:40 PM

#

No

#

Not that

#

look at the prefix

#

[WS => Manager]

#

I

#

..I have some testing to do but I think we're double fetching members

#

https://github.com/discordjs/discord.js/blob/master/src/client/websocket/WebSocketManager.js#L402-L413

vagrant holly Nov 8, 2020, 5:41 PM

#

Oh you're totally right we are

tacit crypt Nov 8, 2020, 5:41 PM

#

wait no

#

I'm actually a bot

#

client.ws.status === Status.READY

#

n v m

vagrant holly Nov 8, 2020, 5:42 PM

#

is status not ready during the initial fetching?

tacit crypt Nov 8, 2020, 5:42 PM

#

nop

#

it's set to NEARLY

vagrant holly Nov 8, 2020, 5:42 PM

#

Ah yes ic

tacit crypt Nov 8, 2020, 5:42 PM

#

It..should..work tho

#

I do this in @signal lintel ~~for now, I'm planning on changing that asap~~

vagrant holly Nov 8, 2020, 5:45 PM

#

Are there any situations where you physically cannot request all members from a guild

tacit crypt Nov 8, 2020, 5:46 PM

#

yeah, if you don't have the guild_members intent

#

or.. y'know, verified bot without it

wide sand Nov 8, 2020, 5:57 PM

#

@tacit crypt i have guildmember intent enabled and my bot is 600 servers

#

i tried the same in small bot it worked in that

#

didn't timeout at all

#

but in big bot it timedout

tacit crypt Nov 8, 2020, 5:58 PM

#

are you 100% sure you're on 12.4.1? Some caching issues can cause that

wide sand Nov 8, 2020, 5:58 PM

#

yes

#

i updated today itself

tacit crypt Nov 8, 2020, 5:59 PM

#

Oddd

wide sand Nov 8, 2020, 6:00 PM

#

"discord.js": "^12.4.1",

#

i checked pakage.json just now

#

to make sure once again

oak quail Nov 8, 2020, 10:28 PM

#

@tacit crypt its gonna be moved out of ws in v13

#

would be breaking to move it in 12

tacit crypt Nov 8, 2020, 10:29 PM

#

well yes but no if you just deprecate the ws one

copper laurel Nov 8, 2020, 10:48 PM

#

yeah you can add it to top level client options without removing ws

wide sand Nov 9, 2020, 2:43 AM

#

DJs is using V6 right

copper laurel Nov 9, 2020, 2:44 AM

#

v7 technically, same API spec as v6 but with better errors

wide sand Nov 9, 2020, 2:44 AM

#

Aah

#

So it can be added outside ws in current djs version

#

Or wait till v13 comes out

copper laurel Nov 9, 2020, 2:47 AM

#

that has nothing to do with the API itself

#

We can provide the ability to receive the options wherever we like

#

Just cant remove the existing placements until v13 because thats breaking changes

unique axle Nov 9, 2020, 11:26 AM

#

unless - horror ensues - we accept both kek

that being said, still not sure i'm personally a fan of moving this specific one at all

lofty birch Nov 9, 2020, 3:46 PM

#

I agree, I think it makes sense to keep it inline with the ws section

#

Given how that's what it affects - the websocket

oak quail Nov 9, 2020, 4:02 PM

#

normally everything the library parses is up in ClientOptions and http and ws are only for advanced settings that are sent directly to discord without modification, which aren't meant for normal users

unique axle Nov 9, 2020, 7:37 PM

#

the planned rewrite to typescript (no release version/roadmap/date estimate, own repository at discordjs/discord.js-next) is planned to be much less monolithic, swapping out cache provider/rest/gateway for own extensions/implementations will be much easier - however no reason for great excitement, it's in a pre-planning phase (very very very early)

#

catThumbsUp

vivid lodge Nov 10, 2020, 8:20 AM

#

👍

#

I hope you plan on making your event methods easier to work with aswell, I had to go through so much shit to get custom events as a keyof interface in typescript

copper laurel Nov 10, 2020, 9:53 AM

#

Extending ClientEvents is "so much shit"?

tacit crypt Nov 10, 2020, 11:29 AM

#

declare module 'discord.js' {
  export interface ClientEvents {
    myCoolEvent: [User, WoahAClassOfMineOwO, SoujiIsSuperCute, BlameVlad];
  }
}```

#

that is not so much shit, it's do it once and call it a day

vivid lodge Nov 10, 2020, 4:12 PM

#

I had so many issues doing that tho

tacit crypt Nov 10, 2020, 4:30 PM

#

such as?

wispy forum Nov 10, 2020, 8:31 PM

#

Within typings of the library, as of 12.4.1, options are mandatory for methods like reply, send or edit. How come that is so? Back in 12.2.0 they were able to be undefined. Why exactly was this change made and how much difference would changing them back to be able to be undefined bring?

ornate topaz Nov 10, 2020, 8:32 PM

#

Mandatory?

wispy forum Nov 10, 2020, 8:32 PM

#

One sec.

#

https://bug-hunters.me/399624330268508160/9690c0.png

#

Mandatory as unable to be undefined. My bad.

ornate topaz Nov 10, 2020, 8:34 PM

#

So you say that it screams at you for not passing them to methods?

wispy forum Nov 10, 2020, 8:35 PM

#

Yes, for my own overwrites of those methods https://bug-hunters.me/399624330268508160/aab2f7.png

#

Which used to work in 12.2.0.

#

Because this is how things looked like in that version of d.js https://bug-hunters.me/399624330268508160/d6fa1c.png

#

I'm just confused.

copper laurel Nov 10, 2020, 8:53 PM

#

The first typing in that list does not have/require options, therefore there is an overload where they arent required

wispy forum Nov 10, 2020, 9:11 PM

#

Alright. Still don't understand the desperate need to not make those optional for sake of edge cases but okay. I'm sorry for being irrational or annoying.

copper laurel Nov 10, 2020, 9:12 PM

#

...but they are optional

wispy forum Nov 10, 2020, 9:12 PM

#

Doesn't look optional in these bottom typings #archive-library-discussion message

#

Yes, I see the top one that solely has content as argument, I'm aware of it.

#

But I still think these bottom ones would be nice as optional.

#

Avoiding a scenario like this whole check https://bug-hunters.me/399624330268508160/40c530.png

copper laurel Nov 10, 2020, 9:19 PM

#

You seem to not understand how method overloads work

#

Okay, credit to @ornate topaz for pointing this out to me, you (and I) were mistaking "optional" for undefined

#

The overloads do not explicitly support passing undefined in place of an optional parameter, because undefined isnt one of the accepted typings for that field if optionally provided

#

I messed up testing that with eval because JS doesnt care of course

#

Only TS does

wispy forum Nov 10, 2020, 9:32 PM

#

Yes I kind of mess the two up sometimes during talking but I see now.

copper laurel Nov 10, 2020, 9:32 PM

#

As did I, so apologies for being stubborn haha

wispy forum Nov 10, 2020, 9:34 PM

#

All good, but guess that clears everything up.

solemn oyster Nov 11, 2020, 12:03 AM

#

@wispy forum you need to somehow port all overloads those methods have, and then you can do options as any

#

While any is disgusting to use, it can be used to tell TypeScript that the data is fine

wispy forum Nov 11, 2020, 12:05 AM

#

Yeah, there's a lot of times when handling types looks really ugly but has to do the trick ig

solemn oyster Nov 11, 2020, 12:05 AM

#

So yeah, your issue isn't about it being potentially undefined

#

But rather about you passing all possible overloads to an overloaded method

wispy forum Nov 11, 2020, 12:06 AM

#

I see that now.

solemn oyster Nov 11, 2020, 12:06 AM

#

TS can't match all the overloads we have as a single one, so that's where this kind of issues happen

left moat Nov 11, 2020, 3:22 PM

#

bump to this issue https://github.com/discordjs/discord.js/issues/4287

unique axle Nov 11, 2020, 3:27 PM

#

the channel is for discussion, if you have nothing additional to add to the issue that requires discussion refrain from bumping, thanks. We really don't need this to become bump central.

vernal atlas Nov 14, 2020, 2:57 AM

#

should these error codes be added into djs? i think they're all for store-related things that djs doesn't even have

#

as well as, should these error codes be removed since they can't be obtained?

copper laurel Nov 14, 2020, 3:01 AM

#

Didnt stores die

vernal atlas Nov 14, 2020, 3:03 AM

#

the store channels did yea

#

idk if the whole thing went with it

#

not sure what to name this one, ACCOUNT_VERIFICATION_REQUIRED maybe ?

#

same for this one, best i came up with is CANNOT_DELETE_COMMUNITY_REQUIRED_CHANNEL but feels a bit too long

oak quail Nov 14, 2020, 3:47 AM

#

the store channels did yea
@vernal atlas no

#

store channels still exist lol

#

only the centralized store and nitro games died

vernal atlas Nov 14, 2020, 3:48 AM

#

ah

tacit crypt Nov 14, 2020, 10:34 AM

#

but feels a bit too long

#

RESTPostOAuth2AccessTokenWithBotAndGuildsAndWebhookIncomingScopeResult

#

https://github.com/discordjs/discord-api-types/blob/main/common/index.ts#L93

#

CannotDeleteChannelRequiredForCommunityGuilds

vernal atlas Nov 14, 2020, 12:43 PM

#

PepeLaugh

vagrant holly Nov 14, 2020, 10:25 PM

#

https://github.com/discordjs/discord.js/issues/5011 🤔 locked but left open?

slate nacelle Nov 14, 2020, 10:26 PM

#

Oh right, forgot about that

sick merlin Nov 16, 2020, 4:29 PM

#

<Guild>.members.fetch() doesn't seem to work anymore with the new intent requirements ( without guild members ), but the error doesn't seem straightforward and the error page in the guide doesn't mention the intent is needed

vagrant holly Nov 16, 2020, 5:35 PM

#

You can't fetch members without the members intent, I feel that's pretty obvious, no?

slate nacelle Nov 16, 2020, 5:45 PM

#

The error is actually an internal timeout, Discord (probably) just ignores the request.

#

Since there is no way to always know what intents are present (read: you can omit them on gw6, what we use), we couldn't reliably throw an error here.
Not until v13, then we surely can.

vernal atlas Nov 16, 2020, 6:31 PM

#

couldn't you check <Client>.options.intents ?

#

oh wait- this is for existing v12

vivid field Nov 16, 2020, 6:37 PM

#

since WebSocketManager is a custom implementation, where is the ws package used?

slate nacelle Nov 16, 2020, 6:39 PM

#

/src/WebSocket.js, which then is used in /src/client/voice/networking/VoiceWebSocket.js, and src/client/WebSocket/WebSocketShard.js.

vivid field Nov 16, 2020, 6:42 PM

#

oh right, i forgot that each shard has its own ws connection, thanks

vagrant holly Nov 17, 2020, 11:35 AM

#

Just as an aside, 12.4.x had some nice memory usage improvements (I was running 12.3.1 w/ my message edit limit patched in). No idea what else changed w.r.t to mem usage, but something seems to have done.
@vagrant holly Just to follow up on this, definitely looks like a leak got fixed. No idea what or where, but since updating d.js my memory usage no longer creeps.

tacit crypt Nov 17, 2020, 11:38 AM

#

are you sure it wasn't the message edits?

vagrant holly Nov 17, 2020, 11:47 AM

#

Nah I was on a hotfix branch with my PR merged before

#

Cause that was causing me to oom

vivid field Nov 17, 2020, 5:32 PM

#

why does collection allow a thisArg? what's the difference between collection.find(fn, myCoolObject) and collection.find(fn.bind(myCoolObject))?

merry python Nov 17, 2020, 5:34 PM

#

arrow functions can't be bound, the same parameter exists on standard js functions

vivid field Nov 17, 2020, 5:35 PM

#

but neither works for arrow functions meguFace

keen cosmos Nov 17, 2020, 6:41 PM

#

consistency with array methods?

solemn oyster Nov 17, 2020, 7:08 PM

#

^

real jetty Nov 17, 2020, 11:16 PM

#

why do we have seemingly useless properties such as <Guild>.ownerID even though we have <Guild>.owner? Is this just for ease of use or is there a valid reason? I understand Discord supplies only the owner_id and DJS works out the owner's guildmember object itself but would it not make more sense to have one or the other instead of both?

#

i feel like just having ownerID would be sufficient

copper laurel Nov 17, 2020, 11:19 PM

#

Guild#owner is a getter for this.members.cache.get(this.ownerID)

real jetty Nov 17, 2020, 11:19 PM

#

yes i've seen which is why i kind've see it as useless, the user could simply get the owner with the ID instead of needing two properties for this

copper laurel Nov 17, 2020, 11:20 PM

#

They could, but thats also the purpose of getters

#

I could make the same argument that message.channel shouldnt exist and we should just have message.channelID

real jetty Nov 17, 2020, 11:21 PM

#

true, but if you make that argument:
we could just have <Guild>.owner instead of <Guild>.ownerID

copper laurel Nov 17, 2020, 11:21 PM

#

But GuildMembers are not always cached, making ownerID the valid property here

real jetty Nov 17, 2020, 11:21 PM

#

ah

#

yeah

#

alright thanks for clearing that up

copper laurel Nov 17, 2020, 11:23 PM

#

Which is why <Guild>.owner can be null (getters return null if they cant resolve the data) and thats when the user needs to fetch via ownerID

#

This issue became significantly more present due to intents

frank turret Nov 17, 2020, 11:24 PM

#

Has the possibility of moving convenience getters like this to their own package in next been considered? Recall someone mentioning it in the past

real jetty Nov 17, 2020, 11:25 PM

#

i feel like removing these types of features has been discussed

#

thats why i brought it up

#

and yes intents seem to complicate this sort of thing, guess that adds more reason for the getter

copper laurel Nov 17, 2020, 11:28 PM

#

@frank turret their own package? why?

frank turret Nov 17, 2020, 11:29 PM

#

Well that was an example of some method of separating them so the whole conversation of "why do we have X convenience method when a person can just do Y”

real jetty Nov 17, 2020, 11:30 PM

#

yeah i guess we have to find a middle ground
on one hand some developers don't need these methods at all since they know what they are doing (more or less)
on the other changes like this would break lots of people's code, and new developers may find it difficult to wrap their head around the change

#

although in my opinion if we're going to remove/change conveniences like this we should do it all at once in a major release to get it over with

copper laurel Nov 17, 2020, 11:33 PM

#

Removal of a property is semver major so yes

real jetty Nov 17, 2020, 11:33 PM

#

yeah ik, but as in remove all the convenience methods at once, not just remove one or two
that would just confuse people more

tacit crypt Nov 17, 2020, 11:34 PM

#

I mean.. considering Discord seems to point at serverless and go: this please; I think we should replace a bunch of getters with fetch<X>

#

Er, stateless

#

Close enough

copper laurel Nov 17, 2020, 11:43 PM

#

Conceptually agreed, but I feel like there are already other solutions for that and discord.js really is the caching model

raven juniper Nov 18, 2020, 12:20 AM

#

I believe what nico is referring to is removing stuff like GuildChannel#viewable, the basic permission checks that the user can very easily implement

fading slate Nov 20, 2020, 11:03 AM

#

How are message replies represented in the API/library?

unique axle Nov 20, 2020, 11:04 AM

#

?replies

rich iglooBOT Nov 20, 2020, 11:04 AM

#

Discord.js will support inline replies in v13, replacing Message#reply with the new functionality.
If you'd like to try out the feature ahead of time (in a server with it enabled), please install and test this PR: https://github.com/discordjs/discord.js/pull/4874
You can e.g. use NPM to do this: npm i discordjs/discord.js#pull/4874/head (this requires git to be added to PATH)

fading slate Nov 20, 2020, 11:04 AM

#

fading slate How are message replies represented in the API/library?

Like these^
If I enable the mention while replying, then the bot detects the mention in the message.mentions object which breaks a few commands

#

Okie

copper laurel Nov 20, 2020, 6:37 PM

#

fading slate Like these^ If I enable the mention while replying, then the bot detects the men...

Yeah that correct, Discord sends it as a mention. You should be able to check message#reference in 12.4.1 to see if it's a reply

#

Discord reused the same property crossposts do, so we already support that

fading slate Nov 21, 2020, 1:08 AM

#

Oh, Okie 👍🏻

round mortar Nov 22, 2020, 1:22 PM

#

How are we looking on d.js v13 (specifically the REST package)?

unique axle Nov 22, 2020, 1:22 PM

#

see above

old kelp Nov 22, 2020, 6:43 PM

#

isn't Guild#voice an inferior shortcut for Guild#me#voice? I'm not sure if that's any better to obtain the VoiceState from the Guild#voiceStates (GuildMember#voice does the same there but with a better approach)

solemn oyster Nov 22, 2020, 6:44 PM

#

@oak quail any update on https://github.com/discordjs/discord-api-types/pull/25 ?

oak quail Nov 22, 2020, 11:55 PM

#

oh, i asked aj something about that and forgot to finish it after he responded, i'll do it now

#

ok there

lofty birch Nov 23, 2020, 7:54 AM

#

Any news on this? It's started occuring again

#

Because I see the PR was merged yet it still happened

lofty birch Nov 23, 2020, 8:23 AM

#

On 12.5 too

tawny warren Nov 23, 2020, 10:14 AM

#

Why can't inline replies be added to v12?

old kelp Nov 23, 2020, 10:23 AM

#

because anything that's marked as semver:major goes to the next major releases according to the semantic versioning's rules (https://semver.org/#semantic-versioning-specification-semver). you're still fully free to test it out, install the PR: https://github.com/discordjs/discord.js/pull/4874

snow crypt Nov 23, 2020, 10:37 AM

#

they can, but they shouldn't

#

that can cause confusion

#

currently message.reply sends a message with a mention, but the name reply suggests that it is the discord reply feature, and calling it discordReply or anything similar is just- no

copper laurel Nov 23, 2020, 10:40 AM

#

My PR was Message#inlineReply at one point, and Souji had done one to remove Message#reply in v13

#

But we decided just to merge the two and make it a v13 release

unique temple Nov 23, 2020, 10:42 AM

#

hi, after the discord.js v13 library exits, will i be able to use discord.js v12 without bot verification?

#

sorry, my english is not perfect

slate nacelle Nov 23, 2020, 10:43 AM

#

Bot verification is pretty much unrelated to libraries, as long as v12 is working, you will be able to use it. (Whether its recommend is another thing though)

slate nacelle Nov 23, 2020, 10:44 AM

#

lofty birch Any news on this? It's started occuring again

Do you have any steps to reproduce that, or the like?

unique temple Nov 23, 2020, 10:45 AM

#

A friend told me that I will be able to use the discord.js v12 library until June, after June I need a verified bot to be able to use it

#

@real jetty tłumacz sie

slate nacelle Nov 23, 2020, 10:45 AM

#

No, I am not aware of such a thing, especially since verification is only available after your bot is in 76 guilds.

real jetty Nov 23, 2020, 10:45 AM

#

what

unique temple Nov 23, 2020, 10:46 AM

#

I hope discord.js v12 can still be used after June.

oak quail Nov 23, 2020, 11:01 AM

#

@unique temple discord.js v12 will stop working sometime next year

#

it has nothing to do with whether your bot is verified or not

#

but updating to v13 will probably not be hard

tacit crypt Nov 23, 2020, 11:02 AM

#

How will v12 break? Aren't you confusing it with v11?

#

Oh, wait, api v7

#

Nvm me

lofty birch Nov 23, 2020, 11:24 AM

#

slate nacelle Do you have any steps to reproduce that, or the like?

There was more info in my original messages, but it's not any particular cause that I've found; a shard suddenly just dies and doesn't respawn

#

I'll try something out in a few hours that could find a cause, but can't atm

#

V4 said that the original issue was caused by a process aborting, not exiting. And the manager would then not restart that

vagrant holly Nov 23, 2020, 12:01 PM

#

lofty birch On 12.5 too

The regression that caused this was fixed in 12.5

#

https://github.com/discordjs/discord.js/compare/12.3.1...12.5.0#diff-75a4f785c550209a707697c399a87938fad288bbd1c571614808ed8c08edbd04 there are very few changes on Shard between 12.3.1 and 12.5.0, so I'm pretty sure the regression in 12.4.x was fixed

#

^ just tested on 12.4.1 & 12.5.0, a shard respawns on 12.5.0 when process.exit() is called where it wouldn't on 12.4.1, so I'm confident in saying its fixrd

lofty birch Nov 23, 2020, 1:34 PM

#

One of my shards died and was off for 15 hours this morning until I restarted the manager

real jetty Nov 23, 2020, 3:14 PM

#

Hmm, quick question, why is publicUpdatesChannel read-only but publicUpdatesChannelID not?

vivid field Nov 23, 2020, 3:20 PM

#

because publicUpdatesChannelID is a property sent from discord, whereas publicUpdatesChannel is just a getter which returns the channel with that id from the channel cache

real jetty Nov 23, 2020, 3:21 PM

#

Ahh, I see. Thank you

#

So then i guess that answers the question I was about to ask, "why is it publicUpdatesChannel and not modUpdatesChannel or something", because that's the property name sent from Discord?

vivid field Nov 23, 2020, 3:22 PM

#

correct, most stuff is named according to the discord api

vagrant holly Nov 23, 2020, 3:26 PM

#

lofty birch One of my shards died and was off for 15 hours this morning until I restarted th...

Are you on 12.5.0? Do you have the manager set to respawn dead shards? Did the manager detect the death at all?

lofty birch Nov 23, 2020, 4:18 PM

#

vagrant holly Are you on 12.5.0? Do you have the manager set to respawn dead shards? Did the m...

Yes, Yes (that's the default), my logs say this (using the posting as that indicates the known guild count)

DATA: [354, 325, 349, 313, 351, 338, 0, 322, 332, 320, 329, 352]

[1d 5m 12.4s ago] - SHARD_RESUME
SHARD: 6

[1d 5m 12.7s ago] - SHARD_RECONNECTING
SHARD: 6

[1d 18m 7.1s ago] - POSTING BLAPI
DATA: [354, 325, 349, 313, 351, 338, 366, 322, 331, 320, 329, 352]```

#

and I fetch those values via bot.shard.broadcastEval('this.uptime ? this.guilds.cache.size : 0')

vagrant holly Nov 23, 2020, 4:19 PM

#

so the shard is alive then

#

broadcastEval will throw if the shard is dead

lofty birch Nov 23, 2020, 4:19 PM

#

but apparently not logged in

vagrant holly Nov 23, 2020, 4:20 PM

#

okay so this is an unrelated bug to before

#

So you never see a death event in your logs?

lofty birch Nov 23, 2020, 4:21 PM

#

I wasn't aware there was a death event

#

on manager there's only shardCreate

#

and there's obviously not one on client

vagrant holly Nov 23, 2020, 4:23 PM

#

Yeah so on shardCreate you then bind to shard events

#

shard death will trigger a respawn

lofty birch Nov 23, 2020, 4:24 PM

#

I do listen to that, no ready events were logged in that time

vagrant holly Nov 23, 2020, 4:24 PM

#

I'm confused, do you listen for shard death?

lofty birch Nov 23, 2020, 4:25 PM

#

only shard ready

vagrant holly Nov 23, 2020, 4:25 PM

#

Ah right

#

I'd suggesting listening for shard death/disconnect in your manager

#

and seeing what you get back

#

this feels more like some sort of disconnect issue rather that outright shard death

lofty birch Nov 23, 2020, 4:25 PM

#

Oh I didn't notice those extra events on the shard

#

yeah, will do

#

oh I already listen for disconnect actually (which I've not had since my logs began)

#

just not death

#

Added that now. Other than that is there anything you can recommend?

vagrant holly Nov 23, 2020, 5:25 PM

#

Honestly not, never seen this before in my experience

drifting knot Nov 23, 2020, 7:38 PM

#

right now the methods for banning and kicking members/users accept options in 2 ways:

// kicking:
member.kick(reason?: string)
// banning:
member.ban(options?: { reason?: string, days?: number });

would it make sense to have the kick methods also accept an object for options, so that it's easier to reuse code to ban/kick someone and pass a reason?

lofty beacon Nov 23, 2020, 7:40 PM

#

not in my opinion

frank turret Nov 23, 2020, 7:40 PM

#

Well, that would make sense only if the object would take more than one param. Kick only has one param you can pass in

lofty beacon Nov 23, 2020, 7:40 PM

#

the way it is is fine imo

lofty beacon Nov 23, 2020, 7:40 PM

#

frank turret Well, that would make sense only if the object would *take* more than one param....

yea because of this, its not needed

real jetty Nov 24, 2020, 12:54 AM

#

just following up on @oak quail's question in https://github.com/discordjs/discord.js/pull/4990, it would make sense for User#system to be treated in the same way as User#bot, would it not?

#

i addressed this in PR #4718 however that was considered semver major, however changes with partials mean this would now be considered semver patch, correct?

tawny warren Nov 24, 2020, 6:44 AM

#

old kelp because anything that's marked as `semver:major` goes to the next major releases...

How is that major? It's just adding a feature in a backwards compatible way

old kelp Nov 24, 2020, 6:45 AM

#

you could read a few messages below that and as well read the PR description

sullen bane Nov 25, 2020, 1:23 AM

#

Have there been any discussions on the github about inlining the documentation in the type definitions? I looked but could not find any.

vagrant holly Nov 25, 2020, 1:35 AM

#

Disconnecting the docs from the source seems like an odd move imo. When I’m working on the lib source, having all the jsdoc right there is rather helpful

oak quail Nov 25, 2020, 1:56 AM

#

tbh it would be useful to have it in the types

#

having it in the source is nice for lib devs but having it in the types is much more useful for users

sullen bane Nov 25, 2020, 2:14 AM

#

Agreed, but we could probably rig up a system to mirror it.

#

Like if we include docs links for each method in the typing, we could probably use a small script to populate the comments in the typing

oak quail Nov 25, 2020, 3:02 AM

#

ig

#

at that point, typings could probably just all be handled automatically?

sullen bane Nov 25, 2020, 4:21 AM

#

Not quite. The typeings in TS are much more precise than what is in the jsdoc.

vernal atlas Nov 25, 2020, 4:27 AM

#

yeah generating the types from the jsdoc would either make the typings inaccurate or the jsdoc super wack

copper laurel Nov 25, 2020, 4:35 AM

#

Im not sure what you're looking to achieve here?

#

Having the docs appear with Intellisense?

oak quail Nov 25, 2020, 5:40 AM

#

@copper laurel yeah like this https://advaith.is-in-hyper.space/c9dcf2b7c8.png

copper laurel Nov 25, 2020, 5:41 AM

#

Was decided against because we don't want to maintain two sets of docs

sullen bane Nov 25, 2020, 7:04 PM

#

Worth looking into if it can be automated.

tacit crypt Nov 26, 2020, 12:58 PM

#

If it wasn't said before, that issue will be solved with -next owo

clever crypt Nov 27, 2020, 5:03 AM

#

correct me if i'm wrong but, can breaking changes be performed to the voice aspect of discord.js since it depends on @discordjs/opus which doesn't have a defined public api (basically it doesn't have a v1 yet)

wild flax Nov 27, 2020, 6:21 AM

#

No

sullen bane Nov 27, 2020, 7:55 PM

#

Semantic versioning is a human thing, there are no technicalities with it, even if you could do that -- it would be very rude.

empty viper Nov 29, 2020, 12:07 AM

#

What means typing count in this method ?

vagrant holly Nov 29, 2020, 12:09 AM

#

Internally there is counter, while the counter is greater than one, typing will be sent to the channel

#

so stopTyping needs to be called counter times to actually stop the typing

#

(e.g. if you use startTyping when a user runs a command, and use stopTyping when the command executes, the counter allows for two commands to be run at the same time in the channel and not break that typing effect)

#

So when you call startTyping, you can increment that counter by a custom count if you want. So you could pass 2, and then you'd need to call stopTyping twice to actually stop that typing (or use the force flag)

empty viper Nov 29, 2020, 12:12 AM

#

Okay I see I see, thanks for explanation, and it should be more precise in the description in the doc !

vagrant holly Nov 29, 2020, 12:13 AM

#

Imo its a pretty weird edge case to need to use the count arg, so having more detailed docs might confuse folks into thinking they might actually need to use it more usually

#

But feel free to create an issue if you want, to log the request for the docs to be improved 👍

limber thistle Nov 30, 2020, 2:57 PM

#

are djs' caching issues gonna be addressed in future versions

#

like the reason djs-light exists

tacit crypt Nov 30, 2020, 3:02 PM

#

the only thing that lib does is disable caching. It's not an issue that we do what Discord used to tell everyone (aka cache stuff). If the question would be like are there plans on changing how caching works in the future, then the answer can become, say, maybe, or depends or idk

vagrant holly Nov 30, 2020, 3:03 PM

#

If you have specific caches that are causing you issues, please do say, I'm always looking to add settings to reduce those

#

But you can just manually sweep most things yourself and D.js will keep working for the most part, esp. if you've got partials enabled

tacit crypt Nov 30, 2020, 3:04 PM

#

^

limber thistle Nov 30, 2020, 3:05 PM

#

right thanks

#

its just its not very feasible to run djs on large bots, atleast for me with subpar hosting

tacit crypt Nov 30, 2020, 3:05 PM

#

Sure there is..

vagrant holly Nov 30, 2020, 3:05 PM

#

What do you consider "big"?

tacit crypt Nov 30, 2020, 3:05 PM

#

it's called sweeping

limber thistle Nov 30, 2020, 3:06 PM

#

a server bot i ran in heroku on one server with 220k members couldnt handle it

#

it had intents disabled

#

my other bot reaching 600 servers runs smoothly rn so thats nice

#

#archive-offtopic ?

tacit crypt Nov 30, 2020, 3:06 PM

#

In highlight, I sweep a bunch of things and the bot works just fine shrug , with little memory too! Course, if there's any cache you notice that eats up a LOT of ram compared to the rest, let us know, preferably with heap dumps

limber thistle Nov 30, 2020, 3:06 PM

#

right

vagrant holly Nov 30, 2020, 3:07 PM

#

Manually sweeping members + users will probably help you in that situation (plus ensuring you're not fetching all on boot etc.)

limber thistle Nov 30, 2020, 3:08 PM

#

yeah im not, currently i upscaled the hosts to fix it

tacit crypt Nov 30, 2020, 3:08 PM

#

using just intents you NEED is also a huge improvement

limber thistle Nov 30, 2020, 3:09 PM

#

i turned off all privileged intents too

tacit crypt Nov 30, 2020, 3:09 PM

#

so then your bot did nothing?

vagrant holly Nov 30, 2020, 3:09 PM

#

I might look at adding some sort of options into D.js for sweeping users/members, I wonder what folks would think of that

limber thistle Nov 30, 2020, 3:10 PM

#

yeah that would be nice too

tacit crypt Nov 30, 2020, 3:10 PM

#

Eh, I'd rather at that point we get some configurable caches instead of piece by piece

limber thistle Nov 30, 2020, 3:10 PM

#

my bot worked when i increased its allocated ram

#

configurable cache is also nice

tacit crypt Nov 30, 2020, 3:10 PM

#

If your intents array was empty, then your bot did nothing

#

if you didn't specify intents, it means you just get all events

frank turret Nov 30, 2020, 3:10 PM

#

does d.js-next plan on allowing us to use our own caching structures? Like if i wanted to use redis for the cache

limber thistle Nov 30, 2020, 3:10 PM

#

sorry i mean privileged intents

tacit crypt Nov 30, 2020, 3:10 PM

#

GUILD_MEMBERS and GUILD_PRESENCES are.. shrug

#

depending on each guild, TYPING_START is nightmare, VOICE_STATE_UPDATES, etc

limber thistle Nov 30, 2020, 3:11 PM

#

ok

#

i dont need any voice stuff

#

ill look into that thanks mate

warm crater Dec 2, 2020, 12:18 PM

#

Discord.js should go back to what it was before datastores and managers, the high level API it exposed made sense, it just needed to be refactored. DataStores broke every basic rule of software design, Managers tried to correct it, but left us with inconsistencies in the API. To me, there doesn't seem to be a good argument for something like channel.messages.fetch over channel.fetchMessage. Just because you replace multiple word methods with multiple single-word object fields doesn't make it better or "more object-oriented".

Slight tangent, but most of the problems caused by bad design could be somewhat mitigated if the library allowed for easy dependency injection through constructors (or some kind of IoC container). This would do away with things like cacheType, cacheOptions, Structures.extend etc which are all ad hoc fixes to the current dependency injection situation.

Just some thoughts I've had for a while...

wild flax Dec 2, 2020, 12:27 PM

#

Short answer: yes.
Long answer: Not quite, no.

#

You said yourself that Managers adjusted for the shortcomings that DataStores have, but on the same page you say theres no good argument over them? That seems to contradict yourself.

#

Overall you are not wrong when it comes to dependency injection, but this is far from a "simple" change. It takes quite some time to implement that or even do it correctly.
And even if we do it, there would also be no "going back" to the old structure. With correctly applied DI it would look somewhat similar to what we have now still, just not as inconsistent.

warm crater Dec 2, 2020, 12:56 PM

#

I'm saying there is no good argument for the current API (that uses managers), over the API that v11 exposed (which didn't have managers or datastores). DataStores tried to separate the responsibilities of the old ClientDataManager, but they also changed the API (e.g. channel.messages.fetch) without good reasoning, this side effect resulted in managers to once again separate cache and Discord API calls, v11 already had this separation. Now we are left with things like channel.messages.cache, channel.messages.fetch alongside channel.fetchInvites, which is inconsistent and clunky. Whereas if we stuck with the v11 style we would have channel.messages for the cache, and we would have consistency with API calls like channel.fetchMessage, channel.fetchInvites etc.

Managers adjusted for the some of the shortcomings of DataStores, but not all of them.

wild flax Dec 2, 2020, 1:00 PM

#

Yeah there is enough good arguments. And all of them are listed in the issue that eventually led to managers. If you just completely overlook those for the sake of your "more words bad" argument then I don't know how I else I can help you understand.
The more "oop-ey" approach was not the motivation at all here.

vagrant holly Dec 2, 2020, 1:00 PM

#

Imo, $0.02, having methods that affect cache inside a manager instead of the parent model is cleaner. Yes, it leads to some inconsistency with model methods that don't have a cache, but I think it provides a clear separation between methods touching cache and those that don't.

wild flax Dec 2, 2020, 1:03 PM

#

Managers adjusted for the some of the shortcomings of DataStores, but not all of them.
And that exactly was the whole point. There is not really any "fixing it all" with the current iterations without a complete rewrite of how the system works. Which would be immensely more time consuming on top of all possible bugs this could introduce. So we are not only talking a new major version increase but also one that has a very high risk associated to it.

#

I don't know how you write software, whether that be hobby-wise or professionally, but since this is mostly a non-profit open source project you can or rather don't want to take such risks if you are aware that it could lead to hundreds or more hours you need to put into "fixing" while you already pushed it to users out there to use but its in a complete broken state.

#

There is a huge component that influences all decisions we make that isnt just "writing code" at the end of the day here. Writing code is maybe 30-40% if at all.

warm crater Dec 2, 2020, 1:45 PM

#

I did read the original issue, it lists DI as one of its benefits, but there are other ways of doing DI that would have worked with the old API, its not unique to managers. It also lists separating cache and API as a benefit, but reverting also has this effect. It also says that one of the main reasons is that the data store API is more fluent than the v11 API (the more words bad argument), which is what I disagree with.

I think the risk of removing Managers would be similar to the risk of adding DataStores, which admittedly took a long time if I recall but it did happen eventually, so I would say its possible without a complete rewrite. DI was more of an afterthought I had, that would definitely need a complete re-write (probably in TypeScript) for it to be solid and not hacky.

wild flax Dec 2, 2020, 2:25 PM

#

Feel free to open a PR if you think its the same risk and effort.

#

The reason Mangers took that long was simply because no one worked on it for a long time, not because it actually did take a long time.

copper laurel Dec 2, 2020, 11:26 PM

#

It's also worth pointing out here that DataStores were never released. They were never in v11, and they weren't in 12.0.0

limber thistle Dec 3, 2020, 5:37 AM

#

Thoughts on having separate partial events that you could specify in clientOptions? ,
partials will only fire in the events specified in that option so that we dont need to do if(class.partial ) return for all the other events if we decide to use partials

vernal atlas Dec 3, 2020, 6:14 AM

#

eh

real jetty Dec 3, 2020, 6:16 AM

#

do you mean different events for partial data or selecting which events the client would emit if the data provided is partial

limber thistle Dec 3, 2020, 7:25 AM

#

same event, if you enable partialEvents, it only fires partialData if that event is enabled

#

if you dont give any partial events it doesnt affect anything

#

say I only want partial data for the reaction event

#

right now i have to go to each event and add if(partial) return

#

and use it only in reactionEvent

#

I can submit a pr if this is a good idea

oak quail Dec 3, 2020, 7:33 AM

#

could use client.ws.on to get the raw MESSAGE_REACTION_ADD event

limber thistle Dec 3, 2020, 9:28 AM

#

guess i could

unique axle Dec 3, 2020, 9:51 AM

#

limber thistle I can submit a pr if this is a good idea

no thanks, the events emitting raw WS data exist on Client#ws
as documented here https://discord.js.org/#/docs/main/stable/class/WebSocketManager - note the info box

oak quail Dec 5, 2020, 12:11 AM

#

is there any chance of bringing back disabledEvents?

glad sparrow Dec 5, 2020, 12:16 AM

#

Why was it removed tho

ornate topaz Dec 5, 2020, 12:24 AM

#

cause intents were created

#

it has pretty much same effect, apart from the fact that intents are groups and are never sent to you, instead of just being dropped by lib upon receiving

oak quail Dec 5, 2020, 3:04 AM

#

that "apart from" matters tho

#

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

This gives a public alternative to the private raw event. (The raw event isn't removed, for the purposes of library testing.) This gives devs the ability to work with d.js in a cacheless way without relying on the private raw event.

#

Like raw, these event's aren't disabled with ClientOptions#disabledEvents (which isn't very aptly named, since it only disables the internal d.js handlers).
however they are disabled by intents

#

also you dont get per-event control with intents

glad sparrow Dec 5, 2020, 10:43 PM

#

oak quail also you dont get per-event control with intents

^

prime prairie Dec 6, 2020, 7:09 AM

#

When I do member.premiumSinceTimestamp, I sometimes get 0, or I get null depending on the user (That aren't boosting), is there a reason why these are sometimes different?

#

Thats a log of 2 users

vagrant holly Dec 6, 2020, 8:29 PM

#

When the messageReactionAdd partials fix was done, did that also update/fix messageReactionRemove?

#

From my super limited test, if I start a bot up and remove a reaction, the event isn't fired

slate nacelle Dec 6, 2020, 8:39 PM

#

Discord does not seem to provide a member or user there: https://discord.com/developers/docs/topics/gateway#message-reaction-remove
So there isn't really anything we can do.

vagrant holly Dec 6, 2020, 8:46 PM

#

Huh, there is a user id there?

#

I wonder if it fires if I enable user partials

slate nacelle Dec 6, 2020, 8:48 PM

#

Yeah, then it should.

frank turret Dec 8, 2020, 12:51 AM

#

Any specific reason @discordjs/docgen has eslint as a main dep? Along with using Tsubaki just for a simple Promisify that could be done with Util.Promisify? The engine field in the package.json intends for docgen to be used with Node >=8.0.0 so Tsubaki is kind of useless here. Is it worth opening a PR over just to remove those? Asking cause I intend to use docgen for a personal project. I'mma go ahead and make a PR anyways OMEGAlul

empty viper Dec 8, 2020, 3:01 AM

#

Shen does discord.js-next will start to be programmed ?

copper laurel Dec 8, 2020, 3:01 AM

#

Whenever the maintainers feel like working on it

vernal atlas Dec 8, 2020, 7:27 AM

#

when can APIMessage#target be a User or a GuildMember?

warped crater Dec 8, 2020, 7:29 AM

#

if I had to guess, DM channels result in it being a user for a start

vernal atlas Dec 8, 2020, 7:29 AM

#

but they are DMChannel instances ?

warped crater Dec 8, 2020, 7:30 AM

#

huh

vernal atlas Dec 8, 2020, 7:31 AM

#

https://github.com/discordjs/discord.js/blob/09d07553ab5f4fa8643862129c17550a21e1c081/src/structures/interfaces/TextBasedChannel.js#L158

warped crater Dec 8, 2020, 7:31 AM

#

ah, it may be because both DMChannel and User implement TextBasedChannel, sug

vernal atlas Dec 8, 2020, 7:32 AM

#

hm

warped crater Dec 8, 2020, 7:32 AM

#

that's still weird though

vernal atlas Dec 8, 2020, 7:32 AM

#

i guess if you create your own APIMessage instance maybe

#

thats like the only place i can see it being a user/guildmember

warped crater Dec 8, 2020, 7:33 AM

#

looks like a legacy of the past tbh

vernal atlas Dec 8, 2020, 7:33 AM

#

possibly

real jetty Dec 8, 2020, 5:13 PM

#

Im curious, when d.js sends a request to the api and it comes back, does d.js translate the received properties into javascript conventions (like camelCase for example)? Or does it come back already camelCase so there isn't much to do?

#

i could actually probably check the source couldnt i

#

interesting, i'm assuming this var instead of let is intentional? smart

real jetty Dec 8, 2020, 5:35 PM

#

So looking through at least the Message structure, it seems that if Discord were to add a property to the message object returned by the API, it wouldn't be seen by the end user (the one using d.js). Why is that?

vagrant holly Dec 8, 2020, 5:40 PM

#

The library isn't really just an API wrapper, it provides proper custom interfaces, so it doesn't just expose API data automagically

warm crater Dec 8, 2020, 6:10 PM

#

You would also have to manually update the typings to support it anyway.

warm crater Dec 8, 2020, 6:33 PM

#

And as v4 was saying, if you use some JavaScript magic and dynamically rename snake_case properties to camelCase then you lose the ability to choose what kind of abstraction you want to expose to developers. This would make the library very unstable because some people would adopt the new property and now you can't change how its exposed without breaking everything.

copper laurel Dec 8, 2020, 6:36 PM

#

yes we do translate snake_case to camelCase
yes the structures are custom and don't expose new properties
unmodified Discord event packets can be listened to via client.ws.on("MESSAGE", message => etc

long perch Dec 8, 2020, 7:01 PM

#

discord.js-commando should have an implemented property that allows the automatic cancel response to be changed or disabled.

empty viper Dec 8, 2020, 9:04 PM

#

Is there a version of this library for Deno ?

raven juniper Dec 8, 2020, 9:05 PM

#

no, only node

empty viper Dec 8, 2020, 9:06 PM

#

Oh...

vernal atlas Dec 9, 2020, 5:01 PM

#

there seems to be a slight issue with the typings for the send method on PartialTextBasedChannelFields, passing something that can be of multiple types results in an error
eg:

const options: string | MessageOptions = ...;
channel.send(options);```
this is perfectly valid code, however results in an error with TS, because none of the overloads technically accept this

i think *more* overloads need to be added here, but it seems like its getting very bulky there are already alot of overloads

real jetty Dec 9, 2020, 9:19 PM

#

https://github.com/discord/discord-api-docs/pull/2295 EYES

unique axle Dec 9, 2020, 9:22 PM

#

Slash Commands:
• PR pr_open https://github.com/discordjs/discord.js/pull/5448
• Docs (Discord): https://discord.com/developers/docs/interactions/slash-commands
• Coming changes (Discord): https://github.com/discord/discord-api-docs/issues/2490
• Arrival in discord.js scheduled for 13.x
• We will not provide support for slash commands before they arrived on the stable branch

unique axle Dec 9, 2020, 9:23 PM

#

unique axle **Slash Commands:** • PR <:pr_open:803281518457913355> <https://github.com/disco...

vernal atlas Dec 10, 2020, 2:54 PM

#

@tacit crypt what precisely do i need to update in my v8 PR for the ratelimits? i did a test and on v7 the API sends 5 as the x-ratelimit-reset-after, but on v8 sends 5.000, so i would assume that rather than 4 for 4 seconds being returned now 4.567 would be returned for 4 seconds and 567 milliseconds? the number is already multiplied though so would be 4567 - or am i just being stupid and missing something

tacit crypt Dec 10, 2020, 2:54 PM

#

retryAfter is in seconds

vernal atlas Dec 10, 2020, 2:54 PM

#

oh

#

oh i see now i think

#

yeah i was being dum dum

tacit crypt Dec 10, 2020, 2:55 PM

#

vernal atlas Dec 10, 2020, 3:16 PM

#

applied change

ruby terrace Dec 11, 2020, 3:59 AM

#

I'm currently working to implement interactions (slash commands being the only interaction for now), based on the last pinned message, should I hold off on my PR?

copper laurel Dec 11, 2020, 5:08 AM

#

Yes, probably. The API docs PR is still marked as a WIP with comments off. Given that even Discord doesn't want it open for discussion yet, probably best to hold off

ruby terrace Dec 11, 2020, 5:11 AM

#

Ok thanks, I was going to mark mine as a draft /WIP as well and keep along with the updates, but I'll just wait until they have finalized their docs

tired valve Dec 11, 2020, 11:16 AM

#

@ruby terrace you have a typo there, Constants.js#L276
https://cdn.discordapp.com/attachments/768863525443338281/786914189893566484/chrome_RXHFezuItQ.png

ruby terrace Dec 11, 2020, 4:30 PM

#

Whoops, thank you!

drifting knot Dec 12, 2020, 8:41 AM

#

the interactions PR needs the v8 api PR https://github.com/discordjs/discord.js/pull/4879

can we expect #4879 to be merged before 2021Q1?

ruby terrace Dec 12, 2020, 8:43 AM

#

I don't think we get ETA's on that, but I believe the intent was to have gateway v8 be a part of the v13 release.

ornate topaz Dec 12, 2020, 9:32 AM

#

the switch to v8 is the reason there has to be a v13 in the first place

tired valve Dec 12, 2020, 12:49 PM

#

& reply() being inline replies is a major change

drifting knot Dec 12, 2020, 1:59 PM

#

does djs use GH milestones? would be nice if appropriate PRs were tagged with a v13 milestone

unique axle Dec 12, 2020, 2:00 PM

#

due to how we use checkboxes for versioning rather than for progress milestones aren't all that useful
(as milestones accumulate progress based on checkboxes)

drifting knot Dec 12, 2020, 2:53 PM

#

oh L

agile blade Dec 12, 2020, 10:47 PM

#

Had a question on a comment on a PR I’m working on, can someone clarify for me? It’s on PR #5026

unique axle Dec 12, 2020, 10:49 PM

#

if you actually ask the question one might be able to answer

agile blade Dec 12, 2020, 10:51 PM

#

Just wanted to make sure I was in the right channel...
There’s a comment asking about the options object of the method, and if it could extend RoleData. I’m not entirely sure what is being asked as a change, I know it’s a documentation related thing but unsure on specifics

lofty birch Dec 13, 2020, 5:45 PM

#

I've noticed that when updating a username, guild member update is fired with an identical user object (both of which have the new username). I presume this is unintended behaviour?

unique axle Dec 13, 2020, 5:51 PM

#

unintended but known: https://github.com/discordjs/discord.js/issues/4800

lofty birch Dec 13, 2020, 5:53 PM

#

ah that sucks. any workaround?

unique axle Dec 13, 2020, 5:53 PM

#

i'd recommend reading the issue responses

lofty birch Dec 13, 2020, 5:55 PM

#

Oh that's interesting, it's apparently caused by presence updates, but I don't use presence intents

#

It must be from user update arriving shortly before member update then, regardless of presence updates

unique axle Dec 13, 2020, 5:59 PM

#

and if you now read the issue comments again you will realise that userUpdate is a artificial event that's not directly emitted from the API, as USER_UPDATE only emits for the client user and instead created based on the data in GUILD_MEMBER_UPDATE (which also emits on underlying User data) as well as PRESENCE_UPDATE (which also control the initial GuildMember and User caches to be filled) payloads.

empty viper Dec 14, 2020, 3:15 AM

#

Are managers coming to djs-next ?

ornate topaz Dec 14, 2020, 3:18 AM

#

https://github.com/discordjs/discord.js-next/pull/23#issuecomment-744138052

empty viper Dec 14, 2020, 9:15 AM

#

Oh...
This should be made in a way that you don't have to put .cache everywhere, like a subclass of Collection that have the methods to fetch or resolve

oak quail Dec 14, 2020, 9:20 AM

#

that was DataStores which got replaced with Managers before v12 was officially released

#

and it is good to have .cache because although it is longer, you know that you are accessing the bot's cache and it will likely not be full

unique axle Dec 14, 2020, 10:16 AM

#

to get it out of the way: "i have to put a word more" is in no phase of the design process a consideration we make. as harsh as it might sound: "deal with it."

the clear separation of cache from API access is a concept we will be moving forward with. we have tried the other approach shortly during the development of v12 with "stores" which we have discarded as it caused more issues than it solved. with the rewrite considering modularity (plugging in own cache implementation) the separation becomes even more worthwhile.

#

in the current version 12.5.1 managers don't seem to be very useful, however there is a PR which will cover this (likely with v13) #4869 and will expose direct API access (so you don't need to unnecssarily fetch things before operating of them if you have the required data), again putting more value in a clear separation.

a general word about discord.js-next : the rewrite is not a sharp picture yet. we notice issues with the current approaches which can not be solved without a major redesign which we consider for the rewrite. we are aware that mangers in their current iteration are not optimal and have expressed that internally as well as externally, howver we do believe that they are better than the v11 approach of having them on the structure they belong to or the (discarded) v12 in-dev approach of mashing cache and api access together (which seems to be what you propose here)

snow crypt Dec 14, 2020, 10:00 PM

#

would the way to fix this be removing ```yaml
- run: git checkout HEAD^2
if: ${{ github.event_name == 'pull_request' }}

ruby terrace Dec 15, 2020, 2:49 AM

#

This is a very strange and unlikely edge case, but currently if you want to edit a message and change suppress embeds (basically if you are editing in an embed, and suppress was currently enabled) the API gets two calls unless the user knows to add the undocumented flags parameter as an option.
Would it be a good idea to clean this up and add a suppressEmbeds option to MessageEditOptions and completely remove suppresEmbeds since it is just a helper method?

oak quail Dec 15, 2020, 8:34 AM

#

@ruby terrace I don't think suppressEmbeds should be removed since there are tons of set__ helper methods which do basically wrap edit

copper laurel Dec 15, 2020, 8:37 AM

#

edit should support the flags though if it doesn't already, I agree with that much

ruby terrace Dec 15, 2020, 8:37 AM

#

edit does support flags, it just wasn't in the MessageEditOptions typedef, and only suppressEmbeds passed it

ruby terrace Dec 15, 2020, 8:39 AM

#

oak quail <@140214425276776449> I don't think suppressEmbeds should be removed since there...

Valid point, forgot about those set_ ones... this may be a not-right-now thing then with the eventual goal to clean all these helper methods out, maybe evening something for -next

vale moss Dec 15, 2020, 12:30 PM

#

https://github.com/discordjs/discord.js/pull/5122
Useless change. In my opinion, it just breaks code. Using enums is possible now, without renoving string perms support

wild flax Dec 15, 2020, 12:49 PM

#

Devils advocate:
If discord ever decides to again, change something in their naming, we don't need people to change it in all their code because discord decided to rename something or whatever (thought further down the line you prolly still want to rename it, so take that with a grain of salt)

#

2nd, people already typo those permissions left and right, ive seen stuff from "SNED_MESSAGE" to "GILD_MEMER"

#

This assures this surely wont happen

vale moss Dec 15, 2020, 12:51 PM

#

So you dont want users to change anything, but change lib api extremely?

#

However, i think lib should give users choice what to use and how to

merry python Dec 15, 2020, 12:54 PM

#

2nd, people already typo those permissions left and right, ive seen stuff from "SNED_MESSAGE" to "GILD_MEMER"
this only works in TS where the compiler can actually tell you whether or not you're using a valid value, if you typo Permissions.FLAGS.SNED_MESSAGE in JS it's no better than typoing "SNED_MESSAGE". But it's better than nothing

wild flax Dec 15, 2020, 12:56 PM

#

JS auto-completion should be good enough to pick this up

#

To at least list you all the possible values

wild flax Dec 15, 2020, 12:56 PM

#

vale moss However, i think lib should give users choice what to use and how to

Giving a choice is good, making everything a choice is the same as just writing your own wrapper with the stuff you want

vale moss Dec 15, 2020, 12:56 PM

#

Agree, extremely do

wild flax Dec 15, 2020, 12:57 PM

#

This isn't just a wrapper after all, its a whole library

#

A wrapper would just expose and let you do all the other stuff, no caching, no nothing at the end of the day

#

We wouldn't then even need the abstraction for events we have, since you could just listen to .on('MESSAGE_CREATE') yourself for example

#

Its a tough choice sometimes

vale moss Dec 15, 2020, 1:01 PM

#

The Best choice is change nothing

wild flax Dec 15, 2020, 1:02 PM

#

Thats subjective here

#

Because as much as you say that, I could argue the best choice is to be as restrictive as possible

vale moss Dec 15, 2020, 1:05 PM

#

Lib must be restrictive from the beginning

wild flax Dec 15, 2020, 1:05 PM

#

I can also change

#

Thats the purpose of major changes

tender field Dec 15, 2020, 1:37 PM

#

Hi, why is discord.js not using a transpiler (such as babel)?
It seems the "main" reason to drop support of node 12 is to benefit of the new ES2020 features, but why not just use babel? It will also allow the use of the "import" notation (which I know is only syntactic sugar), and it will not even be, i think, a breaking change, will it ?

frank turret Dec 15, 2020, 1:38 PM

#

is that really necessary to do that when djs-next is being rewritten in typescript and can be transpiled down to a lower es version?

tender field Dec 15, 2020, 1:39 PM

#

no ofc, but why wasn't it use from the beginning? (sorry for the english btw)

tender field Dec 15, 2020, 1:41 PM

#

frank turret is that really necessary to do that when djs-next is being rewritten in typescri...

and why increasing the minimum nodejs version, if, with djs-next, it will be possible to bring it down again?

#

i mean it's not a problem for me, i'm already on 14.5.1, but i'm just curious 😅

undone ravine Dec 15, 2020, 3:40 PM

#

tender field no ofc, but why wasn't it use from the beginning? (*sorry for the english btw*)

We chose to only support the latest (at the time of release) Node LTS version and newer, so there's no point in transpiling to allow use on older versions.

tender field Dec 15, 2020, 4:09 PM

#

okay

low minnow Dec 15, 2020, 5:23 PM

#

Are the recently-merged Slash commands and Interactions (https://discord.com/developers/docs/interactions/slash-commands)
being actively worked on and is there any ETA?

ruby terrace Dec 15, 2020, 5:24 PM

#

No ETA, but actively being worked on yes https://github.com/discordjs/discord.js/pull/5106

low minnow Dec 15, 2020, 5:24 PM

#

Alright, ty

empty viper Dec 15, 2020, 11:52 PM

#

Does this will come to djs v12 or v-next ?

frank turret Dec 16, 2020, 12:05 AM

#

I don't see this as being a breaking change, so I don't see why it wouldn't come to v12

empty viper Dec 16, 2020, 12:07 AM

#

Oh I understand, breaking changes comes into new releases ?

unique axle Dec 16, 2020, 12:30 AM

#

frank turret I don't see this as being a breaking change, so I don't see why it wouldn't come...

This will need #4879 before it lands.
which is the switch to gateway v8
which is semver major
=> slash commands will land after 13.0.0

frank turret Dec 16, 2020, 12:31 AM

#

:oops:

#

hadn't realized interactions were v8

unique axle Dec 16, 2020, 12:31 AM

#

empty viper Oh I understand, breaking changes comes into new releases ?

for reference see: https://semver.org/
breaking changes need a semver major - format being MAJOR.MINOR.PATCH
current stable is 12.5.1, meaning a breaking change will happen with 13.0.0
the next breaking change 14.0.0 and so on, where as minor releases are new features and patch are bug fixes or internal improvements

empty viper Dec 16, 2020, 12:37 AM

#

Mh I see, I was thinking that you have to change the MAJOR version when there is a big feature that comes

copper laurel Dec 16, 2020, 12:37 AM

#

Standard reminder that -next is not the next major release either way

wide sand Dec 16, 2020, 6:40 AM

#

so there is no option for INTERACTION_CREATE

ruby terrace Dec 16, 2020, 6:41 AM

#

That's actively being developed, please check the pull requests (you can also get the raw event)

wide sand Dec 16, 2020, 6:56 AM

#

i see

wide sand Dec 16, 2020, 7:08 AM

#

ruby terrace That's actively being developed, please check the pull requests (you can also ge...

is raw event available?

ruby terrace Dec 16, 2020, 7:09 AM

#

yes, ask in #archive-djs-v12-deprecated for how to get raw events

raven juniper Dec 16, 2020, 12:48 PM

#

ruby terrace yes, ask in <#223867697312694272> for how to get raw events

Please don't, we do not support the raw event, it's private for a reason

oak quail Dec 16, 2020, 5:26 PM

#

@raven juniper client.ws.on works and is public

raven juniper Dec 16, 2020, 5:28 PM

#

i see nothing about it on the client.ws docs but i'll take your word for it, i don't mess too much with that stuff, i just know it's a pain and people looking for support aren't likely gonna get any because not many people know it

tacit crypt Dec 16, 2020, 5:29 PM

#

we don't document what events we emit on client.ws for..obv reasons

#

But, any packet that has a t will get emitted

unique axle Dec 16, 2020, 6:14 PM

#

WebSocketManager extends EventEmitter
The WebSocket manager for this client.
This class forwards raw dispatch events, read more about it here https://discord.com/developers/docs/topics/gateway

snow crypt Dec 18, 2020, 9:14 AM

#

Is .tern-profect still needed?

kindred haven Dec 18, 2020, 11:37 PM

#

Should Client#token really be instantiating to process.env.DISCORD_TOKEN if it exists?
The behavior seems really odd

ornate topaz Dec 18, 2020, 11:42 PM

#

what's wrong with it?

kindred haven Dec 18, 2020, 11:46 PM

#

Nothing in particular
just wondering why it was added
it seems like it would only be useful for env vars but nothing really else

ornate topaz Dec 18, 2020, 11:46 PM

#

this way you don't have to "store" token in your code

merry python Dec 18, 2020, 11:47 PM

#

it's also used by the sharding manager to pass the token to the shards

ornate topaz Dec 18, 2020, 11:47 PM

#

and considering that there are million other ways to populate process.env than dotenv, you can do it from outside of your bot code or even node

kindred haven Dec 18, 2020, 11:47 PM

#

ah k

#

makes sense

frank turret Dec 21, 2020, 7:40 PM

#

Are there any plans to encorporate the pending property on a guildmember? Ref: https://discord.com/developers/docs/resources/guild#guild-member-object

unique axle Dec 21, 2020, 7:42 PM

#

yes, search GH for PR, if none: make one

frank turret Dec 21, 2020, 7:42 PM

#

Make one, got it

unique axle Dec 21, 2020, 7:42 PM

#

haven't done step 1 yet, so that might need to happen before WonkBOYE

frank turret Dec 21, 2020, 7:42 PM

#

02facepalm there is one nevermind

real jetty Dec 22, 2020, 1:19 AM

#

is there support for the new /command system?

#

oh thanks

dawn lodge Dec 22, 2020, 3:49 AM

#

Nico beat me to it 👀

dawn lodge Dec 22, 2020, 3:53 AM

#

frank turret <:02facepalm:780642752534675467> there is one nevermind

Care to link me? I'm either dumb or blind I guess.

frank turret Dec 22, 2020, 3:54 AM

#

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

dawn lodge Dec 22, 2020, 3:54 AM

#

Oh nice, already a PR

#

I assume this will arrive in v13 as well?

frank turret Dec 22, 2020, 3:57 AM

#

I don't see why it wouldn't come in v12, it's not a breaking change and the PR doesn't specify whether only the v8 api would have it

quaint bronze Dec 22, 2020, 4:35 AM

#

I'm not sure but I think it makes more sense to have an event for that maybe GuildMemberAccept it emit when the member accepts the rules so we can do something like sending a welcome message or giving a role

old kelp Dec 22, 2020, 4:58 AM

#

we cannot really implement something custom if the API does not support natively (which makes it a way unreliable), so that is upto them, then surely.

ruby terrace Dec 22, 2020, 5:07 AM

#

frank turret I don't see why it wouldn't come in v12, it's not a breaking change and the PR d...

it's semver minor meaning it could come to v12, however, i do not believe there will be another release before v13 (at this time at least)

wild flax Dec 22, 2020, 5:23 AM

#

This is correct and it needs API v8 so it’s a v13 only

ornate topaz Dec 22, 2020, 5:37 AM

#

How does it require v8 though?

oak quail Dec 22, 2020, 5:46 AM

#

it doesnt

wild flax Dec 22, 2020, 8:17 AM

#

I have not touched v6 in a long time but gus mentioned the v8 PR in his

#

Do registering commands / the gateway event exist in v6?

ruby terrace Dec 22, 2020, 8:19 AM

#

oh, we were talking about the guildMember#pending property. As far as v6 for interactions, I've heard they work just fine, but we should be on v8 at that point anyways

wild flax Dec 22, 2020, 8:19 AM

#

Right. I was looking at the wrong PR then.

#

Either way, very slim chance this will be released in the 12 cycle, as semver:major prs already landed in master

frank turret Dec 22, 2020, 12:36 PM

#

old kelp we cannot really implement something custom if the API does not support natively...

But what about userUpdate? Referring to this message that claims userUpdate is merely an artificial event emitted by djs <#archive-library-discussion message>. If we can have artificial events like user update why not a guildMemberAccept?

unique axle Dec 22, 2020, 12:40 PM

#

why? should be the question, rather than "why not"

#

it emits guildMemberUpdate, you check #pending on old and new

#

if the end user wants to make that its own event they are free to use the node vent API to emit it, but i don't see any benefit in doing it on the library level

ruby terrace Dec 22, 2020, 12:42 PM

#

There's also been a lot of push to make that event a native API event, but as long as we get a difference in pending state, then it shouldn't matter, that's an easy check to make.

unique axle Dec 22, 2020, 12:43 PM

#

~~and that push is just as nonsensical from discords perspective, it emits an event, that single check should not warrant it being its own event~~

#

nvm, intents have happened, people want to operate without cache

#

ofc, if it becomes its own gateway event it will get its own Client event in discord.js - as it is GUILD_MEMBER_UPDATE currently however at the present time that makes no sense on the library level

ruby terrace Dec 22, 2020, 12:45 PM

#

I doubt it will become its own event at this point, supposedly we only get the pending parameter (set false) on the GUILD_MEMBER_UPDATE event after someone finishes screening. That should be enough for people without cache too.

old kelp Dec 22, 2020, 12:55 PM

#

agreeing Souji and ckohen on that, I guess must be fully enough to make a (single) check against the .pending-property (as GUILD_MEMBER_UPATE already emits for that specific change), and except if you're messing with partials.

vivid field Dec 22, 2020, 3:12 PM

#

https://github.com/discordjs/discord.js/blob/master/src/structures/IntegrationApplication.js#L13 is that a property the library adds to the data object somewhere? https://discord.com/developers/docs/topics/oauth2#application-object doesn't seem to document it

vernal atlas Dec 22, 2020, 3:56 PM

#

thats an IntegrationApplication (https://discord.com/developers/docs/resources/guild#integration-application-object)

#

(also see https://discord.com/developers/docs/resources/guild#get-guild-integrations)

vivid field Dec 22, 2020, 3:59 PM

#

oops, didn't notice that integration applications have their own part in the docs

#

thanks

hollow salmon Dec 23, 2020, 4:07 PM

#

Can I ask here if the Collections utility is still maintained or would that be off-topic?

vivid field Dec 23, 2020, 4:31 PM

#

it is maintained

proper dock Dec 23, 2020, 7:22 PM

#

I was asking some questions in the Discord Development server, and someone mentioned that if discord.js hits a rate limit, it waits until the limit expires and then tries the call again (#697489244649816084 message). Is that accurate? I feel that when I call a method that might be rate limited, I should be able to pass in options to tell it whether I want it to retry and/or whether I want it to throw an error. At the very least, it would help in debugging. But ideally if the bot can't do something right now, I'd like to be able to act on that. My bot could say something like, channel.send('Sorry! I've been doing that too fast, and I'm not allowed to right now. Please try again later.');

slate nacelle Dec 23, 2020, 7:24 PM

#

The behavior you are describing is correct.
Something like an option to limit retries that are longer than x or the like have been brought up, but nothing really has been done in that regard so far.

proper dock Dec 23, 2020, 7:24 PM

#

Oh, interesting. I missed that. So, something like setTopic - I'm limited to 2 every 10 minutes. Does this fire when I've done the second one, or when I attempt the third one?

#

So discord.js will still make that attempt later, right?

#

Is there any way to stop it from re-trying that request?

slate nacelle Dec 23, 2020, 7:25 PM

#

You would get a debug log there, rate limit only emits when the request is preemptively throttled. (That is indeed a bit weird)

#

No, there is currently no way to cancel a request.

proper dock Dec 23, 2020, 7:28 PM

#

Are there any ongoing discussions about this topic? I'd be willing to take a stab at something and make a PR, but I'd totally welcome some guidance onto what the best way to handle all of this is.

#

Option 1: A map of known rate limits. We could fire a rateLimitWarning based on a map of known values: If you try that again in the next X seconds, it will be rate limited.
Option 2: Some hook on the current rateLimit event that does the current behavior by default, but the developer can do something with the event to cancel the request if required.
Option 3: Pass options into anything that might get rate limited to tell it what to do.

Out of these 3, it seems Option 2 is best to me. But maybe there are other options I haven't thought of.

slate nacelle Dec 23, 2020, 7:44 PM

#

I am not aware of any discussions currently (or recently) about that. (I am pretty sure there was something about that, but I can't find anything at the moment.)

1 is a no, since Discord might change limits at any point, and is generally not happy about hard coded limits.
3 is possible, but feels like it could become a hassle since everything is subject to be rate limited.

2 indeed looks like something that could be done, although I'm not too sure how it would work exactly.

Some possible naive solution could be to add a function to the object that, when called, cancels the request (causing the returned promise to reject with some error).

My initial idea was to be able to configure a static limit for rate limits as client options, but that might be a bit too broad, while yours would allow better control about when to (not) wait.

proper dock Dec 23, 2020, 7:46 PM

#

So - I haven't FULLY read the code yet. Just given it a quick glance. Requests go into a queue, right? If we attached a UID to each request, we could pass back the UID in the rateLimit event. Then we could provide a method to remove an event in the queue by passing in a UID.

slate nacelle Dec 23, 2020, 7:47 PM

#

They go into a queue, one per route.

proper dock Dec 23, 2020, 7:48 PM

#

Okay. So if we have a method called something like cancelRequest(route, uid), that might work.

#

Find the queue for the route and in there, find the request with uid...

#

And although a bit confusing given the rateLimitInfo.method there, it might also be interesting to pass back the name of the method that was called. For example, rateLimitInfo.callingMethod: 'channel.setTopic' or something like that.

#

Unless that's information that's in the route already. I'm not familiar with how the routes are named in the API.

#

I guess my only remaining question is - if I tackle something like this, how do I ensure I'm doing it in a way that will be accepted in a PR? I don't want to do the work, and then have someone say, "no, we're not implementing this." That's the only reason for all of this discussion/questions. So what do I need to do/to whom do I need to speak, to make sure that the spec work I'm doing describes work that will be accepted?

slate nacelle Dec 23, 2020, 7:54 PM

#

Somewhat, I don't think there are too many, if any, not-helper functions sharing the same route.
What public-facing-method caused the request is currently not known to the request handler.

#

That is indeed a good and reasonable question, which I do not really have an answer to jynEHEH

I'd be +1 on this feature, but think it could be troublesome to actually cancel a request that currently waits for a rate limit to expire (as that's just a promisified setTimeout, and polling some cancel flag does not feel too right?).
But I do not really have another idea about how that would work.

proper dock Dec 23, 2020, 8:01 PM

#

This'll be my last post. Please @ me if you reply so I can check it later. If we put the setTimeouts into an object with that UID I was talking about as the key, then we could do clearTimeout(queue[uid]). Maybe. Anyway, I'm off. Merry Christmas. Thanks for the chat. Is it correct that I'll need to make an Issue describing my spec ideas and wait for a +1 from you and/or someone else to know it will be accepted? any clarification on how I can only do work after knowing it'll be accepted is appreciated 🙂

vernal atlas Dec 24, 2020, 4:18 PM

#

im refactoring usages of GuildChannel#permissionsFor to handle there being no permissions returned, but in the getters should i just return null here or default to false?

#

null feels like better option but i just want to be sure

loud moat Dec 24, 2020, 4:26 PM

#

There's a difference between false and "we don't know", right?

vernal atlas Dec 24, 2020, 4:27 PM

#

yeah

#

i ask also because

#

GuildChannel#viewable just returns false

#

if there are no permissions

#

but all the other getters just error

old kelp Dec 24, 2020, 4:29 PM

#

why not also take GuildChannel#viewable under consideration to be removed (relative to all other removals for v13)? I think it has been discussed once

#

<#archive-library-discussion message>

I believe what nico is referring to is removing stuff like GuildChannel#viewable, the basic permission checks that the user can very easily implement
agreed there, users must be able to do basic logical checks 🤔

real jetty Dec 25, 2020, 12:41 AM

#

hey uh guys, i heard you guys are removing the like <message>.delete({timeout:500}) functionality in v13, and im a bit confused as to why?

#

i dont see any downsides personally to keeping it, and it really helps keep code clean

#

rather than having a lot of settimeouts which makes code kinda messy

#

if someone has a moment can they please like gimme the reasoning behind this? thanks!

unique axle Dec 25, 2020, 12:44 AM

#

it should never have existed in the first place.
no other structure has a native delay on delete, why should message have one? this is nothing the API actually supports but just a timeout wrapper, which the dev can do themselves to the same effect through Client#setTimeout

ruby terrace Dec 25, 2020, 12:45 AM

#

it also forces you to think about how to handle deleting messages after a time (such as checking if it is actually still deletable)

real jetty Dec 25, 2020, 12:45 AM

#

yeah, personally I understand how like no other wrapper has a native delay for deleting and stuff, but since it's already like there, and it doesn't exactly have any downsides, I'm not getting like why you guys are removing it
(sorry if i seem pushy, im just genuinely kinda confused)

unique axle Dec 25, 2020, 12:47 AM

#

ruby terrace it also forces you to think about how to handle deleting messages after a time (...

this was the last push, since there is actually a lot of things you need to take care of which immensely complicates the whole endeavour

vernal atlas Dec 25, 2020, 12:47 AM

#

if you miss the functionality you can always add it back by extending the structure yourself

real jetty Dec 25, 2020, 12:48 AM

#

oh, oof, i guess that kinda makes sense, Personally I still feel like the amount of code a lot of devs will have to re-write isnt worth like removing functionality, since theres other options if you dont wanna use it, but I guess that like reasoning kinda makes sense, so thanks!

unique axle Dec 25, 2020, 12:48 AM

#

we generally are moving forward with removing inconsistent and unnecessary "convenience" methods, since they have and still do cause more pain than they relieve

real jetty Dec 25, 2020, 12:48 AM

#

vernal atlas if you miss the functionality you can always add it back by extending the struct...

i guess this is also a good idea, thanks!

real jetty Dec 25, 2020, 12:49 AM

#

unique axle we generally are moving forward with removing inconsistent and unnecessary "conv...

wait if you have some spare time, can you like help me understand how they cause pain? im kinda like not getting it, srry

unique axle Dec 25, 2020, 12:49 AM

#

amount of code a lot of devs will have to re-write isnt worth like removing functionality,
this is not a consideration we make for major version updates.
we are moving forward with what's the more consistent, coherent and ultimately hopefully semi-straightforward API

real jetty Dec 25, 2020, 12:49 AM

#

ohhh kk gotchu, ty!! 👍

carmine socket Dec 25, 2020, 9:46 AM

#

Hey there. I don't think my question is 100% related to Djs, but I'm wondering how events work. (ex. client.on('event', callback) in d.js). I first thought that the Discord servers were sending a request to the local machine to trigger an event, but it seems very unlikely. How is the message event triggered for example? Is it some kind of infinite loop that keeps asking for updates over HTTP? (please ping to answer)

vivid field Dec 25, 2020, 9:49 AM

#

updates aren't sent over http, your client opens a websocket connection to the discord gateway where it receives events on client.ws and forwards them to the user

carmine socket Dec 25, 2020, 12:32 PM

#

vivid field updates aren't sent over http, your client opens a websocket connection to the d...

Oh, ok! It makes sense. Thanks

real jetty Dec 25, 2020, 3:25 PM

#

Could the member who deleted /created a Channel be added to channelDelete and channelCreate? It could be pretty useful to a lot of things.

unique axle Dec 25, 2020, 3:26 PM

#

we can only provide information discord provides, so that's a "nope"

#

"who" did something is always accessible through audit logs, not the general event that emits when it happens

real jetty Dec 25, 2020, 3:27 PM

#

Sad that discord does not provide that directly in the event

solemn oyster Dec 25, 2020, 4:22 PM

#

real jetty rather than having a lot of settimeouts which makes code kinda messy

https://nodejs.org/dist/latest-v15.x/docs/api/timers.html#timers_timerspromises_settimeout_delay_value_options

#

Alternatively, if you're not using Node.js v15, you can use const sleep = promisify(setTimeout);, then do await sleep(1500); to delay the execution of the following code by 1500 milliseconds, that's a lot cleaner than making callbacks within callbacks: https://nodejs.org/dist/latest-v15.x/docs/api/util.html#util_util_promisify_original

real jetty Dec 25, 2020, 7:22 PM

#

solemn oyster Alternatively, if you're not using Node.js v15, you can use `const sleep = promi...

oh yeah wait both of these options help a lot! tysm! 19ThumbsUp

latent crag Dec 26, 2020, 9:32 AM

#

Should i pull request directly to the master branch or PR a new one? If creating a new one, how do i name it?

wild flax Dec 26, 2020, 9:34 AM

#

You should never commit directly to master

#

And whatever seems most logical to you

latent crag Dec 26, 2020, 9:36 AM

#

Do i name branch using my github nick and PR to djs repo then?

ornate topaz Dec 26, 2020, 9:40 AM

#

it doesn't really matter. you're going to create a branch on your fork, which would just get merged into one of branches at the upstream ~~(or closed)~~

grizzled rover Dec 26, 2020, 5:13 PM

#

Not sure if this is the right channel but what is message.nonce even useful for? I was just reading docs and couldn't really see a use for it other than maybe checking if you already fetched the message?

frank turret Dec 26, 2020, 5:30 PM

#

used for validating a message was sent

https://discord.com/developers/docs/resources/channel#message-object

solemn oyster Dec 26, 2020, 5:47 PM

#

It's something you send that you can use to verify when you get the response back, e.g. if you send a message with nonce foo bar, you'll get a response that will be a message with nonce foo bar.

However, all other clients (and even you when fetching the message) won't get said nonce again. Think of it as an integrity check. @grizzled rover

ruby terrace Dec 28, 2020, 2:07 AM

#

I guess this got purged on accident:
The current behavior of the USER partial only affects reaction events and typingStart. Since userUpdate is an internally emitted event through GUILD_MEMBER_UPDATE in most instances, it makes me question whether userUpdate should be emitted for an uncached user. Right now it does not, and other Partial types behavior seem to suggest that it would. Does anyone have any insight into whether this was just an oversight or if its intended.
I definitely see how it could be intended since most GUILD_MEMBER_UPDATE events have nothing to do with a user update, and this would always emit userUpdate if the member was uncached, even when only member parameters have changed.

unique axle Dec 28, 2020, 9:47 AM

#

i'm currently questioning if userUpdate should be tweaked at all, or if it should just be emitted for current user changes, as the API emits it

ruby terrace Dec 28, 2020, 10:10 AM

#

Yeah, I was highly considering suggesting just to remove the external handles into userUpdate completely

old kelp Dec 28, 2020, 10:10 AM

#

i'd personally suggest that, i don't think so there is any use to emit it artificially other than convenience, which rather makes it inconsistent and harder to manage on the library level 🤔

ruby terrace Dec 28, 2020, 10:19 AM

#

And to further that point, the event is probably significantly more confusing for users now that at least one of the privileged intents are required to get the event. I think this would go hand in hand with many of the other changes for v13 that aim to emulate the API more directly.

empty viper Dec 28, 2020, 6:05 PM

#

I have a question, why on GitHub can't we see the versions prior to v5, and where can I find these ?

vernal atlas Dec 28, 2020, 6:14 PM

#

https://www.npmjs.com/package/discord.js?activeTab=versions

#

npm install discord.js@version

#

all versions before v11 are deprecated and probably dont work / are very broken

empty viper Dec 28, 2020, 6:22 PM

#

I know

#

but just for seeing the code

oak quail Dec 29, 2020, 12:37 AM

#

why aren't the v11 versions marked as deprecated in npm?

solemn oyster Dec 29, 2020, 12:48 AM

#

Probably an oversight

#

But yeah, we should eventually mark v11 versions as deprecated, as they'll stop working next year

frank turret Dec 29, 2020, 7:11 PM

#

Would we prefer having separate prs for removing all the unnecessary getters (like viewable and other dumb permission checks) or is it alright to have one collective pr for the removal of all unnecessary getters
and hearts to @old kelp for the reminder abt this blobReachReverse

undone ravine Dec 29, 2020, 7:30 PM

#

don't understand why anybody would want to get rid of those

old kelp Dec 29, 2020, 7:33 PM

#

i think the point is removing "unnecessary and inconsistent convenience methods" as per <#archive-library-discussion message>, which we are already moving forward with

#

@unique axle was t:caching label intentional for https://github.com/discordjs/discord.js/pull/5152 🤔

unique axle Dec 29, 2020, 7:36 PM

#

~~it's not rest, it's not gateway, i thiiiink caching can be interpreted as "methods that don't do any calls outside and don't interact with discord in any way"~~
could be that my interpretation of that label is wrong tho shibaSmile

#

nvm, it's utility, i'm a doofus

old kelp Dec 29, 2020, 7:38 PM

#

ah, right, thanks catThumbsUp

frank turret Dec 29, 2020, 7:40 PM

#

so cough cough #archive-library-discussion message

undone ravine Dec 29, 2020, 8:01 PM

#

old kelp i think the point is removing "unnecessary and inconsistent convenience methods"...

don't see how the permission getters fit into that description

frank turret Dec 29, 2020, 8:13 PM

#

Some of them are simple permission checks that the user can do on their own, unneccessary for the lib to provide methods for something they can do on their own imo. It also feels like a bit of pollution

copper laurel Dec 29, 2020, 8:45 PM

#

This has been a debated topic for a while but people generally lean towards removal, for a cleaner library.

Having said that, I think the checks we're removing should be "ported" over to a guide page - there are other ways to support good practices.

frank turret Dec 29, 2020, 8:47 PM

#

Agreed. One other thing I'd like to ask, if we have other methods that depend on the getter, should we leave it?

undone ravine Dec 29, 2020, 9:15 PM

#

I don't think there's any good reason to remove the permission getters, specifically.

#

They add almost no additional overhead to the library in terms of maintenance
The tiny bit of overhead they do add (making sure the permission checks change to match up with Discord's behavioural changes) aids in making the users' lives much easier, ensuring they don't have to go through and make the same updates themselves
They are substantially cleaner for users of the library vs. the alternative
They give a simple, descriptive name for what a bunch of otherwise arbitrary permission checks are accomplishing
They often build upon each other (see GuildMember#manageable -> kickable/bannable)

#

Seems foolish to remove these widely-used getters that aid in producing much cleaner code on the users' end in the pursuit of a "cleaner" library (they're not even messy, inconsistent, or obtrusive in any way that I can think of internally)

#

All you would be accomplishing by removing them is making an extremely common task much less convenient/clean, there's not even a downside to them existing afaik

lofty birch Dec 29, 2020, 9:25 PM

#

what could perhaps be better is making them more consistent, as the above complains about them not being so

undone ravine Dec 29, 2020, 9:25 PM

#

Don't think they were called inconsistent. I believe that was directed at the weird message delete timeout functionality that nothing else shared

frank turret Dec 29, 2020, 9:27 PM

#

In my PR I outline that getters that are used internally (see point 5 of gawds message) wouldn’t be touched

undone ravine Dec 29, 2020, 9:27 PM

#

Sounds like you'd be introducing more inconsistency by removing the ones that aren't, then

#

Because then you have some convenient permission getters with much smaller coverage vs. them generally being available on everything where relevant

#

In fact, I think these permission-related helpers should be expanded further. Any object -> action relationship should be covered, ideally. Additionally, the comparison should be able to made between any two arbitrary objects, not just with the client user/member (i.e. a GuildMember#canBan(GuildMember) method or GuildMember#canView(GuildChannel))

unique axle Dec 29, 2020, 9:40 PM

#

just to clarify: you are suggesting we should essentially have a permission getter per flag on the member as well as a getter per overwritable flag per channel type
additionally relationship methods as well as - possibly the reverse GuildMember#canView(GuildChannel) - GuildChannel#canBeViewedBy(GuildMember)

undone ravine Dec 29, 2020, 9:41 PM

#

the reverse, no, not really

#

and not every flag, just actionable items

undone ravine Dec 29, 2020, 9:45 PM

#

undone ravine the reverse, no, not really

maybe, actually. i can see the argument for it but i feel like it makes more sense to always start from the object that is performing the action

copper garden Dec 29, 2020, 9:47 PM

#

So ur saying we'd add fail-guards for permission errors to methods like TextChannel#send?

undone ravine Dec 29, 2020, 9:47 PM

#

no

raven juniper Dec 29, 2020, 9:49 PM

#

undone ravine In fact, I think these permission-related helpers should be expanded further. An...

i do actually like the idea of this, you see a lot of member-to-member checks in kick/ban/other mod actions, and it feels like the same as Role#comparePositionTo

frank turret Dec 29, 2020, 9:51 PM

#

Thonk should it really be the responsibility of the library to do simple permission checks

undone ravine Dec 29, 2020, 9:51 PM

#

permission checks are rarely simple

copper garden Dec 29, 2020, 9:51 PM

#

Why is Role.comparePositions static method still there? I thought the raw position moved to Role#rawPosition?

#

Or at least why is it still using Role#position

ruby terrace Dec 29, 2020, 9:56 PM

#

undone ravine In fact, I think these permission-related helpers should be expanded further. An...

I agree with that, if you take a look at some of those permission checks you are removing with your PR Nico, there's actually around 5 checks going on for each one (aside from editable). Because of the slightly weird way discord handles permissions, some of the steps of these are likely to get overlooked by many people if they are implementing it themselves.

undone ravine Dec 29, 2020, 9:59 PM

#

Agreed. I think it is absolutely the responsibility of the library to abstract the [often obscure to those not intimately familiar with discord/its API] requirements behind whether you can do something to an object or not

frank turret Dec 29, 2020, 10:01 PM

#

Hm, then should the PR be reduced to only getters like message#editable?

undone ravine Dec 29, 2020, 10:08 PM

#

Personally, I don't really see any reason to remove that one. Just because it's much simpler than the others doesn't mean it can't change in the future. Plus, that would only bring inconsistency, IMO

#

That one is kind of unique in that it's not tied directly to a permission currently

ruby terrace Dec 29, 2020, 10:10 PM

#

I feel like that may be necessary for an edge case that is coming soon (but this particular one puts a lot extra on the library): interaction responses are from the same user id, but aren't guaranteed to be editable. E.g. once the token expires, and those must be edited via webhook, not the same general edit method

frank turret Dec 29, 2020, 10:10 PM

#

some of them like voicechannel#speakable and the likes are just wrappers for permissionsFor, which would fall under my meaning

ruby terrace Dec 29, 2020, 10:16 PM

#

I think that wrapper methods like that were the original aim. This becomes a question of whether those actually want to be removed, as that encompasses all of the basic *.edit() wrappers as well. IIRC, that is a desired end goal, but needed further discussion.

oak quail Dec 30, 2020, 12:08 AM

#

I agree with gawd here, I don't really see a benefit in removing these, it just adds more work for bot devs

#

I do support changing things which would have an actual improvement, like, iirc someone said changing channel/message type to numbers saves a lot of ram? although they were numbers in early v12 dev iirc; that has an improvement and doesn't really have a disadvantage other than having to change code

#

but removing these methods seems to have disadvantages with no advantages other than them just not existing

ruby terrace Dec 30, 2020, 12:14 AM

#

I support those changes as well, those type from string to numbers changes would also align with the removal of strings for permission flags

solemn oyster Dec 30, 2020, 12:35 AM

#

oak quail I do support changing things which would have an actual improvement, like, iirc ...

That was me, and yeah, I'll be working on that once #5132 is finished

#

Probably before, I want to evaluate the impact the refactor will have to other PRs (merge conflicts mostly)

#

#5022 definitely needs to be merged before I can do that

#

Just pending review from Space

frank turret Dec 30, 2020, 4:26 PM

#

So then is the decision to keep all the getters including ones like message#editable and voicechannel#speakable?

vernal atlas Dec 31, 2020, 9:09 PM

#

is the reply-prefix branch gonna be deleted? mmLol its just been sitting there for months lol

snow crypt Dec 31, 2020, 9:20 PM

#

the native replies are going to replies discord.js's reply, making reply-prefix useless

ebon radish Dec 31, 2020, 11:17 PM

#

Would it be out of scope for the library to include a few handy regexes, like the elusive invite link regex

snow crypt Dec 31, 2020, 11:21 PM

#

that specifically you can grab from resolveInviteCode

#

?docs DataResolver.resolveInviteCode()

rich iglooBOT Dec 31, 2020, 11:21 PM

#

ebon radish Dec 31, 2020, 11:24 PM

#

@snow crypt You can apply this to a whole message and get an invite code?

snow crypt Dec 31, 2020, 11:25 PM

#

yes

#

you can also make that regexp global and match many

#

but that is outside the scope of this channel

dawn lodge Jan 1, 2021, 4:44 AM

#

Has the library been updated to allow for the "pending" param upon join to support the screening feature?

frank turret Jan 1, 2021, 4:45 AM

#

There is a pr for it currently, not merged yet

dawn lodge Jan 1, 2021, 4:45 AM

#

Okay, thanks!

#

I assume there is no ETA on it quite yet?

frank turret Jan 1, 2021, 4:46 AM

#

, it's probably gonna be included with the v13 release since there aren't any more planned v12 releases

dawn lodge Jan 1, 2021, 4:47 AM

#

Will v13 have breaking changes like v12 had?

frank turret Jan 1, 2021, 4:49 AM

#

Major versions generally do have breaking changes

dawn lodge Jan 1, 2021, 4:49 AM

#

Well dang..

raven juniper Jan 1, 2021, 5:50 AM

#

Not nearly as many as v12, though

long mason Jan 1, 2021, 6:56 AM

#

Why does <Guild>#equals() even exist

#

Along with <User>#equals()

real jetty Jan 1, 2021, 7:08 AM

#

Another like basically useless method is <MessageEmbed>#addFields() which I doubt anyone uses, which just adds more like clutter to the library

#

nah i think addfields should stay. people do use it and it makes code easier to read (ie you don’t have to have .addField 8 times in a row in your code)

old kelp Jan 1, 2021, 7:09 AM

#

long mason Why does `<Guild>#equals()` even exist

it is for internal use, and perfectly reasonable as its description already says

real jetty Jan 1, 2021, 7:10 AM

#

oops i meant normalizefields @real jetty i copypasted the wrong thing

#

i meant to write <MessageEmbed>.normalizeFields(), idk why i wrote the wrong thing haha

#

sry

snow crypt Jan 1, 2021, 10:39 AM

#

addFields imo is just... meh ```js
// addFields
embed.addFields(
{
name: "Global",
value: ${stats.globalWins} wins; ${stats.globalLosses} losses;,
inline: true,
},
{
name: "Per-country",
value: stats.countries.map((s) => ${s.name}: ${s.wins} wins; ${s.losses} losses;).join("\n"),
inline: true,
}
);
// addField
embed
.addField("Global", ${stats.globalWins} wins; ${stats.globalLosses} losses;, true)
.addField(
"Per-country",
stats.countries.map((s) => ${s.name}: ${s.wins} wins; ${s.losses} losses;).join("\n"),
true
);

wild flax Jan 1, 2021, 10:51 AM

#

Yeah for composition I prefer the former

copper laurel Jan 2, 2021, 5:09 AM

#

real jetty i meant to write ``<MessageEmbed>.normalizeFields()``, idk why i wrote the wrong...

Theyre statically used internally

real jetty Jan 2, 2021, 6:29 AM

#

ohhh kk gotchu , ty!!

lofty beacon Jan 2, 2021, 10:50 AM

#

If they are statically used internally, in es2021 are they going to be private methods?

unique axle Jan 2, 2021, 11:35 AM

#

snow crypt `addFields` imo is just... meh ```js // addFields embed.addFields( { name:...

The initial idea was to only have #addFields since it's much more verbose, doesn't bear the danger of providing arguments in the wrong order (which has often occurred in support) and takes a variable amount of arguments (field objects) which allows workflows like spreading or providing arrays of data objects.
However due to "feedback" from the community (read as: help channels being full of people calling the person applying the change (me) idiot, the library staff dumb and being very verbose about how much they hate the change) the method was re-introduced shortly after removal, after some proficient+ also expressed doubts in that approach. I might re-visit that thought in -next though, since a full on rewrite allows for structural changes like these to be perceived much less emotionally than in an already existing API.

snow crypt Jan 2, 2021, 11:36 AM

#

Good point about the spreading, didn't think about that

#

Yet I still believe addField is better for stuff like my example

unique axle Jan 2, 2021, 11:36 AM

#

i don't but that's besides the point and nothing to be discussed here

unique axle Jan 2, 2021, 11:38 AM

#

lofty beacon If they are statically used internally, in es2021 are they going to be private m...

Rather likely, yes, there isn't much reason as to why anyone would want to use that method in their own code.

tacit crypt Jan 2, 2021, 1:33 PM

#

Kinda hard to male them hard privates and then use them externally actually..

lofty beacon Jan 2, 2021, 1:59 PM

#

What? NormalizeFields is being used inside the MessageEmbed class, right?

#

If it's being used else where, then it can't be private

unique axle Jan 2, 2021, 4:46 PM

#

do we use that anywhere else potatodetective
no we don't

old kelp Jan 4, 2021, 12:03 PM

#

do we use TextBasedChannel as a typedef?

tired valve Jan 4, 2021, 12:33 PM

#

btw @vernal atlas the v8 refactor
https://github.com/NotSugden/yeetcord.js/blob/1bea1403bec653a76737dce99e74a136c62e2dc0/src/client/websocket/WebSocketShard.js#L597
is missing

intents: client.options.intents,

https://cdn.gideonbot.com/fNFApQL.png

tacit crypt Jan 4, 2021, 12:35 PM

#

If it gets set in .ws then it's fine..if it isn't then it's a problem

tired valve Jan 4, 2021, 12:44 PM

#

it doesn't hence when you run the pr it throws 4013 invalid intents

vernal atlas Jan 4, 2021, 1:56 PM

#

resolved

junior pumice Jan 4, 2021, 3:02 PM

#

who are the libary devs