#archive-library-discussion

25217 messages · Page 19 of 26

tacit crypt
#

-types is handled by me, and it has a much faster (ok ish) release cycle compared to d.js shrug
I can afford to do 4 releases in a day, d.js can't. we have several PRs that we need that are more important than scheduled events, and we'll get to scheduled events too don't worry

outer raven
tacit crypt
#

Let's see..

CI not passing
Reviews still pending
Decisions still to be made

#

So the PR is still WIP?

outer raven
#

CI isn't passing because -types wasn't released simply, but I thought everything else was good since no other changes were requested?

dawn merlin
#

Don’t these blocks contradict each other?

ornate topaz
#

no

unique axle
#

if you go camel it overrides snake, that's all that second one says, right?

ornate topaz
#

first one says that you can use snake_case, the second that if you pass camelCase, it overrides snake_case

dawn merlin
#

Ah I see

outer raven
#

@dawn merlin since you’re gonna remove MessageActionRow in v14 I suggested removing the external link from that file and keeping it on the new one instead

#

Think you got confused there

#

So that when that pr does come it’s as simple as deleting the file without worrying about missing links

dawn merlin
#

ok

dawn merlin
#

@outer raven can you explain what the event status type checking would look like?

outer raven
outer raven
#

Would it be possible to create a Message#awaitEmbeds method that waits for URL embeds to resolve and returns them? Could be useful in the messageCreate event since these don't have embeds when they are sent but they appear a few seconds later

tacit crypt
#

I mean you'd need to:

  • check the flags, in the event that embeds are suppressed
  • parse the content to see possible urls that aren't escaped and assume they'll embed
  • take into account that you may never get embeds to begin with
    I can see a use case for wanting this don't get me wrong, but there's gotta be a lot of factors considered when/if implementing it :D
#

I guess point 2 and 3 can be substituted into a timeout

outer raven
#

and yeah you'd need to check for regexes and then listen for the messageUpdate event

tacit crypt
#

Are you sure you cannot create a message with the flag pre-set? And I'm talking bot made not client made

outer raven
#

let me test that

tacit crypt
outer raven
#

what about the intent? You'd need to have it to even receive the message to begin with right?

tacit crypt
#

Well yeah except for messages pinging the bot/dming the bot

outer raven
#

yeah so you'd always have access to the content if you're doing this

outer raven
#

tried to post a message with this and the flag didn't go through so yeah I don't think you can suppress embeds when you create a message

#

I'm gonna look into how collectors are done and see if I can replicate that but I'm not sure if I can pull it off

ruby terrace
outer raven
ruby terrace
#

you do get everything in those cases

outer raven
#

well then in other cases you don't get the message at all do you

ruby terrace
#

yes you do

#

its the message content intent, not the message intent

outer raven
#

ah I see...

#

so we'd have to check for client intents too

ruby terrace
#

I'm not sure if message content intent is going to be like current intents, it might only be a flag, we don't know yet

outer raven
ruby terrace
#

that's not what I'm saying, the "intent" (because its starting as privileged), may not be toggleable via the identify payload

outer raven
#

I think they would've mentioned it by now if that was the case

ruby terrace
#

there's nothing documented about it at all, wdym

outer raven
ruby terrace
#

the flags are public, no new intents have bee documented

#

and the flags aren't documented either

oak quail
#

its prob intent 1 << 15

#

iirc they said itll be in identify

ruby terrace
#

I haven't seen that, but if they said that then yes, you'd need to check that rodry

oak quail
#

if u meant the application flags

#

my pr got merged 26d ago

ruby terrace
#

oh, yeah...I forgot that was already merged ~~used to things like that taking 4 months to get merged mmlol ~~

oak quail
#

lol

outer raven
ruby terrace
#

Like I already said, those are completely separate

#

you want message events? use those, you want the content in those messages? use the new one too

oak quail
#

yeah, those control the events

outer raven
#

oh I see

oak quail
#

message_content controls the object fields

#

without msg content, you'll still know messages are being sent and everything

#

just not the content

#

like those memes people made

outer raven
#

so bots that don't need to be whitelisted will need to add that new intent anyway?

oak quail
oak quail
outer raven
ruby terrace
#

and yes, that'll be a breaking change

outer raven
tender field
#

out of curiosity, why is Guild#toJSON() are most toJSON methods typed as unknown?

outer raven
tacit crypt
#

My answer is no, idk about the others thoughts

outer raven
tacit crypt
#

And what do we do in the event Discord adds 4 more eventMetadata fields, and it happens that some collide? meguFace

astral cliff
#

Possible bug in the typings of discord.js?

I am checking for <Interaction>.isGuild() in the if statement yet it gives me this warning

Note: I am using typescript in case it's not obvious
https://i.jarco.dev/YktuhMja.png

dawn merlin
outer raven
loud jayBOT
#

pr_open #6998 in discordjs/discord.js by suneettipirneni opened <t:1637171468:R> (approved)
Fix: Interaction channel type should be GuildTextBasedChannels when in guild
📥 npm i suneettipirneni/discord.js#fix/interaction-channel-type

astral cliff
#

Ah, my bad forgot i should've checked the pull requests / issues

dawn merlin
#

Lol, it hasn’t been merged yet no worries

tacit crypt
outer raven
#

well idk if I should ping them or what but I'd really be interested in this being reverted
Also are the performance hits really that noticeable?

tacit crypt
#

It's..not.. the performance part is just what the meme says

outer raven
#

oh I didn't know that was a meme kek

opaque vessel
#

What do people think about a method that narrows properties of a message if it is from a webhook? member would be null and webhookId would be not null, in this case

dawn merlin
opaque vessel
#

I have functionality that needs to differentiate between bots and webhooks (ignore bots, allow webhooks) so the only check for that is if (message.webhookId !== null) {...}. The narrowing is more just a "why not", not really sure if that's a valid use case shrugs

grand eagle
#

Is there currently anything in the Discord API for events?

loud jayBOT
outer raven
#

@grand eagle ^^

grand eagle
outer raven
grand eagle
#

ah okay, sounds good. Just meant that I hope they mention when the PR is closed and integrated

outer raven
cyan cargo
#

Hi are there any way to cross server / hosting sharding?

unique axle
#

you will need to write your own sharding manager or see if someone has already done so.
this channel is for coordination regarding developing discord.js itself, not for developing with discord.js

outer raven
#

@dawn merlin as of the latest dev build (after the *Data PR was merged) passing a ChatInputApplicationCommandData type to ApplicationCommand#equals and #create throws this error

#

could you look into it? I believe this is because the method isn't expecting string types

smoky dawn
#

iirc, you can edit message attachments using the discord bot API. But using D.js I can’t edit the message attachments, only append, on my ephemeral interaction reply. Is this something to do with it being a ephemeral interaction reply, and not a normal message or does D.js simply not support editing message attachments?

outer raven
smoky dawn
#

Oh. I see, thanks.

outer raven
#

either it gets reverted or we add some inconsistencies in places where the types don't match, which sounds more of a pain to me

#

or we add types using &, which also doesn't sound very maintainable, but I'm looking to know what you guys think

dawn merlin
outer raven
dawn merlin
#

The plan is to remove string types in the future and only allow numbers

outer raven
#

why would that be a good idea

#

and when was that suggested

dawn merlin
#

In my ticket

outer raven
#

which?

dawn merlin
#

The original one talking about using camel cased dapi types

outer raven
#

can you /github it

loud jayBOT
outer raven
#

thanks

#

yeah it seems like I missed that part, but I really don't think that's a good idea, and the types shouldn't break until/if that is ever implemented

dawn merlin
#

But I can summarize by this:

  1. Having multiple data types to represent one property is not a good approach at all
  2. The data should be as close as possible to the api payload, making the naming conventions completely separate from the djs implementation.
dawn merlin
outer raven
#

the purpose of a library is to make it easier to interact with the API, and I don't think slapping numbers in types is readable or easy to understand and get used to, and having to import an enum to access its properties seems much less handy than simply writing the string which is very easily converted on the library's side

outer raven
dawn merlin
outer raven
#

in fact I don't understand why these were marked as deprecated if nothing was noted on the docs

dawn merlin
outer raven
rough roost
#

why does djs delay events until all shards are ready? i have 7 shards, each always has some unavailable guilds, meaning it will wait at least 15 seconds before becoming ready. shards are also spawned sequentially with a 5 second delay, which creates a total delay of like 2 minutes for me

loud jayBOT
rough roost
#

yeah but it's not really dealing with the core problem

iron escarp
#

When is Djs gonna support max_concurrency? I'm kinda getting sick of having to dig into the code to add support for it myself every update SadCat

tacit crypt
iron escarp
#

How far is the progress on @discordjs/ws then? I requested support for it ages ago and it supposedly was on the todo list already back then

iron escarp
unique axle
#

if you can't wait for it feel free to PR

loud jayBOT
outer raven
#

I suggested this method should reject in case no embeds are added in X seconds but that may not be a good idea do I’d like to know if the managers think it should always resolve or if it should reject when there are no more embeds to add like I suggested

#

I’m fine with both since I understand the argument for both which is why I’d like to hear more opinions

dawn merlin
#

To clarify: should awaitEmbeds reject the promise when it can't find/or resolve embeds or should it instead just return an empty array of embeds?

outer raven
#

(Or an array with the already existing embeds for that matter)

visual hornet
#

well, is there even any guarantee that the embeds would load in x seconds/ms?
i think there should be an option for how long to wait for (as a maximum i guess, if that could be checked) to reject if no embeds are found (or resolve with an empty array)

dawn merlin
outer raven
tender field
burnt cradle
#

@copper laurel did you say you dropped your builders buttons pr?

copper laurel
#

Kinda. I wanted to redesign it and haven't had time. Not sure it even needs to be in builders tbh

tacit crypt
#

Components could go into builders, sure

outer raven
#

Djs has a builder for them tho what’s the point

copper laurel
#

Migrating and consolidating builders in one place I guess

outer raven
copper laurel
#

But that's the whole point of builders

wild flax
#

lol

copper laurel
#

They don't need to be in djs at all

outer raven
#

They’re integrated nicely with the library and work just fine unlike builders which often bring up issues like snake case and having to do .toJSON() all the time

outer raven
copper laurel
#

I mean... yes, I've expressed frustrations with incompatibility between the modules and core djs before too, but that's irrelevant to the overall design of builder classes being separated

#

Because "current ones" is nothing more than a legacy after the decision was made for them to be separated really

#

The snake_case compatibility issue is planned to be addressed, and "having to do toJSON()" is a weak argument honestly, make a necessary function call

outer raven
#

It looks like no one cares about builders rn tho

outer raven
copper laurel
#

Conceptually I'd like it if djs could accept the builder class object, I agree

wild flax
outer raven
# wild flax ?

it has some PRs that have been open for a while with almost no attention despite the comments of people asking for it

#

I don't use builders nor do I plan to do so but from looking at the github feed this is the impression I get

wild flax
outer raven
#

¯_(ツ)_/¯

wild flax
#

Please make sense if you try to say something

#

A blocking PR was merged yesterday, which pretty much blocked all the others

#

And they need rebases now because of that

#

Theres only 3 open, 1 has requested changes, 2 needs a rebase, 1 reviews and another draft

outer raven
#

there even was a second PR by that same guy to add autocomplete that was closed for some reason, then they opened that one

wild flax
#

Which makes no sense to merge it because it would need a rebase either way and people couldn't use it without the ow replacement

outer raven
#

well nvm ig

pure flare
#

Hi, just bumping to see where this is at?

outer raven
#

Just out of curiosity, what versioning system does discord-api-types follow?

solemn oyster
#

semver

tacit crypt
#

Technically semver, practically it looks like Zerover

outer raven
solemn oyster
#

Whenever Discord as a company dies and stops releasing new updates

#

aka not in decades

outer raven
#

oh really

#

so it is zerover mmLol

#

alright thanks

solemn oyster
#

Problem with bumping 1.x, is that it'd require us to bump new majors every time Discord decides to break something

outer raven
#

I thought they only broke stuff on api version bumps (or when a feature is experimental ofc)

ruby terrace
#

things may not break actually but we're going on documentation that sometimes isn't accurate, so the types can change in a breaking way based on a mistake there

outer raven
#

Yeah makes sense

#

I mean you can always call those patches if it’s only the types that break but the values are the same

ruby terrace
#

that works for djs, and technically since discord hasn't changed their values it is a patch I suppose

burnt cradle
visual hornet
#

could the default for position in GuildChannel#clone be changed to this.rawPosition instead? that would make a more accurate default regarding the position but it still wouldn't be perfect i guess

#

it would be sending the same position discord gave back to discord instead of sending the position calculated by djs

slate nacelle
#

Sounds reasonable

visual hornet
#

i feel like there should be some kind of note to this in the docs, but im not quite sure how to word/structure that part

#

i guess i'll submit a pr and mention that?
welp forgot to mention it because i was trying to get the fork to work properly but nvm now i guess

tender field
#

Hello, for the GuildScheduledEvent PR, wouldn't it make sense to add a SubscriberManager? because i don't see any, which means if we want to know if a member is subscribed we have to make a request (or keep a cache of our own).
I think it would make sense because you could have cache, and move fetchSubscribers() to subscribers#fetch() (and even userCount to subscribers#count?). The cache could be updated through the GuildScheduleEventUserAdd/Remove actions

opaque vessel
#

I believe the idea is to create at least a good base right now, because the events you listed are actually documented as experimental and not officially supported... so would rather wait to see if it sticks around before making a manager for them?

tender field
#

ah I see, but the PR won't be merged if the two events are still experimental, will it?

opaque vessel
#

I think it will be because only base support is added and nothing more

tender field
#

gotcha

outer raven
#

I think the initial implementation should be the best possible and the idea of a subscriber manager is nice because the events will stay almost certainly

#

might change of course but they will exist

tacit crypt
#

it can easily be made a sem minor

#

deprecate fetchSubscribers and make it call subscribers#fetch

#

voila

outer raven
#

eh ig but more deprecations

#

at this point we could use a deprecation manager lol

tacit crypt
outer raven
#

I don't see why they wouldn't?

outer raven
tacit crypt
#

It's experimental

outer raven
tacit crypt
#

And it can just fetch a list

#

instead of caching them

#

And this is turning off topic fast

outer raven
#

¯_(ツ)_/¯

oak quail
#

Those two dispatches you're referring to were introduced relatively late in this feature's development. When the docs say "experimental" here, it more means that this is a "beta feature" since we're actively monitoring to make sure these dispatches are performant at scale. If we notice issues, we may rework when these dispatches are sent and what data they contain. That all said, we haven't seen any signs that we're going to have trouble with them, so if I had to make a guess I'd say they'll stay as they are right now. But we're not giving the complete green light yet just in case.

visual hornet
#

also why doesn't endReason seem to acknowledge the time and idle end reasons

weak kraken
#

is the SessionId property of VoiceState supposed to be unique to the connection->disconnection event? That is to say, everytime you connect to a voice channel a new SessionId is generated? I am not seeing that currently (#archive-djs-help-v13 message)

#

I'm just going to cheat in the meantime and use channelId to detect online/offline states

#

but this seems to be an error with the sessionId not being deconstructed during the disconnect state update

outer raven
tacit crypt
tacit crypt
outer raven
tacit crypt
#

I don't see the point

#

usually if there's messages they're text based

weak kraken
#

so then the correct way to detect "connect" and "disconnect" events to a voice channel would be channelId changes being null or not

#

feels like a weird means to detect those changes tbh

outer raven
tacit crypt
tacit crypt
outer raven
#

aight ill keep the messages check

#

for voice, should I keep the bitrate check or use the types?

tacit crypt
#

Probably bitrate?

outer raven
oak quail
#

@outer raven also stage channels will not have text (at launch, at least)

#

and forum channels

outer raven
#

Ah right

#

Forum?

solemn oyster
#

Yeah, datamined stuff, you'll see when it's ready

#

It's just like a text channel, with threads, but no messages (in theory at least, I haven't seen it)

real jetty
#

why are the .toJSON() methods not documented?
like Message#toJSON() and such

outer raven
#

Why are there no methods to edit individual properties of an ApplicationCommand like there are for every other structure? Does Discord not allow editing 1 property only?

tacit crypt
#

Probably an oversight?

outer raven
#

I'll test to see if they work and add if they do

#

if it's a patch endpoint it should support that

#

yeah it does indeed work, will PR

#

Is it possible to edit the type of an application command? Apparently this is documented but I tried and it doesn't seem to work

#

probably another PR should remove that documentation because the API seems to just ignore type conversions and Discord doesn't document them

tacit crypt
outer raven
#

Yeah I won’t PR because of the types since we’d need to make new interfaces and idk how to do that with the current type guards

outer raven
#

@remote wasp the guildScheduledEventDelete event doesn't seem to get fired when an event is over and goes away from the events list, how is this meant to fire?

remote wasp
#

when you delete the event

oak quail
#

when an event ends it doesn't get deleted

#

it just gets set to completed

opaque vessel
#

It seems as of b6b4570, stuff is typed as never when the passed type to the API call is imported from discord-api-types:

import { AuditLogEvent } from "discord-api-types/v9";

const audit = await <Guild>.fetchAuditLogs({
  type: AuditLogEvent.MemberUpdate
});

const entry = audit.entries.first()!;
const test = entry.action; // Never
const test2 = entry.actionType; // Never
const test3 = entry.extra; // Never
const test4 = entry.target; // Never
const test5 = entry.targetType; // Never

Is this acceptable? This is fine via the passed type of <GuildAuditLogs>.Actions.MEMBER_UPDATE imported from discord.js, though

tacit crypt
#

Probably a typescript moment where it doesn't recognize the numbers because they're from different enums

#

Try casting the type as const..otherwise, You might have to use the d.js constants object

solemn oyster
#

I was aware of the issues in jsdoc, since they were making yarn test fail locally, thank you @opaque vessel

#

And there are two issues, the one that's making CI fail, and the fact I can't document getter-setter pairs

#

But yeah, thank you for letting me know about that PR, I was about to check 😅

hollow pelican
#

I want to create a pull request and while npm test I get this err. how can I fix it?
Edit: Got it

lusty bolt
#

hi hi, if you wouldnt mind divulging a bit of internal knowledge here, what's the difference between the idToBinary function in the Util class versus just parseInt(id).toString(2)?

solemn oyster
#

That util has been removed from the main branch (and 13.4.0). Also, it's actually BigInt(id).toString(2), but it's useless.

visual hornet
solemn oyster
#

Snowflakes can't be converted to numbers, since they have a precision of 16 digits (and snowflakes typically have 18).

lusty bolt
#

i see now

lusty bolt
visual hornet
#

number the primitive type / Number the wrapper

lusty bolt
#

wait that second reason doesnt make sense, snowflakes are already a numerical value Thonk

lusty bolt
#

but even then it's still useless? how so? you don't get a timestamp from the first 22 bits of the snowflake?

outer raven
#

that's why the function was removed?

visual hornet
lusty bolt
#

interesting! i'll take a look

#

thanks <3

lusty bolt
#

also curious as to why the lib uses 0 as the process ID when generating snowflakes and not the actual.. process ID Thonk but i guess it doesnt matter that much does it

copper garden
#

Pretty sure only the date portion of the snowflake is taken into consideration for paginated endpoints

lusty bolt
#

see this is like the third time i’m hearing about paginated endpoints but i have no idea what that means

#

ah wait never mind i might have an idea

#

never mind this is outside the scope of the library lol

solemn oyster
solemn oyster
sullen idol
#

For Permissions, the only way you can tell if a permission is set to default in discord is if both values are false in the allow and deny. Why not set the values to null if its default? So we won't have to go through allat hassle 😪

solemn oyster
#

Because it's more computationally effective, and also because that's what Discord sends us

opaque vessel
#

Anyone else feel this is a bit off where the warning precedes the type? Would have thought it would be on the same line or after it, like it is with others such as ThreadAutoArchiveDuration or BufferResolvable etc.

solemn oyster
#

You're right, wanna tie with Rodry placing the warning below?

solemn oyster
#

@outer raven I'd say, feel free to PR equals to builders

outer raven
solemn oyster
#

Not sure what the other contribs think about it, but I have no problems with that myself, might be useful to have them in slash command builders (and in turn, also the rest of embeds), cc: @wild flax @tacit crypt

tacit crypt
#

Having built a method that reports all differences between two api datas (so, builder returns), equals is NOT nice to implement

outer raven
#

well equals just returns a boolean, not the differences

solemn oyster
#

Yeah, so better have them where they're at, than implementing them everywhere else we use them at

#

And that

wild flax
#

modules?

outer raven
#

#equals isn't used by the lib itself (although it could) but it's pretty useful in my code at least and having to make and maintain a function to do that myself is annoying

#

could it fit in Util? (something like embedEquals)

wild flax
#

I don't think so, at least not in the main lib

#

we have nothing to do with raw data

outer raven
#

equals is not about raw data

solemn oyster
#

So... you're suggesting to have @discordjs/comparers or something?

outer raven
#

me?

solemn oyster
wild flax
#

yeah something like this

#

idk what do to about the type-guards either

opaque vessel
dawn merlin
outer raven
dawn merlin
#

Wdym

outer raven
dawn merlin
#

You import them?

outer raven
#

and some typeguards are useful even in js like the interaction ones

dawn merlin
outer raven
dawn merlin
#

What?

#

There’s no casting

copper laurel
#

I think the questions are getting confused here

#

So rather than Interaction.isCommand(): this is CommandInteraction
Is it possible to do Typeguards.isInteractionCommand(interaction: unknown): interaction is CommandInteraction or something like that?

#

idk how it works but that seems to be whats being implied

#

Because just getting a boolean true back doesnt help

outer raven
#

yeah that was my question

#

and even if that's possibly it still seems unnecessarily complex

#

I think we should just move all messageembed methods to builders, including equals

analog oyster
#

although that particular function is not included in the pr

zenith oracle
#

I mean, that seems a method that should be included in the class, I don't see what's the advantage of having it in a different package

analog oyster
#

that's true, the package is kind of confusing and doesn't include much so it's hard to figure out what it's actually supposed to be doing/how you're supposed to use it

dawn merlin
dawn merlin
#

Comparing json objects rather than having something be put on a class also seems to have a lot of utility, take /rest and Dapi-types as an example

outer raven
#

thing is the equals method compares embed instances too and, personally, that's what I use it for in my code

dawn merlin
#

Ig my question is does builders output a instance version of embeds? (IE one that isn’t a buildable state)

outer raven
opaque vessel
#

Ah I see thank you

opaque vessel
opaque vessel
#

I'll change it then :eyes:

junior pumice
#

is there already a PR for guild banners?

opaque vessel
#

Yea

visual hornet
opaque vessel
#

I believe they mean animated banners

junior pumice
opaque vessel
#

What you're saying and what you mean are two different things :P but no

junior pumice
#

yeah sorry

#

didnt know what to call it

opaque vessel
#

No one has made a pull request about it to Discord's documentation yet either

outer raven
#

The API doesn’t have that field either

wild flax
#

It’s an experiment

outer raven
wild flax
#

That doesn’t mean anything

outer raven
#

Well it’s more than an experiment at this point

torpid mesa
outer raven
#

Ah ok

torpid mesa
dawn merlin
#

Yeah I’m on stable and my client has it lol

wild flax
outer raven
#

Well it’s not exclusive to the experiments tab that’s what I meant

wild flax
#

Yeah almost no experiment is

#

There’s always a tiny rollout almost

#

Server profiles has been in a tiny rollout for ages before they decided it’s not an experiment anymore

tacit crypt
#

Server banners and bios are barely starting to rollout

outer raven
#

Everyone seems to have access to them now

#

But yeah it’s not on the api so nothing we can do

tender field
#

For #7091 (removal of deleted getters), instead of iterating theough every entry to set the deleted field to true on a XXDelete event, can’t you just check if the parent was deleted in the getter? i.e.:

Message: In the ChannelDelete event, where it checks whether or not a channel has messages, then iterates through all of them to mark them as deleted.
Then can’t you make Message#deleted return deletedMessage.has(this) || this.channel.deleted or smthg? So you don’t have to update it

tame marlin
#

will this come out soon?

vernal adder
#

It's not released yet, but yes, we will support it.

solemn oyster
tender field
heady sable
#

Suggestion: explicitly require setTimeout/setInterval/setImmediate from node:timers wherever .unref() is used
Reason: browsers dont understand unref, so using djs13 in something like, electron renderer prcess, throws error

ornate topaz
#

D.js should not be used in render process

heady sable
ornate topaz
#

Cause it's not rendering anything?

heady sable
#

Well, I need it in the renderer process

#

setting up IPC for everything is a lot of work

ornate topaz
#

Then just get the data from the main process

heady sable
#

there are a shit ton of restrictions on what can and cant be sent-
you need to .toJSON everything before sending
that messes up with a lot of properties-

ornate topaz
#

Then don't send entire d.js structures but only the data you need

heady sable
#

I need entire djs structures-

ornate topaz
#

Do you?

heady sable
#

Mhm

haughty flame
#

probably use REST instead ?

ornate topaz
#

What do you do

heady sable
ornate topaz
#

...and hiw exactly does that require full structures instead of just data?

haughty flame
#

or just make an api of the bot and transfer data from that api ?

heady sable
ornate topaz
#

That's a roundabout way of achieving same thing, moon

#

You see

#

D.js should not be used in renderer, because as you have noticed, it's different environment

heady sable
haughty flame
#

there was actually djs webpacks, not anymore

ornate topaz
#

If you absolutely decline the proper use, feel free to make your own fork of d.js

#

And probably expect more stuff to not work in the renderer process

heady sable
heady sable
ornate topaz
#

"everything"

heady sable
ornate topaz
#

I gave you the reason why it most likely won't

haughty flame
heady sable
#

Alright then, I'll publish it as a separate package and use it for my project 👀

heady sable
ornate topaz
#

Yiu don't have to ping me with every message

heady sable
#

but as you said, I'll make my own fork and work on it 👀

heady sable
ornate topaz
#

Then don't reply either, i am capable of understanding that you were talking to me

heady sable
#

kk

dawn merlin
wild flax
#

It doesn't matter regardless

#

Using d.js in the render process is unsupported and youll likely encounter other issues

#

Set up proper IPC

heady sable
heady sable
tender surge
#

Was going through some of my todo's and found

// TODO: remove once native check is implemented
function isGuildTextChannel(
  channel: TextBasedChannels
): channel is TextChannel {
  return channel.type === "GUILD_TEXT"
}
```Was there any plan to add a native check? I'd like to follow that issue but I couldn't find it
loud jayBOT
visual hornet
#

i believe this is what you're referring to?

tender surge
#

Thanks! I didn't think of checking for the word typeguard

visual hornet
#

There was also a convo about it in this channel, but search is down
You could probably search for "isStrictText" when it comes back up, i remember that was mentioned, that probably hasn't been used for much of anything else

opaque vessel
outer raven
#

That discussion also seems to suggest that /pull/num works for issues, so maybe use that everywhere instead?

wild flax
#

Idk yet that seems like a bug

#

And not a conscious decision?

vernal atlas
#

!777 oops, accidentally typed this and just noticed lmfao

fiery herald
#

he just didn't update it on GitHub?

frozen patrol
#

What is the best handler for a discord.js bot? Like which many js bots use? Glob/builders?

real jetty
#

this is moreso a question for #archive-offtopic as this channel if for conversations about the librairy itself

outer raven
#

Is there any preference for the use of toString() over ${var} on the library?

copper laurel
#

I would think toString() when being called on classes that have that method, ${} if actually string-building is fine

outer raven
#

it seems like doing ${var} is faster though, and toString is actually only used in a handful of places

copper laurel
#

By that I mean return this.thing.toString() is probably preferable to return ${this.thing}

outer raven
#

This is the test I ran btw

solemn oyster
#

That looks like a monstrously flawed benchmark.

Try a class with that, there are some optimisations going on in there, because both have the exact same semantics.

outer raven
#

oh yeah with a class they're both equally fast

#

well nvm that I guess

real jetty
#

Some servers have access to the timeout on Discord. Is there a draft PR to use it with bots?

loud jayBOT
tender field
#

this?

real jetty
# tender field this?

No, this PR adds the property to know if the user is timeout or not but not all the functions to timeout a user from the bots :/

#

My bad

#

I didn't see the end of the modification, thanks 👍

tender field
#

np

raven juniper
#

The feature is still not released from discord and is not available through the API yet

real jetty
visual hornet
#

the bot doesn't know the guild has access to the feature. as far as the bot is concerned, it may as well not exist.

real jetty
#

If the only problem is whether the server has access to the functionality or not, then it is not a problem ( Servers are not selected randomly ) 😉 The only thing I needed was to know if the bot could use this feature (thanks to the PR) if it was in a server having access to this feature. Now that I have the PR I could test

visual hornet
#

The feature is still not released from discord and is not available through the API yet

dawn merlin
#

@opaque vessel for your PR I was requesting the interface for GuildMemberEditData be updated for the new field

opaque vessel
#

Isn't this right?

export interface GuildMemberEditData {
  nick?: string | null;
  roles?: Collection<Snowflake, Role> | readonly RoleResolvable[];
  mute?: boolean;
  deaf?: boolean;
  channel?: GuildVoiceChannelResolvable | null;
  communicationDisabledUntil?: Date | number | null;
}
dawn merlin
#

oh I missed the diff in ur PR, ignore me

opaque vessel
#

Haha, no worries! (:

real jetty
# visual hornet > The feature is still not released from discord and is not available through th...

It's released... As I said some servers have access to this feature (screenshot made by me few seconds ago), when I say something I have a reliable source behind it (I hate to assert something without proof) 😅
Never-mind, this channel isn't made to discuss if a feature is released or not. If other people are interested in the answer to my question here is an answer with tests :
Bots can use this feature in servers that have access to it (I'll let you discover how to know if they have access but it's pretty easy)

unique axle
#

not merged on DAPI docs -> not released, for all we care

#

this is still in a pre-release phase and could potentially still change in usage and API documentation, hence it won't be merged yet, until the API is set, confirmed to be set and merged on API docs.

hasty bluff
real jetty
#

Yes, I understand 🙂 but that didn't answer my original question which was whether there was a PR going on and whether a bot in a guild with access to this feature could use it

real jetty
hasty bluff
#

Yes there is

#

They are waiting for discord docs to be updated first

verbal solar
#

Is v12 gonna be deleted any time? Or is it gonna stay?

wild flax
#

it will just stop working eventually

#

¯_(ツ)_/¯

fiery herald
wild flax
#

I don't quite get what you are asking

#

like yeah I didn't make a release, because nothing noteworthy happened there anyway

fiery herald
#

you've replied me even if you didn't get the question ._.

oak quail
#

all servers with the PARTNERED feature have access

#

as well as certain others

unique axle
#

this does not need to be discussed any further here

#

as long as it isn't merged on DAPI docs it's not going into the library

sullen idol
#

Add the allow and deny objects to the permissions property for creating a role 😪

unique axle
#

that's unfortunately not how role permissions work.
guild level permissions can only be granted or not granted
the only input for role creation that makes sense is the granted ones, which is exactly what it takes at the moment

fiery herald
#

which version of Discord API is discord.js v12 using?

unique axle
fiery herald
#

._.

wild flax
#

v7 technically doesn't exist

#

so whenever v6 goes down, so does v7

outer raven
#

why is it that in almost all structures with timestamps the *Timestamp property is obtained by doing new Date(...).getTime() and the *At getter is just new Date(...)? Wouldn't it be more efficient to make *At a property and *Timestamp a getter that returns <At>.getTime()?

vernal atlas
#

probably yeah

#

although actually

#

*Timestamp (and or *At, its been a while so i forgot) is sometimes assigned in initial construction

vivid field
#

it would probably be more efficient to use Date.parse(x) instead of new Date(x).getTime() unless that gets optimized

visual hornet
#

isn't the *Timestamp sent from discord though? why would that need to be a getter?

vivid field
#

discord sends an iso8601 date string, not a timestamp number, so discord.js converts it

visual hornet
#

ah, i misread rodry's message as them both being getters, my bad

#

wouldn't *At be modifyable if it wasn't a getter though?

outer raven
visual hornet
#

*At properties are Dates, and you could modify them with the setX methods

#

wait, none of the objects are frozen, are they
so every thing else is modifyable?

outer raven
visual hornet
#

i mean if all the other properties of the object are modifyable then the date being modifyable doesn't really matter

#

i was referring to if *At was the property and *Timestamp was the getter

outer raven
#

the only way you can modify them is through the edit method ?

visual hornet
#

reassignment...?
like modifying the object directly

outer raven
#

but... why?

visual hornet
#

Just to the end user, if the object gets modified directly such that the data is incorrect
I was thinking about that, but i realized that all the other properties are modifyable as well so it doesn't really matter

outer raven
vivid field
#

I'm already working on it dogeHaHa

#

don't see a reason not to change it

outer raven
solemn oyster
#

So they take a lot of space in memory

outer raven
#

ahh that makes sense

#

well then ig the only thing to do here is use Date.parse instead which is a great idea and I didn't even know about the method

vivid field
#

same tbh, I looked it up just because of this discussion

haughty flame
#

#djs-help-v14 message

I've been testing with some events for my bot, and it seems like whenever I kick it from a server, it tends to trigger both guildDelete and guildMemberRemove events instead of just the guildDelete event

is this supposed to happened ?

proven blaze
#

I believe so? Its not a bug so to speak as a member is being removed

visual hornet
#

if it does happen it would be an api bug/issue/behavior, not a djs one
like the phantom guildDelete

proven blaze
#

fair enough

outer raven
#

@vivid field I did some tests and using the ternary operator seems to be faster than using && for when dates are possibly null, should probably change that too in your PR maybe?

vivid field
#

are you sure? it's almost identical for me, even a tiny bit slower

#

oh after a few runs it turns out to be faster, but only by 0.8% max

#

not sure if that's worth removing simplification of code

wild flax
#

It’s not

outer raven
quiet viper
#

There are lot of other things to make the libary faster such as converting the caching system...

dawn merlin
outer raven
#

hm?

quiet viper
# dawn merlin ?

Saving whole nested Structures vs saving raw data.
I was intending to solve bigger "problems" rather then complaining on small things.

outer raven
#

what are u on about

dawn merlin
#

^

quiet viper
# dawn merlin ^

Just forget it lol.
I am talking about other factors, which are more relevant for a "faster speed".

dawn merlin
#

I mean we have an issue ticket for storing raw data it’s planned to be added

quiet viper
#

tomorrow I will tell more, currently falling asleep. I made a list...

dawn merlin
visual hornet
#

About the workflow of releasing versions, is my understanding correct that each version will be released when the relevant milestone is completed?
ie 13.4 when the 13.4 milestone gets completed, etc

copper laurel
#

In theory

#

But the milestones themselves are subject to change too

real jetty
#

I mean if there was a critical security patch then I hope the maintainers will release the next version pretty quickly, without the milestone necessarily being met

copper laurel
#

Has that ever happened....?

real jetty
#

I don't think so, but it definitely could in the future

copper laurel
#

I just don't see how it's relevant to the question about our milestones. Of course we can make other releases as needed

dawn merlin
copper laurel
#

Security patches are not roadmapped milestones in the first place

#

Same for discovered bugs and regressions, yeah

solemn oyster
#

We'll just make another milestone and move everything that was planned and didn't merge to it, @real jetty

real jetty
#

So if there was a security patch release, only the patch would be released, and not the other bug fixes, is that correct?

solemn oyster
#

We do that a lot, in fact we did that recently for 13.3 > 13.4

#

We'd just release whatever is on main

#

And the version depends on the semver from the commits, if we just landed bugfixes, dep updates, or docs changes, we'd just release a new patch

undone ravine
#

This is definitely not the correct place to ask this question

hallow ocean
woeful rain
# 
public reply: (options: string | MessagePayload | InteractionReplyOptions) => Promise<Message | APIMessage | void>;

// reply func
const reply = async (options) => {
  if (!await interaction.fetchReply()) return await interaction.reply(options);
  else return await interaction.editReply(options);
},

I fixed it by adding the GuildCacheMessage<CacheType> type which according to discord.js typings returns editReply. Isn't there a bug in the docs then?
https://github.com/discordjs/discord.js/blob/main/src/structures/interfaces/InteractionResponses.js#L130

Types: https://github.com/discordjs/discord.js/blob/a0fe0acbf1c0134d88d9fc519506cf33116288cc/typings/index.d.ts#L1580 | https://github.com/discordjs/discord.js/blob/a0fe0acbf1c0134d88d9fc519506cf33116288cc/typings/index.d.ts#L348

opaque vessel
#

I fixed it by adding the GuildCacheMessage<CacheType> type
I'm a bit confused by this, don't those links you provide already include them?

woeful rain
#

I have

// ˇ Without error
public reply: (options: string | MessagePayload | InteractionReplyOptions) => Promise<Message | APIMessage | GuildCacheMessage<CacheType> | void>;
// ˇ With error
public reply: (options: string | MessagePayload | InteractionReplyOptions) => Promise<Message | APIMessage | void>;

public static createWithInteraction(interaction: CommandInteraction | ContextMenuInteraction, command: Command): CommandContext {
  return new this(interaction.client as GClient, {
    ...(super.createBaseWithInteraction(interaction)),
    interaction: interaction,
    command: command,
    commandName: command.name,
    arguments: new ArgumentResolver(interaction.options.data),
    reply: async (options) => {
        if (!await interaction.fetchReply()) return await interaction.reply(options);
        else return await interaction.editReply(options);
    },
    editReply: interaction.editReply.bind(interaction),
    deleteReply: interaction.deleteReply.bind(interaction),
    followUp: interaction.followUp.bind(interaction),
    deferReply: interaction.deferReply.bind(interaction),
  });
}

When I had everything but GuildCacheMessage<CacheType> in the type, it threw the error shown in the screenshot. So do you guys happen to have some error in the typings there? Because in the documentation there is Promise<Message|APIMessage>

File: https://sourceb.in/R4iFs4v1xH
Full code: https://github.com/Garlic-Team/GCommands/tree/next

opaque vessel
#

It's... never a good idea to supply such a huge block of code or your entire codebase to reproduce an issue, you should create a bare minimum reproduction sample

woeful rain
#

ˇ

#

I don't really know how to fully explain it. I simply have a reply function, and there I have used the reply and editReply functions. When reply isn't there yet, it gives reply, when it is, it already edits. I have typings that the function returns Promise<Message | APIMessage void>;. But, when I just have this in the typings, it throws me an error which is shown in the screenshot. When I clear editReply in the function, it works. However, when I want the editReply to stay there, I look more and find that I have to add GuildCacheMessage<CacheType> there as well. However, the docs don't state that editReply can return a GuildCacheMessage<CacheType> type.

opaque vessel
#

The issue isn't that type... that makes no sense, GuildCacheMessage<CacheType> is Message | APIMessage. Looking at your error, it states that APIMessage imported from @discordjs/builders isn't compatible with that of APIMessage from discord-api-types/v9. So... there you go. This just means there's a change in the exported type, and you're comparing cross-versions that are not compatible

#

If you scroll down in the error you screenshotted, that is the reason why

woeful rain
#

I import from discord-api-types/v9

opaque vessel
#

|:

#

Maybe @discordjs/builders's discord-api-types dependency should be bumped @tacit crypt

tacit crypt
#

Feel free to PR it if it wasn't already

analog oyster
#

You guys should setup dependabot or renovate or whatever else to bump the dependencies automatically

dawn merlin
analog oyster
#

Pretty sure you can configure the bots to not update the dependencies if it's a major version difference

outer raven
golden mortar
#

With my pr switching d.js to undici, it seems it's getting held back by whatwg streams + blob being experimental and I don't really understand why this would be a deciding factor? I just wanted to ask here to see the reason

tacit crypt
#

@remote wasp Any thoughts on the 3 other comments on the events PR? eyess

sullen idol
#

Why does guild.bans.create() possibly return a snowflake? Cant you try to resolve the guildMember and if that fails, return the GuildBan which has the user object?

copper garden
sullen idol
copper garden
#

Also the GuildBan can’t exist until it’s created

#

That would require another api call

sullen idol
#

I gotchu

outer raven
copper garden
#

Would ppl actually use it tho?

outer raven
#

I think so because returning a Snowflake is the least useful information you can get from creating a ban

copper garden
#

Could make it a partial user

outer raven
#

I think the GuildBan would be the best way to go tbh

ornate topaz
#

But isn't Snowflake the absolutely only thing you need to fetch a user? if you really need to have the user object that for some reason wasn't given, you can use it to fetch. + This way you have clear way of controlling if you want to cache the user upon fetching, where the ban option would have to have its own sub-option to allow that control

#

And while true, you don't have a full GuildBan from that ban in that case, what exactly (apart from User) do you not have at the moment of creating the ban, given how it's your bot that created the ban?

solemn oyster
#

To be honest, if you banned a user, you should at very least have the User or the GuildMember beforehand, unless you're banning on sight without any validation whatsoever. And since you'd normally do, d.js returning User, GuildMember, or their partials, is completely useless

tacit crypt
#

From what I see tho, managers return the least amount of data needed, while structures return more, and I personally like that

sullen idol
opaque vessel
#

If you pass a snowflake that isn't a user id then yes... nothing to build there, just invalid

sullen idol
#

Well yeah I was thinking about catching the rejected and have users enter an ID. If its invalid then itll send a message letting them know, with the resolved tho I can see who got banned instead of having to fetch. Also, my ban command bans users who arent even in contact with the bot so instead of me having to fetch the api, this would be helpful

outer raven
sullen idol
#

^

sullen idol
#

Btw when is server banner being added? Like GuildMember#bannerURL n stuff

ornate topaz
outer raven
outer raven
sullen idol
ornate topaz
#

wdym Thonk
we don't release stuff that is not documented in the api docs

sullen idol
#

Ik but ian ask for tht, I asked when, thnx for the info tho all cool

analog oyster
#

When it gets out on the api and documented on the docs

sullen idol
#

"When do u go to the store?" "When I go to the store"

#

Ofc it needs to get documented

ornate topaz
#

we are unable to give you a date you could use in your calendar, simply because it is not in our control. the answer you got is as close as possible

sullen idol
#

Thanks

solemn oyster
#

Without any validation whatsoever?

ornate topaz
#

doesn't API handle passing invalid id anyway?

#

you save a request trying to fetch the id just to ban it and never use it again

zenith oracle
# solemn oyster Without any validation whatsoever?

I mean, many bots have something like a ban command where you can supply the ID of the user (for example if you want to ban a user who is not in the server) and returning something like "Username was banned" is common. So, we can assert on our side that the ID is actually a valid snowflake but we don't want to fetch it from the API to see if it's a real user ID because we don't want to do 2 API calls and we don't need to... When we ban the user the API checks it for us and returns an error in case.

solemn oyster
#

But in order to display username (as well as create a moderation log, which also many bots do), you need to fetch the user glare

opaque vessel
#

Would people be opposed to adding a fetchUser option in BanOptions, which fetches the user object after successfully banning? Akin to how interaction replies have a fetchReply option since the response is nothing

#

Could always assure the return type is User then, even if uncached

solemn oyster
#

I knew it'd come up to this, it's basically a big can of worms

#

We just allowed the fetchReply thing to go thru because it was very highly requested and a lot of people wanted it, but in turn, it has also increased the development cost of that method, and brought this very proposal Jira is proposing

tacit crypt
#

I still don't get why we should fetch/create a user object if you pass in an id..when you can do that yourself if you want

solemn oyster
#

Hence why I'm saying we should change that to return the manager, Vlad

#

Like many other manager methods do

tacit crypt
#

Returning the manager is useless too, what will you do then?

#

We don't return the managers for delete calls for instance

zenith oracle
# solemn oyster But in order to display username (as well as create a moderation log, which also...

Yeah, fair enough, but since returning a Snowflake is totally useless (as I surely already have it if I ban a user) shouldn't djs return the cached user, or a partial one if none is cached? Because now we need to do something like this:

const id = interaction.options.getString("id", true);
await interaction.guild.ban(id);
const user = await interaction.users.fetch(id);
interaction.reply(`${user.username} was banned`);
tacit crypt
#

You could use a user type in that example

#

Since that'll resolve for ids too

opaque vessel
#

Other methods return the manager? :thinking:

tacit crypt
solemn oyster
#

Discord doesn't return anything? We shouldn't try to make up something. What if Discord decides to return something that isn't compatible with what we're returning? We'd need a semver-major to change that. While that wouldn't happen if we return void, because changing something to a promise that resolves to a void (always ignored), to one that resolves to non-void (may be ignored), is technically not breaking.

opaque vessel
solemn oyster
#

For all we know, Discord could change that endpoint to return a ban object, or a partial guildmember, and not a user

tacit crypt
#

or could do nothing

solemn oyster
#

The fact the possibility exists, and we're making up stuff that Discord doesn't give us, is troublesome

#

And we're also trying to move away from requiring cache so much, plus, any extra operation in the managers will slowdown the operation of the structures that call them and do return this;

opaque vessel
#

I'd say return void and call it a day tbh lol.

These days people use slash commands... if you pass an id, it'll resolve to the user object and congratulations, you have that already. Nothing else you need to do (and you even get the guild member object if they're in the guild)

solemn oyster
#

The people who don't fetch the member/user before banning are people who aren't aware anyone could pass an ID to it and literally ban *anyone*, even those with higher roles than them

quiet viper
#

Its completely senseless providing data back, when Discord does not give them.

"Just because the Users are to lazy" is not a valid reason.

• The User has to be fetched before banning the Person, in order to validate if the User exists and if the Permissions are below the executor user

solemn oyster
#

The user doesn't have to be fetched before banning, guild.bans.add doesn't rely on cache, but it has to be fetched for permissions

#

This is exactly why Discord returns nothing, it's beyond useless. If you're banning somebody, you should always have the user or the guildmember beforehand, because you're supposed to check permissions to not get a 401 back, or banning users regardless of the hierarchy or any protection (e.g. mod role protection) the bot should have

quiet viper
solemn oyster
#

It uses resolveId, which returns the ID as-is when you pass a string

tacit crypt
#

Meister meant that on the bot dev side the user must be fetched

#

Not on the lib side

quiet viper
#

^

tacit crypt
#

Anyways the points were made preeetty clear from what I see

  • you ought to fetch the member/user yourself to check for permissions and hierarchy
  • we shouldn't return data for things you can fetch yourself because of lazyness
#

Of course, the last point has the asterisk of interactions fetchReply or w/e (but I'd argue that one is fine due to the nature of the interactions api, and is a common enough requirement that makes sense to add)

outer raven
#

So do we agree to return void on manager methods where discord returns nothing? So that we can remove the mess of return types that is guild.bans.add?

sullen idol
tacit crypt
#

So do it

#

Fetch the member, if it doesn't return a member you can freely ban, else check hierarchy, ban if possible

sullen idol
#

Why not have it return a User or GuildBan instead? That way we just have to resolve and boom we good

solemn oyster
#

Have you even read any of the messages?

tacit crypt
#

We've already discussed why we shouldn't fetch after the ban, with the clearest reasoning being that Discord doesn't return anything right now, and should they choose to, it'll require a breaking change and a major version

sullen idol
#

Alr

tacit crypt
#

Alongside that:

  1. Calling fetch will check caches first, which, if you don't sweep said caches, means super fast returns
  2. An API call to fetch a single member or user is super fast too, and isn't as ratelimited as chunking members, you don't need the GUILD_MEMBERS intent, etc, and gets cached once fetched
sullen idol
#

I gotchu

sullen idol
#

How is GuildMember#User nullable?

raven juniper
#

partial probably

sullen idol
#

Gotchu

copper laurel
#

Theres been a lot of talk here - if theres an issue with the ban method returning inconsistent values then arguably you should reduce it to the maximum one that can be guaranteed

#

Which would be for it to always, only return a Snowflake

#

Then the developer is free to use that to fetch any additional data they wish - either a User object, or a GuildBan object

outer raven
copper laurel
#

Can snowflake not be guaranteed?

outer raven
#

it can, but why would it return a snowflake if discord doesn't

#

that's the least useful piece of information

#

and it's something you certainly already have

#

returning void is just so much more consistent

solemn oyster
outer raven
shell vector
#

With the V13 update, did the library change anything with the privileged intents? On v12 I was having issues trying to get my bot to show the actual full user count of my bot. It would only show the cached user count. However, after getting privileged intents, I am able to start my bot and it shows immediately my actual full user count (80K) users. But when I switch to my V13 branch, I’m having once again the same issue. It is only showing the cached users as my bot user count. So did these privileged intents get changed? And if so is there a way I can fix this? I want my bot to start and immediately show the actual # of users my bot has, not the cached user count. I have the same exact intents and partials etc. the client is setup exactly the same. So with the v13 library I’m not sure what changed this. Can anyone input on this?

unique axle
#

your premise is already wrong.
if you rely on client#users or guild#members (accumulated) you have never received the "actual" user count. to do so you'd need to fetch all members of all guilds at ready (which we heavily recommend not doing because of the massive memory overhead, time and availability reliance). a good estimate (though it includes duplicates) is to accumulate guild#memberCount instead, over all guilds in client.guilds.cache.

with version 13 discord.js does not send all possible events in the identify payload anymore, meaning you will have to specify each intent you want to receive in the client options (https://discordjs.guide/additional-info/changes-in-v13.html#intents)

shell vector
#

So this is the same code I am using on v12 and v13, but on v13 like I said it won’t show the 80K users

const intents = [Intents.FLAGS.GUILDS, Intents.FLAGS.GUILD_BANS, Intents.FLAGS.GUILD_EMOJIS_AND_STICKERS, Intents.FLAGS.GUILD_INVITES,
Intents.FLAGS.GUILD_MEMBERS, Intents.FLAGS.GUILD_MESSAGES, Intents.FLAGS.GUILD_MESSAGE_REACTIONS, Intents.FLAGS.GUILD_VOICE_STATES];
const client = new Client({ intents: intents, partials: ['GUILD_MEMBER', 'REACTION', 'CHANNEL', 'MESSAGE'] });```
unique axle
#

you don't receive all guild members on large guilds on ready, never did, no matter the intents

shell vector
#

I had to apply for user presence and once I got that approved I was able to show the full user count. Before this it was only showing the cached users

unique axle
#

that's a misconception. even with the intent you rely on cache and user data that hasn't arrived yet will not be included

#

it's just that you get more data due to GUILD_MEMBER_ADD and GUILD_MEMBER_UPDATE events with the GUILD_MEMBERS intent
as for presences: yes, that is necessary to get the initial members (again, not all members) on ready with the initial guild data

shell vector
#

I’m just confused because I was using those exact intents and I was only able to show cached users. I applied for user presence intents and now I am able to show full user count on startup. So that intent i was approved of fixed my issue. If I disable the user presence intent, I go back to only being able to see cached users

unique axle
#

it is not the full user count, as much as you want it to be, you are always only seeing cached users, because that is simply how the library works
we cache data as it arrives through various websocket events or requests you make

#

intents just mean that you get more events, more data, faster cache fill (or data to cache at all, depending on the type of data)

shell vector
#

Well then my question is, how with the user presence intent I can see 80K users on startup but without it I can only see 20 users then it grows slowly? Those 80k users weren’t cached.

unique axle
#

Those 80k users weren’t cached.
well, yes, they were.
the presence intent controls if you get guild member data for guilds on start-up (on large guilds: online/idle/dnd only)
the user data for any members we receive through that are cached.

shell vector
#

Okay, so if they were cached then how come with v13 they aren’t being cached? I’m sorry if I’m being ignorant. But I spent so long fixing this for v12 and then updated to v13 and now that fix isn’t working.

copper garden
#

Try limiting intents on v12 and you’ll produce the same results

shell vector
#

So do I need to add more intents to have this outcome I want?

shell vector
copper garden
#

The only reason you get more users with the presence intent is bc the presence update event comes with the user object, which d.js caches

shell vector
#

So with the difference from v12-v13 why is this not caching all members?

copper garden
#

v13 is forced to use intents

#

v12 is using an older api version, where it got added as an optional property for backwards compatibility

shell vector
#

Okay, so I just won’t be able to show all users on startup with v13? I’ll have to just update via cache?

copper garden
#

Presence intent will only cache non-offline users

#

I believe you still need the guild members intent to initially receive all members if the guild is not large

shell vector
#

I do have the guild members intent

copper garden
#

50 members is the large threshold by default

#

You can increase it up to 250 members

shell vector
#

Okay, well thank you both @copper garden @unique axle I appreciate all the clarification and advice. Thank you, I do appreciate it. I’ll start trying to figure out how I can change it. I appreciate your time ❤️

visual hornet
#

you could just sum up Guild#memberCount with only the GUILDS and GUILD_MEMBERS intents as mentioned before.

shell vector
#

Yeah that’s not recommended though as souji suggested and I agree, that’s not the best way of going about it

unique axle
#

wait, other way around, i recommend that

#

it includes duplicates but it's much less straining on your caches

visual hornet
#

the fetch on ready was the one not recommended?

shell vector
#

Oh, I got that mixed up my b

visual hornet
#

there's just not really a great way to go about it while also getting perfect results though, those 3 solutions each only tick one of those boxes

shell vector
#

Yeah unfortunately. Well thank you all again. I’ll try the suggestions you have given me. Thanks again!

shell vector
copper garden
#

Need the nullish coalescing in case of unavailable guilds

shell vector
#

Okay

visual hornet
shell vector
#

got it working! Thank you all client.guilds.cache.map(guild => guild.memberCount).reduce((a, b) => b + a, 0)

visual hornet
#

that iterates on the cache twice btw

shell vector
#

you have a more convenient way you can provide?

visual hornet
shell vector
sullen idol
#

Am I on the old docs? Lol i jus click the redirect

visual hornet
#

That's how the collection docs are now, and also #archive-site-discussion for developing the docs btw, this channel is more for the functionality of the lib

sullen idol
#

Ohh alr

visual hornet
#

seems like your djs and/or djs/collection versions are outdated then

#

and can you just stick to a single channel

sullen idol
#

Gotchu, imma see

sullen idol
dawn merlin
real jetty
#

I'm on v13.4-dev and its just not there peko

sullen idol
visual hornet
#

oh huh i do recall using it though in old code. well that's odd, my bad then

outer raven
#

Reverse was merged 20 minutes after the last release so u gotta wait for a new one

#

Hopefully when the other pr is merged

visual hornet
#

that is somewhat comical

real jetty
#

Why is this enforcing the void return type for callbacks?

#

Does djs even do anything with the callback after its called?

dawn merlin
real jetty
#

Guess that's fair, makes everyones code a bit messier though.

outer raven
opaque vessel
sullen idol
#

Theres an error wit djs returning a collection of members when fetching only 1 btw

copper laurel
#

how so

#

Please be more descriptive

errant brook
#

hello if i wanna add a new type of option to command option types what all do i need to check

sullen idol
#

I just check more into it, if the value passed is undefined it returns the whole collection instead of a rejected promise, dont think thts supposed to happen righ?

copper laurel
#

Of course it is

#

members.fetch() and members.fetch(undefined) are identical in Javascript

#

You couldnt have the first work if the second didnt

sullen idol
#

Thats interesting, it didn't do that before so I thought it was an error

#

the more yk I guess

copper laurel
#

I promise you it always did haha

sullen idol
#

Yh I probably was trippin or sumn lol

copper laurel
#

If you were to pass something that isnt undefined, but also isnt a valid ID, that would error

sullen idol
#

Alright, Lemme try

#

Is there anyway I can get undefined returned? To make the code shorter

copper laurel
#

Wasnt meant to be a reply to you sorry

sullen idol
#

I gotchu

errant brook
copper laurel
#

Depends how different it is to other option type

errant brook
copper laurel
#

No, I mean the discord.js typings

errant brook
#

where do i find those?

copper laurel
#

Though possibly api-types too if we pull those from there

errant brook
#

i added it in api-types

copper laurel
errant brook
#

all i need to do now is add in djs tuypings and constants like you said

#

thanks!

errant brook
outer raven
#

That’s not what they meant…

errant brook
#

???

worn bobcat
#

Hehe

errant brook
#

lol it's my pr i know what im making the pr for XD

errant brook
outer raven
#

I can but keep in mind I'm not a maintainer

errant brook
errant brook
#

why did MessageAttachment#_patch not patch filename ?

#

i know that but why was it not in MessageAttachment#_patch tho

#

like all other properties are being patched in MessageAttachment#_patch then why not name

visual hornet
#

Because it's seperated out from the data object as the second parameter in the constructor, as megatank mentioned
it's for convenience when making your own attachments to send, why wrap it in an object when you have no other data to provide

copper laurel
#

why would the name of an attachment ever change

solemn oyster
#

I doubt we patch nested objects, if only, we re-create them

errant brook
zenith oracle
errant brook
#

ill do that

tame marlin
#

does it trigger userUpdate event when changing profile banner?

opaque vessel
tame marlin
#

and does GuildMemberUpdate get triggered when changing in-guild profile avatar/about me/banner

opaque vessel
#

No. This is more of a question you would ask in discord.js's support channels, not here (or test yourself)

real jetty
dawn merlin
real jetty
#

I think it should be moved to Util though because its a useful utility if you're already using the ApplicationCommandData type for creating your slashie objects. I personally use it for deploying without having to be logged in to discord.

dawn merlin
#

But it’s transformed internally anyways

real jetty
dawn merlin
#

Yeah that’s my point lol, it’s run for you anyways when you pass an object in

tropic hull
#

Why use webhooks instead of embed for answer at slash commands?
We can't use custom emote in webhooks

copper laurel
#

I dont quite know what you're asking here but
A) Webhooks can have embeds in them, they are not mutually exclusive
B) Webhooks can also have custom emotes in them, as long as the @everyone role has USE_EXTERNAL_EMOJI permissions
C) Discord designed slash command responses as webhooks, not us

tropic hull
#

It's not practical to have to give permission to everyone

opaque vessel
#

Webhooks aren't in your guild - has nothing to do with your bot

opaque vessel
tropic hull
tropic hull
visual hornet
#

Your bot answers through the webhook which isn't exactly attached to any member so you can't give it perms directly, it just takes the default (ie @everyone) perms

tropic hull
#

Interesting

copper laurel
#

Your bot user doesn't need to be in the guild at all for slash commands to be provided, hence, response are webhooks

outer raven
#

Why are we allowed to modify a guild's features on Guild#edit? Does the endpoint actually support adding/removing any features?

dawn merlin
outer raven
#

yeah I know it's there but does it actually work?

opaque vessel
#

For ones that obviously won't, yes... you can for example remove the community aspect of a server

outer raven
#

oh I thought bots couldn't do that

#

alright

#

and is there a way to obtain all available features? It doesn't seem to be exported in constants

#

@opaque vessel could you say something about the currently unresolved reviews on the timeouts pr pls cookieCat

opaque vessel
#

Well for the first one, looks like two members of discord.js decided against for renaming the helper method, so that's a resolution

export type TimeoutDateResolvable is pretty harmless, but no core maintainer has said anything yet

I have nothing to say about "Why does this method not support TimeoutDateResolvable?", ckohen already said my reasonings too

So... I have nothing to say to any of them

outer raven
#

Well for the first one, looks like two members of discord.js decided against for renaming the helper method, so that's a resolution
I genuinely don't understand why, and people only reacted, no one actually said anything. I replied to your comment and I genuinely think it makes sense, so I'd like to understand your POV on why you think that name makes sense here but not on other situations

I have nothing to say about "Why does this method not support TimeoutDateResolvable?", ckohen already said my reasonings too
I mean it doesn't hurt to support it does it

junior pumice
#

is there already a PR for the timeout feature?

quiet viper
junior pumice
#

is there or not

tired valve
#

Keep the channel on topic

junior pumice
#

wdym its channel topic

#

PRs are literally a part of developing discord.js

quiet viper
#

#archive-sharding message
Is this a bug of the action handler? Seems to cause a crash of the Process. Should they create a issue?

opaque vessel
#

They just need to update to stable

sullen idol
#

Can you add like an errors option to MessageComponentCollectorOptions, so the end event will only trigger by time or whatever we specified?

copper laurel
#

Should already be there, not sure why its not documented

#

Should be in the base CollectorOptions

#

Oh nvm, I know why

#

Errors are only relevant to the promisified versions

#

Collectors dont have error events, they just end with a reason

sullen idol
#

Right right, thats why we use .catch() ain it?

copper laurel
#

Well not on a collector no

sullen idol
#

Hmm, I mean like .awaitMessages and .awaitReactions, are the errors not rejected promises?

copper laurel
#

Well that doesnt use MessageComponentCollectorOptions, it uses AwaitMessageComponentOptions

#

And that already only errors on time

sullen idol
#

So, we won't be able to have it end by time only for MessageComponentCollectors?

copper laurel
#

It only ever collects one component, or runs out of time

#

Thats the only conditions it can end

ornate topaz
#

You don't need error to be able to specify time

sullen idol
#

I gotchu

copper laurel
#

component - resolved
time - rejected

sullen idol
copper laurel
#

It was designed that way (single collection only) because Discord requires you to immediately respond to the interaction

chrome plover
#

Not sure if this is the right place, but any idea if it will be possible to place multiple users on timeout at once? like for example:

await guilds.disableCommunicationsFor(Array[Targets], {options}):

Options being duration in ms and a reason for audit log.

sullen idol
copper laurel
#

Unlike reactions/messages where you can apply extra error conditions like ending on a max number etc

sullen idol
#

..

copper laurel
#

The API isnt designed that way, much like you cant multi kick or ban

chrome plover
#

true, thanks for the quick reply.

copper laurel
sullen idol
untold sedge
#

hope your pr for timeout get merged to the library 🙂

dawn merlin
outer raven
#

@dawn merlin a few days ago you PR'd this change and now I'm not getting types on my created channels when not specifying a type (defaults to text) and I'm getting the store channel deprecation, could you look into it?

#

it always falls back to the last overload

dawn merlin
#

There’s a type test for this and it seems to be passing

outer raven
#

oh and intellisense only gives me GUILD_STORE as a possible type

dawn merlin
outer raven
#

I am yeah

#

and that was not accounted for in the tests

#

if I specify the type it does work, but I get no intellisense

loud jayBOT
#

pr_open #7132 in discordjs/discord.js by suneettipirneni opened <t:1640041398:R> (review required)
types(CategoryChannel): createChannel should default to a text channel
📥 npm i suneettipirneni/discord.js#types/default-category-channel-type

outer raven
#

@dawn merlin shouldn't there be more?

dawn merlin
#

no, these are the valid options:

export type CategoryChannelTypes = ExcludeEnum<
  typeof ChannelTypes,
  | 'DM'
  | 'GROUP_DM'
  | 'UNKNOWN'
  | 'GUILD_PUBLIC_THREAD'
  | 'GUILD_NEWS_THREAD'
  | 'GUILD_PRIVATE_THREAD'
  | 'GUILD_CATEGORY'
>;
outer raven
#

right you can't make threads

#

alright then that works like a charm, thanks!

#

I mean, shouldn't GUILD_STORE be suggested?

dawn merlin
#

It's hard bc it's an overload that comes after it, it still works, but it's deprecated

outer raven
#

oh right yeah and if you remove the exclude it doesn't get marked as deprecated

#

alright then I guess that doesn't hurt anyway

dawn merlin
#

@outer raven what do you want me to test?

outer raven
#

the checks pass, but just to make sure they dont break in the future

dawn merlin
#

done

solemn oyster
#

@woeful rain there's no disableCommunicationUntil method

woeful rain
#

my bad

spice junco
#

is this in djs v13.4.0 beta yet?

#

ping me if u got answer

copper laurel
#

there is no beta

#

Its not merged into -dev yet

outer raven
spice junco
copper laurel
#

not yet

spice junco
#

ah

#

will it be in djs 13.4.0?

#

the official release

copper laurel
#

yeah it should be

spice junco
#

alright

#

thanks man

lofty birch
#

will the timeouts PR override the user's permissions getter to remove the permissions that it's taken from them (send messages, connect to vc's etc.) or does that have to be implemented on our side

opaque vessel
#

Not sure if that's something that should be done. They technically still have those permissions, they're just timed out. Maybe you should check if they're timed out before doing whatever it is you need to do with them in that state

lofty birch
#

it feels more like a convenience thing - I'm happy to do it on my own getter but I think it could be nice to have within the lib as during the timeout, they can't in fact do those things

outer raven
#

and maybe you could also add a moderatable getter just like kickable and bannable?

#

also VoiceChannel#joinable should take timeouts into account too

#

I can leave a review on the PR with all the info if u need

opaque vessel
#

Their permission bitfield remains the same from the API if someone is timed out. I'm not really sure discord.js should modify that?

#

A quick look at other libraries reveals they don't factor this in either

opaque vessel
#

Ah wait you mean the helpers not the actual modifying the bitfield. Read the wrong initially... guess I could do those

outer raven
opaque vessel
#

So BaseVoiceChannel#joinable I added the check in
GuildChannel#manageable too - this accounts for the .deletable property also
VoiceChannel#speakable has the check too (stage channels don't have one)
Message#deletable has the check too

It seems there is no helper check for reacting on a message or sending a message, so I did nothing there

You can still edit a message and pin a message when timed out, so did not alter those properties (no idea why)

Did I miss anything?

lofty birch
opaque vessel
#

I read wrong, disregard that

lofty birch
#

Ah yeah, no I definitely didn't mean actually modifying the bitfield, that would be bad

visual hornet
#

oh wait i brainfarted on that last part those checks wouldn't be necessary if bots couldn't be timed out mb
so yeah sendable

lofty birch
opaque vessel
#

Well I've tested it and found it to be the case - have you?

lofty birch
#

Huh, you're correct. must've confused losing channel perms with that

visual hornet
#

same for channel and message deletions, both of your own and others' messages

opaque vessel
opaque vessel
visual hornet
#

im testing with admin perms and highest role

opaque vessel
#

Timeouts have no effect on administrators

visual hornet
#

can't send messages (nor reply) with it so i don't think that's fully true
although as an admin i still can do the other 2 actions listed here

opaque vessel
#

You can't send messages when timed out with administrator?

visual hornet
#

not through the ui, no

opaque vessel
#

This is strictly the bot API, doesn't matter what the UI does

visual hornet
#

guess that's a negligible inconsistency then

#

if the api allows sending, anyways. (and it does)

lofty birch
opaque vessel
#

Huh what's the bug? Not being able to send messages when timed out as admin?

lofty birch
#

yes

#

you can do so, the client just doesn't show it

rough roost
#

it seems you also can't pin messages when timed out

opaque vessel
opaque vessel
opaque vessel
opaque vessel
rough roost
#

all the permissions it has. it can't publish/pin messages when timed out

create_instant_invite, kick_members, ban_members, manage_channels, manage_guild, add_reactions, view_audit_log, read_messages, send_messages, send_tts_messages, manage_messages, embed_links, attach_files, read_message_history, external_emojis, change_nickname, manage_nicknames, manage_roles, manage_webhooks, manage_emojis, use_slash_commands, request_to_speak, manage_threads, create_public_threads, create_private_threads, external_stickers, send_messages_in_threads
opaque vessel
#

Ty just verified that

#

Why are there so many helpers

visual hornet
# 
permissions.has(Permissions.FLAGS.ADMINISTRATOR, false)

is the second param you put here really necessary? or is it just more of a standard internally?
not really significant but just noticed and was curious

#

GuildMember#bannable : no changes needed, accessible in API
GuildMember#kickable : no changes needed, accessible in API
GuildMember#managable : no changes needed, accessible in API
Invite#deletable : no changes needed, accessible in API
Role#editable : no changes needed, accessible in API
ThreadChannel#editable : 50001 Missing Access
ThreadChannel#joinable : no changes needed, accessible in API
ThreadChannel#managable : 50001 Missing Access
ThreadChannel#sendable : 50001 Missing Access
ThreadChannel#unarchivable: 160005 Thread is locked
ThreadMember#managable : 50001 Missing Access

opaque vessel
#

There's more? Oml

visual hornet
#

yeah im just going through the typings file lol. pretty handy.

opaque vessel
#

I'm kind of scared that some of the above things (verified myself btw) are still usable... like, what if they're oversights and will be patched in some future API deploy and this library has them hardcoded

visual hornet
#

i'd.... hope that would fall into a semver patch.

opaque vessel
#

It probably wouldn't be a priority to release either

#

Hai hai @solemn oyster, do you think the library should account for the client user being timed out for the permission helper checks above?

#

Or would you say that's something for the developer to account for?

visual hornet
opaque vessel
#

I just did that cause it's done everywhere else internally... not like that extra parameter does anything though in that specific case

visual hornet
solemn oyster
solemn oyster
opaque vessel
#

I suppose, alright, ty (:

visual hornet
#

checkAdmin false -> BitField#has(ADMIN)
checkAdmin true -> (true && BitField#has(ADMIN)) || BitField#has(ADMIN)

ruby terrace
#

the admin permission can be set in a channel overwrite, it has absolutely no effect on actual permissions, so you must ignore it, server wide admin is already split out

outer raven
visual hornet
wild flax
#

@opaque vessel you still haven't checked your "add necessary checks to permission helpers" is this done already though?

opaque vessel
#

Thread channels has some left, like sendable

wild flax
#

alright, thats the last thing thatd be blocking the merge then

#

so whenever you get to it, or need some help

opaque vessel
#

Should now all be done (:

wild flax
#

@outer raven i dont get what you are asking in your latest comment

#

it already returns true if you have admin, regardless if you were muted

#

🤔

outer raven
#

are you talking about speakable?

wild flax
#

yeah i mean

#

some people might not check joinable

#

¯_(ツ)_/¯

#

you could be dragged into it you know

#

so youd only have to check speakable

outer raven
#

But given that you joined the channel, you're allowed to speak in it if you're timed out, but you're not allowed to join any channel to begin with unless you're admin

outer raven
wild flax
#

¯_(ツ)_/¯

#

I don't think it matters much

outer raven
#

I just think that helper shouldn't be touched, along with most others

#

the only ones that should be changed are joinable and sendable, everything else is not affected by timeouts

wild flax
#

imo itd be kinda dumb to have joinable return false

#

but speakable true

#

lol

outer raven
#

but that's how Discord designed it

#

you can't join, but if for some reason you do, you're allowed to speak

wild flax
#

like theres a lot of edge cases for admin anyway

outer raven
#

I think that's the only one isn't it?

wild flax
#

but semantically itd be confusing

outer raven
#

being able to speak when timed out could be (and imo should be) considered a bug on Discord's end, but if they allow it for now, we should too and only change later if they do change this

wild flax
#

i dont think so

outer raven
#

well then it's your call

#

what about manageable though?

wild flax
#

im not a huge fan of implementing discord shenanigans

outer raven
#

and deletable on messages

wild flax
#

id rather have some coherent system

#

while you technically (even though you cant join) speak

#

it doesn't make sense since you cant join

#

so I can safely say you can't speak for the helper method

#

it just makes things less confusing

outer raven
#

I mean yeah I don't see a scenario where someone would time a bot out if it has admin

#

but for big bots that might be something they gotta take into account

wild flax
#

or an admin another admin