#archive-library-discussion
1 messages · Page 19 of 1
If the return type won't accept big integers then there's no point doing it in the first place then
oh whoops
there is, for doing the math
Jiralite pls
Heck what
Do you see me calling Number twice? 
also as a side note, im not sure if i set something incorrectly in my dev env, but uh,
i haven't modified this or anything, just cloned the repo
eslint is complaining that this should be under node-fetch, but nothing about it shows up with npm test
doesn't hurt to run an npm ci, restart the eslint server and also re-run the test script
Apparently that's a false positive
#archive-library-discussion message
aight ill try looking into that, thanks
As long as npm test works fine then all should be good I guess
yeah i understand that, just want to make sure eslint is working fine in the ide since the changes im planning are more than just swapping a and b like i initially planned lol
Should https://github.com/discordjs/discord.js-modules/pull/45 be closed? Seems like the changes are no longer accurate/true
i got to this, but it feels kinda clunky, im not sure if this could be improved in some way?
Number(a instanceof GuildChannel ? BigInt(a.id) - BigInt(b.id) : BigInt(b.id) - BigInt(a.id))
Suppose you should use variables to make it less clunky? Shrugs
as an iife? or just make it a block and return the result?
Yeah it looks like a block would be more readable
Like so?
const aId = BigInt(a.id);
const bId = BigInt(b.id);
return Number(a instanceof GuildChannel ? aId - bId : bId - aId);
aight
return collection.sorted((a, b) => {
const aId = BigInt(a.id);
const bId = BigInt(b.id);
return a.rawPosition - b.rawPosition || Number(a instanceof GuildChannel ? aId - bId : bId - aId);
});
so this is what i've got now, anything else to be desired here?
@dawn merlin your question you just asked isn't for me, that's for Discord
ok, I just wanted to verify that this currently how discord is sending events
I don't really know how ddevs and that all works (not in there), but you should probably ask in there. If you don't want to, I can get an answer for you during working hours
i'll just make an issue ticket on the dapi-docs github, someone from ddevs will probably answer
alright i have an issue with my pr that i cannot figure out for the life of me,
in the latest djs pr these lines were added https://github.com/KhafraDev/discord.js/blob/main/src/structures/MessagePayload.js#L181-L189 that cause some issue in my pr https://github.com/discordjs/discord.js/pull/6586 and prevents attachments from being sent. without these lines, i can send an attachment just fine, anyone got a clue?
here's what attachments is ```js
attachments: [ { id: '0', description: undefined } ],
aren't you supposed to use files to send them initially
and attachments is mainly for editing?
no clue, these were just added as the result of a rebase
removing those lines makes everything work fine once again
still have no idea what attachments are really for :/
neither do I but i'm wondering if that's a bug, extraneous code that can be removed, or if i need to implement a fix on my pr
the naming scheme is kinda weird, files is the array that is processed into the attachments array, the attachments array in MessagePayload is the thing actually processed into formdata.
There is also the attachments key in Messages, which is JSON data and completely separate.
so any reason sending the attachments array would cause a 400 status from discord's side?
i have no idea how to fix the issue i'm having minus just removing that section of code linked above
the exact error:
DiscordAPIError: Invalid Form Body
attachments[0]: Attachment data not found
code 50035
- if (file?.file) body.append(file.key ?? `files[${index}]`, file.file, file.name);
+ if (file?.file) body.append(file.key ?? file.name ?? `files[${index}]`, file.file, file.name);
You made this change to the formdata appending, which I believe causes that error. Take a look at the new attachment uploading stuff in the api docs, seems that was missed in the rebase
that fixed it! but that brings up a second question:
the issue is that file.name wasn't und/null so the name would default to that.. but if file.key was a valid name, wouldn't it throw an error there as well?
the key is used for stickers only, because the formData key needs to be "file" for that
the stickers endpoint uses formdata but is more json styled
interesting đ thanks for the insight & the help
np, its all kinda confusing, I wouldn't know about that stickers stuff if I hadn't just implemented that in /rest
(unrelated to the current discussion)
i think im doing something wrong with testing
i only added a require and changed discordSort, but when testing im getting Util.setPosition and Util.idToBinary not being functions, logging Util gives an empty object
i tried requiring the index through a filepath, and also by npm pack then npm i, and they're yielding the same results
requiring the index where?
in testing code, i just did require('../../discord.js/src/index.js')
well actually it was esm that i already had from earlier
circular requiring index is generally very very bad, any chance thats happening?
oh it wasn't inside djs
i had a test file inside a different project in the same directory
Is there any package that can perform automated tests for bots using slash commands?
pls ping if answering
this isn't really a question for this channel, you can just write tests yourself
@tacit crypt has there been any discussion/decision on the issue of replacing ow in builders? Sorry for the bump but esm support being broken feels kinda high priority
ow, my validation...
Discord.js seems to lack some API fields according to the Discord API Documentation here:
https://discord.com/developers/docs/interactions/application-commands#application-command-object-application-command-option-structure
The attributes min_value and max_value is not present in the type ApplicationCommandOptionChoice and also not set in transformOption().
See:
https://discord.js.org/#/docs/main/stable/typedef/ApplicationCommandOptionData
https://github.com/discordjs/discord.js/blob/stable/src/structures/ApplicationCommand.js#L330
I see that an PR is being merged 4 days ago. Let me use the github master version then
It's just not in stable
Because of the way dynamic works, shouldn't gif be excluded from the format type here as it'll already use gif when possible if you specify the dynamic flag?
Possibly, but iirc providing both isnât technically incorrect
What if you don't know if the user has an animated avatar icon? Providing your desired format there is a fallback
Feels like the default for dynamic should be true
the defaults for images should be changed a bit imo
but yeah it's a bit risky to provide a gif format
Im pretty sure the defaults we have now exist for a good reason, this discussion comes up every so often
It feels a bit odd imo to specify a dynamic property to get the actual avatar icon that is being used by the user in the right format... wouldn't it be more desirable to replace that with a static property where you decide whether you want to receive their URL in a non-animated format?
So { static: false, format: "jpg" } would get the .gif and fallback to .jpg if it's not animated
{ static: true, format: "jpg" } would get the .jpg always
I'm not sure where this can falter tbh
And whats the default, static: false?
I just dont really see what benefit this has over setting a format, and a property which will override that for animated avatars
Yep yep, static: false is the default. If anything, this seems more like a helper property by discord.js shrugs
If you think about it, fetching the avatar's hash will return it in a format starting with a_ if it's animated. discord.js converts every image received to static by default, though that's not necessarily what should be happening? It should be returned as-is, and the user can specify if they want to enforce the image to be static
Not exactly? The default format is webp
So what you'd be suggesting is this: https://github.com/discordjs/discord.js/blob/5ec04e077bbbb9799f3ef135cade84b77346ef20/src/util/Constants.js#L50
- if (dynamic && hash.startsWith('a_')) format = 'gif';
+ if (!static && hash.startsWith('a_')) format = 'gif';```
Yeah but currently, you have to specify if you want it to be dynamic
Yes I know
Sorry didn't see the code block with the huge thing being collapsed x_X but yes!
Tbh at that point the property becomes useless, if you want a static image, just supply "png" or "jpg" or something
uhh.... no? Because it will default to gif?
Can you elaborate
Supplying "png" would be for deciding the format if it is not animated
Unless you also provided static: true
Or the reverse with dynamic: supply "png" to always get a png, or supply "dynamic: true" to get a gif if its animated
What I'm saying is that if we flip the logic to ensure all the URLs made are dynamic by default, you wouldn't need the static property. Since all animated avatars on Discord are of a .gif format, then the other formats .webp, .png, .jpg and .jpeg are all for static images so... they would never attach themselves onto animated avatars
Supplying one of them implies you want them to be static
No it doesnt
That's breaking the existing functionality of being able to specify the static image format while also resolving an animated one if applicable
Currently:
() - webp
({ dynamic: true }) - gif > webp
({ dynamic: true, format: "png" }) - gif > png
({ format: "png" }) - always png
With your proposed static: false default:
() - gif > webp
({ static: true }) - webp
({ format: "png" }) - gif > png
({ static: true, format: "png" }) - always png
If you remove static/dynamic entirely, you lose that gif > png use case
The fallback scenario is gone
I got you yeah just at the last moment, thank you for being concise there haha
Otherwise the change is literally just swapping the logic on the first two outputs
Yeah exactly, I'm pretty sure everyone everywhere is favouring always using dynamic: true, so... we should probably change that
Not true, I dont
Well, mostly, at least, but the logic I follow is if the user object logs the avatar's hash as "a_..." and you run .avatarURL(), one new user would likely think they're going to receive the animated avatar
Uh anyway... I guess that's a change for version 14?
Would definitely be breaking yes
Cool, alright, thank you for this lil' conversation (':
On that note, I believe thereâs no good reason to use webp as the default is there? Discord doesnât have a default, the client used png and webp doesnât even support transparency
Webp does have transparency
It does not
If you try to set somethingâs icon or avatar to a webp image it loses the transparency, Iâve tried it
Well the format does dunno why it doesnât work for discord
ÂŻ_(ă)_/ÂŻ but supplying png for that works as intended
So maybe that default could also be changed for v14?
Actually now that I look into it, webp is supposed to provide quality images with less size but itâs made mostly for browsers, and djs doesnât work on a browser, so maybe that was forgotten when that was removed ÂŻ_(ă)_/ÂŻ
Is this via the client gui?
the client gui doesn't even allow you to upload webp
We did not write our code with browsers in mind past the parsing res.stuff from node-fetch.
If discord cannot process webp's that's an issue on their end not ours
Also the client uses webp whenever possible
If a platform doesn't support it, then it defaults to png
Thats because you didn't press "skip" in the selector
You cropped it with discords internal crop tool, which gets rid of any transparency
As for our methods, the problem exists most likely with their image microservice
I didnât crop anything
So why donât we default to png
This is why
Because the client is based on web so it needs smaller images, but if webp doesnât work properly with djs I donât think we should use it right?
You do realize that it's not discord.js's fault that Discord's media whatever the hell it's called breaks webp transparency, right?
And also, we already default to jpegs for uploads
if you send discord a webp image thats on you
I don't see why we should change internals for this
Maybe we have a bug that we send the image wrong to discord when using an URL
My point is that if you donât specify a format, discord.js sends webp which then breaks the image. I understand this may not be the libraryâs fault, but itâs something that can be fixed by changing the default, and then if the user decides to specify webp itâs their own fault
in this case it is the libs fault because of what vlad said
we just assume its a certain extension
which could potentially mean gifs break too, except if we check only for gifs
But whereâs the code thatâs defaulting to jpeg?
@outer raven the regex you gave for INVITES_PATTERN doesn't work for events, need some help with Client#fetchInvite
which PR? I don't remember touching that one đ
yeah so the idea was for it not to match events, and for a new regex to be used for those
I remember that now
not sure if you agree but I feel like it would make sense for an event not to match with the invites pattern
so that regex does work for events only (not sure if the https should be matched or not)
Client#fetchInvite uses that pattern to resolve the invite code, so we need something that matches event's link too
but if you wanna fetch an event shouldn't there be a sort of Client#fetchEvent?
clicking an event link does make you join the server, so I guess you can leave the invites pattern unchanged, but that method could be interesting if there is an endpoint for that (not sure, haven't really looked at the documentation properly)
actually, since you wanna capture the event ID and not the invite id, lemme update that comment
fwiw they also use discord.com/events/snowflake/snowflake
android client share does at least, and I'm not entirely sure
one of them is obviously the event ID
an example if it helps: https://discord.com/events/613425648685547541/908867166378553345
oh guild ID and event ID
on iOS I get missing permissions 
oops sorry for all the confusion, I got confused by the guild_scheduled_event_id field in https://discord.com/developers/docs/resources/invite#get-invite-query-string-params and thought we need to somehow resolve the invite link to a code for Client#fetchInvite to work.
We don't, the invite code is of the channel and that query is just for fetching event data if there is one in the channel
Now, the issue is that how to add a way to let users pass an event id to Client#fetchInvite without a breaking change, because it only takes invite resolvable as argument
well make it a second arg
but it's really annoying that you cannot resolve an event from an invite, maybe we could add the method and warn users that it would make 2 api calls?
that's gonna be controversial though since every other method in djs uses 1 unless given certain options
btw this link only works if you're on the guild, it doesn't work as an invite
that's weird
anyways, I just wanted to point it out because I've seen that form a few times
honestly not sure what to do with it
add an options object (since thats how we do optional args) with eventId
yup, that's what I decided too. Had to go with ClientFetchInviteOptions because FetchInviteOptions is taken. Could change that to FetchGuildInviteOptions in v14 đ
#archive-library-discussion message
Anyone got any suggestions for what i did wrong with testing here?
Forgive me if this isn't the right place to ask, but there's a fix for an upstream CVE that can now be pulled into @discordjs/node-pre-gyp: https://github.com/discordjs/node-pre-gyp/issues/5. Is this the right place to draw attention to this?
Yes, Ill be handling that in a few days time
Thank you for figuring that chain of deps out and making it to the source to get it fixed đ
Ok cool, and then @discordjs/opus will also need to be updated downstream. Thanks.
Lol i've been chasing it all the way down from the top.
also prism-media will need to start referencing whatever updated version of @discordjs/opus that integrates the fix but i'll bug them about it once that happens
desktop has a copy link button too
that was not the point. the point is that the link that is copied on android is different than the one on the other platforms
Has there been chat about creating a general .send() method on interactions that will send a message no matter if a reply was already sent (by calling .followUp()) or deferred (by calling .editReply())?
Apparently I was the only one who disliked that but the issue was closed, so I'm not sure what that means
Usually djs doesn't like utility methods that have other workarounds iirc, but it's a matter of opening a PR and seeing the feedback ig
Yeah it's an abstraction that is misleading
Crawl never really agreed to it, looks like it was summarised by my comment
None of the reactions on the initial post are from maintainers
Crawl did disagree to my comment, along with 6 other people
not sure why
but yeah I assumed it wasn't something ppl wanted
Usually djs doesn't like utility methods that have other workarounds iirc, but it's a matter of opening a PR and seeing the feedback ig
I've got a question regarding this since it's true to my knowledge: why does the lib includeFormatters? It simply exports some functions from builders but they're not used in the code whatsoever. Plus it adds1211 dependencies to the main lib
Hi @dawn merlin - thank you for letting me know about deprecated usage of ThreadMemberManager#fetch() <:
Looking at it closely, how come the second parameter is an object and not the first? If one wanted to fetch all members in a thread but not cache them, the method would have to be called as fetch(undefined, { cache: false }). Why not fetch({ cache: false })? I may have missed something x:
Mainly because if the first was an object, it would be a breaking change, since Snowflake would now be an object
Sorry, I don't follow. Before this commit, there was no Snowflake type?
oh sorry it was a boolean before
Ya! Exactly haha
So imo, I thought it would be better if a boolean was passed, it would be internally converted to { member: undefined, cache: boolean, force: false }
yeah I think that's what it's doing
The member to fetch. If
undefined, all members
- in the thread are fetched, and will be cached based on
options.cache. If boolean, this serves- the purpose of
options.cache.
So ig maybe a deprecation warning isn't needed
You're willing to keep the boolean property?
That does look like it'll also solve the issue
So I guess, either make a change to keep the boolean property, or convert the first parameter into an object shrugs
well for v14 just an object but to prevent breaking changes im pretty sure it needs to be a union
Ya
honestly if you don't mind it can probably be an addendum to your PR, but if you'd rather not I can make a PR
Would you pretty please mind making one <3
for sure (as in I wouldn't mind)
(:
is there a way to destructure and have a named parameter on a function? ie:
function foo(options { a, b })
for the same parameter? i don't think so
but you could just destructure out afterwards since you'd need to check for the boolean first
yeahhhh, I also have to deal with default values as well but I think thats the only way
i think the default value should be fine, since it would only trigger if neither the object nor the boolean were given
oh wait I just realized you can get the first argument via arguments[0]
this will be changed with a breaking change in v14, right
yeah
We never really cared about dep count
Itâs a metric that is rather bad to go by. You obviously shouldnât add all kinds of junk, but at some point it gets rather silly
I agree in some cases but adding 11 deps just so people can import formatters from discord.js and not builders is rather strange imo
especially since in v13 dev a bunch of old methods that weren't used in the codebase got removed as well
just wondering what benefit having Formatters in the lib gives over importing djs builders instead?
iirc
/**
* @param {SomeType} options
*/
function foo({ a, b, ...options }) {
}```
*more of a js question but you asked it in here so*
in that case options will not have the a and b fields
the best you can get is ```ts
function foo(options) {
const { a, b } = options;
}
i mean yes but thats just kind of silly IMO, at least for making a function in djs
@copper laurel ban
what
There was a nitro scam someone deleted it
@opaque vessel looks like I need to improve those type guards đ
Is this regarding issue #7001? o,o
Yeah
Sweeping the channel manager isn't actually supported so... dunno if you want to do that shrugs
Hmm it isnât? I thought sweeping any cache was valid
Ik extending caches isnât supported
https://discord.js.org/#/docs/main/main/typedef/ClientOptions
The sole warning block on that page says so, right? As far as I know, that's the only way to sweep channels out
oh yeah I'm just being dumb, I literally said extending isn't supported, but thats the only way to change the sweep settings anyways.
I could've sworn it throws if you do that, so im not sure how the person in 7001 got around that
oh it just emits a warning...
#7002 in discordjs/discord.js by That-Guy977 opened <t:1637212129:R> (review required)
fix(Util): fix sorting for GuildChannels
đ„ npm i That-Guy977/discord.js#main
could i request for someone to check if putting those changes in breaks Util in the same way mine did?
#7001 in discordjs/discord.js by ElectrifyPro closed <t:1637206940:R>
Interaction.reply() with the fetchReply option returns a message object with no Message prototype
For CommandInteractionOptionResolver#getChannel, where does the Option.channel come from? Discord does not list this as a valid property from Application Command Interaction Data Option.
From what I can see, minimal transforming is done, but I've only looked at the AutocompleteInteraction#transformOption
Ah wait. That's coming from resolved. However, I don't think resolved is properly being passed to that properly. I've been looking at AutocompleteInteraction#constructor at https://github.com/discordjs/discord.js/blob/main/src/structures/AutocompleteInteraction.js#L45
and the signature for transformOption only has 1 param which does not include the resolved
Im not sure what you think the problem is here?
I got really confused because the signature didn't have a resolved param, but it will still being passed anyways. Type safety is the issue
The autocomplete interaction doesn't, so it is useless here
But autocomplete is only for string types anyway
Its a JS library there is no type safety lmao
This is the full one
Trying to fix that 
So yeah, it probably shouldnt pass resolved in the autocomplete interaction
That was my problem because my brain is melting trying to make things type safe
sorry for confusion
Documentation suggestion for @dusk loom:
<:_:874569322742308864> Interaction#type
The interaction's type
you mean this?
but that does exactly the same as the typeguards, except without type safety. If that's not it then I'm not sure what you're looking for
determining if it's a select menu, button, command or context menu requires 2 checks, which are done by the typeguards, so why not just use those?
the only alternative to the typeguards is doing the checks they run yourself, which is less clean imo. There are all sorts of typeguards both for specific interaction types and more generalist ones so idk why you can't just use those
and by that I mean isApplicationCommand and isCommand for example
Yeah I really don't understand this question. It's the "how do I do <thing> without doing <correct existing way to do thing>"
What's wrong with the methods
- public on<K extends keyof ClientEvents>(event: K, listener: (...args: ClientEvents[K]) => Awaitable<void>): this;
+ public on<K extends keyof ClientEvents>(event: K, listener: (...args: ClientEvents[K]) => Awaitable<unknown>): this;
```Do you think this would be possible?
Makes sense to me, return type shouldnât matter here.
cc @dawn merlin
I'm not sure what this would be used for đ , the return type is intentionally void because you don't return values from a client event, you only consume what's given to you
If you make a event handler it's nice to be able to do early returns when calling methods that don't return void
Yeah in the end it doesnât really matter what the listener returns, so Iâd say any would be fine too
export function createEvent<T extends keyof ClientEvents>(
cb: (
...args: [...args: ClientEvents[T], prisma: PrismaClient]
) => Awaitable<void>
) {
return cb
}
export default createEvent<"messageCreate">(async (message, prisma) => {
if (x) {
return message.channel.send(...) // Promise<Message> not assignable to void
}
})
```If you do change to unknown in your handler, you can't dynamically pass it to client.on
just return on the line after the send
Yeah but that makes the code unnecessarily more bulky when it doesnât make a difference if you return a message
any is fine too
return void await x
return void x
The ending type of the function doesnât matter though. unknown/any feels more representative of the node typings (this is just a better typed alias of EventEmitter.on)
yeah, i was just suggesting an alternative soloution to their problem, at least until if/when its changed
You'll just have to return after the method executes
if you make the return type a promise of unknown it's misleading because it implies that return value is used somewhere else which it isn't
What about any? Or a type alias that represents something with the value of any
It just adds extra noise atm, especially with
padding-line-between-statements:
[error, { blankLine: "always", prev: "*", next: "return" }]
```I get it's my issue but the return type doesn't matter
This applies to anything non-void
I need more context on what this means
eslint rule to always add a new line before a return statement (separation of concerns preference)
ig disable it then? lol
What about passing a type parameter to specify the return type, or will that not work
it would but I don't really see what justifies it?
Shenanigans
I think it would be nice to support as many JS patterns as possible, generic return type would be fine too
I just donât get the issue with having it return any
For semantic reasons, but generic return type fixes that
What would that generic type look like
public on<TReturn = void, K extends keyof ClientEvents>(event: K, listener: (...args: ClientEvents[K]) => Awaitable<TReturn>): this;
TReturn should probably come first so you can specify it easily
True, edited
Why not default it to any?
My issue is that it enables code to be written with unclear intentions, it's unclear if the return value is consumed by the client or not. Also from a documentation standpoint when the return type is Promise<unknown> or Promise<any> it seems like you need to return something, and may confuse people.
IMO, it's just confusing to add a return type of any/unknown as users may think that a value should be returned or that it can be used somewhere
^
I mean isn't Awaitable confusing for the exact same reason?
I read it as oh I can await this and it might return something
No awaitable just means it can be await'd that doesn't imply anything is returning a value
Could endlessly discuss those being different, anyway just something I faced today, I'll stick to ts-ignore
or just put return on another line
Why is that confusing? Any is literally any type, including void. Something that can return any type to me means that it doesnât matter what it returns, not that you have to return something because the return type would be more specific if that was the case
It's confusing because any could be a value
This is not an option due to the eslint rule they showed above
But it could also be void, and if the return value mattered it wouldnât be any nor unknown
the return value doesn't matter because it's never used, when I see a return type of any I honestly assume something needs to be returned
You can't tho..
I don't see a reason why it should be any/unknown too.
I mean, yeah, in a command handler having a return type of any would be more comfortable but also lead to unexpected issues, like we may return a string because we think that it'll be sent as a reply for example, so it's always a good practice to put your return statements outside any expression.
Also iirc the return type of that function in the built-in EventEmitter is void...
Thatâs a wrong assumption then because if something had to be return, that type would not be any
Doesn't matter it's still not as clear as void
void is always going to be more explicit and less of a gray area
built-in EventEmitter is void
void, not Awaitable<void>, if djs uses it, it's not following standards anyway
Iirc it was changed to Awaitable because of an eslint rule that didn't allow the use of an async function in that case.
It's however really different from any/unknown
it doesn't matter it's a callback, Promise<void> | void are void once resolved
eslint didn't allow the use of async functions
ts doesn't allow me to return methods early while it's still technically valid, just like you're able to await
I honestly see both cases as supporting JS patterns, I do get where you're coming from
Awaitable isn't needed, it's just an alias from Promise<T> | T
You can also return void x and have it all in one line
Just a bit upsetting as most ts features that are being added are to be able to type JS patterns
Yea I know I can work around it
honestly imo returning a value for a method that's supposed to return void isn't a great pattern anyways
đ€·ââïž
speaking of TS, they themselves don't even recommend that pattern: https://www.typescriptlang.org/docs/handbook/declaration-files/do-s-and-don-ts.html#return-types-of-callbacks
its technically not correct, yes
since whatever you return, if its fails, is unhandled
so what we do is fine and correct
Correct me if im wrong about this behavior but shouldn't this always be a guildmember because of the typeguard?
try inCachedGuild instead of inGuild
Yeah that did it, forgot about that one đ
inGuild() there refers to just a guild, whether it be cached or not yeah
Is there a set in stone idea for what djs-modules/ws would be responsible for? Is it a general powerful websocket module that's capable at handling any url type, or one that's specific to discord only and can do all of the stuff that the current djs one can do?
Are there any plans to move util functions to their own package like a @discordjs/util of sorts? Some of these functions are quite useful and people don't always need the full library to work with them
like?
SnowflakeUtil for example
Thatâs the one that sparked this idea, could look into the others too
SnowflakeUtil is likely superseded by @sapphire/snowflake, which @discordjs/rest uses
Yeah snowflake Util isnât super useful honestly
is there a reason Shard#eval can't have a context passed into it? (like why wasnt that implemented)
Ah I didnât know about that sapphire package, will take a look ty
I'd say that's an oversight that could easily be implemented (just not the "must be a function" part, since that's breaking)
You can work around this by passing (${function})(this, ${JSON.stringify(context)}) as script to the method.
ig so but i added it into the src of the pkg should i pr it?
Gladly
Can we get a way to specify the type of the components in an action row, through something like new MessageActionRow<"SELECT_MENU">() like was done for collectors?
cc @dawn merlin đ
Iâm guessing this is just for enforcing that everything in the row is the same type?
yeah since you can't really mix component types and it would make doing this easier
you might be able to mix component types in the future though, so that type could support multiple component types
Even if this was implemented wouldnât you still have to cast?
Because the array of rows isnât guaranteed to have the same component types
I'm talking about individual rows through
so in that case I wouldn't if I just created the action row with the type like we do with collectors
But if you access the the row by index how it know the type? Because the array of rows is a less specific type
idk about you but I never access a message's rows, I just store the row in a variable and modify it later on
and that's the use case I'm talking about, since you can't get more specific when accessing a message's components array (and perhaps you shouldn't)
what if the first component you add to a messageactionrow changes the class or something
But isnât that what you did in that screenshot?
oh wait no that wouldn't work
in that screenshot I have a row constant that was created by me, not retrieved from a message
like this
and the idea was to do this
So addcomps would only take select menu components?
could you maybe add a typeguard based on the type like how you do it with Interaction
yeah, and then the components array would be an array of select menus
Ok I see
that wouldn't make sense here
...yeah.
i shouldn't be here
No worries, it happens
This is what I did:
declare const selectMenuRow: MessageActionRow<MessageSelectMenu>;
// @ts-expect-error
selectMenuRow.addComponents(new MessageButton());
assertType<MessageSelectMenu[]>(selectMenuRow.components);
yeah sounds good
make sure to also test with spliceComponents and setComponents (and maybe resetting the components array ?)
those both seem to work, I'm assuming by reset you mean setting the components to [] and splice should only take components of the correct type
I meant re-setting, aka doing row.components = [new MessageButton()] which should error
hmm idk if I can type check that without creating a setter in the typings, shouldn't that be readonly anyways, because setComponents should be used instead
well yeah it should be used but there's nothing stopping you from doing that either. I thought that if the type of components is set to MessageSelectMenu[] and you try to overwrite it with a MessageButton[] it would error out wouldn't it?
oh wait I'm dumb, yeah it's doable
This works as expected
// @ts-expect-error
selectMenuRow.components = [new MessageButton()];
ready for the PR? I'd be glad to test it
wait can you send stickers with interaction.reply?
i didn't find it on the api docs but the typings for the method tells you you can since it extends BaseMessageOptions
Yeah that seems to be an issue on the typings. You cannot add stickers with interactions and the typings for editReply seem to be correct. Feel free to PR if you know how to fix, otherwise I can look into it
you do it đ

#7012 in discordjs/discord.js by ImRodry opened <t:1637436949:R> (review required)
types(WebhookMessageOptions): disallow stickers
đ„ npm i ImRodry/discord.js#types-webhook-stickers
@void rivet ^^
đ
In what scenarios can Invite#uses not be null? I already fetched an invite and I didn't get that data
I'd assume when obtained through Client#fetchInvite.
that's what I did though and didn't get the uses, same thing when looking at the raw data from the API
the uses property appears in an "invite metadata object" in the discord docs that is supposed to be extra info that may be present, but they don't mention when that can be present
it's mentioned at https://discord.com/developers/docs/resources/guild#get-guild-invites
oh so we only get that data when fetching the invite on the guild? 
I think the Invite class could use some improvements on its documentation to specify these quirks
the docs are open source ÂŻ_(ă)_/ÂŻ
I'll give it a shot with a PR, let's see how that goes
Audit log documentation needs some updating as well, seeing that the description of <GuildAuditLogsEntry> is literally just "Audit logs entry."
I just thought of this, but why not use a type guard to prevent casting here?
I feel like a typeguard would make less sense since you're the one constructing your action row, you usually don't receive it without knowing what it will hold
you could add the typeguard as well to make it work when you receive it too ig
Hmm
Why are API objects not exapanded upon? For instance i don't see why we couldn't provide support for APIMessage#edit() (you could get an api message when you followup an interaction)
I don't see the purpose of just dumping the api obj on them when we're supposed to be wrapping around said api object
Api objects are usually returned when youâre client isnât a bot in the guild. The api* objects are just the raw data returned from the api. The reason we donât wrap them in a class is because the cache cannot be properly updated because it doesnât receive guild events. In fact in the case of the message, you canât edit a message purely based on the message recieved it needs to be done via the interaction (since the bot isnât present in the guild)
I see, makes sense.
You can edit any message as long as you have its id and its channel id using the manager
But yeah if itâs an interaction you should be using the interaction methods instead
discord.js\src\util\Util.js:413
if (typeof data !== 'string') throw new error(errorMessage);```
Couldn't the data be tried to convert to a string first?
interaction.reply(client.ws.ping) will crash the process because it is a number
this used to be done, but was changed in v13 to allow for more strict typings and less [object Object] strings. You can easily convert that to a string by wrapping it around template strings
oh yeah I remember this working in previous versions
Are we still doing consistency with the api with types?
message type 20 is listed as CHAT_INPUT_COMMAND in the api docs, but it's APPLICATION_COMMAND in djs, which i guess could be somewhat confusing since CONTEXT_MENU_COMMAND is a seperate type, type 23
when that was introduced the discord docs called it APPLICATION_COMMAND
something for v14
didn't see any issue/pr for it
i guess this would need some type updates, which i don't know how to do, so... unless someone's free to do it, i'll make an issue in a bit
all you gotta do is change the value in constants
and then change the typings accordingly
but it's a semver major so ÂŻ_(ă)_/ÂŻ
which i don't know how to do lol
eh it could be left for later
go ahead
also for reference, this is the PR that changed it: https://github.com/discord/discord-api-docs/pull/3651
client.users.cache.size has only ever been cached users
Never ever has this property been populated with all users in all your bots guilds
Fetching all members is absolutely not recommended at all
Please go back to support, this is not a library discussion issue
@copper laurel
ty
Hello
About the presence update
I think game activity presence should be separated
No idea what you are asking
to know if there is a game u a member is playing
coz when i use presenceupdate
while playing a game then i have set a custom status or some other activity like listening to spotfy, it will give my undefined or the latest activity for that
what do you mean? what are you suggesting? could you give a better understandable example?
I have this bot that gives role when a member is playing then remove the role when he is not, then when he have set a custom status then removed it, it will remove the playing role coz, i get an undefined precense activity
but he is still playing
So the playing role shouldn't get removed to him
so what do you suggest we do?
i don't know if the issue is from the presence update or my code
i guess your code
members can have multiple activities, right? your code probably wasn't made to deal with that
but would it be possible to retain the array no. from the oldpresence to newpresence
you do know that you can just see what an activity is, and then check any other one that is present? it doesn't end on [0] or [1]
you have multiple tools in javascript to do that
you can find it by it's type, which for you would be playing
yeah but the problem is i am comparing same array number from new and old but the new don't now have that last array numbers so it gave me undefined
then don't do that.
Okay okay i'll be trying ur suggestion
yeah it's not really an issue with the library, it is your code
how you dealt with presenceUpdate
i think it's my code
I just compre new from old
Thanks @void rivet I now have an idea
Why does MessageEmbed has .video property if you can not embed a video?
received embeds can have them, you can just not send them from bots
hence why there is access to it but no means to set it
Is there a specific reason to why the Client constructor doesn't default to no intents?
Like, this just seems like unnecessary:
const client = new Client({
intents: []
})
I'd much rather just do this:
const client = new Client()
Because intents are mandatory
So basically because people NEED to know they aren't enabling any intents?
Because people NEED to provide intents to connect*
EDIT: They need to specify that they either want no intents or some intents so users know about them
You don't need any intents to run the bot, though?
I don't know if Discord lets you connect if you specify intents 0, but our lib does require at least GUILDS intent to work most of the time (iirc with interactions that's less the case)
The fine line here is omitting the intents and providing no intents. You should explicitly specify your intents and discord.js shouldn't shortcut it
Yeah, 0 will connect
TIL (and it makes sense I suppose)
for the sake of explicity, we make intents mandatory
Alright, thanks guys.
This is probably better for the majority, as they wouldn't understand why is working, before realizing they were missing intents.
Glad to clear up, that it was done for a reason.
isnt it supposed to be true by the default?
More of a #djs-help-v14 question but since you're providing allowedMentions in your client thats what we use when it's missing from your reply calls
Still, they didnât specify repliedUser so shouldnât it mention them?
thats more of an API question but no, it shouldn't, because if you specify allowed_mentions at all Discord just disables it by default
Ah I see
That's some weird behavior on Discord's end.
Probs an API bug then
I think if you do not send allowed_mentions, all mentions are parsed (and replied user is true), but if you specify it, replied user defaults to false.
I wouldn't say its an API bug but an annoyance personally
so the API should see which values were sent, and use the defaults for the other ones instead of reading them as false when set to undefined
but probably not worth the bug report
@outer raven hey sorry to bother you, i fcked up my rebase again đŹ i'm sorry, can you help me ? I still have no idea how to fix those đ
thanks
https://github.com/discordjs/discord.js/pull/6647/commits
Sorry bro just shut down for the day, I can only do it tomorrow but I can help you do it in dms
no it's intentionally weird
That just sounds like bad code tbh but aight
The api has a lot of âintentionally weirdâ things
well it was discussed with multiple staff back then
i dont know if this is the right place to ask but do we know if we will be able to insert any of the current message components into the new modal feature coming?
modal feature..?
at launch only text input; select menus will be added later but not buttons, also ddevs is the correct place to ask, not here
https://devsnek.notion.site/Modal-aka-Form-Interactions-e839b3dd8c214eb08f950764a8328e36 announced at the ddevs event
thanks, i tried finding the correct place to ask in their server but was just as confused
api-questions would be the best for now
so the default of repliedUser in the docs should be false, right?
nope
if you pass no allowedMentions then the default is true
only if you do pass them you overwrite that default
ah i see
its actually marked as default false in discord's docs (which was confirmed in the discussion with staff), because it is in the object
it doesnt exist at all if the object doesn't exist
and d.js doesnt seem to modify it so... shouldnt it be the same as Discord and say false?
allowed mentions itself is optional too and that missing defaults too "all mentions"
At least that's my explanation
Should default to Discordâs default but they should enable repliedUser since thatâs the default on the client
the client doesnt send allowed mentions by default
When you click reply on a message, the replied user is pinged by default
Thatâs what Iâm saying
Its really not as complicated as this discussion would suggest
allowed_mentions not provided - all mentions are enabled, including replied_user
allowed_mentions is provided - only those mentions listed are enabled, which mean replied_user only if provided
Theres no reason to think of it as some separate default, its just an allowed_mentions property
Discussing the fact that the desktop client has a toggle in a default state is irrelevant, this is the bot API, not a desktop client
This seems more like support than a discussion for this channel
still it would be nice for them to be consistent, and if you provide allowed_mentions and only pass an array of users, all roles will still be mentioned, so your argument doesn't make much sense
I wish this was the case for interactions as well
Just tried and I'm not able to replicate this. Provided users array with no parse, did not mention roles
At least, not in djs
Thought this worked before but yeah you're right. That's quite annoying but I can see it's not something looking to be improved on
I dunno, I think the design is fine. parse is mutually exclusive to the arrays. You can:
- parse all users and/or roles and/or everyone
- array of users and parse all roles
- array of roles and parse all users
- array of roles/users
And add replied_user to any of the above
yeah but if you don't specify any of those values, they should use the default that is used when the object isn't passed at all
so allowedMentions with a roles array and nothing else, repliedUser would be true for example
because I think that's what the average user would assume would happen
and the current behavior is also inconsistent with the docs, which say repliedUser defaults to true
Eh, I disagree that they would or should assume it, thats their fault for making assumptions
I do agree on the docs though, its just annoying to accurate represent both
You overwrite the default, so the default doesn't apply anymore
I don't understand how that concept is so hard to grasp
I dont think it should be marked as defaulting to true though, since doesnt that imply the code sets it to true if not provided?
you're not overwriting the default if you don't specify it
Yes you do
You're making the same mistake I originally called out
We don't merge with our defaults
If you pass ANYTHING into allowedMentions it will overwrite our default
If you change allowed_mentions you have overriden the default
There are no sublevels
lets say you do:
allowedMentions: { parse: ['users'] } }
now that means our default which includes repliedUser will be overwritten with JUST what is above
so if you wanted repliedUser to still be true, you have to manually include it
So having said that, shouldnt the docs specify the default as none rather than true, because we do NOT default that property if not provided
I cant find where we do
but it would be really easy to apply these defaults by deconstructing the object. I was trying to test it but idk where this is parsed if it is at all
But we dont want to because Discord doesnt
we can do things that Discord doesn't tho
I cant find anywhere that we actually set a default for allowedMentions or repliedUser
yeah me neither
I know we can, but if you refer to the first half of that sentence I also said we dont want to
aight ig ÂŻ_(ă)_/ÂŻ
Ah, its on the message options for it
Well the problem with that is that it probably used to be the behaviour when that PR was made
and it was documented as a discord default
Which is something we indeed usually don't do
Probably yeah
Where as now, at no point do we apply a function default parameter for that, so it should probably have the default removed from the JSdoc too
Because I do read that as implying that if repliedUser is not supplied in allowedMentions, discord.js sets it to true
(and we dont)
but we could, since it's been documented like that
Well in case I havent been clear, I do not think we should have a different default behaviour to Discord
I believe it wouldn't be the first time we fix little quirks of the discord API to make them more logical
of course this "logical" is very subjective, but I think it's what the users would assume the default behavior to be
default being not passing the parameter, regardless of the object being passed
because whether you pass allowedMentions or not, the properties you don't specify are set to undefined, which should always be replaced by a default value
Its a bit scary defaulting to discords defaults
Since they could change, and preferably we want to too, but thatd require a new major
well in this case we'd be defaulting to a default that isn't always used and if it does change we can handle that in a semver major, without the behavior simply changing without any version bumps (although this is unusual, discord usually doesn't ship a lot of breaking changes without version bumps)
so if we set defaults on the library's side, we can change those defaults without relying on what Discord does, and follow semver properly
@visual hornet have you tried moving the require to below module.exports?
At the very bottom
which require? the GuildChannel one i added in Util?
Yeah
yeah that.. solved it...
what changed here?
CommonJS considers a module "loaded" when at least one export or when module.exports is defined, so by moving the import to the bottom, you're requiring that file from a loaded module, so when it's required back, it works as intended
hm i see it's also used in TextBasedChannel with a comment, I'll copy that comment and commit that
thanks
Is there any reason why UserManager#send doesn't exist so you can send a message to a user without fetching them first?
I noticed MessageManager#delete where you can delete a message without fetching it so I feel like UserManager#send would also be rly useful
Can probably be done
how will you get the dm channel?
That's not relevant, when one is created it'll return the existing item
let me rephrase: how will you achieve that in a single request
Don't believe you can
Oh, I didn't realize that :( nvm
I guess the current User#send method already does 2 requests if the dm channel isn't cached
Yea that's right, so you'll essentially be doing nothing under-the-hood, just refactoring
Anyway on that topic, I suppose you can move .createDM() and .deleteDM() there

there are a lot of methods that could be moved to managers honestly
just like the message manager has
I tried to do some of those at some point but there were just too many
so that'd be a good way to start
I feel like there aren't too many methods that couldn't be moved to managers
Just out of curiosity, whatâs blocking the GuildScheduledEvent PR and the release of 13.4?
Every time you ask the it gets delayed by two weeks
I really hope thatâs not the case cuz I think a lot of people, including me, could use it on a dev release at least :/
But itâs the first time I ask about this PR
I donât make the rules 
Yeah ik, just saying it would be nice
We need a few bugfixes in, at very least, and to start with
@outer raven are you looking for to do a PR?
I had one in mind but it takes some time, what you thinking of?
Adapt the new component stuff for builders
Are those reviews on the PR? I didnât see any
Last time I touched builders it was painful cuz of the validation and all that
I have no clue how that works tbf
What I was thinking was the PR to add methods to managers
CC @burnt cradle
Which methods?
You might want to wait on any major builders prs until after the validation lib gets changed so you won't have to rewrite ur pr halfway thru
This is tru
Also adding the new components would be bigger than you think cuz there's currently no component infrastructure so you'd have to write it completely from scratch
A lot of methods that are currently handled by classes and not in managers, similarly to the guildmember and message managers. I donât know which can be moved which is why I gotta look into it better, but there were some ideas above about dms for example
Not everything floats on the same PRs, there are more
rn there's a critical bugfix PR pending for review, among a few more
But on djs?
I saw the dapi types pr was merged which I thought was the only blocker
Yes, Rodry. Check the list of pull requests, and you'll see
I can't find anything that could be related to scheduled events, can you give me the PR id?
It's not related to scheduled events
-types is handled by me, and it has a much faster (ok ish) release cycle compared to d.js 
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
oh I know -types is different but I'm not talking about releases anymore, just asking why it wasn't merged into main so we can use it in a dev release. It's a pretty big change that has been out on the API for a while now and I think a lot of people, including myself, are looking to use it
Let's see..
CI not passing
Reviews still pending
Decisions still to be made
So the PR is still WIP?
CI isn't passing because -types wasn't released simply, but I thought everything else was good since no other changes were requested?
Donât these blocks contradict each other?
no
if you go camel it overrides snake, that's all that second one says, right?
first one says that you can use snake_case, the second that if you pass camelCase, it overrides snake_case
Ah I see
@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
ok
@outer raven can you explain what the event status type checking would look like?
something like this (not tested, just in theory)
class GuildScheduledEvent<Status extends GuildScheduledEventStatus = GuildScheduledEventStatus> {
public status: Status;
public setStatus(status: Status extends 'SCHEDULED' ? 'ACTIVE' | 'CANCELLED' : Status extends 'ACTIVE' ? 'COMPLETED' : never)
}
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
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
embeds cannot be suppressed in messageCreate which is the only situation where this would be viable
and yeah you'd need to check for regexes and then listen for the messageUpdate event
Are you sure you cannot create a message with the flag pre-set? And I'm talking bot made not client made
let me test that
Ideally we wouldn't parse contents, especially with the upcoming message intent
what about the intent? You'd need to have it to even receive the message to begin with right?
Well yeah except for messages pinging the bot/dming the bot
yeah so you'd always have access to the content if you're doing this
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
no, that's not how the intent works...you still know that a message is sent, just not everything about it
pretty sure they said you'd get the content if you were mentioned, dmed, otherwise what would be the point of receiving the message to begin with
you do get everything in those cases
well then in other cases you don't get the message at all do you
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
well theoretically if you can't enable the intent you won't be able to pass it in your client constructor right
that's not what I'm saying, the "intent" (because its starting as privileged), may not be toggleable via the identify payload
I think they would've mentioned it by now if that was the case
there's nothing documented about it at all, wdym
you can already apply so I'd assume all the changes are public by now
the flags are public, no new intents have bee documented
and the flags aren't documented either
I haven't seen that, but if they said that then yes, you'd need to check that rodry
yes they have
if u meant the application flags
my pr got merged 26d ago
oh, yeah...I forgot that was already merged ~~used to things like that taking 4 months to get merged
~~
lol
wait then what's gonna happen to GUILD_MESSAGES and DIRECT_MESSAGES?
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
yeah, those control the events
oh I see
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
so bots that don't need to be whitelisted will need to add that new intent anyway?
bots in <100 servers? yeah i think so
and yes, that'll be a breaking change
oh wonderful isn't it
out of curiosity, why is are most toJSON methods typed as Guild#toJSON()unknown?
Because there are no interfaces written for those since they are literally just the classâs properties in a json format. This will change when the issue about raw data is addressed so it probably doesnât really matter
@tacit crypt whatâs the veredict on this https://github.com/discordjs/discord.js/pull/6493#discussion_r757791139 ? Can we please go back to specifying location only instead of the metadata object?
My answer is no, idk about the others thoughts
Why though? Isnât it much more complicated to provide two objects instead of one? The library has recently been going in the direction of having everything in one object even (role creation and threads are two good examples of that)
And what do we do in the event Discord adds 4 more eventMetadata fields, and it happens that some collide? 
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
This is being fixed in a PR
why would they add a property to the metadata object with the same name as a property in the main object? And why was this not a concern when adding threads?
#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
Ah, my bad forgot i should've checked the pull requests / issues
Lol, it hasnât been merged yet no worries
Why? https://media.discordapp.net/attachments/106126169627181056/231117241892995072/unknown.png
Jokes aside, who knows why, but the possibility is there. I must've missed it for threads then?
Also, that's just my opinion, and as I said, if the other Core Maintainers say otherwise then thats how it'll be done 
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?
It's..not.. the performance part is just what the meme says
oh I didn't know that was a meme 
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
I'd say if it has use cases then it's valid
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
Is there currently anything in the Discord API for events?
#6493 in discordjs/discord.js by iShibi opened <t:1629573546:R> (changes requested)
feat: add support for GuildScheduledEvent
đ„ npm i iShibi/discord.js#feat-guild-event
@grand eagle ^^
kk thanks, hopefully they will include this in the release docs for the next version
the api docs are already live, thats the djs PR
ah okay, sounds good. Just meant that I hope they mention when the PR is closed and integrated
A release will probably follow but you can always subscribe to the PR
Hi are there any way to cross server / hosting sharding?
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
@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
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?
yeah you can edit attachments, the docs state that MessageOptions#attachments are the attachments to keep and #files are the attachments to add
Oh. I see, thanks.
yeah I don't see this being fixed without reverting the entire PR. This is why we never used discord-api-types, because the differences aren't only in casing, but also in actual types
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
We can just adjust the equals method why would the PR need to be reverted?
because this issue appears in many many other places, this just so happens to be the one I found but anything that involves types (numeric and string) will have this issue, and possibly others
The plan is to remove string types in the future and only allow numbers
In my ticket
which?
The original one talking about using camel cased dapi types
can you /github it
#6958 in discordjs/discord.js by suneettipirneni opened <t:1636305505:R>
Remove *Data types from Discord.js types
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
But I can summarize by this:
- Having multiple data types to represent one property is not a good approach at all
- The data should be as close as possible to the api payload, making the naming conventions completely separate from the djs implementation.
If it's breaking a lot of things then it'll probably have to be reverted
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
in my entire code the applicationcommand types were the only ones that broke but there could be other scenarios where it does
Enums are just as readable as strings, and they correspond properly to the true api value. "Handy" for the users doesn't mean it's as maintainable for us. I think the requirement of one extra import is a small price to pay for that.
enums are just as readable but my concern is the extra import where it can simply be avoided. Maintainability here isn't an issue at all because you can convert these with only one line and it's very easy to understand
in fact I don't understand why these were marked as deprecated if nothing was noted on the docs
Can you show me the code snipped that causes this error?
that function returns ChatInputApplicationData
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
#6576 in discordjs/discord.js by kylerchin opened <t:1630476545:R> (changes requested)
Creates the waitGuildTimeout amount client option
đ„ npm i kylerchin/discord.js#main
yeah but it's not really dealing with the core problem
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 
Probably once we build out @discordjs/ws and integrate it into the lib
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
Was on the todo list in march this year
if you can't wait for it feel free to PR
#7053 in discordjs/discord.js by ImRodry opened <t:1638287834:R>
Add Message#awaitEmbeds method to get URL embeds in a message
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
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?
(Or an array with the already existing embeds for that matter)
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)
There's no guarantee that it will load in x seconds (it's the halting problem). But if it doesn't resolve in x seconds should it reject or spit out an empty array? I'd say spit out an empty array, because chances are if the client can't resolve them then the embeds don't actually exist, hence an empty array.
yeah there can be an option and a default, but usually URL embeds resolve in a few seconds
hello, may i bump this PR please? it's been stale for a while now and there is already 1 approval https://github.com/discordjs/discord.js/pull/6647
@copper laurel did you say you dropped your builders buttons pr?
Kinda. I wanted to redesign it and haven't had time. Not sure it even needs to be in builders tbh
Components could go into builders, sure
Djs has a builder for them tho whatâs the point
Migrating and consolidating builders in one place I guess
Pls donât remove the existing builders from djs though 
But that's the whole point of builders
lol
They don't need to be in djs at all
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
Why canât we keep the current ones like this though?
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
It looks like no one cares about builders rn tho
Well with djs classes you can just pass the class itself
Conceptually I'd like it if djs could accept the builder class object, I agree
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

ÂŻ_(ă)_/ÂŻ
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
https://github.com/discordjs/builders/pull/53 this has been open since before the initial PR to replace ow was created and has a lot of people waiting it seems
there even was a second PR by that same guy to add autocomplete that was closed for some reason, then they opened that one
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
well nvm ig
Hi, just bumping to see where this is at?
Just out of curiosity, what versioning system does discord-api-types follow?
semver
Technically semver, practically it looks like Zerover
yeah that's what I was thinking 
When will 1.0.0 come, if ever?
Whenever Discord as a company dies and stops releasing new updates
aka not in decades
Problem with bumping 1.x, is that it'd require us to bump new majors every time Discord decides to break something
I thought they only broke stuff on api version bumps (or when a feature is experimental ofc)
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
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
that works for djs, and technically since discord hasn't changed their values it is a patch I suppose
I've rebased it
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
Sounds reasonable
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
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
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?
ah I see, but the PR won't be merged if the two events are still experimental, will it?
I think it will be because only base support is added and nothing more
gotcha
but then the creation of that manager would require a semver major
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
No it wouldn't
it can easily be made a sem minor
deprecate fetchSubscribers and make it call subscribers#fetch
voila
Unless you magically work at Discord and are giving us insider info, we don't know if those events stay or not soooo 
I don't see why they wouldn't?
not a manager but something similar to the error handler where you simply call it and pass the message and it checks if the warning was already sent and sends if not
Because it's useless for their clients? Because they don't want to keep them?
It's experimental
it's not useless for clients because the clients have to display the users
And it can just fetch a list
instead of caching them
And this is turning off topic fast
ÂŻ_(ă)_/ÂŻ
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.
For XCollector.endReason, why are max[X] options treated as [X]limit?
Shouldn't they be max[X] just for consistency with the option that triggered them? Or at least be documented?
https://github.com/discordjs/discord.js/blob/main/src/structures/MessageCollector.js#L103
https://github.com/discordjs/discord.js/blob/main/src/structures/ReactionCollector.js#L164
https://github.com/discordjs/discord.js/blob/main/src/structures/InteractionCollector.js#L189
also why doesn't endReason seem to acknowledge the time and idle end reasons
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
about https://github.com/discordjs/discord.js/pull/6957#discussion_r761979364 @tacit crypt when voice channels get messages (since that was seen in datamines) should isTextBased() return true on those?
Well...yeah... Shouldn't the check cover it tho (return 'messages' in this)?
We don't control the session id, that's on Discord, so at least I can't give you an answer to that
I was gonna make them all uniform so they check if the type is in TextBasedChannelTypes so my question was if the voice channel types would be added to that array
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
well isn't every channel gonna have messages then? Except store but that's being removed soon
Categories?
Correct
right yeah
aight ill keep the messages check
for voice, should I keep the bitrate check or use the types?
Probably bitrate?
aight ill keep that too then
@outer raven also stage channels will not have text (at launch, at least)
and forum channels
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)
why are the .toJSON() methods not documented?
like Message#toJSON() and such
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?
Probably an oversight?
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
Highly unlikely
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
@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?
when you delete the event
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
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
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 đ
@wild flax can you do a new docgen release? So we can use this bugfix https://github.com/discordjs/docgen/pull/15
I want to create a pull request and while npm test I get this err. how can I fix it?
Edit: Got it
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)?
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.
well, as you might see in the function, there's a high and a low section of the id
due to how numbers are stored, the highest number that can be reliably stored (Number.MAX_SAFE_INTEGER) is 16 digits
which is why it's been changed to BigInt as kaira mentioned
Snowflakes can't be converted to numbers, since they have a precision of 16 digits (and snowflakes typically have 18).
i see now
when you say "Snowflakes can't be converted to numbers" do you mean "number" as in number the primitive type or literally like a numerical value
number the primitive type / Number the wrapper
wait that second reason doesnt make sense, snowflakes are already a numerical value 
ah yes i see. so that's why kaira mentioned BigInt.
but even then it's still useless? how so? you don't get a timestamp from the first 22 bits of the snowflake?
that's why the function was removed?
we use bitwise arithmetic for that in SnowflakeUtil
also curious as to why the lib uses 0 as the process ID when generating snowflakes and not the actual.. process ID
but i guess it doesnt matter that much does it
Pretty sure only the date portion of the snowflake is taken into consideration for paginated endpoints
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
I mean, we should do that, gonna PR that
@lusty bolt updating on above, I created https://github.com/discordjs/discord.js/pull/7079, however, this is a semver: major update, see the PR's description.
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 đȘ
Because it's more computationally effective, and also because that's what Discord sends us
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.
You're right, wanna tie with Rodry placing the warning below?
@outer raven I'd say, feel free to PR equals to builders
oh really? Alright then I'll bundle that with the others too, didn't think it would be appropriate to be in that package tho
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
Having built a method that reports all differences between two api datas (so, builder returns), equals is NOT nice to implement
well equals just returns a boolean, not the differences
Yeah, so better have them where they're at, than implementing them everywhere else we use them at
And that
modules?
#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)
equals is not about raw data
So... you're suggesting to have @discordjs/comparers or something?
me?
Crawl, with this ^
I can do that I suppose don't know what tie means in this context though
Iâd say put comparisons and type guards into one module since theyâre both similar in scope
wouldn't that defeat the whole purpose of having typeguards?
Wdym
how do you use type guards from other packages
You import them?
but how does an imported method serve as a typeguard for another class
and some typeguards are useful even in js like the interaction ones
Itâs a function that takes a class as a parameter and tells you if itâs a certain type or not
but how can an external function cast the type of another class?
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
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
yes, that's how it works
although that particular function is not included in the pr
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
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
Yes this is what I was going for
This seems weird to me, doing comparisons on builders makes less sense than comparing the output they give. One hasnât been finalized yet while the other has
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
thing is the equals method compares embed instances too and, personally, that's what I use it for in my code
Ig my question is does builders output a instance version of embeds? (IE one that isnât a buildable state)
Oh btw about this, I looked at threadarchiveduration before making the PR and tbh I thought it made sense for it to go before since itâs explaining the next line, not really a major thing but it was a conscious decision
Ah I see thank you
I just noticed there's not one, but two Promises here in GuildAuditLogsEntry's constructor to resolve an invite. Isn't this... bad? I'm pretty sure one shouldn't be executing tasks in a constructor, right?
https://github.com/discordjs/discord.js/blob/6e57b65e99389eb8cbc8c2112281a9c1b7d3783a/src/structures/GuildAuditLogs.js#L504-L518
I'll change it then :eyes:
is there already a PR for guild banners?
Yea
for... what exactly? guild banners aren't exactly new, they've been supported at least since v11
I believe they mean animated banners
no profile per guild banners
What you're saying and what you mean are two different things :P but no
No one has made a pull request about it to Discord's documentation yet either
The API doesnât have that field either
Itâs an experiment
Itâs very much live on canary
That doesnât mean anything
Well itâs more than an experiment at this point
It's on stable as well.
Ah ok
There is a feature request to include banner for member(s): https://github.com/discord/discord-api-docs/discussions/4217 đ€·
Yeah Iâm on stable and my client has it lol
That doesnât indicate that it isnât haha
Well itâs not exclusive to the experiments tab thatâs what I meant
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
Server banners and bios are barely starting to rollout
Everyone seems to have access to them now
But yeah itâs not on the api so nothing we can do
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 returndeletedMessage.has(this) || this.channel.deletedor smthg? So you donât have to update it
will this come out soon?
