#archive-library-discussion

25085 messages · Page 19 of 26

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

waitWhat

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

Thonk

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

swagcat_pray

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

Thonk

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

¯_(ツ)_/¯

outer raven
wild flax

what about it

outer raven

why was that changed in the timeouts pr?

wild flax

why do you ask me

outer raven

idk you seemed to agree with it

wild flax

id rather want to know why you dont

instead of playing this back and forth game here lmao

outer raven

actually I got confused because you can edit a single property on a thread (default auto archive duration) but not anything else on any other channel so I guess that's another bug, ignore

however you can always join threads regardless of timeouts and perms

wild flax

cc @opaque vessel

this is something we can talk about

:D

outer raven

yeah sorry for my confusion earlier, joinable seems to be the only helper that doesn't need to be touched

Also could you please add a moderatable check that works similarly to kickable and bannable but with the new perm? cookieCat

visual hornet

did you test with the api on this

outer raven
visual hornet

ah my bad i skimmed over and missed the last few messages

opaque vessel
opaque vessel
outer raven
outer raven
opaque vessel

Yeah there's a big difference between the client and the API side. The client won't let you do it though (visibly it will, but the request also errors out)

outer raven
opaque vessel

How would this getter work? Just check if the guild member is timed out? Lil' confused on that one

outer raven
opaque vessel

Ah right a check to see if you can timeout a user

Interestingly it looks like a bot can still timeout a user if they're currently timed out (lol)

outer raven
opaque vessel

Nah

People may alter their user cache to remove all users (it can be set to 0)

That includes the client user

outer raven

is that supported?

opaque vessel

Apparently yeah

outer raven

then that ?? false should be applied elsewhere too

opaque vessel

It's also in other permission getters:

const permissions = this.permissionsFor(this.client.user);
if (!permissions) return false

'Cause the only way that is defined is if you're cached in the guild

opaque vessel

Anyway, that should all be done now [:

outer raven
opaque vessel

[:

outer raven

0 so it returns false?

actually probably -1

slate nacelle

It's already throwing an error

outer raven

oh bruh

blind facepalm

I don't need to touch these examples do I

opaque vessel

I say examples are fine

opaque vessel
outer raven

I'm gonna apply that same logic to these

solemn oyster

If you modify the getters to throw a defined error, you'll make it semver-major, since the error will change

outer raven

I've done this same exact thing before and it was semver patch

solemn oyster

You're changing it from a TypeError to an Error, so yeah...

You're changing the behaviour in there

outer raven

how can I make this patch then

solemn oyster

Also please re-use guild.me, no need to run the getter twice

You can't, gotta wait for v14

It'll come out soon, so don't stress much on it

outer raven
outer raven
solemn oyster

Over the 50% of the open PRs are semver-major

zenith oracle
solemn oyster

7 of which were created within a month of 13.0.0's release

We shouldn't leave them sitting for any longer, we're aware of that, and we're working towards a v14 quite soon

outer raven

oh alright 👀

outer raven
opaque vessel

Anyway, that should finally be it for the timeouts pull request [:

outer raven

Poggies

and events seems to be done too so v13.4 soon™️? 👀

solemn oyster

Yup, hopefully before the Christmas break

outer raven

aye

solemn oyster

So you don't have to use base types (which aren't really strict typed)

outer raven

didn't I just do that?

outer raven

@dawn merlin when I reviewed your PR this was returning a TextChannel promise like it should, why'd you change that?

that PR didn't fix anything it seems

oh wait this was because of the rebase

im gonna try to fix it

this method should never return that type union anyway

dawn merlin

I think this was from the make channel types stricter PR

CC @solemn oyster

outer raven

I don't fully understand that PR but shouldn't TextChannel stay as TextChannel?

dawn merlin

Not necessarily, dm and group DM’s don’t count

outer raven

what?

solemn oyster
outer raven

gonna PR

dawn merlin
outer raven

that's not what I said

a TextChannel isn't a dm channel

heavy heron

Hi there any idea when the new timeout feature will come to djs?

copper laurel

when its ready

soon ™️

outer raven
heavy heron
heavy heron
outer raven
copper laurel
outer raven
heavy heron

But how do i access discord.js@dev?

What is it even?

outer raven

you install it with npm

heavy heron

Oh ok

outer raven

npm i discord.js@dev

copper laurel

I probably shouldn't meme in here, never mind lol

dawn merlin

Rodry taking everything literally smh

outer raven

i genuinely didn't get it

copper laurel

Sorry haha

outer raven

Any reason why these structures are required here instead of at the top of the file?

BaseMessageComponent#create btw but this is done elsewhere too

tacit crypt

Circular imports

outer raven

hm?

tacit crypt

Every component imports BaseMessageComponent. BaseMessageComponent imports every component

The import is thereby circular

copper laurel

By having the import scoped to the case block, it avoids the circular import since MessageButton imports BaseMessageComponent

tacit crypt

Of course, the other solution would be moving them at the bottom, but it's not the prettiest view

outer raven

oh so if they were at the top it would error?

copper laurel

Yeah you get weird constructor errors at runtime iirc

outer raven

ah alright

opal sapphire
outer raven

Would it make sense to add the MessageEmbed getters from discord.js (like hexColor and createdAt) to builders?

visual hornet

couldn't you just import djs to reexport its MessageEmbed at that point

loud jayBOT
outer raven

@visual hornet ^^

visual hornet

oh. well then yeah i guess
although im a bit confused on the naming of createdAt tbh, but other than that i guess yeah if you want to keep those properties

outer raven

yeah it seems like it's just the timestamp and not when the embed was created
and I don't think knowing when the embed was created is useful, but maybe a unix timestamp instead of an ISO string would so that could be made into a getter

real jetty

is the new timeout feature already added to the library?

outer raven
real jetty

ty man

pine python

this might be a naive question but why do the require statements for node libraries use require("node:events") rather than require("events")? My jest unit tests freak out because it can't resolve the require statements in the discord.js source code that start with node:xxxx,

rough roost