#archive-library-discussion
25085 messages · Page 20 of 26
yeah i just found the release where they added support for it as you sent that, thanks for the help guys
@tacit crypt https://github.com/discordjs/discord.js/pull/7143#issuecomment-1000914216 I know what it means, I’m saying that it will look bad for user and role mentions
The only difference will be that if your nickname is everyone, it will ping. Nothing else. Roles will use their names, users will use their usernames, members will use display names
What?
Doesn’t clean content output the mentions with their ID?
...no?
cleanContent getter calls Util.cleanContent
It has always called that method in fact
Hmm ok
Will there be no more 13.x versions?
We'll squeeze a small v13.5.0 release soon
When attachment options and modals come out?
Not sure, we don't even have an internal ETA for it (while we do for v14 👀)
If v14 happens to work out before 13.5, those changes would all just get squeezed into 14.1, right?
Or would you want to wait to put them in with v14
v14 won't happen that soon where you'd end up with the 13.5 turn into 14.1, so don't stress about that
How soon do you expect it to be though? (If you wanna share that ofc)
Ah ok i misinterpreted your note lol, mb
although if something like that were to happen, would the major update wait for the minor changes? or would said minor changes be moved onto x.1 of that new major version
At least 1
1 what?
dunno man I just review and write code
Exactly 1 semver major release away 👌🏻
If major is released before minor, then a new minor is released, otherwise they'll both end up in the same major probably. Idk
setAuthor string params are deprecated. Why not do the same on setFooter?
Because that only has 2 parameters
setFooter doesn't have 2 optional parameters like setAuthor does
with the author, you could have a url without the icon, but to show either you'd just need text, so both of them are seperately optional
with the footer, you only have the optional icon, which is dependent on the text being there
@solemn oyster with the switch to builders for the embed, setFooter() will take an object, right? If so, maybe we should add a deprecation warning for that too
https://github.com/discordjs/builders/blob/a9addd5f4a65d534d34b55f0d61dc4304cf797cd/src/messages/embed/Embed.ts#L220-L225
Uhhh, probably
They should add a timeout() function for Guild#Member
Why do you get a warning in console when not providing a token upon client.login()
It defaults to DISCORD_TOKEN so why does it error?
I don't do that and don't get a warning, ever. You're doing something wrong
Ask in the support channels
it defaults to process.env.DISCORD_TOKEN, it has to be an environment variable
It is and it successfully logs in, it just throws a warning
what warning?
@trim vigil
I don't think it works anymore because I just get an error now that says a token must be provided
No it definitely does work if you have the environment variable set up correctly
I had it setup properly
It got removed from the docs so it probably got removed
it didn't though? https://discord.js.org/#/docs/main/stable/class/Client?scrollTo=token
you have to have the env var set before instantiating the client, perhaps that couldve been it?
Why fs.readFileSync isn't used here?
Doesn't matter, those test files are quite useless and should be replaced with unit tests
Oh ic
Is there a type guard that turns all interaction reply and editReply return types into Message classes but doesn't require them to be sent in a guild?
Is this assuming fetchReply: true?
it's more fore editReply where you don't need that
I think cacheTypeReducer can be used here
Yeah but not with the current functions I believe since those are only for messages in guilds
@burnt cradle I just realized that typescript allows this combination for autocomplete getIntegerOption().setAutocomplete(true).setName('test').addChoices([]);
I don't know if there's a way around that
Yeah I don't think this propagates the restrictions it previously had on it, so setName returns a full option to ts
But that's why runtime checks exist anyway so ¯_(ツ)_/¯
I’m questioning the benefits of the static typing here then, if it can easily be worked around I don’t think it’s worth the complexity
CC @tacit crypt
It..does??
What
Do you have to explicitly set the return type to this?
I’ve tried that but it just resolves to the whole class
Wack...
Last time I tested this is valid to discord, it’s very strange behavior though
Yeah but it’s unintentional from our types. And it kinda invalidates the way we set types up in builders
why was, setAuthor() was depracated, while addField() remained the same.
Shoudn't be addField take EmbedFieldData as well for consistency?
The method isn't deprecated, just how you use it is
addField() doesn't have optional values
what I mean is in the arguments obviously, sorry for the misleading info. But what I meant is the values
Actually in the next major version, addField() will take an object as a sole parameter
addField() has inline as optional.
and another thing is, why addFields accept a single EmbedFieldData option, if addField can obviously accept that, where in addFields should only accept an array for consistency.
I mean they did change the setAuthor in 13.5.0, so I actually hoped the addField was also changed so people would just do a single refactor on a single semver minor release.
addfield only has one optional param so making it an object isn't needed
making it an object is useful when there are multiple optional params
though since addFields accepts an EmbedFieldData, I think it also makes sense to add addField to accept an EmbedFieldData
and depreciate the old parameters options, so its either a single argument, or an object with multiple params to make message embed consistent.
You seem to have missed this
Yeah, we'll switch without deprecation I guess, it's unlikely we'll have a 13.5.1 (or a 13.6.0 for that matter), as we're now working on 14.0.0.
What does the roadmap look like for 14.0.0?
You can take a look at the project, its lists some of the things that are wanted/in—progress https://github.com/orgs/discordjs/projects/2
oh damn, thank you!
why? this change seems pointless and negative
and i dont see any previous discussion of this, or an issue or pr
switch to builders
Objects are easier to add onto, without creating long parameter lists. They also have “built-in” labels for the arguments.
an embed field is literally just name, value, and inline
making it an object is just code clutter
people keep saying "d.js is making useless changes to break code and make it less usable", and honestly this change would just prove them right
The way we have it now is inconsistent, addField accepts parameters while addFields accepts arrays of objects. In fact the method just converts the input into an object anyways, which is just a layer of indirection that’s unneeded.
it may be inconsistent but its logical, and a better ux
if you're only adding 1 field why would you need to construct its object? It's just nicer to type without it, also ^^
is the plan to have no methods that take more than one argument
functions can have multiple params for a reason
But if the only thing a function does is take input and shove it into an object and append, the object should be provided the user
by that logic you would just make the user write out a whole discord message object and simply send it to discord
the point of d.js is to make it easier than that
The send method does way more than just serializing an object
And if you want to do anything more than send text, you have to provide an object anyways
Same with setFooter but it's also changed 🥲
but why change the semantics if its going to be removed anyways? (for a much worse alternative)
that's why the change is happening. For addField, I don't necessarily disasgree with whats been said here, but that PR needs to be made to /builders in order to keep the current function signature
if maintainers agree with it, then said PR will merge, otherwise it'll be closed
Hey, if we didn't do that, we wouldn't have a job to do.
Out of jokes, the addField change affects a huge deal to a lot of people, even me (who has been rejecting the change to objects for quite some time, this is going to take hours to fix in my bot T_T), but something undeniable is that making it take objects alongside the rest of methods promotes a level of consistency that allows users to intuitively use them correctly.
Having to remember which methods take multiple parameters, and which methods take an object is a bother and a mixed API, we're simply consolidating them into a single for everything, although in a quite unintended way.
I also would like to go a bit further into this and ask the question how something taking multiple Params makes things “easier”
How is something taking multiple params compared to an object easier? By what definition?
What is “easy”?
How is it measured
in this case i think the version which makes you type less is easier
since there isnt really other difference
also everyone is used to the current system already; I don't think making it more similar to the other methods really provides a benefit here
especially with modern editors which will tell you exactly what you need to put
it would make the method totally unnecessary too because addFields already accepts a single object through rest parameters
are we going back to "remove addField" discourse 
(tbh it would probably be better to remove addFields, does anyone use it)
I'm not sure if this is the right channel to ask.
guild#premiumProgressBarEnabled has the same value for both oldGuild and newGuild, why's that? shouldn't it return false in oldGuild and true in newGuild in case i enabled it?
(using latest djs version 13.5)
quite a few possible answers to this, maybe try a support channel instead of the dev channel
it seems like a bug that's why i asked here
support channels would be more active for possible debugging to just kinda make sure it's actually a bug and not a mistake (not that that's bad, it happens, but having someone else check your work can help filter those out)
if it's reproducible (and you can provide those steps), please open an issue on https://github.com/discordjs/discord.js
mhm alright, it was on my end sorry.
Typing less doesn't automatically make it better. That's a gripe I have with a lot of our methods that do this annoying "list of required parameters with an optional object at the end for all optional fields". What is each option?? Yes, if you use vsc or intellij suite you'll see what it is, but not everyone uses that, and yes you can check the docs but if I have to check the docs every time to remember the order.. I'll pass. With an object, you know at a glance what each field is, is it a name, a file, a value, you name it. It brings consistency with everything else
In my opinion, yeah, it's surely more consistent having it as an object... But, it may be misleading. Both name and value are required, while inline is optional so having it as an object with these 3 properties may be difficult to understand what field should be filled and what field may be leaved blank, while with parameters you know you must put them.
Actually, not really a big problem if it's changed to an object however... it was already done with the send() method and I think it would also be better if Discord a day decides to add a new field to that object, just thinking about all the big projects that will require a big rewrite of all those addField()
Technically, a good find and replace can automate most of the migration to an object based interface 
I kinda agree with the notion that addFields() is a useless method. Its existence is only to be a shortcut to addField(). Something that can easily be used with .forEach
Would be happy, when someone could provide me such a thing.
This works with vscode?
(Had to change 1234 lines in 107 files manually)
If the problem is having to check the docs when writing these methods I think that using a single object for addField makes that even harder because, while you get suggestions when typing on modern IDEs (with the name and type of the parameter), the same doesn’t happen when that parameter is an object, you pretty much have to guess the names of the properties because not even vscode will give you intellisence unless you start typing one of the properties out. Also I’m pretty sure this has been mentioned here but if addField is going to take 1 object only then might as well remove it entirely because you’d be removing the only reason people have to use that over addFields
Does vscode work with capturing groups? I haven’t been able to do that
Should do yea
I can experiment with that and see if I can come up with a regex
besides the point
I press option + escape and it brings up the object keys
- It was an example
- You do get suggestions in your IDE even for object ones..have you never CTRL + Space'd in vsc?
- I'm not talking about addFields because they cover different usecases
Yeah I have use Ctrl + space but that doesn’t tell you which parameters are required even, which would make life harder for people on JS. Not to mention that they may not even get types depending on how they’re importing their embed builder
How do they cover different use cases? If you change the syntax for addField it will become the exact same as addFields or setFields for that matter
They would notttt be the same as setFields.
If you use it when adding the first field it would, and syntax-wise it would be the same too
Yoo this will be handy
If the field has a question mark it’s not required if it does then it is
Hey all, ran into an issue last night with message embeds and displaying an image. If I use an image URL from my server, discord won't show the image. But if I use the image from the example at https://discordjs.guide/popular-topics/embeds.html#embed-preview, it does. I ran across a reddit or something that said discord only allows images from certain servers??? Embed aside, I tried posting the link itself from my server and the one used in the link above, and same thing, my link will not show an image but theirs does. If I send it in a direct message, it shows just fine. I know this is less a discord js issue, but wondering if any of you have run across this??
might be better to ask this in discord devs
Thanks, yeah I wasn't sure. Is that a different server (sorry, new to this channel of troubleshooting)?
discord devs is a different server, the invite is listed in #useful-servers
also btw this isn't actually exactly a troubleshooting channel per se (check channel topic)
Gotcha. Thanks.
Hello, when I used the example provided for RoleManager#delete() in the docs https://discord.js.org/#/docs/main/stable/class/RoleManager?scrollTo=delete with the intents of GUILDS and GUILD_MESSAGES, deleted is undefined, however in the example, it uses deleted.name which will throw an error. I have also noticed that the method returns Promise<void>.
Yeah the example is just wrong
the return type is correct
alright thanks
could i open a pr for this
if there hasn't been one already, go ahead i guess
alright
would it make sense to use rust's discord module, compile it to web assembly and use it? will that performance increase be worth it?
no
wow thanks for that pro tip :D
I wonder how do bots communicate with websites. Trying to make a captcha system that redirects to a website any idea how I should go about it?
Websockets
damn I am an idiot
Redis pubsub I heard is decent too
Redis is server side
Good luck with that on a website without leaking your credentials
yeah but what about having it run serverside for the web app and having the bot as a different node app
using php or something im still tryna learn web dev
Would the monorepo PR be a good chance to start using tabs all across discord.js? Most if not all of the other packages already use them so since the diff is big I think that would be a good opportunity right?
that makes retargeting all those semver majors PRs that much harder, not opposed but those PRs should be merged first and then do that if we want to IMO (merging the other PRs first may be in the plan, don't know)
i really hope prs are merged before the monorepo one so i dont have to setup everything again 😄
that will always be an issue inevitably I think since there's always some PRs open, but yeah we could wait until most are merged, however this PR will inevitably cause merge conflicts so that would just be another minor thing to fix which is why I thought it would be a good opportunity but it's the maintainers' decision ofc
it will cause merge conflicts yes, but without changing anything else in the files git recognizes the file structure is the only thing that changed and thus a rebase will successfully complete without any user intervention (unless you touch package.json or similar)
that's not a minor difference
Those are easily solvable, there's a command (or two) @strong hull ran a while ago for my bot to rebase PRs easily when the files were moved, if what Ckohen said wasn't the case
oh alright then, I guess there will be a better time for that one
@remote wasp :eyes: for https://github.com/discordjs/discord.js/pull/7179, maybe you should just remove it instead of deprecating it, since version 14 is the next target
can't remove it until discord does it first
Is there really a need to have two types for the same thing here?
Well, channelTypes will be the same thing at runtime
Thats strictly to support /builders or raw api data. IIRC the camelCased ones take priority over snake_cased ones
Why not use a second type for raw api data (probably from -types) and then use a union?
Thats what it is!
I don't exactly know why your editor shows both
Hmm.. very strange
Hey guys, would you use Jest to unit test TypeScript modules ? I heard it does really bad with asynchronous tasks
It will show both until you use a property that’s strictly camelCased btw
Using ts-jest with jest it works fine atleast for me
Did you face such thing: https://github.com/facebook/jest/issues/2235 ?
I’m wondering if it’s worth it to work around problems from Jasmine to unit test scenarios that should be easy to test…
(I mean working around could be easy but to me it sure means it is not as easier as to use the things like they were built for)
We're already using Jest for -modules, but we're not using ts-jest, it's too slow and has many issues.
Also, that last bit is a bit off-topic and not related to this channel's topic.
some getters (ex. Role.members) are O(n) operations which is not documented at all. should this be changed? either lib-wide or for this specific instance
adding a note like "don't do role.members.has(userId), it's way slower than member.roles.has(roleId)" or even "this is a O(n) operation" can help users understand why their code may not be performing well at scale
Do you think users know what Big-O notation is?
We could add it in the docs just like Redis does, but we'd need to decide on whether we want to do that, because it'll involve a lot of maths to even process them, specially for recursive things
i wouldn't recommend adding time/space complexity to the entire library as it's a very tedious process like you said
i think in this specific instance it'd be good to add a note about performance
I would just say "runs in linear time complexity"
Yeah, and what is "linear time complexity"? How do you explain that to a user?
or perhaps make a page of performance recommendations for less obvious things like this one
you could argue that the only users who are at a scale where performance matters would know enough of the jargon to talk about it
Yeah, I agree. Having the Big-O notation of getters and methods is hella helpful for me
And such things could solve this issue: https://github.com/discordjs/discord.js/issues/3925
I don't know if it's doable at all (cc: @wild flax), but maybe we could add an "Advanced" switch just like we do for privates, to show the time complexity alongside the docs, I think that would balance keeping things clean and simple for newbie users and verbose but resourceful for advanced users
probably worth making a GH issue/discussion as an RFC for this
i have a few ideas on how you could document this info but don't want to clutter the channel
Feel free
Is there a particular reason we don't get a guildMemberUpdate event when a timeout expires?
That's a question for Discord
Alright
There can be a toggle on the docs like for the private methods. Default disabled...
because it adds clutter that isn't useful for majority of users
Hello, I want to use discord-js RPC to mute my self via a script. The example for rpc defines a clientId. What is a clientId and where do I get it?
Not sure if you read the channel name but this channel is for library discussion, you should use a help channel instead
Additionally I’m pretty sure that muting yourself through a script would fall under self-botting, which is not allowed by Discord
I'm sorry. You are right this is the wrong channel. I thought rpc made to allow such functionality. Thank you very much.
@outer raven @fervent crescent it is allowed
but #archive-rpc-help is the right channel
rpc isn't selfbotting
interaction.options.getMember("user", true) throws an error when the input is a user but not a member. But as there is no way to limit the input to member only (as per ik) then why getMember have the required parameter? Means what i mean is there shouldn't be any required param in getMember and it's output should be always GuildMemeber | APIInteractionDataResolvedGuildMember | null
if the user is in the guild the getMember's erroring behavior would function like getUser i guess?
if the option is optional and isn't set, required being true makes it error
if the user is in the guild the getMember's erroring behavior would function like getUser i guess?
You mean it'll return user instead?
if the option is optional and isn't set, required being true makes it error
option is required but the input was a user who isn't a member
You mean it'll return user instead?
...no, i said erroring behavior
option is required but the input was a user who isn't a member
and there's no member to return? so that makes sense
if you don't want it to error then you can just setrequiredto false? (or omit it as that's the default)
That's what i'm saying that i can't set a member type while registering a slash command so required param in getMember doesn't makes sense as it can be null irrespective of the option is set to required.
if you don't want it to error then you can just set required to false? (or omit it as that's the default)
I can use like this and I'm using too but what's the use of required here then?
...for there being no member
@vernal rose I’m confused on what’s being asked the required parameter is only set to true if the option is required in your slash command
My question is related to getMember. As discord don't provide a member type in slash command so users can enter any users id in USER type means a user who isn't present in that guild. So if the option is set to required then also we can't set getMemeber's 2nd param to required because it can still be empty irrespective of the user option is set to required.
I'm not able to explain it properly as English isn't my 1st language if u didn't got it then i can show a example.
so what i want is that there shouldn't be a required option in getMember method and it's output should be always GuildMemeber | APIInteractionDataResolvedGuildMember | null
But you can't select users outside of the guild the command was sent in
hence they're members
We can as it's a user type and u can provide a user is
Id*
Tag suggestion for @slender idol:
• > text: single line blockquote
• >>> text: quote until the end of the message
hmmm
I honestlty didn't know entering the user's direct id worked even if they weren't in the server
Yeah u can try
I just did
it works
Yeah so should I make a pr to remove required from getMember?
no? it still has the use for optional arguments
and still for this use here that you've pointed out
Other methods have use case but getMember don't have
it's for typechecking
it has one more use than the others, though.
It can be null so if u set required to true then it'll throw error
yes but it's inaccurate if the user isn't in the guild
they're no longer a guild member, and as a result it's a null response
@dawn merlin
interaction.options.getMember("user", true)throws an error when the input is a user but not a member.
that seems like an expected behavior to me?
Yeahhhh that’s fine
How u can set the options to member only? Bcz it's input can be a user
just check for the output of getMember, or catch the error if you have that required set
U mean we should do a try and catch. We can just set it to false but but what I'm saying is required have no use in getMember
it... has the same use as it does in the other getX methods
In other cases we define that it should be required or not but in this case we can't
no it does, compile-time types means that if something doesn't/cannot satisfy the expected type, an error is acceptable
im really not seeing the problem with this, if the user isn't in the guild then throwing the error (along with the typeguard thing) seems like expected behavior.
to me, at least.
yeah no, there isn't a problem, I just forgot it threw
Ik that and that's why I was using true to avoid ts check now when i got a error in my bot so I remove all required and added if !member check to all cmds
a try/catch should be used with true then
or switch to getUser()
This seems to have gone past lib discussion into general support on how to use these methods
Hm better use false to avoid a let and try/catch xD but I solved my issue so I thought it should be changed in lib but leave now
And for type check case u can just add a if statement to check if no member and Typescript will remove the null after that line
I do agree that ultimately enforcing a try/catch, is not a great DX. I think a better solution for this would to have a type-guard ie Interaction.options.isMember('option-name'). This method would gaurantee that options.getMember('option-name') will always be a non-nullable GuildMember. I'll play around with this and see if anything comes to fruition.
Or just remove the required parameter 😉
Leaning towards the latter since (ignoring network errors) you can’t ever guarantee getMember is not-null compile-time. Setting required to true is just basically lying to you that it’s not null. It’s one thing to set required to true and have your option have required set to false. But you as a developer already know what options are required and which ones aren’t before runtime. getMember isn’t ever known to be present by a developer before runtime so it’s a different circumstance.
sorry for late response but this is what i was saying. Btw if u plan to remove the parameter then if possible lmk so that i can do my first contribution to djs 😅
You don’t need to wait on anyone, you can make the PR whenever
Thank you
are there any specific reason why every other method's required is set to false by default in CommandInteractionOptionResolver but for getSubCommand and getSubCommandGroup it's true?
because why would you be trying to get a subcommand or a subcommand group in a command that doesn't have such a thing
subcommand groups and sub commands can be used I mean like this
{
options: [
{
type: "subcommandgroup"
},
{
type: "subcommand"
}
]
}
In this case when using 2nd one means sub command then there will be no subcommand group then it'll throw error but the subcommandGroup is present in that command. So it can also be default to false.
Idk if u understood what i mean because my English is so bad 😄
that's why you can pass the parameter as false for those niche cases, but in most cases the subcommand (group) will be required
hm yeah. But like all other's have default to false so it can also be set to false unlike subcommand which should be default to true.
you can always make a PR but I doubt it would be accepted because iirc that was a conscious decision when the initial pr was made
i noticed in some places that arrow functions that return an object usejs () => { return { foo: 'bar' } }when () => ({ foo: 'bar' }) could be used, which is easier to read, is this intended? i can probably make a pr changing it, but i wanted some feedback first
I don’t think it’s intentional I think the formatter does that automatically but you can see
is nor a typo? 
should it be not?
No
ok, thanks
If builders is going to pre validate names for slashies could it be expanded to show the string in question and the specific error with it? Taking about these errors btw:
ZodError: [
{
"validation": "regex",
"code": "invalid_string",
"message": "Invalid",
"path": []
}
We're planning on replacing zod so in the future errors will be much more useful
https://github.com/discordjs/discord.js/blob/main/src/rest/RequestHandler.js#L292
Currently when encountering a high amount of invalid requests it just fires the event.
Is this Idea in plan/something for the future?:
- When the Invalid Request Count hits a specific (userset) amount, it will stop all requests until the count/ratelimit resets (or the requests will be dropped - not the best solution)
Don't think so
you can keep track of it yourself
@dawn merlin we can discuss the middleware concept here rather than fill Github if you want
I very much do want to support it, so please consider it constructive criticism lol
Yeah that’s fine
What about "custom" events?
Like an event: guildFetch
Which will be triggered on every fetch of a guild
So you could extend the cache with data like settings from a database related to that guild.
or like memberFetch
So you could for example fetch custom data about that member such as subscriptions, economy / rank stuff
Just an idea, I guess at this moment you'd need to do it on apiResponse I guess and then check the requested path
i mean, you could just add those yourself to your own code
Let me guess, by looping through the cache's?
well no, just whichever ones you need or want
That doesn't make any sense to me, elaborate please.
if you need guildFetch, then make that event, emit it after fetching guilds or add it to your version of djs within GuildManager#fetch or Guild#fetch
i don't see how an event for fetching guilds would relate to database fetching
Add it to your version, is basically something you don't want to do as it get's lost every time you update your D.JS.
Manually after obtaining guild data would still not be satisfying as you'd still required to do multiple manual checks after that.
It's a feature I could see being useful to other people as well.
i don't see how an event for fetching guilds would relate to database fetching
It's an event... so you can smash your own sauce onto something that's being done, this was just an example.
In this case, it would be for fetching settings in a database.
Could be used to fetching data in a file.
Just data you might need more than once without the requirement to keep checking it.
Example: A bot log channel.
Fetching it once from the database right after the initial fetch that cached the guild wouldn't you require to check if the bot log channel id is in the cache on every single command you have.
If the guild is in the cache, the bot log channel exists as well.
On member fetch as example:
You could check if the member has a VIP membership active.
If not, take off the VIP role.
If they do, add or keep it.
On that you can also (re-) load your economy data.
On that you can also (re-) load the ranking data.
As this is always triggered when a guild or member is fetched, this data always exists and thus does not require an additional if (data !== undefined) -> obtain data
The event won't be triggered when the fetch data returned is from the cache.
that seems like something an extension would do, these aren't exactly gateway events from discord, no?
and also with those examples, you still need to add checks such as for the guild being unavailable, the bot losing perms, the channel being deleted, the member leaving, so this isn't going to be doing much anyways in those cases
said checks on "member fetch" seem to be better off based on fetching from the database than based on fetching from discord
It's part of an automation.
These aren't gateway events no.
Doesn't mean it couldn't be a feature.
What does a guild unavailability or the bot losing perms have to do with your custom settings?
Pretty much nothing if you'd ask me.
Your last sentence is exactly what this event can be useful for.
The event is triggered AFTER it's fetched from discord to add your data to the cached version.
Thus adding your own sauce on it. hence that's what events are for.
Your last sentence is exactly what this event can be useful for.
so... if you need to remove vip from a member, you're just going to wait til that member gets randomly fetched?
again, you can just fetch from the database, check, then fetch the member yourself
that's what promises are for, not events
So you insist on looping through 1000's of guilds per client possibly millions of members as well
Then run over each member on bot startup just to obtain the data.
Running a query the same amount of times as an event would be triggered. When this could be extended by triggering an event when the object you are working with is going to be necessary.
Again these are just examples this event would fit.
if you're referring to bulk fetch, then there's already an event for that, guildMembersChunk
those members aren't going to be randomly fetched reliably, you're still going to have to fetch them to do whatever you need to. for rankings or economy or whatever that you mentioned, those can all just be fetched on demand or cached
Didn't know about guildMembersChunk
But it is exactly what I was talking about for on memberFetch.
This event is exactly what it could be useful for on guilds
However, guilds are already fetched on the beginning.
On a side note, guildMembersChunk would or wouldn't it be triggered when you fetch one member.
probably not, seeing as it's called Chunk and always gives a collection. but i don't know, i haven't used/tested it much.
as far as i can tell from discord docs, no
Answer is no, and neither happens when the guild initially fetches the members (automatically after login)
because those a) aren't fetching b) aren't a request?
those are sent with guildCreate
GuildCreate is triggered when a bot joins your guild....
https://discord.com/developers/docs/topics/gateway#guild-create
Guild Create
This event can be sent in three different scenarios:
- When a user is initially connecting, to lazily load and backfill information for all unavailable guilds sent in the Ready event. Guilds that are unavailable due to an outage will send a Guild Delete event.
- When a Guild becomes available again to the client.
- When the current user joins a new Guild.
Emitted whenever the client joins a guild.
https://discord.js.org/#/docs/main/stable/class/Client?scrollTo=e-guildCreate
im referring to the gateway event, not the djs event.
I'm talking about djs events not gateway events whatsoever.
Every discord.js event corresponds to a gateway event
What you're describing though is modifying the internal structures that get stored in discord.js caches - exactly one of the major issues that resulted in the removal of Structures.extend
guildCreate for an unavailable guild acts as a patch for the guild instead of emitting the client event, though.
Doesn't need to modify the cache, it's what the user desires to do with it.
Simply said:
a guild is fetched from discord
Event: apiRequest is triggered
When the response is received: event apiResponse is triggered
feature request: event: guildFetchedis triggered
a member is fetched from members:
Event: apiRequest is triggered
When the response is received: event apiResponse is triggered
feature request: event: memberFetchedis triggered
event guildFetch or memberFetch to fetch from discord wasn't what I meant, it's an event being triggered after it has been fetched from discord.
Way too much feature bloat imo, as you said you're free to implement those custom behaviours in apiRequest and apiResponse
Like the event ready is when the client becomes available
you can just use the promise resolution from actually fetching them though
Those methods were introduced to allow users to act when API requests have occurred
This is another good point - additional events such as memberFetched are not going to execute before the promise resolves where you actually fetched a member
So whatever data you intend to expand isnt going to be returned yet
If the member (or guild) isn't fetched, it's neither in the cache, the data isn't required at all then
Thats not what I said
Anyway, Im of the opinion that adding events for when every possible type of structure has been fetched is excessive feature bloat that offers very little to the actual execution of the fetches
Not every. I only see it usable for guilds and members (atm) to be honest.
that's what you see, but if these do get implemented, someone's going to want them for other structures
Just because you only have those use cases doesn't mean others wont - if we're going to add a feature of this design, it would be done consistently
But, we probably wont
Then that's fine as well. But anyways I'm out. Just a feature idea, turned down, cool. No need for me to spend more time on that then.
@wild flax could you add if: github.repository_owner == 'discordjs' to the first line of each job in the documentation CI so that the workflow doesn't fail on forks?
ayee monorepo setup, about time
👍
yeah saw it too, a quick question:
Does it mean that the existing code will be dropped soon and replaced with the ts code (like the rest ones) ?
I think so
probably, typescript is better anyways
type safe
🌈
this is already almost done
for /rest at least
Is it worth making a PR for this?
As this includes a lot of breaking changes (like the @discordjs/sharder) will it be released in a new version like v15.x or even v14.x ?
Or is the plan: slowly replacing the parts with ts?
(sorry for the internal questions, will give me more planning safety...)
/rest is planned for v14
so how would /rest work with undici
or is that just gonna be scrapped?
the idea is to replace each module over time, and if its semver major then its semver major
I'm gonna port your pr to /rest, been waiting for the monorepo
nock doesnt work with undici, which means all tests need to be ported 😐
along with other issues such as using response.buffer, etc. (i did try to do the work)
we're aware of that
thats great to hear
my plan is to get /rest into djs, then implement undici in a semver:major bump of /rest
are u planning on waiting for nock support or were u planning on rewriting all of the tests using undici's mock client?
Nock doesn’t work?
How come?
nock mocks the http(s) modules which undici doesnt use
And yeah our second choice after nock would be https://mswjs.io
Which should work?
Since it also works in browsers
i messed with a few mocking libs that mocked sockets but didnt get very far lol
mostly from https://github.com/nock/nock/discussions/2247
I plan to have /sharder done for v14.0.0
Thanks for this, looks like nock may be pretty close https://github.com/nock/nock/discussions/2247#discussioncomment-1902118, maybe by the time I get to tests it'll be ready 🤞
doesn't appear to work either
since d.js is a monorepo now, do module related prs go there, or they still go to the individual repo?
The other ones have been archived
cool thanks
Has anyone else gotten this error after the monorepo change when committing to djs? I recently reset my PC so I'm not sure if it's related to that or the monorepo change
also I already updated all deps
change the line endings in yarn.lock
lf?
if you're on windows it has to be crlf
oh alright
but dont commit it
lol
just change it for now
it won't commit IIRC
it will eventually be fixed in turbo
I changed mine and commited and git just ignored it
you sure can make it commit, but git will prolly convert it to lf again
yeah, so it noops in the diff
yeah that fixed it, thanks
was this change intentional?
the rule was completely removed and lower-case seems to be the default, which no longer allows us to put class names in the scope
yeah
oh okay
so should I put the class name in lower case?
sure
alright
or rather
not put the class name
but a somewhat generic one
instead of "CommandInteraction" its ok to just put "interaction" or "interactions"
oh alright
this PR is very specific so I'll go with the class name but I'll keep that in mind for the future
Pretty sure I've seen this error before but I'm not sure what caused it and I'm getting this on the latest main commit, any ideas on what could've caused it?
I would try to debug but we can't install packages from github with the monorepo anymore
restart ts server
We've been deploying @next releases for several months now, which you're supposed to use instead of git installs
yarn link, or run yarn pack in the d.js folder and paste the zip's contents into your bot's node_modules
those are released once every 12 hours, not useful when going commit by commit
What about resetting to commit hashes? Like git reset --hard <commit>
yeah I know how to do it, it's a bit more tedious now but I can try to find the commit if you wish
yeah that's what I was thinking
I think you want git bisect here 
Ah yeah, even better
yeah so it was https://github.com/discordjs/discord.js/pull/7197 but I'm not exactly sure why
maybe @dawn merlin knows?
context
we should probs add type tests for these functions 
It seems we cannot access to CommandInteractionOptionResolver after PR #7197, since options field has been moved to ChatInputCommandInteraction class
I’ll be home in like 5min
oh btw that's an actual js error, not a TS error only
uh oh
😂
which type guard are you using for TS?
none, plain old CommandInteraction
is this straight from the event listener?
it's in a command file which is typed like that
comes from this function
ok but like does your command file handle both chat input and context menus or just chat input?
just chat input
Then you have the wrong type, it should be ChatInputCommandInteraction
ahhh
BaseCommandInteraction -> CommandInteraction
so should we never use CommandInteraction from not on?
no you can use CommandInteraction, but it should only be used in cases where you expect a context menu or a chat input command
well then we'd need to cast it to use the options class right
or use a typeguard yes, it's the exact same like before expect it's not called BaseCommandInteraction
got it, thanks
so the js error should be fixed by #7210
@real jetty did you just open that PR?
nope
did it cuz I had the same issue
@wild flax sorry for the ping, since the last publish dev failed and most issues seem to be fixed now, could you re-run the script?
As the repo is now in ts so it'll use import/export. And vscode have a settings for import
organizeImport or smt like that which organizes all imports which isn't used in djs. So is it's worth making a pr to disable that setting in .vscode folder?
that setting isn't enabled by default and you shouldn't be able to commit with that anyway because eslint should fix issues before that if you run the git hook
Yeah that is disable by default. But eslint allowed me to commit. I committed from terminal and all the tests passed.
sounds like a you issue
the repo shouldn't need to disable a setting that comes disabled by default, and the eslint rule is much better
Yeah that's why asked here before making a pr. Ty
the maintainers may think otherwise tho so ig wait for them, but it would surprise me
if you're talking in packages/discord.js eslint doesn't run in the typings file
its dtslint
ic dtslint run only in gh actions and not in git hook?
btw r u gonna migrate to @typescript/eslint?
eslint doesn't work on d.ts files
oh ic
its a non issue since typescript rewrite is happening sooner rather than later
It does it just doesn’t have the same rules dtslint has
some of it works, last time I tried it failed on the tests.d.ts
is there any example of a dynamic command parser for subcommands or subcommand groups?
pls use #djs-help-v14 for help
Current labeler only adds labels based on files changes.
https://github.com/rafaelalmeidatk/webhook-labeler
This webhook can be used to label like
created by: discord core maintainer
this is used in nextjs
what's the point of this if gh already tells you who's a member and who isn't
Yeah I dont really see the benefit of that
yeah that makes sense
I was talking with the owner and he said this.
...okay?
if i've understood correctly what he've said then he means if anyone who isn't a member of djs creates a pr then the current labelers won't work
nvm ig it's working in djs as it worked for Rodry's pr so leave it
if you were to make a pr to your own fork it wouldn't work, that's fine
why you guys gonna shut down v12?
@ruby terrace any idea?
its already shut down, it will stop working soon anyways when discord stops supporting the gateay/api version it uses
oh
wdym why
Becuase we made v13
Dev releases are broken because the eslint hook is failing I think
why this is showing? It wasn't showing these errors last time
Because whatever used to cause a type error, not longer does it
btw I'm not able to commit what's wrong here?
Go to the yarn.lock file and change LF to CRLF
Idk how to do that 👀
how can i do that?
Bottom right side in VSCode, where it says "LF"
oh okay ty
maybe pin this here?
that one worked but now. I didn't touched role file then how can i solve it?
wait for #7215 to be merged
ok. my pr have conflict so i was fixing that and now 
Yeah, main's green
So that's a merge conflict on your side
Oh wait, it isn't
hm?
conflict isn't in role file. It's
nvm
comaptibillity with twilight http proxy
Can someone try re-running the publish dev script again? Last one failed because of the unused process so maybe it will work now
All dev versions on npm are deprecated now and the last one was published 10 days ago
Still fails because of the unused directives apparently
but I can't reproduce running the same commands locally
the unused directives can be removed tho right?
I dunno
are you the author of that PR?
For the Permissions constructor, as a parameter, can you add like a permission object to return a bitfield? Example:
const { Permissions } = require('discord.js');
console.log(new Permissions({ SEND_MESSAGES: true, /*extra perms*/ }));
//object was created by hand, not of permission class or wtv
//throws invalid bitfield error
That's not exactly suitable for the permissions constructor, since it's actually 2 bitfields (3 if you want to be pedantic), we have this instead: https://discord.js.org/#/docs/discord.js/stable/class/PermissionOverwrites?scrollTo=s-resolveOverwriteOptions
Alr lemme see
I know a few people have farmed PR requests using bump licenses. I understand that it's been closed but in a few packages like voice it's been accepted. Now that the discord.js repo is like a monorepo, it says 2020 - 2021. Shouldn't this be changed to 2020 purely so that we don't have to make these pull requests every year afterwards?
All packages with "xxxx - xxxx": voice, collection
Without license: rest
The year doesn’t need to be updated regardless
Okay, but wouldn't it be better if there was only a starting year in each license? One more thing, there is no license in the rest package.
I’m mean I’m sure rest needs a license, a ticket should probably be created for that I’m not sure about the ranges
GuildMemberRoleManager.add(), tho it says it accepts role objects it doesnt
Make an issue with a reproducible code sample if you've found an issue
just a note to the core contribs
it'd be nice if you guys could update the old readmes to point out that the code has been moved to discordjs/discord.js/packages/
What old readmes
Ig the old repo readme in github which are now archived
I was testing the latest issue of GuildMember never type and saw this.
If I do if inCachedGuild then return, then the interaction should become interaction<"raw"> but it's the default now. Is it's a bug? asking because i don't have much knowledge of these this is type
if its not in a cached guild
it needs to be a raw interaction
lol
or rather one with a raw guild
yeah but the type is still "raw" | "cached"
after searching a bit i found that it's not possible if that inCachedGuild is true only then the type will narrow else it will be the same
should the main djs repo be using yarn 2+? i'd be happy to PR if yes
Turbo doesn’t work with yarn2+
eh... it does in my experience
It does not
have you run into issues with it?
i know their docs explicitly say it doesn't but like
Jared himself said it doesn’t, and yeah we’ve run into cache hit misses constantly when running yarn 3
hm ok
@golden mortar will you be opening another PR to /rest for undici?
maybe, if ckohen doesn't beat me to it (#archive-library-discussion message)
the problem with /rest is that you'd have to rewrite every single test to use undici's mock client (which isn't api compatible with nock) and no other mock libraries work
and undici's mock client doesn't have as many features as nock
Undici has a mock client?
And it could maybe be extended, we don’t use a whole lot of stuff I guess
although this is about as far as i got rewriting the tests https://www.toptal.com/developers/hastebin/adelebajuc.typescript
You can intercept
So i guess you can do anything you want then
Just more own code
yeah nock's api is way nicer with the chaining
and there are a lot of tests that need to be rewritten
hm, seems like yarn 1's lack of a "workspace:* dependency version feature is why lint needs a build first
@outer raven hot take, you can make an utility method to abstract all those nullish and dates
like a convertToDate method?
Oh wait, it's just 2 usages, I thought it'd be more places
nah I looked everywhere and its only those two
could come in handy in the future though ?
Nah
No unnecessary abstraction
Nah, we can look into that if we run into the case of needing more dates
aight 
@wild flax instead of using an action to assign reviewers why don’t you just add a CODEOWNERS file
I see no reason to
It runs faster and already exists on github itself, the action ends up being useless because it does the same
The people you choose as code owners must have write permissions for the repository.
Don’t all maintainers do?
Also code owners is a bit more than just "add this person to the review"
The only other use is if you have branch protection rules which you don’t
Although it would automate more things too
And would make it more clear to the author of the PR what needs to happen in order for their PR to be merged
Hulloooooo @drifting knot, I think your pull request regarding Turbo optimisation may have caused this lil' issue:
https://github.com/discordjs/discord.js/runs/4755241901?check_suite_focus=true
are you able to look into it? It worked fine before that change it seems
ugh, was hoping this wouldn't happen on CI too
could you revert my PR?
@wild flax ^ x:
for whatever reason, turbo only sometimes runs the build script before lint

i spent a while resting ^build vs build in the dependsOn array locally
super inconsistent results
i assume it's a bug on their side
There’s also a bug if you turn on parallelization
Where it fully ignores the dependsOn lol
lmfao
discordjs/builders
discordjs/collection
discordjs/voice
@remote wasp can you rebase this:
https://github.com/discordjs/discord.js/pull/6642
https://github.com/discordjs/discord.js/runs/4762790759?check_suite_focus=true
Here EventEmitter was used in docs. If he removes the import then EventEmitter will be undefined in docs but if he imports then it'll cause lint fail due to unused var. Than what's the solution?
Without explicitly denying rules, just remove the JSDoc
You mean remove {EventEmitter} from jsdocs?
Means the param line or only this type?
All of it
/**
* Decrements max listeners by one for a given emitter, if they are not zero.
* @param {EventEmitter | process} emitter
* @private
*/
decrementMaxListeners(emitter) {
const maxListeners = emitter.getMaxListeners();
if (maxListeners !== 0) {
emitter.setMaxListeners(maxListeners - 1);
}
}
To
decrementMaxListeners(emitter) {
const maxListeners = emitter.getMaxListeners();
if (maxListeners !== 0) {
emitter.setMaxListeners(maxListeners - 1);
}
}
Then it won't show up in the documentation at all... since it's private I guess this is a viable solution without disabling valid JSDoc rule or unused imports rule
@solemn oyster what do you think^
Actually all he did was forget a description :thinking: seems fixed now
Yeah and he remove the EventEmitter import from 2nd file which was causing error last time. Now he removex so its undefined in docs.
EventEmitter will link to https://nodejs.org/dist/latest/docs/api/events.html#events_class_eventemitter everything looks good now!
So there is no need to change anything else right?
Other than what I just dumped as a review just now x:
👍
We can no longer add a Pascel case subject. So should I create a pr to change these?
What page is that?
probably the contributing guidelines or something
Oh yeah, I though this had to do with the enum PR lol
xD btw should i create a pr to change them?
Yeah you don’t need my permission
changing only 2nd one. Do i need to change 1st one too?
Just open a PR and if there’s something wrong we’ll let you know
ty
thoughts on adding a spoiler prop to https://discord.js.org/#/docs/main/stable/typedef/FileOptions that just takes a boolean
I found myself needing to spoiler an image I wanted to post via URL and it felt so unintuitive at first
I did know I could prefix the filename with SPOILER_ but then I was like "how do I actually pass the file now" until I noticed BufferResolvable does take URLs
regardless of how intuitive it is right now - feel like this is the sort of thing the library should offer 'abstraction' for 
Make a new MessageAttachment then https://discord.js.org/#/docs/discord.js/stable/class/MessageAttachment?scrollTo=setSpoiler
I did notice the class but having to make an instance for a task this trivial feels off.
It's also a trivial task to prefix SPOILER_, but adding a boolean option would result in duplicate code
is v14 of the library going to have packages/sharder?
@fervent walrus
noice
Is Interaction.locale coming soon?
it's in the latest dev build, if you're brave enough to use it
I'm not
Thanks though
Installing the dev releases and updating breaking changes as they come is better than updating it all at once btw
Hope this is the right channel, apologies if not does, or will in the near future have support for the other application command types, USER and MESSAGE? or will it just be CHAT_INPUT commands?
These are already supported under the term "context menu", see #archive-interactions pins
when im committing the formatting git hook errors out at this, i didn't touch this file so what should i do? skip the hooks and commit? or should i fix the issue if possible (this will be out of scope for my pr)
That shouldn’t be an issue
Make sure to reinstall node modules
oh ok, doing that
yeah that fixed it, thanks!
@tacit crypt did I do it wrong or uh?
i'm re-thinking of my pr
not much else you can do that wouldn't take too much effort / keep things readable
I mean
Looks fine
ok
ty
Nono, it was more of a poke to why we should be using enums for these in the future
yeah that got me wrong lmao

i'm not event sure of the changes
I need to test more
I get ChatInput as this._hoistedOptions[0]?.type, or it's a subcommand
and the name fits my subcommand name
welp another PR
nvm I will add it to the one I made
Option "content" is of type: String; expected STRING. 
Why is the old PLAYING activity type called Game on discord-api-types?
@dawn merlin why not add a locale enum in -types and then use that on discord.js?
in response to: https://github.com/discordjs/discord.js/pull/7261#issuecomment-1011395464
thats a good point
That doesn’t sound like a good idea to me but ok
hate to be that guy but could this be merged before the next dev release? Currently some things are throwing type errors where they shouldn't and this should fix them all https://github.com/discordjs/discord.js/pull/7260
idk if it fits here, but can we talk about whose idea it was to depricate using strings for the footer, author (and as far as i can tell also for fields). Now we have to use objects, which isnt bad per se. but if you are like me and have a utility bot with 30+ commands, all of which have atleast 2 or 3 different embeds which it can send back it kinda will be a lot to change wont it?
the idea was to line up the api with /builders for an eventual transition, since it's only deprecated you can take ur time replacing strings
i mean ig
but having a blah blah blah is deprecated error spamming your console isnt the funnest thing in the world, tho my db also spams console so i guess i cant complain
the deprecation message should only show up the first time you use it which isnt really spam
well yes, but for testing i restart my bot a lot, meaning i see it many more times. which ig cant really be changed on their end
man, that really sucks to hear
deprecated error spamming your console
Deprecations are not errors on patch and minor versions
ye its not really an error, but still an annoying msg
anyways
guess ik what ill be doing this weekend
tbh the only reson i even updated was because interaction.editeReply() wasnt working anymore, which eventually was due to a different issue but still
also this situation could have been avoided if only i didnt just add stupid commands noone will ever use. e.g. /dogeify, /curseify, /uwuify (as for what those do, dont ask) and the 3 text to image commands, 1 is normal, 1 uses mc blocks and 1 uses an ai to try and make an image out of text. which could probably just be sub commands.
i think you could do a single find and replace in vsc using regex.
hmmm, well yes but how would i be able to still keep the contents of the footer
and even if i do keep the content and like replace only the first part i still need to add an extra bracket at every command
look I'll do it for you how does that sound?
let's stick to developing discord.js in this channel, please, for regex and general chat we have #archive-offtopic
nahh
i have a question about the new monorepo setup... https://github.com/discordjs/discord.js/pull/7175
for other packages who were previously using some of the subpackages (i.e. collections only), what does this mean for them?
will those other packages still receive updates on npm? will there be any change to how dependent projects should organize their dependencies?
there won't be a change regarding npm releases and such
or is it recommended for other people to just stop using collections lol
the packages are still released to NPM as before, the only thing that changes is that issues and PRs will go to the main repository now
it's easier to apply changes across multiple projects this way
Nothing is changing in how you as a user consume the discord.js ecosystem, its just ^
ah, ok, thanks
my project uses d.js collections and i was worried this would break something in the future
ty!
oh, one more thing
why isn't discord-api-types package being moved to main repo as well?
I think because its npm package isn't scoped to @discordjs and its designed to be independent of discord.js
isn't collections package even more loosely related to djs than api types? 
one might think that at first, but collection only exists because of discord.js needing a k/v structure for caches in the first place
whereas api types are more likely to be used by other libraries
also another collection exists on npm so we need to scope it to publish 
more likely than collections???
in most cases a map is enough, whereas the discord api types are way more complex and feature-rich
yeah, Collection is an extension of Map and...beat me to it
interesting
so why exactly does collections exist again? like why wouldn't regular map work
for d.js
collections only adds some utility methods to maps right?
yeah
but they're pretty useful in this case
Probably the most important thing is filter
filter and find I'd say
oh right, forgot about find
Will the issues on the old archived repos ever be transferred to djs?
Nah
If they're still around, they should be made anew
I thought gh had a "transfer issue" button
I mean... Map is already a K/V structure
And it does
It would be pretty easy considering they’re all on the same org
Is the MessageEmbed.setFooter method with a single string supposed to be deprecated?
The docs seems to suggest that only the second parameter of setFooter is deprecated, nothing about the first parameter as string
i don't think so? same as the setAuthor allowing a single string?
It won’t anymore
So ig yeah that is intentional
what is
cause those 2 messages seem to contradict each other
"setAuthor won't allow a single string, so setFooter with a single string being deprecated is intentional"?
seems fine to me
Both footer and author will now accept a object and no more single string
but the original question asked if it is meant to be deprecated at all since docs don't say that it is deprecated
U can check this typing for details
ah, i see what you mean there
Yeah single string is deprecated if u see the typing but it's not mentioned in docs probably adding it in the description will be good
So the setAuthor deprecation implementation needs to be fixed too if the typings are correct
Typing and implementation both r correct but ig there should be a msg about deprecated string in the docs
Currently as implemented, setAuthor(string) does not trigger a deprecation message. But setAuthor(string, string) does
Oh ic lemme try
But anyways as there will be no 13.6.0 (as per ik) and v14 will use /builder so I don't think a fix is necessary what do u think?
A fix is necessary to provide accurate documentation
If u check https://github.com/discordjs/discord.js/blob/2bb40fd767cf5918e3ba422ff73082734bfa05b0/packages/discord.js/src/structures/MessageEmbed.js#L439 then it should emit a deprecated warning
Author my bad lemme check tha
Currently as implemented, setAuthor(string) does not trigger a deprecation message. But setAuthor(string, string) does
It should emit for only a string. docs need a clarification
According to the PR, it’s supposed to be conforming to what the builders package implemented, which means setAuthor is not supposed to take a string.
#7153 in discordjs/discord.js by Jiralite merged <t:1640772256:R>
refactor(MessageEmbed): Deprecate strings for setAuthor() (completely) and setFooter()
Yeah. Ok lemme first confirm that r u saying about it needs to be fixed in docs or in code.
That was my question
The code is correct and typings too. Both says that if u pass a string as the 1st parameter then it'll throw depreciation warning
But in docs it says only for 2nd parameter and not about 1st parameter
The typings, docs, and implementation are inconsistent with each other when it comes to setFooter and setAuthor
Implementation and typings aren't inconsistent if I've checked correctly bcz both says if 1st parameter is string then it's deprecated
The typings says that strings are completely deprecated.
The docs says that string parameters after the first one are deprecated.
The implementation is halfway: single string allowed for setAuthor, but no strings allowed for setFooter
In implementation single string is also deprecated. Yeah doc only says about 2nd param and not 1st that's what I said in above msg
Not sure if this is known but on the latest 2 dev releases I get TypeError [COMMAND_INTERACTION_OPTION_NO_SUB_COMMAND]: No subcommand specified for interaction. even if there is a subcommand. Downgrading to 14.0.0-dev.1641945998.1479e40 worked and debugging the code with the latest version I can see that the option is present in the raw options data.
Is known
Dev releases have no guarantee
Ok 👍
locale is undefined in interactionCreate event (defined in WS INTERACTION_CREATE event)
- I don't see the addition of the locale in the interactionCreate event, but the discord itself returns the locale.
14.0.0-dev.1642032388.2bb40fd
latest djs dev
I cannot reproduce, you very much likely are not even running on that commit being as it's not autocompleting for you
its my problem
resolved, thanks
Does it make any performance difference by importing/requiring setInterval from 'node:timers'?
I have seen discord.js importing setInterval and setTimeout from 'node:timers' module when its globally available.
Not sure about performance but Node.js considers it to be a best practice to do so
oh, I thought it was for documentation purposes
From kyranet's PR (https://github.com/discordjs/discord.js/pull/7157):
For the performance kids, because the globals are now const assigned, it's faster than pulling from the global, since the value cannot change.
Hello library people. When might a version with the new interaction locale property hit stable?
v14 most likely
on latest dev version, MessageButton.setStyle with a value from the ButtonStyle enum crashes, is this known?
import { MessageActionRow, MessageButton, ButtonStyle } from 'discord.js';
new MessageActionRow().addComponents(
new MessageButton()
.setCustomId('primary')
.setLabel('test')
.setStyle(ButtonStyle.Primary)
);
yes components are currently non-functional on dev
thanks 👍
Oh, I see
Speak of the devil
what does discord.js use for keep connection alive and receiving data?
so an interval with heartbeat?
how do I generate a session_id tho?
I just realised the return type of GuildBanManager.create() is a promise of GuildMember | User | Snowflake
but why
it resolves the best it can
if the user was a member of the server (and cached), a GuildMember is returned
if the user was cached, a User is returned (was not a member of the server, "hackban")
if the user was not cached, the ID is all we can provide
i know what it is doing, i was asking why. why not return a single thing, or nothing at all since if you're using that method then you'll already have at least the user id
I don’t see the problem
There’s been a discussion here about making managers not return anything and that was one of the reasons why
I think it would be much better for it to not resolve anything and let the user decide what they want
🤨
I don’t remember where that is anymore but I think @copper laurel was in it
How do they have any choice if it doesn't return anything
I dont remember caring about this one, dumb hill to die on
I certainly don't think all managers should not return anything
Add timeout in fetchAuditLog, I cant fetch audit log for timeout
Timeouts are of type 24 MEMBER_UPDATE
@radiant iron ^
oh, thank you so much
RESTPostAPIApplicationCommandsJSONBody is supported for ApplicationCommand#equals and ApplicationCommand#edit right? From the code it looks like it. But the typings don't allow it.
Bug or am I wrong?
I'm on d.js v13.5.0
i noticed the master branch moved to workspaces. is there any chance that interaction stuff will be abstracted into its own package so it could then be used with something like an http server?
It’d have to be a new package
then it was probably someone else but I'm sure someone said something along the lines of "we should make the managers return whatever the API returns (which in most cases is nothing) and only return usable structures when calling the methods on those structures itself
why does npm run build:deno create 132 new files on discord-api-types? I'm trying to commit something small and all of these files get added for some reason
is the from the git hook or are you running this manually?
because it builds for deno?
Git hook
I only changed a few lines in some files, didn’t add any so it shouldn’t be committing stuff I didn’t do right
Or is it fine to PR with that
Is there a reason why <Interaction>.locale is typed as string over something like InteractionLocale? Just curious, and asking if it'd be worth making a PR for it
I believe that was suggested and someone was gonna do that
👍, I don't mind doing it if they aren't able to
-types isn’t released yet with it iirc
So you couldn’t even do it if you wanted to
And 13.6.0 most likely won’t get it
ah, alright
@tacit crypt do you know if this is normal?
Did you clean:node before?
@outer raven
You shouldn't have any built files
Before running build:deno
oh right now it did work
weird, but I made the PR without that mess anyways so it's all good
the problem is that the function has extra complexity for no reason, and the return type is more unpredictable
the more reasonable return type is guildmember|null since you wont be able to fetch the member afterwards because.. they were banned
like i said, if you're using that method then you'll already know, at least, the users id
so you can always get the user from the cache/fetch them yourself
making the function return guildmember|null or nothing at all would remove unnecessary complexity from the function
But a reliable return type would be Snowflake
Because we can always return that
But that’s useless because you already have it
I know
But its no more useless than null
/ not returning anything
But not returning anything makes way more sense
It sticks to the API behavior
when fetching a GuildTextBasedChannel's message it returns Collection of Message<boolean> instead of Message<true> is it's intentional?
I assume that'd be this signature?
https://github.com/discordjs/discord.js/blob/main/packages/discord.js/typings/index.d.ts#L3064-L3067
yeah this just returns Message without passing in a generic
this seems like its type parameter could be inferred unless there's something I'm missing
yeah you could say that is always cached
since you literally just fetched it
well, not always
you could literally pass cache: false
that's not what this type parameter means
oh yeah nvm I just saw the types
the cached boolean is whether some properties are present or not
yeah this seems like it could just be Message<true> then unless there's something I'm missing
actually it's weird because that type parameter assumes things that aren't necessarily true
it seems like it's used for messages in guilds
you can pass true if the messagemanager is from a guild channel
hm
the name "cached" for the generic type in message isn't very accurate
i suppose the MessageManager could also have a "cached" parameter so you can pass it down to the messages
yeah I see now
Yeah I think this true isn't for cached but it's for message in guild.
yeah so maybe that name should be adjusted
Can we bring back #djs-at-dev for users of the dev versions? Or maybe once they're fixed but it would make sense now that we're going into v14
ButtonInteraction {
type: 'MESSAGE_COMPONENT',
id: '932222868455055380',
applicationId: '919328973585002606',
channelId: '931943047741210655',
guildId: '925331433831170058',
user: User {
id: '853394858895343636',
bot: false,
system: false,
flags: UserFlags { bitfield: 0 },
username: 'Sopow',
discriminator: '7130',
avatar: 'a4b3672e77d23278ff7c931aad0ca838',
banner: undefined,
accentColor: undefined
},
``` i logged interaction, but there is no channel
In the documentation, channel exist https://discord.js.org/#/docs/discord.js/stable/class/ButtonInteraction?scrollTo=channel
what is this bug ?
it's not a bug, channel is a getter
that is to say ?
it's not a property, it's not going to show up when you log the object
not everything is going to be displayed when you're logging entire objects, javascript does have a way to set properties as non-enumerable, and discord.js utilses that.
if you want to see all properties, go to documention for respective class, or try logging the value directly, instead of object that contains it
you can still log private properties and getters if you really want to, see showHidden and getters https://nodejs.org/api/util.html#utilinspectobject-options
Hi i think i found a bug in @discordjs/voice. Problem is: when i disconnect the voiceconnection and also stop the player i see 2 Sockets being not disposed when i look at the process._getActiveHandles() but if the player goes to idle because the resource finished rather then me using AudioPlayer.stop() it properly disposes that sockets is this my code problem or if anyone can replicate this should i make an issue on gh repo
if you can reproduce it on your own i think you could go ahead and make the issue to see if other people can reproduce it?
i am not sure if it is because of my dependencies, node version etc etc because of nobody ever pointing at this problem in anywhere so i didnt wanted to open an issue first
If you can reproduce the issue with a minimal reproducible example you can create an issue, then, if the problem is not in the package, the issue will be closed
okay i am making an issue
I see in the README, where are listed the optional packages, that erlpack is one of them, suggesting to install it using npm i discord/erlpack:
erlpack for significantly faster WebSocket data (de)serialisation (
npm install discord/erlpack)
But I see that erlpack is also published on npm so it's possible to usenpm i erlpack.
Is it suggested to install the package from GitHub for a specific reason?
Yes the published one is not published by discord
Oh, thank you very much
Is there any reason MessageComponentInteractions don't have a messageId? They have a channelId and guildId
Discord sends a channel_id so we show a channel id. Discord sends a guild_id so we show a guild id. Discord does not send a message_id. Discord sends the entire message object. Just get the id from there
Is there a typedef similar to GuildChannelResolvable but without ThreadChannel?
👍
Nu-uh
⚠️ WHO PINGED ME?!?!?! 
We have been experiencing a mention raid, our bot took care of it (#mod-log)
No, you don't need to complain about it
Yes, we will action shitposting in response to mention raids
do u guys think EventEmitter subclasses should be passed captureRejections? this allows proper error handling for async callbacks https://nodejs.org/api/events.html#capture-rejections-of-promises. ive noticed a few spots in the code where this occurs and obviously most users probably have async callbacks in some capacity
for a real world example...
client.on('ready', () => console.log('ready'));
client.on('error', (e) => console.error(e.message));
client.on('messageCreate', async (m) => {
// do some async task here that throws an error
throw new Error('whoops');
});
this will no longer exit the program with an unhandledRejection
you could make a PR for that
this is incorrect, that's not what the error event is for -- e: didn't realize this was #archive-library-discussion and there's a pr or something oops
with captureRejections, eventemitter auto emits the error event, regardless of how discord.js uses it as well
i've checked and the example works as expected
i thought this was support when i opened the server
continue on
Doesn't this say... experimental? o,o
yes but it has been there since around 2019 so i dont think it matters much
If it doesn't matter much, then they should remove the warning :P
But they haven't, so I'm uncomfortable with it
they have for v18 i guess? same with Blob & Web streams too
o,o
v14 will probably release with node v18? idk
or probably similarly to v13, which released with v16 as a requirement while it was on current still but it hit lts later
so we wont have to have try/catch in every async listener anymore?
as long as you have an error listener
so it‘s the same as if I listen to unhandledRejection
and handle rejections there
unhandledRejection event doesn't handle the errors, it just tells you there was an unhandled rejection
wait roly
rlly*
I thought it also handled them
I‘m not home atm to test it
so I just tested unhandledRejection and it indeed prevents the program from crashing
preventing the program from exiting and handling rejections are two very different things
const fd = fs.openSync('.'); // might throw error
// later on
fs.close(fd, ...);
although unhandledRejection prevents the program from crashing, you are still leaking file descriptors (for example)
I dont really get the difference 
idk what file descriptors are but nvm this is not the right channel
Wouldn't be good if it specified in the docs the permissions needed for both the bot and the user to run functions for example create a channel, timeout someone...
we cannot feasibly document permissions, discord can change them at will without any prior notice
they are documented upstream on discord api docs, but it's not feasible to copy these via PRs every time they're changed either
most that i can personally see happening there is a link to the upstream docs as to which endpoint is used
Node 18 is too far out for that, it won't even be in development yet
Even if listening to unhandledRejection prevents the program from crashing, that's mostly so you can log it and exit cleanly
oh alright so the method he suggested would be cleaner
it hits LTS in october this year, just like node 16 did last year
now idk how long v14 development is gonna last
that's really far out
considering the amount of features Discord is gonna add to get over the line for message intent and we've said no more v13 releases? I think you get the picture
yeah I see what you mean
so would the plan be to have v14 out by april?
No, far earlier than that
v14 should at least ship with modal support
Planning specific numbers on specific dates is troublesome when it comes to keeping up with Discord's release cycle
The date shouldnt matter. Just increment the version based on the changes we're making
both of these have the v14 milestone 
and at least the second one includes plenty of changes that would have to be tested
We also won't require Node.js v18 (geez, that's quite the version number) until it's near LTS or LTS, if it brings something useful
Second one is v15/TS

yeah we should probably...migrate that to a v15 milestone now
Yeah, whenever Crawl makes it
I wanted to get that in too, but there's already a lot of big stuff in v14, and its not the ts rewrite
The issue tracker doesn’t show everything, we want to make more internal changes like using /rest within djs
We don't want the v14 update to be as breaking as v13 was, as simple as that
Nope, it's hell to do that change without TypeScript
And there's still stuff to discuss
oh alright
more...incremental, most of the breaking changes are removals of deprecated v13 things
Because we want raw data storage to be beneficial, not a burden for those who are trying to scale their bots
Yup, we basically want to do major releases more frequently, as opposed to making large major releases every year or so
That way it's a lot easier to update between versions
just don't pull a dotenv who releases 3 major versions in a weekend
lol no
I think we want to do 2-3 majors a year, depending on how much stuff we want to do during that year
that's nice
And ofc also depending on what Discord releases
with a few patch & minor versions in between
yeah lol
rodry4contrib
This should also alleviate some of the pressure on people to upgrade major versions if its less likely v13 is going to break while we work on v14, v15 etc
Not relevant to this channel, thanks
this is what I'm really looking forward to, we're ahead of the curve on api versions now, so v13 isn't in imminent demise like v12 is
I'm not sure where to post this, and it doesn't feel important enough to go make an issue on the github.
But I feel like it'd be worth while to put a comment in the https://github.com/discordjs/builders readme that says it has been moved into a monorepo of the main repository. Cause right now it looks like it was archived for no reason and archived generally means "not supported anymore"
I'd make a PR but it's archived so 🤷♂️
Something like this at the top of the file
## @discordjs/builders has been moved into the main Discord.JS GitHub repo. New link: https://github.com/discordjs/discord.js/tree/main/packages/builders
Especially because the guide still links to the builders repository.
Yeah the other packages should say the same, not sure if one can commit to archived repos though
I recently came across that djs v14 uses discord-api-types which is cool. I was just a bit puzzled by the Subcommand thing, why is it Subcommand and not SubCommand when in UPPER_CASE it is SUB_COMMAND so in PascalCase it should be SubCommand
I think dapi-types has it correct because it’s one word in the docs: https://discord.com/developers/docs/interactions/application-commands#subcommands-and-subcommand-groups
Will the event messageCreate disappear after April? Or still accessible?
accessible
but if you want to see content, you need have message intent
People are lazy.. Starting a / command takes them too long 😅
okay, because i saw this
Slash commands are really good
Yeah think it’s a mistake in djs
Also, why did you choose PascalCase when discord uses UPPER_CASE in their documentation?
I mean, a user already has to upload an image (and the bot read out its content). That step often is already too much 😂. < In my case
It’s TS convention to use PascalCase enums
why do GuildEmojiRoleManager and GuildMemberRoleManager extend DataManager, when most of the other managers extend CachedManager?
is this a mistake?
It's intentional, since they don't store data but rather point to it
interesting
what exactly is the difference?
between datamanager/cachedmanager
don't they both have a cache
If you take a look at the source code you can notice the cache getter actually hides a redirection to another collection that's external, rather than an internal cache (which is what CachedManager offers)
DataManager does indeed not have a cache, and the getter just throws an error if you try to access it
CachedManager does have one and its cache getter points to it
ahh ok ty
in what situation would this.holds be falsy?? https://github.com/discordjs/discord.js/blob/12ffa069aa8b247e945fef16a543f41c2c391bf1/packages/discord.js/src/managers/CachedManager.js#L44
(i think this is a permalink for what you are referring to? i couldn't find a .d.ts) https://github.com/discordjs/discord-api-types/blob/03b8d3fee032fb77213389019baa2b80377dcfdc/rest/v9/index.ts#L756
Only guild commands can have permissions on them, so there's only one thing it can ever be
(source? where???)
If you realise that then the distinction isn't needed
Not our problem? They should read up on the routes they're going to use lol
can someone explain to me where this d.ts file comes from
i thought github was the source already
does that show up after installing and building the package?
When it's compiled d.ts are made
ahhh ok
Depends it can be hand-written or generated
Route names for the method are usually build from what the route says (guildMembers, guildBans, invite, channelMessages) etc. Annoying? Yes. Consistent? Also yes
yea I'm just curious where this particular one comes from, cuz he said "there's a d.ts in the 'source'"
but apparently they meant in the output
ALTHOUGH to be fair, it should've been applicationGuildCommandPermissions
who did this
Yeah in most TS projects it’s generated
does anyone happen to know the reasoning behind this check 
const entry = this.holds ? new this.holds(this.client, data, ...extras) : data;
wondering if there is any situation where data would actually be returned 
are components fixed in the latest dev release?
Likely not
They might be since they got replaced with builders but you can test them out
I'll try then
So components are but interaction.options.getSubcommand() isn't, I guess that will be fixed by the enums PR
That's not true anyways, global commands can have permissions, it is just scoped to a guild
here isNaN is used and isNaN don't check that is the input is a string or number. Is this intentional?
there's a typecheck right before it
Could change it to use Number.isNaN, which does both
yeah
Or actually no, we need it to return true if it’s not a number type
Number.isNaN only checks for NaN
you would still need the type check yeah, Number.isNaN is more specific to NaN
just seems unnecessary to me.
Number.isNaN checks for number type as well as NaN or probably Number.isFinite can be used
I think some of them can take Infinity tho
it gives false for strings which can't replace the typecheck, so why bother
It would also give false for NaN, which is correct
meant Number.isNaN
yeah just checked it + Number.isFinite also can't be used bcz of the infinity so current implementation is correct
All it does is v !== v, it doesn't check for the type
The global isNaN does Number.isNaN(Number(v)), which parses values to a number
yeah got it
Publish Dev has been failing sometimes recently, could you try rerunning it? https://github.com/discordjs/discord.js/runs/4867272929?check_suite_focus=true
I submitted a PR to address that.
Thank you!
Can we get a manual run of publish dev pls 
Done
Thank you!
On the latest dev the component constructors are exported from builders but they don't exist there yet do they?
It seems like there hasn't been a builders release since that was added so that won't work
would you guys recommend using enum resolver or importing types or just putting the raw number in code
