#archive-library-discussion
25217 messages · Page 14 of 26
There are times when things are intentionally not documented
when its constructed from an incoming message its the URL
its just a really weird field
it doesn't expose new information regardless
it would be easy to doc tho and it can be private
is there.. a benefit?
PR farming of course
everything in d.js is documented, even private properties and methods, so if this means users can actually see what properties a MessageAttachment really has then I'd say so yeah
Nah not everything is
In the past we didn’t document privates really
Indicating they are private therefore
One can say that documenting private stuff might help contributors especially new ones in understanding how the lib works 👀
Don't know it's worth doing for current version but can be considered for ts rewrite?
Just like you shouldn't be using discord.js when you're starting with JS, you shouldn't be trying to change internals on your own when you're starting to contribute to d.js, unless of course, you know very well what you're doing
Internals usually hide the most complex code of Discord.js
Didn't expect you to call out Rodry like that lmfao
Exactly, we forget what our code is doing when we come back to it after a long break. A 100% documentation will not just help new but even let old contributors to quickly grasp what a private piece of code is doing.
It will also improve the developer experience, where a contributor writing a public method gets helpful documentation while calling private methods in it.
Documenting everything is a great thing and with ts rewrite we have a chance to start doing it. We aren't getting any runtime penalty for documenting so I'm unable to understand why it's being seen as a bad thing.
I don’t PR farm tho, I just open PRs for stuff I stumble across and think is worth fixing/changing, and most get accepted
Yeah I agree but tbf for this specific property it’s pretty easy to understand what it does, just saying it could be documented if everything else is. Not gonna open a PR solely for that but if I find many others I might, if it’s worth it ofc
What are the plans for something similar to @discordjs/permission-helpers?
what do you guys think about a replyOrFollowUp() method on an interaction? what this method would essentially do is try to call .reply() , and if there already is a reply, instead of throwing an error it would call .followUp()
Similar module to perm-helpers
Hmm, helper method.
well yes it would just be for convenience
Doesn't followUp just replicate the behavior of reply if there is no reply yet/if the reply has been deferred?
oh does it? if that's the case then the method would be useless xD
Yeah I think that's done on Discord's side
so reply() is basically redundant? since we can always call followUp()
I personally dislike followUp so no not really
apart from personal preferences, is it?
whatever you wanna call it but Discord has an endpoint for that so it has to be there
yeah I don't want to say it should be removed, just wondering because if I can always use followUp() in my code I will
btw, I just tested it and calling followUp() on an interaction that hasn't been replied to throws an error
that would be expected, because the follow up will reply to the reply - which it can't if there is none
👍 I just wanted to say it because it would've made my idea useless if it worked
Ah nvm, only acts as editReply if it was deferred then
What is being used for managing the commit messages for the library? Stuff like feat: or chore: , etc.
Is that all with Husky and commitlint?
or something else?
husky enforcing commitlint https://github.com/discordjs/discord.js/blob/main/.commitlintrc.json
@opaque vessel how do you have an uncached guild to begin with?
Hey hey, sorry my wording was a lil' off. I meant the guild member was uncached (hence the partial bug report) - thank you for pointing this out <: I edited it now
Ahh alright. I will try to reproduce this and experiment a little tomorrow. If no one else opens a PR to fix it I might since I have a solution in mind but it may not work
Unfortunately any fix to this would be semver major though
So probably not worth the time now, just a minor inconvenience that we will have to deal with later
What is the scope field in the commitlint meant for in the repositories? Is it just what component was worked on?
So if I made changes to Message, would I do something like feat(Message): increase character limit
yes, that's right, the area of which the commit was made in
usually it's the class or area of code affected
aha, kk thanks
Would rebasing commit messages be the only way of adhering to that standard? I have already made a lot of commits on a repo that did not adhere to the standard.
the maintainers would edit the PR title most of the time before committing them, if it so happens that it's already pushed to the main branch then 🤷♂️. but if you can amend the commit then sure, not all rules are strictly followed though
ahh, yea, I heard about the squash and merge method of controlling PR's
@outer raven "Scope" doesn't refer only to the files you edit. If a PR does one, specific thing, it should not become a sink for random commits you decide to dump into there regardless of what they do, just because "they touch the same file".
What happens if it turns out that your PR adding new ES features broke something for any reason? It could be reverted, but then we also lose every single thing you decided to dump there that was completely unrelated to the thing that was initially being changed at all.
Also lol, you went "why change 😕" on the PR for links, but then decided to dump it under your own PR
Yeah I get it but this was a very small thing and it’s ok if that gets reverted.
I said “why change” because the other lad opened a PR just to fix some links in the tests, when it could’ve been bundled somewhere else
small or not, it doesn't change the fact if it's in scope or not
"why change" doesn't sound like "this could be handled in some bigger bulk"
"somewhere else" should still probably be somewhere in scope of fixing old links or a general, non-code chore
and i don't think it's for you to judge what is "too small" to have its own PR
IMO yes, but i'm not the one to speak for that
Should I tag Crawl then
Alright I just undid that commit and addressed the unresolved conversation, sorry for that
Also considering this is still pinned, @unique axle have you considered updating this issue? https://github.com/discordjs/discord.js/issues/4961
It still references stuff that was removed in v13 so it's probably better to do so
#6551 in discordjs/discord.js by tignear opened <t:1630246622:R> (review required)
fix(xxxable): follow more properly with discord behavior
📥 npm i tignear/discord.js#fix/follow-discord
Why is this a major and not just a patch 🤔
It removes a method
Uh, what method I didn't notice
VoiceChannel#deletable
If this, it's already implemented in GuildChannel... It was an override
Or is it considered major the same, even if it's implemented in the parent class? 🤔
I'm not really informed about this lol
I mentioned it in internal a few hours ago, but Crawl didn't see it
It's corrected now, dw
Oh nice, thx
Why does awaitMessageComponent now return a collector??
Did anyone test #6476
If anyone knows suneettipirneni's discord please tag him, idk who they are in here
btw it seems like this only happens with awaitMessageComponent, not collectors
Hullooooo @tacit crypt, are you talking to me there :eyes: what I do halp
You install deps
Run..uh, i think build:deno
And push the changes
thats me
I think ik what the issue is but lemme test it first
I managed to sort it out :D It now changes the deno/payloads/v9/ file, the same one as mine
you essentially made awaitMessageComponent and createMessageComponentCollector return the same thing
Pushed @tacit crypt
yeah and unfortunately the tests I wrote checked the wrong types
Can you also update v8? 😇
Would changing the possible type of a property from undefined to null be considered semver major?
yes
alright, won't do that then
any plans to add the bulk overwrite endpoints (
https://discord.com/developers/docs/interactions/application-commands#bulk-overwrite-global-application-commands
and
https://discord.com/developers/docs/interactions/application-commands#bulk-overwrite-guild-application-commands)
to ApplicationCommandManager?
oh they are
thank you
😬
Shouldn't https://github.com/discordjs/discord.js/blob/main/docs/logo.svg be updated or does this logo not even matter
For interactions we have .isButton(), .isCommand(), etc, is there any reason things like channels don't have a simular thing? For channels I often have to do channel instanceof TextChannel to ensure its the correct type so it seems a bit oddly inconsistant that interactions use .isWhatever rather than also being interaction instanceof ButtonInteraction. Would be useful for consitancy to add it to channels as well
isText()
GuildChannel#isText()
Indicates whether this channel is TextBasedChannels text-based.
oh
Guessing that got added v13?
https://discordjs.guide/additional-info/changes-in-v13.html#channel-1 ah yeah, looks like ill have to read through the docs see if thers any other super helpful things iv missed
i don't think it would be included in the additions section if it wasn't added in v13...
also wouldn't that fall into a minor update, not a patch?
Who cares
is invalidated event still a thing? Can't find anything about that in discord.dev
oh it is custom event of djs
Do we need to sign our commits when submitting PRs?
i'm like 38 commits deep and I just learned about signing commits
does that mean they get signed when the maintainers squash and merge then?
I'm not sure how it works actually.
Is signing commits really that important?
YES ITS CRUCIAL
In Git, you can commit as anyone, which means you can also impersonate them. This is because Git is a decentralised system, and pushing other people's commits (e.g. rebasing a PR with commits from different authors) are required to work. To prevent impersonation, you use GPG/PGP signatures, so everyone can verify it's you the one who committed and pushed, and not somebody else.
Note that if you commit through the GitHub interface, the commits will be signed by the commiter (on merge for instance)
Commiter? Thought it would be by GitHub
Yeah, those will be via GitHub itself Im pretty sure
Github displays it like if it was the commiter who signed it, but yeah
why doesn't ClientVoiceManager extend BaseManager? not really important, but just wondering, i don't see any reason for it to not do that
I doubt there is a reason for it, probably just an oversight.
was just looking at the docs folder lmao
I think it used to be used on the old website but now it isn't since the logo is correct on the new one
because its not a cache manager
(see below, ClientVoiceManager doesn't really do what the description for BaseManager says)
BaseManager
Manages the API methods of a data model.
@wild flax what's the difference between types and typings and why do you always edit the title of PRs to say typings instead of types? When should types be used?
I can’t remember if the changelog gen picks up types correct
So i change it whenever I remember
Lmao
ahh ok
so maybe it should be removed from commitlint?
actually typings isn't even allowed now that I look at it
is Message#createMessageComponentCollector supposed to be able to take InteractionCollectorOptions<T>? Because using the interactionType field and/or the channel and message fields doesn't affect the message component collector?
https://github.com/discordjs/discord.js/issues/6409 has the has pr label but the PR was closed, should this be closed as well?
i closed it just now
ah aight
interactionType should work, message and channel would not
Though isnt that componentType anyway?
But wouldn’t interactiontype always be the same? It would always be a message_component interaction, right?
Right, yes
So wouldn't MessageComponentCollectorOptions<T> be a better fit rather than InteractionCollectorOptions<T>?
it already exists
Then yeah probably
ok cool, just wanted to make sure
I can see the second one but uhh.
BaseManager doesn't have cache, DataManager does
I'd say it would still fit into BaseManager depending on how you interpret the wording though, and I think something like disconnectAll would be useful if discord would allow that (or if it's already in @discordjs/voice? i can't seem to find the docs for that)
In the ws property of ClientOptions only large_threshold is documented but the createDefault static method in Options has other properties: compress, properties and version. Also, compress and properties don't seem to be used anywhere and version isn't in the typings...
What are correct the options for this object?
I think what they currently are.
If anything compress and properties shouldn't be there at all, compressing is not supported by us and properties shouldn't be messed with.
So only large_threshold should be used? Now I see that neither large_threshold is used 🤔
Only the version property is used in the websocket and it's the only which isn't in the typings 😂
BaseManager only has the client property and ClientVoiceManager also defines its client property so it could extend that so that the code doesn't need to be duped
perhaps a more useful change would be adding the id property to Base instead of assigning it in the constructor of every extending class
if you're looking to remove duplicated code
id?
the id of a structure
that would be a bigger refactor, would you like to do that and do this ClientVoiceManager thing too?
doesnt really make much sense for ClientVoiceManager to extend BaseManager
it doesnt manage any methods for any data model
BaseManager only has the client property
cache is from DataManager
its not about the properties it has its about the description of the class
that description should probably be changed then because a BaseManager doesn't manage much, that's probably a leftover from when it was moved to DataManager
well yeah that manager does, but BaseManager has no properties or methods other than client, so the description could be updated
its just not the same type of manager lol
hm?
all the other managers do what the description says
but the ClientVoiceManager simply manages voice state changes
iirc this isn't really feasible 
one second
why not tho
can't find the conversation I'm thinking of
point is, there's structures that don't have IDs that extend base - which is why its not there
so if you wanna go about doing this you should make another "base" that adds the id and the structures that don't have an id to continue extending this class
there should be some changes needed there then?
Represents a data model that is identifiable by a Snowflake (i.e. Discord API data models).
and https://github.com/discordjs/discord.js/blob/08419561edd710a6574b5e1449bf5dc1040580d5/src/structures/Base.js#L38-L40 returning undefined
- Yeah that's def been talked about before
uh, "talked about", as in, brought up and not discussed further 
I 100% remember a conversation about why id isn't on base and the jsdoc being weird, but I can't find it for the life of me no matter what search terms I try
it might've been in #archive-offtopic or something but that'd be a pain to dig out
@tacit crypt when I switch to the enums in the context builder pr should I stick to inRange or should I switch it to oneOf, they would be the same right now but if discord adds more types later, oneOf would be more readable imo
oneOf maybe?
got a list of classes that extend Base and don't have an id property btw
[
'GuildBan',
'GuildTemplate',
'Invite',
'InviteStageInstance',
'Presence',
'Typing',
'WelcomeChannel',
'WelcomeScreen'
]
||code i used to get this list if anyone wants to see actual hell: https://pastebin.com/LatwWFXQ||
so uhh yeah guess there are some classes that do extend base but don't have an id property
why are the prerequisite modules for using /commands not installed by default
Because as wizo said, not every bot depends on commands (regular or slash). There are so many bots which just does specific things on ready like that and doesn’t rely on commands. Thus those modules are burden/extra for them.
Isn’t it the best practice to have only what i need? I guess that’s best to install slash modules only if he needs that.
I hope you read the rest of what was said, but tl;dr not every bot depends on can be said about almost everything , but realistically, almost every bot uses commands
[and in the near future, /commands is expected to be the only available option for commands for most bots]
I dont really know what you mean
We just tell you to install the additional modules as you reach the concepts that need them
hm
fetching invites to unknown channel types also causes an error lol
ig channel is null so its the same issue as fetching friend invites
this looks like discord's bad but it essentially makes CommandInteractionOptionResolver#getMember unsafe/unusable with the second parameter as true as you can pass in an id into a USER option and if the id is a valid user id (but not a member [not sure if has to be member of the guild the interaction is in/didn't test]) the interaction will go through and the method throws the error ```
node_modules/discord.js/src/structures/CommandInteractionOptionResolver.js:100
throw new TypeError('COMMAND_INTERACTION_OPTION_EMPTY', name, option.type);
^
TypeError [COMMAND_INTERACTION_OPTION_EMPTY]: Required option "user" is of type: USER; expected a non-empty value.
at CommandInteractionOptionResolver._getTypedOption
`CommandInteractionOptionResolver#getUser` seems to be working fine though
im on djs v13.1.0 btw, not sure if it's been addressed/fixed in master
Not sure what else you would expect it to do
If theres no member of the guild, getMember cant possibly have a value to get
And if you pass true to make it required, it will throw an error
Sounds entirely expected to me
they why i said "this looks like discord's bad".
I mean... I also don't understand what you expect Discord to do about this
If you provide an ID of someone who is not in the guild, Discord cannot possibly give you a GuildMember
if you pass in a channel id discord just doesnt send the interaction
To what type of option
USER
i guess yeah, thats true
but doesnt this make getMember unsafe
with the required field true atleast
So dont make it required
Or do, and catch the error, and handle it and tell the person using the command that this user isnt in the guild
This is entirely up to you how to control this behaviour
mhm
Its unsafe not to handle an error, no matter why it happened
i expected the error to be not possible because it should always be there if the option is required. but i guess with the nature of the method as its not based off of the option types provided by discord, it makes sense
The getUser will always be there if you make the option required
yeah, i did test that
But a required option isnt the same thing as making the resolver required
In fact if its a required option, theres no reason to make it required in the resolver at all
The resolver gives you error control flow
doesnt it provide type narrowing
eh I guess, if TS
yea yea
i guess this would be a discussion for if this persists when/if discord introduces a member type for options
and still it wouldnt really have anything to do with djs i guess :p
is it worth adding a note to the docs that it throws if the user isn't in the guild?
@stable sequoia @copper laurel ^^
No, that should be common sense
No guild member for someone who isn't a member of the guild
It also won't throw if you don't make it required
it would be kind of a wacky workaround to mark a required parameter as optional, but yeah i agree that its obvious, but also might confuse someone seeing the error
which is why i think a warning wouldn't exactly be the worst idea
The option being required is not the same thing as forcing the resolver to resolve something or throw
A required USER option will have a User
I may or may not have a GuildMember
So you can resolve it without required:true and check undefined
Or resolve it with required:true and try/catch the possible exception
Like I said early, the resolver option is an error control flow, it doesn't really have anything to do with if the option is required or not
looks like not everyone knows that the user param takes ids. it would be nice if the guide or docs had a note specifying that (if it doesn't already)
yea
but i do agree marking a required param as optional feels weird, and i feel like most people wouldn't think of that
is there really a point in even having the required parameter for getMember (although this isnt a change applicable for v13)
i don't think so, unless you would prefer for it to error instead of returning a nullish value
i would definitely rather have the 2nd param yeeted and have it nullable so more people don't walk into this but you guys might know better than me
having it nullable just feels right compared to the current behaviour imo
because the required param is kinda irrelevant
You're not marking it as optional
You're simply choosing how the resolver should behave
They are not the same thing
If you want it nullable stop using the second param, there's literally nothing more to this
Why do you want to take freedom of choice away?
If you mark getMember() as required then you're telling the code that this function requires a GuildMember, and will throw if one cannot be resolved
You could alternatively use getUser and resolve the member later, this way you can be sure if there is a member and make your own error if not
that just makes it more complicated than using it with optional false though?
in what scenario would i use <CommandInteractionOptionResolver>.getMessage()? https://discord.js.org/#/docs/main/stable/class/CommandInteractionOptionResolver?scrollTo=getMessage
i don't think there's an option of type MESSAGE for slash commands
There is? It’s a context menu command for messages
Yeah strictly for context menus
oh. that makes sense. i was too tunnel vision on slash commands.
I found another bug with Message but this one is about Message#pinnable, would that fix still be within the scope of #6581?
#6581 in discordjs/discord.js by ImRodry opened <t:1630614289:R> (review required)
fix(Message): throw error on missing channel
📥 npm i ImRodry/discord.js#fix-edit-no-channel
the bug is that the getter returns false on replies and other messages that should be pinnable, so it's not related to the channel being missing which is the original scope of the PR
Meh all these bugs about permission checks makes me think if they should exist in the first place
same but they can't be removed now. I can't wait for that permission helpers lib tho
and I think this was missed because you can only crosspost DEFAULT messages, but you can pin types other than DEFAULT
also for ThreadMemberManager#add you can pass @me as the member which results in the function returning @me which isn't a Snowflake. Should the docs and types be updated to say this or should the function be updated to send the client user's ID?
For types Snowflake is a string so @me is acceptable
Snowflake is strictly typed as a numeric string, not as any string anymore
Is it? Thought the ${bigint} was reverted
Afair only in discord-api-types, or something like that
Yeah, that's what I meant. Actually if I import the Snowflake type from discordjs I see that it's of type string and I see the discord-api-types description
I wasn't aware of that change but the definition of a snowflake is a string with a bigint inside
so @me should not be considered one
Yeah that only makes it easier to use for convenience, but doesn’t change what I said above
Also @unique axle why is the partials part in the issue template required?
have you checked PRs?
@tacit crypt since you reviewed, can I get your opinion on this?
here
The answer is simple: Is it related to the this.channel change? If yes, in the same PR, if not different PR (at least imo)
yeah it's not, I'll make a separate one
hello, i have a suggestion/request i dont know where to send this. anyway if you have a multiline string like this in embed, the indents are visible on mobile devices (pc discord seems like it parses automatically but not mobiles. it would be good if there was some middleware option which would allow us to remove indents in one place rather than for every message separately. its not big deal but it would be nice and helpful feature to have
that's how js works, dude
you can use common-tags to do that with a tagged template string, but that really has nothing to do in lib discussion
https://www.npmjs.com/package/common-tags#stripindents
i know that this is how js works and I know I can use some function but im asking for library implementation where it does this automatically because there is no good for it, or like I mentioned a middleware which gets called each time before a message gets send where we could handle it ourself in one place
stripping indents from your strings is not something a discord library should do
then the middleware :/
souji just linked you some
then define a function somewhere and pass content to it before sending it?
.send({content: prepareContent(stringHere)})
you dont understand forget it sorry for your time
i understand, you want to define a middleware somewhere (client options, maybe) that every message content gets passed to before sending it off to discord
yes but this doesnt solve it, i'd have to go to every single place where message is sent (rougly 2000lines) and pass the content into the "fake" middleware function. I could just use the strip intent at that point.
thats not really how middleware should be made
sideone why do you think a library for interacting with a discord api would implement string cleanup
there could also be middleware for kicking, banning deleting messages not just my request
if you didnt notice we are already talking about middleware
you know we have managers 
what does that mean?
MessageManager for managing messages (ie deletion), GuildMemberManager for managing guild members (ie kicking & banning)
and how does that relate to middleware?
but yes the Manager classes could have have an optional middleware function which could be set (maybe like the makeCache thingy)
adding middleware across the library that modifies options before making api calls is not something the library in its current structure supports.
if you want that feature i'd suggest opening a feature request on github, so it can be tracked https://github.com/discordjs/discord.js/issues/new/choose
im banned on the repository 😦 thats why im asking here
ill actually respect the ban and not make new account but please could you reconsider with the staff my unban? I havent done anything terrible really it was stupid joke
I've encountered the following issue when my bot leaves a guild:
Trace Stack: DiscordAPIError: Unknown Guild
at RequestHandler.execute (C:\goat\node_modules\discord.js\src\rest\RequestHandler.js:298:13)
at runMicrotasks (<anonymous>)
at processTicksAndRejections (node:internal/process/task_queues:96:5)
at async RequestHandler.push (C:\goat\node_modules\discord.js\src\rest\RequestHandler.js:50:14)
at async Guild.leave (C:\goat\node_modules\discord.js\src\structures\Guild.js:1222:5)
is guild.channels.fetch() supposed to force-fetch the channels from the API everytime? The docs state that it does a force fetch unless the channels are cached, therefore returning the cache. I used guild.channels.fetch() in a loop and it got ratelimited after 8 iterations (for doing the force fetch). Providing {cache:true,force:false} to fetch options does nothing too
the cache check is only done if you try to fetch a single channel
otherwise you can't tell if a channel is missing
@grizzled scaffold wdym the plugin has been uninstalled? (#6587)
is it true that discord will only support slash commands?
Discord has indicated they will not approve bots for the message intent for regular commands if that's why you apply. This does not apply until your bot needs to be verified
Well, my bot is already verified, so probabbly i will have to reapply for the message intent since i use regular commands like ban, kick, mute
You will be rejected since message content is not required for any of those commands.
I meant the plugin specified in the jsdoc.json file, jsdoc-strip-async-await
U sure it isn’t needed tho?
Yeah I tested it and the file isn't referenced anymore
Is there a channel I can ask about unit tests? Of a bot, not the library. It is proving quite a bit more difficult with slash commands as I pretty much need CommandInteraction objects. Is there a way to create one through the library with particular values? Can I "new" one somehow?
You can use @discordjs/builders for building slash commands (like Embeds), when you meant this.
@quiet viper That is what I'm using. I'm trying to unit test my bot and so I need to generate the "responses" that such commands generate without (always) installing the commands and typing in multiple different responses. The unit tests run independent of the bot.
#869655843958821005 might be useful for you 
It definitely looks like there is info there. Is that just a message though? I don't know what that thing is a special channel?
its a thread, you can discuss there about it, share your ideas....
excellent... thank you
Its not, I was kinda wondering how long it would take someone to notice it should be removed 
@ruby terrace allow me to grab your attention while you're still here. you mentioned a while back something about discord making an overhaul for slash command permission. would you mind answering this? #archive-interactions message
https://github.com/discord/discord-api-docs/discussions/3581 as well as the FAQ they held on the ddev server some time ago
found it. thank you
i know im on the wrong channel but, im currently making a PR for the guide and i was wondering if it would be ok to include a little note in the section about slash command permission that links to that discussion? the note can say something like "Permissions for Slash Commands are getting updated by Discord. You can see the discussion here. For now, you can manage your slash command permission with the different methods explained in this guide"
no, guide content is supposed to be long-term
this feature is not developed enough to even mention + the discussion itself is meant to be temporary to inform devs of "things to come potentially, hopefully soon™️"
no, guide content is supposed to be long-term
would you suggest keeping the current section about slash command permission as is then? I already wrote a more extensive explanation for that section, but now im not sure if it's worth including it in the PR because of what you said. I could include my extensive explanation in the PR, and simply omit the "little note that links to the github discussion".
if you improved the current explanation sure, go for it
just that temporary notes should not be included
(there have historically been exceptions to that rule with the temporary intents explanation, just because of the sheer amount of people facing the problem)
👍
So I'm just kind of curious, why the hard requirement to bleeding edge NodeJS? What is it about this library that hinders support for LTS?
Pretty sure that has been answered numerous times by now
check the issue or search for it on the server
Was invite information removed from the guildMemberAdd event? As I know it worked just fine on V12, figured I would ask here as it's more of a library thing. Any thoughts?
I have searched the changelog ^ Nothing touches on it.
there never was invite information on the guildMemberAdd event
I used to be able to fetch invites when a user joined, and it could log who invited them, what happened to being able to fetch invites?
You'll need to be more explicit than that, and I'm pretty sure this falls outside of this channel
Methods have changed and you'll need to update to the new ones iirc
Can I ask a question about a discord.js code here ?
This channel is about development of the library, or its source code
Questions about using discord.js go in the help channels
It's about its source code so ig I can
It's about the compression part of the ws client, the chunk size where did the number came from? I'm trying to understand why but no clue
Sorry I'm on phone rn
I'll check out thanks for the answer
imo the messageReactionRemove should emit if uncached and the partials are enabled similar to messageReactionAdd
i checked the code for messageReactionRemove.js and there is no place where it tries to check if partials are enabled
https://github.com/discordjs/discord.js/blob/main/src/client/actions/MessageReactionRemove.js
The action handler specifies partials in it's calls to Action#getChannel, Action#getMessage and Action#getReaction, all of which internally call Action#getPayload where partial handling happens
ah, alright then. thanks
why do some managers have fetch options (cache/force) as a combined object with the target (ie GuildMember, Guild, etc) while others have the fetch options as a seperate object as the second parameter? (ie User, Role, Channel, etc)
I believe the former managers you described have several overloads, and the latter ones you described don't
overloads?
why not merge interaction.update with interaction.editReply? if the interaction is already updated then just use editReply
Sounds lazy. Those methods are not the same and shouldn't be used as such
Aren't they fundamentally different? update() edits (updates) the message the component is on, whilst editReply() edits the original reply to an interaction?
@tacit crypt @solemn oyster @wild flax
i want to PR to next with doc gen, literally ported from sapphire. thoughts?
We have no interest in merging editReply with either reply or update, they do different things
@dawn merlin re #6600 I don't understand why you think member and guildId would be non-nullable
mistake on my end. For some reason I thought that guildId was the guild ID the bot was in, but that doesn't make sense, and member shouldn't be there
No worries then
I hate to be that guy but there’s been a series of bug fixes and new features in the main branch that haven’t been published on a full release yet, discord api changes included, so when can we expect a 13.2 with those?
Bug fixes should be able to be released with a 13.1.1
But it's usually a lot of work to cherry-pick commits that way
No cherry picking around here
Is global rate limit handling in plan?
or rate Limit handling across shards?
should there be a Rolemanager#setPositions, or rearrange?
https://discord.com/developers/docs/resources/guild#modify-guild-role-positions
basically a method that takes in an array of roles, and rearranges the roles accordingly
right now if i wanted to rearrange my roles, discord allows it but it's not a thing on discord.js afaik
https://discord.js.org/#/docs/main/stable/class/Guild?scrollTo=setRolePositions this seems to be the method
ah didn't notice that was there, thanks 👍🏻
I would think it'd be on the rolemanager 😅
@tacit crypt were gonna need that -types version fix to bump the builders dep
I am aware
👍
The thing is mostly the api changes, and those are semver minor iirc
Issue Form Feedback
Would it make sense to create a CategoryChannel#createChannel() method that creates a channel inside that category?
The only thing I'm struggling with this is the documentation e.g. the name of the typedef and if it should just have all properties from GuildChannelCreateOptions and then make that extend the new typedef. What do you guys think?
i dont think that method would be a bad idea
as for the documentation/typedef:
just all options except for parent, and of course don't allow the type to be a category channel
So something like this
{Object} CategoryCreateChannelOptions
- (all options from GuildChannelCreateOptions except for parent)
{CategoryCreateChannelOptions} GuildChannelCreateOptions - only unique option is parent
does that sound good?
pretty much yeah i guess
also are we supposed to be able to pass a GUILD_NEWS_THREAD type to GuildChannelManager#create?
GUILD_PUBLIC_THREAD and GUILD_PRIVATE_THREAD are excluded from the typings, but not that one
no, news threads didn't exist when I did that and forgot to update, feel free to fix
There's no route for this tho.. that'd be a d.js alias, and I'm not sure how many of those we have nowadays
we do have quite a lot of those and this would make it easier to set categories and also replicate the behavior on the client (the + next to the category name) so I don't see a problem with this
I didn't say no, I mentioned other things.. what aliases do we even have nowadays
ThreadChannel#fetchStarterMessage I'd say is one and there surely are others, I just don't remember how all of them work to know if it's a shortcut or not
now am I missing something here or is TS drunk? The error is saying the type of the type property is not compatible
And what's the actual error it gives
it is a type, but Omit is also a thing, I can try
exclude is a type
Oh interesting
I never used Exclude
Just read on it tho
Can see where it's useful
The presence of helper methods in other places in the library is not a strong argument to add more. I don't see the point of basically duplicating the channels#create method to set one value for the user
Isn't the lib moreso removing helper methods these days anyway?
if you pinged me I would've seen this earlier but the PR is made now so I'll leave that up for the reviewers.
Either way no code is being duplicated, this method just calls the method from the manager (just like other trivial things like Message#edit) and the function actually exists on the client, so I don't see why not
#6614 in discordjs/discord.js by ImRodry opened <t:1631141001:R> (review required)
feat(CategoryChannel): add createChannel shortcut method
📥 npm i ImRodry/discord.js#feat-category-createChannel
Search exists on the client but we don't implement that
because there aren't endpoints to do that easily I'm guessing
it would be possible, but unnecessarily hard
There's no route for this either, but you're still proposing to add it
Feels a bit weird that the GuildChannelCreateOptions extends CategoryCreateChannelOptions. The former shouldn't be relied on the latter as it's just some helper
it's just a way to not duplicate the descriptions, but I can keep the old typedef as it is if u want
#100 in discordjs/website by ImRodry opened <t:1630101593:R>
Expand all extended typedefs by default
also this would really help with that ^^
Don't like moving a manager method off the manager either
If anything I do feel the reliance should be swapped around
Also bots can't create store channels due to needing to pass a sku id which isn't a field during channel creation
I've seen that in an issue, but that's outside of the scope of my PR
Yea maybe, thought I would mention it since I noticed an overload there
so if the manager supports store channels, this method must do too
you can leave that in a review and let the managers say if that should be removed from the manager or not
Last night I looked to see if store channels explicitly were noted to be unable to be created in Discord's documentation but I couldn't find anything, soooooo... maybe not a strong enough reason to remove it vs. it could be added in the future (big chance no) so idk
sku_id and optionally branch
Been a few years, still a no-no
Seems like a very redundant shortcut method tbh
why
I don't know how to answer "why" - because that's exactly how it seems to me
It saves you passing a parent option directly and... thats it
I also think that createChannel naming convention is a step back towards the pre-managers style of v11, most instances of that sort of interface have been removed
there wasn't a better way to name it, since children is only a collection, not a manager
But if a category channel has children, why wouldn't you be able to add children to it directly in the class?
children is only a collection, not a manager
This is why
there's no reason to make it a manager though is there
No, and there's no reason to have a create method on a single object instead of the relevant manager
is it intended that https://discord.js.org/#/docs/main/stable/class/ApplicationCommand doesn't have the options typed?
if you are looking for the typings its ApplicationCommandData
@vernal atlas
I tried for a bit but I have no idea how these types work so I'll leave that for someone else to do in a different PR
oki
type ExcludeEnum<T, K extends keyof T> = Exclude<keyof T | T[keyof T], K | T[K]> seems to work
not quite
you need to use it as ExcludeEnum<typeof Enum, ...>
will do but testing this on TS playground makes it seem like passing DM is invalid but 1 is valid, which it shouldn't
you can't disallow out-of-range numbers using Exclude
that's a limitation of ts number enums
for instance, this code is valid too
enum Foo {
A = 0,
}
const a: Foo = 1;
in fact I see
it's only validated for string enums
eh but I guess it does make it shorter so I'll add this
this shouldn't be exported right?
on second thought, I probably wanna add this type to other things that use Exclude the same way these interfaces did so I'll wait for this to be merged then open a different PR with the new type
I think that it would be great if there was also a list of the intents/permissions that a bot needed for each of the methods.
It is really hard sometimes to know what permissions the bot needs to operate.
we deliberately don't document these, as they are documented upstream (discord api docs)
adding DAPI doc links would be ideal, however unfortunately they change so regularly because someone decides to restructure docs, that that's not all that feasible either
Regarding issue 6602. If that is an API bug, how should it be reported to Discord?
Ok. Thanks!
For things that can be a Snowflake or a regular string (like reactions) should the docs include both types or only string?
Cuz I've noticed this behavior is inconsistent in some places
Can you give an example?
Integrations are documented as Snowflakes in some places and strings in others, and they can be both
So which one should it be?
Decided to go with Snowflake|string just like reactions
#6623 in discordjs/discord.js by ImRodry opened <t:1631324641:R> (review required)
feat(Integration): add missing props and fix docs/types
📥 npm i ImRodry/discord.js#feat-integration-props-docs
Is it a bug that calling .update on an interaction with new files appends the files instead of replacing them?
is this documented somewhere? if not would be good to
Documentation suggestion for @mighty sequoia:
Message#edit()
Edits the content of the message.
MessageEditOptions
Options that can be passed into Message#edit().
https://discord.js.org/#/docs/main/stable/typedef/MessageComponentCollectorOptions shouldn't this have some description or are those optional?
It can have a description, but no description doesn’t hurt either
can someone explain the purpose of the discord-api-types package? what exactly does it do
I'm looking thru the repo on github rn and I can't tell if this actually parses the API responses or just documents them
like are there transformers or anything in this package? or just types
i.e. can this be used to verify json responses at runtime?
sorry if this is a dumb question, but if it's only types then why isn't the whole repo just .d.ts files?
why should it be?
isn't that what declaration files are for
it also holds static values to be used with the api iirc
aren't d.ts files supposed to work along .js files? since typescript would be able to work our everything from .ts files, .d.ts would be useless for it
since there isn't any .js code in the -types, and there isn't really anything that would be .js to which you could match a .d.ts, the repo can't really be a bunch of .d.ts files.
for typescript libs d.ts is not useful - .ts is enough for typescript
for javascript libs, .js is ambiguous type-wise, so you use .d.ts to type existing codebase without rewriting it to .ts
The repo provides static types for Discord API. The compiler generates .d.ts files using the repo which gets published for end-use. TS compiler uses these types to catch errors at compile time, but if you want to validate something at runtime, you can use a lib (https://github.com/YousefED/typescript-json-schema) that generates JSON schema from static TS types and then pass that schema to ajv (https://github.com/ajv-validator/ajv) compiler for validation.
And there's also JS code emitted from it (enums and util functions as an example)
@tacit crypt I think there might be something wrong with dapi types or am I doing something wrong?
you need to use EmbedType.Rich instead
Or cast as const
why use enums then? In djs you can use string types pretty much everywhere
also yeah it doesn't, I tried
djs usually uses keyof typeof Enum
so then you get a union that a string is assignable to
that doesn't work either though
wdym?
I edited the types file on discord-api-types to say keyof typeof EmbedType and that didn't work either
actually, Rich works, but rich doesn't
well because the enum key is called Rich and not rich
also I don't think djs has any string enums anyway
yeah true, they're all numbers
You don't set type anyways
Discord even explicitly tells you that it's ignored
@outer raven ^
yeah I know I was just experimenting with a type due to an issue someone opened, but it doesn't really matter in this case
Considering image sizes for the makeImageUrl function in Constants end up being transformed into strings, should we allow string types as well as numbers? I'm saying this because the error can be misleading if a user does use strings for the image size
or maybe we should throw a different TypeError instead
format is for the file format though, not the size
so that screenshot seems unrelated?
from testing, giving 12 and "16" both give just 12 or 16 in the error so yeah i think that might be a bit confusing, i think maybe have a seperate error for being an invalid number vs any other invalid value? like getting a string
Wait bruh I entered the wrong thing
The error is still the same tho
what you said still applies though
RangeError [IMAGE_SIZE]: Invalid image size: 16
this could be pretty confusing
Yeah that’s what I’m saying. I don’t see any reason not to do Number(size) in the includes check though
In the hypothetical scenario that a user sends the size value from a url they received they’d have to turn it into a number for it to then be turned into a string again
So it would be rather easy and useful to allow both
Shouldn't the style default to f here?
the default is from discord processing the text iirc
Yeah, they default it to f but I just thought that would be displayed in the default column
that would be the defaults for the function though, not the displayed text in discord
don't see any reason to provide a default when the default is provided by discord, not djs
If discord would change its default (really rare thought) we need to change it as well. Also it's related to that function, not discord
that makes sense, thanks so much for explaining to me even tho it's kinda off-topic for this channel
does d.js do this? how can you be sure that the api responses will be correctly shaped
or does it just assume everything is correct
tldr does djs do any runtime type checking?
Can I get feedback from a maintainer on this please? (disregard the wrong screenshot, I meant to write size but the error still applies)
why not
also this
Discord API is well documented. No, discord.js doesn't do that because it's not required but we do check for values that may or not be available before accessing them
thank you 
Why do methods like VoiceStats#setMute or VoiceState#setDeaf require the member to be cached if GuildMember#edit just calls the manager which only needs the member's id?
could this be improved so that this error could be removed?
I found the commit that added this code and it was before managers were introduced it seems like, so this can now be removed
can you send link to that commit
Why does deleting an emoji (GuildEmoji#delete) support passing in a reason as an argument? It doesn't seem like that's a param for the api endpoint (https://discord.com/developers/docs/resources/emoji#delete-guild-emoji) and it also doesn't show up in audit logs or something as far as I can tell
The reason gets sent in the X-Audit-Log-Reason header
oh, well yeah that makes sense
https://github.com/discordjs/discord.js/issues/6627 could someone update the labels on this issue
Done
Thanks 
is this change intended => interaction.options._subCommand to interaction.options._subcommand intended? (_subC... to _subc...)
Yes
where are the accepted default color values for ColorResolvable taken from?
the ones at https://discord.js.org/#/docs/main/stable/typedef/ColorResolvable or at Constants.js:514
from this array as you mentioned: https://github.com/discordjs/discord.js/blob/stable/src/util/Constants.js#L514
er, that's an object, and im asking where the colors are from, not where the source code is...
Some are from discord’s branding colors but most seem random to me
For reference https://discord.com/branding
in Message#equals, why is rawData mandatory? (at least in the typings)? because you check wether it exists or not before using it, so why make it mandatory ?
It was used to check if two messages were equal on MESSAGE_UPDATE a long time ago. I don't think it's referenced anywhere internally and that code hasn't been touched in years. It probably can be removed
👍 i realised i don't need it, but thanks for the answer.
**
**btw is it planned to improve audit logs typings? because i always have to do things like this (probably missing property, but those are only the ones that i use), and they're starting to pile up quite a bit.
export interface MessageDeleteAuditLogsEntry extends GuildAuditLogsEntry {
action: 'MESSAGE_DELETE';
target: Message;
targetType: 'MESSAGE';
}
export interface MessageDeleteAuditLogs extends GuildAuditLogs {
entries: Collection<Snowflake, MessageDeleteAuditLogsEntry>;
}
```You could narrow that if the `type` option has been given in `fetchAuditLogs`, otherwise have a union of all of those (or just the base guildauditlogs, but then it doesn't narrow type when we check for "action").
or is it too much work for a not-so-used feature, and will be improved with -modules?
Is there any reason why the type of the "channel" property is not changed with the inGuild() function for command?
Instead of :
public inGuild(): this is this & { guildId: Snowflake; member: GuildMember | APIInteractionGuildMember };
It should be :
public inGuild(): this is this & { guildId: Snowflake; member: GuildMember | APIInteractionGuildMember; channel: TextChannel | NewsChannel | ThreadChannel };
Yeah I can see a clear use for this, would be worth looking into. If you have the knowledge, you could try opening a PR with these interfaces
👍 i'll do that tomorrow or thursday
the channel being null is not related to the interaction being in a guild or not afaik
I mean your suggestion would work as long as you keep null in there
is it normal that GuildAuditLogsEntry#target's type has nothing to do with GuildAuditLogsEntry#targetType ? because i have a case where targetType is Message, and target is ClientUser (which btw gives me no way to access the message's id but that's another story)
i guess it's normal, but it does seem really counter intuitive
yes because target is the user who executed the action
it does seem counter-intuitive, but that's how discord named things
not really because targetType is completely made by djs afaik.
It’s based off of actionType and just groups different kinds of actions in one property so that you can know the generic type
But I think the confusing name here is target and that one is given by discord
It’s too small for them to care
If they butchered interactions like they did, I doubt they’d care more about audit logs
Actually on second thought, maybe targetType would be better off as actionCategory but I don’t think that changing names just for the sake of it is something we do around here
Well i have to say it will make things less confusing for sure
Up to the maintainers if they wanna do it for v14. You can always open a PR now or at a later development stage to suggest this and collect feedback
@outer raven CC @wild flax
https://github.com/discordjs/discord.js/pull/6637/files#r708460248 I don't think this would be considered sem major at all
Because that would mean changing GuildEmoji#url to a function instead of a getter
Since it would need to take format and size parameters
I tried searching first: what are the current thoughts on migrating the whole thing to Typescript?
That's what -next is
so it's happening?
It's planned and slowly worked on. Though priority is updating current version with new things discord throws in
👍
as pointed out by souji elsewhere, actually called -modules now, not -next. #858851268914577428
Does that mean ditching CJS as well?
@wild flax and @outer raven I just saw that there was already a type for the textual channel of a guild : GuildTextChannelResolvable. So finally, shouldn't I put this type instead of creating a new one?
And types seems to be ordered alphabetically but not all (e.g. GuildTextChannelResolvable)
not all are ordered alphabetically but most are. You should just use
Exclude<TextBasedChannels, 'PartialDMChannel' | 'DMChannel'>
instead of a new type
That type includes a Snowflake, so maybe exclude that
not TextBasedChannels
The type above your comments
ah ye
I also wanted to ask @wild flax if it would be too much of a hassle to require node v16.6 in Collection because I wanted to make a PR to add an at() function similar to Array.at()
I would personally say that you shouldn't rely on the index when working with collections, but on the other hand methods like first or last exist
You could do something like return this.first(<number>)[<number> - 1]) ?? null right? In case the bump won't happen
This solution seems to not work :/ With :
public inGuild(): this is this & { guildId: Snowflake; member: GuildMember | APIInteractionGuildMember; channel: Exclude<TextBasedChannels, 'PartialDMChannel' | 'DMChannel'> };
if (interaction.inGuild()) return;
// On this line, my IDE says that interaction.channel can be PartialDMChannel | DMChannel | TextChannel | NewsChannel | ThreadChannel```
Yeah we can always use that, but the idea was also to simplify first and last with that function
yeah I know but there are situations where it is handy and using .at makes more sense to me than .first
odd, that should work
lemme try
On that note, should the .inGuild() method check for a guild channel type like it checks for the guild id and whether the member data is present?
I tried multiple things and I cannot get this to work for some reason, only thing I was able to notice is that you need to add back the readonly tag to channel
bump 
Yes :/
The only way is to use a new type without Exclude like what I did
Aight, just fix the order then ig
👍
I've finish doing this (strong typings for audit logs, i.e. you do guild.fetchAuditLog({ type: 'MEMBER_UPDATE' }) and then you get the typings for .extra and .target that match the member update entry)
BUT it means i can't accept numbers anymore in GuildAuditLogsFetchOptions.type. Only GuildAuditLogsAction. Is it worth the change? Should i do a reversed interface to enable this ? (interface that maps numbers with their GuildAuditLogsAction so we can resolve numbers too) ? wdyt?
Otherwise i can shoot a PR and we can discuss that there
It’d def be nice to be able to pass a number
I use the constants in discord-api-types to resolve the type which are raw numbers
oh yeah right i forgot about -types, i'll look into this. thanks for the feedback
(btw it's a really generic heavy PR, with many ternary expressions. It's def not "pretty" but it's effective. I'll summarize all the pros and cons in the pr)
it uses an enum defined only in -types, so i can use that but it will mean a good chunk of refactoring to create mappings from enum to string (eg AuditLogEvent.RoleUpdate -> ROLE_UDPATE)
so i can do that but "lines-of-code"-wise it will be the same as creating a reverse mappings from numbers to GuildAuditLogsAction
Yeah but we can def not allow it not taking a number all of a sudden
And it would be quite the regression imo
Maybe write some safety tests in the typescript file
But other than that it’s fine
wdym safety tests? and would you prefer mappings from enums to Actions or from numbers to Actions?
i'll make a draft pr, we'll look into that then.
My friend, they are not strings.
channel: Exclude<TextBasedChannels, PartialDMChannel | DMChannel> will work
Why is it interaction.user and not interaction.author like it is with message?
😮 , I'm just dumb thanks 😂
To be consistent with the API
more like to be inconsistent with the api lmao
@outer raven this channel is for serious discussion, not shitposting
Ok chill it was 1 message
Also fyi it's consistent. You get interaction.user in dms and interaction.member.user in guilds, we just top level both for users convenience
yeah ik discord.js is consistent with the api, what I was saying is that the api isn't consistent with itself for providing user for interactions and author for messages
Probably because the author for a message isn't always a user
what else?
webook, system message
message.author is a user in both of those though 🤔
no, its a "user" that you can do none of the normal user stuff with because its a fake user.
it's a user class nonetheless, you can do a lot of stuff with it, just not interact with the user directly e.g. sending messages
in djs it is, not in the api, and since we're matching names, well...we match
<Client>.on(Constants.Events.GUILD_MEMBER_REMOVE, (guildMember): void => {
guildMember.id // No errors
guildMember.user.id // Error: guildMember.user is possibly 'null'.
});
guildMember.id returns the id through .user.id. Isn't the above error somewhat... strange? Pretty sure this isn't correct behaviour
👀 it's actually never null, its either undefined or a valid user, though the entire class does assume it is present always....I smell bugs
I'm also not sure when a user wouldn't be included to some degree when constructing a member
I'm thinking about making a library dealing with chat messages for a non-discord service and I am wondering how you test features and the library as a whole?
i'm not talking about things like jest, but just using it. do you just have a separate directory where you import the library and test the new feature there?
well how do you do it with djs?
Most of us test with a dedicated testing bot, using the actual API and using the local instance of the library as a dependency
ok cool
Yeah you can use the npm link functionality to link to local packages
#6648 in discordjs/discord.js by acd124 opened <t:1631765512:R>
Bug: Role.toJSON() returns permissions as a BigInt
Regarding this - I mostly agree with Voltrex that its not a bug because BigInt isnt JSON-serialisable, but Role.toJSON() does return permissions as a bigint literal
Shouldnt the object returned from that be JSON-spec compliant?
yea, it seems like the only utility class that uses bigint for their flag bitfields is the Permissions class which is what that issue is really pointed towards, I think we should just call <Permissions>.toJSON() when serializing the Role instance into JSON, so it casts the bigint bitfield literals to strings
Doesn’t it do it automatically? 
Bot quite library discussion tho
I think chrome has something that lets u download it
Or just hard reload
If you closed the toast that said it's ready to use online you're fine
Try it out, see what happens
It's automatically downloaded o.o
this exists under the invite creation methods
https://discord.js.org/#/docs/main/stable/class/VoiceChannel > targetApplication + targetType
you call #createInvite on a voice channel instance and provide the target application and target type as detailed on https://discord.js.org/#/docs/main/stable/typedef/CreateInviteOptions
not quite sure this is what they meant, have you seen the feature that lets you watch yt and other apps on a voice channel? This doesn't require an invite
how would we get the ApplicationResolvable for that?
and at the present time it requires
- whitelisted server
- client modification
- an invite
find the application ID, we're not documenting these if they don't get documented on DAPI
ah alright, I hope this becomes easier once the feature is available to the public though
also I didn't need a client modification ?
maybe the user who started it did, idk
yes
alright 
I was wondering, why
<GuildMemberManager>.fetch(....) has a completely different management (parameters and on return types) than <GuildChannelManager>.fetch(...) :
First difference :
<GuildMemberManager>.fetch(....) accept only one parameter (BaseFetchOptions + user id)
<GuildChannelManager>.fetch(...) accept two parameters (channel id, BaseFetchOptions)
Second difference :
<GuildMemberManager>.fetch(....) throws an error if the member isn't found whereas <GuildChannelManager>.fetch(...) returns null if the channel isn't found
they work totally differently
for members it uses the Request Guild Members gateway command which has a bunch of params so you can find based on many things
for channels it just GETs the specific channel or the guild's channel list
i did ask about this earlier, and it extends beyond these a bit
i got a single reply and they never clarified...
There's nothing really to clarify. One is just more flexible with methods. advaith explained it above a little
uhm, you mentioned overloading and i asked what that was and you never responded 
advaith is right that those methods function differently, but honestly, theres various inconsistencies across the lib if people really wanted to interrogate them all
The GuildMemberManager#fetch method is a real fetch. It accepts an id or FetchMemberOption (single) or FetchMembersOptions (multiple). Theres a REST endpoint for retrieving individual guild members by id. Otherwise if options are provided it can fetch multiple, but for this it uses gateway opcodes and receives chunks.
GuildChannelManager#fetch actually fakes the individual fetch method - theres isn't a REST endpoint for fetching individual channels. Instead it calls the endpoint which returns all channels for a guild, and then just gets the one you asked for.
That explains the different return values. There isnt really a reason for the different params as input though that I can see, other than unenforced consistency
usually, what should be the case is that required parameters are consecutive function arguments with a single options object as last argument, if multiple optional parameters are possible (essentially so you don't have to do .someCall("a", undefined, undefined, 3, undefined, undefined, 5), but can instead do .someCall("a", {d: 3, g: 5}))
- however, that isn't consistent across the library at present
theres isn't a REST endpoint for fetching individual channels
there is, https://discord.com/developers/docs/resources/channel#get-channel, it seems to return the same channel data as the objects in Get Guild Channels
can't fetch a single channel in a guild specifically
client.channels.fetch prob uses it
theres no difference though
/guilds/:id/channels/:id would function the same as /channels/:id so theres no reason for it to exist
4 years ago
there's one functional difference, it ensure the channel is in said guild, but I made a change to GuildChannelManager#fetch that just checks the guild id after fetching using the single endpoint a while back
(although it looks like I forgot to perfrm the same check when fetching from cache oh no I'm dumb, the cache only has guild channels, I must've thought of this before
, there's a free PR for someone)
why dont we use that then
and to answer that, we do, as of
was gonna fix #6655 and found this lonely type that isn't referenced anywhere, what is this for?
v12 tho
No, you showed me the docs
...that say where were MessageAdditions used
My question was if that is relevant or if it can be removed
and since i am showing 12.5.3 instead of 13, it just might be because there is no MessageAdditions mentioned in send on v13
then it's safe to remove from the typings
Will there be something done with the new role icons?
yes
#6633 in discordjs/discord.js by iShibi created <t:1631504644:R> (review required)
feat: add support for role icons
📥 npm i iShibi/discord.js#feat-role-icon
@worn bobcat
Also discord.js supports all api endpoints afaik, so yes it will support every new feature discord adds, it’s just a matter of time
Ik, just I was curios :)
I'm a little bit curious, but on the .fetch method to retrieve a Message object. When it hits Discord's endpoint, if the message doesn't exist it errors and gives a 404. Doesn't this make the .deleted on the message object redundant?
Ahh gotcha, makes sense if its .cache, I was using the fetch method and the typing on it said that it promised me a message back. I assumed that the discord API would give me something and I could use .deleted
<TextChannel>.fetch() should promise a <Message | false > than, instead of just 404ing
That is a good point,
you could still throw an exception if the res.error_code = 403
Btw, the GuildChannelManager.fetch when fetching channels can promise a null if a channel wasn't found
it is inconsistent with the message fetcher

didn't know, huge discord not enough time to read. gotta bash keyboard
#697138785317814292 message
Does the library already support this modification (PR in progress or not) or not?
#6652 in discordjs/discord.js by iShibi opened <t:1631859222:R> (review required)
feat(MessageAttachment): add support for ephemeral property
📥 npm i iShibi/discord.js#ep-attach
yes
either the guild property needs to be set or the manager can be changed, preferably the former to demonstrate how to set permissions from the global manager
that works yeah
might be a good idea to distinguish the ids from each other
yes, mainly so that they don't look like they are the same id that you are supposed to pass twice
Can we add vscode extension recommendations? I was thinking of suggesting prettier and eslint so that users can fix errors before committing so the CI doesn't fail
would look something like this
Most of those people don’t edit in editors
They do it from the web
Hence it shitting itself. Because git would run the dependencies before committing, you wouldn’t need those things
But you can still commit with eslint errors, nothing will prevent you from doing that
Specially not for non-auto fixable issues
And this won’t fix that either, but at least if people install these extensions they will see the errors
And I’ve actually seen many prs that are made on an editor and have errors
You can not
only if you skip it on purpose
A normal commit won't go through otherwise if you do it on a local machine (read: not the web editor)
Your IDE has nothing to do with it
the pre-commit hook runs: eslint --fix --ext mjs,js,ts
which means it will fix whatever it can, but throw on whatever lint errors it cant
alright yeah you're right, but this would still help them identify their errors and fix them more easily
Having the faulty line underlined with an explanation of the error is easier for people to understand what's wrong
I don't see anything wrong adding it actually but isn't the .vscode folder ignored in the gitignore 
we can easily overcome that, I have the fix already but I'm hesitant to pr it now cuz of what crawl said
Btw, what about adding prettier to pre-commit hooks?
Ohh, didn't know this 👍
Question, since builders utilize markdowns, will Util.escapeMarkdown also be included in the builders as well?
Builders is a different package from discord.js so if it'll be included it will in a new builders version
oops i mean will it be removed from the djs package itself?
pretty sure builders already contains the message formatter functions
oh it doesn't contain escapeMarkdown, mb
Can we update the message component collector docs with an info block advising people not to use filters? It's bad practice to leave interactions without a reply so they should always let all interactions through and then run their own checks to see if the user is allowed to perform a certain action
Not sure if this should be on the docs or guide though, which is why I'm asking
The guide already uses deferReply in the filter
that's not really a response though, it needs an ephemeral reply
Well, yeah, it can be surely improved
but do you not think it's worth putting a notice in the docs?
maybe not in the docs but in the guide i guess
Yeah, I don't see why it should be in the docs
Would you like to do that? I've never really looked deeply in the docs so I might miss something if I do this
Hint: if you use a ternary in your filter, you can reply to those that do not pass the filter
const filter = something => {
if (something) {
return true;
} else {
interaction.reply("hi");
return false;
}
@solemn oyster @wild flax there is a way to add more dynamic typing to SlashCommandBuilder#toJSON, are the people opposed to this? #813896878058897458 message
I don't have access to wherever that channel is from
yeah I know and that's what I'm saying could be mentioned on the guide, since most users just use a regular filter and don't reply to their interactions
Looks like Crawl already said no
he said no to the docs, not the guide
Why would you add more dynamic typings exactly?
Also can't see that message
^^
The linked message is the last
Would it be possible to do a interaction.inGuild() boolean just like we have interaction.isButton()?
there.. uh... is?
Interaction#inGuild()
Indicates whether this interaction is received from a guild.
.. oh
Is there a reason why that ts still thinks that interaction.member could be an APIInteractionGuildMember after using interaction.inGuild()?
Maybe you're not in the guild
if its not in a guild then interaction.member will be null
I think he wants to check if the client user is in the guild as a type guard to remove raw api object
yep, that's what I meant. bad phrasing on my end
Basically a shorthand for writing this:
if (!interaction.member || !(interaction.member instanceof GuildMember)) return interaction.reply("I need to be in the guild where this command is run!");
That would also be quite useful yeah
also I don't know if this is intentional but APIInteractionGuildMember isn't exported from djs, which is why i had to do the messy instanceof
It is indeed intentional
its in discord-api-types
So is Snowflake, no?
Snowflake is in both iirc
Could probably add a parameter in inGuild() to check if you're in the guild additionally
not sure if its the same in both tho
Yes that one is the only exported one from discord-api-types
It is
unfortunately someone made it looser in discord-api-types iirc
yeah because of a ts bug iirc
used to be `${bigint}`, now its just string
What bug?
i dunno, but that was the bug
I believe that bug's for TypeScript <= 4.2
Hmmm
Dunno never faced it
But now that 4.4 is out of beta maybe it could be brought back?
It's this, right?
https://github.com/discordjs/discord.js/issues/6322
oh yeah it is 4.2 not 2.x
but I thought it was removed because of the dev experience, the bug isn't mentioned in the PR?
@wild flax can probably answer instead of us just guessing
"too hard to use for some developers" what exactly does that mean?
People who shouldnt be using TypeScript at all probably
how hard can it be to type Discord.Snowflake
well the library usually doesn't care for people who don't hold the required knowledge to do what they're doing so why did it this time
Huh, I thought there was an actual bug with it
honestly that would make it more justified imo, but it's w/e, it doesn't make too much difference anyways in the long run
wondering the same thing, not like djs to revert a change because developers didn't want to adapt to it
re: .send change
The send change was reasonable
The type was just annoying to work around
I didn't necessarily make anything stricter
fair
anyways, yeah I think that'd be an eloquent solution
There was a bug too
so a more eloquent way to type narrow GuildMember | APIInteractionGuildMember?
yep
perhaps make the class generic CommandInteraction<InGuild = false> then implement it like this
public isInGuild(): this is CommandInteraction<true>;
get member(): this extends CommandInteraction<true> ? GuildMember : APIGuildMember;
Yeah that’d be nicer imo
How is that accurate? If its not in a guild it wont have a guild member
Or is it supposed to be specifically checking a bot user being in the guild?
You'd still have to account for DMs though, it could be null
TECHNICALLY, if we have the guild in cache, we have a member instance too
yeah, I was just confused if thats what its trying to do
Is it checking if the interaction is in a guild, or if the application has a bot user in the guild
Ideally it would be checking the latter
well both
@tacit crypt I wanted to mention this but, when committing on the discord-api-types repo the hooks don't run properly, I have to adjust the executable bits on the husky files or I get this:
hint: The '.husky/pre-commit' hook was ignored because it's not set as executable.
hint: You can disable this warning with `git config advice.ignoredHook false`.
hint: The '.husky/commit-msg' hook was ignored because it's not set as executable.
hint: You can disable this warning with `git config advice.ignoredHook false`.
...I thought I set those already
@tacit crypt do you think the -types update builders pr could get merged soon so I could finish up the context menu pr?
thats not in my powers to decide sadly
arent you the builders maintainer?
Unlike -types, builders seems to respect the same merging requirements as the main module. I'll need to ask @wild flax about it tho
What are those requirements?
Well, in the main module its usually 3 reviewers approving + crawl merging
I see
Reading user's about me section is possible, in the future or not?
@dawn merlin what about this part?
Oh for some reason I thought that was in your suggested changes, yeah I can change that
it wasn't because I didn't wanna spam comments for something that could turn out not to be wanted
the only issue is I wouldn’t know what to call it
.applicationInGuild()maybe, off the top of my head. Also thought of.clientInGuild()
Client is more accurate imo
The application had to have been added to the guild for slash commands, even if it doesnt have a user present
clientUserInGuild()
Though even then, that implies the existence of specific intents
Technically correct would just be something like hasCachedData()
Or the opposite, isRaw()
But yeah, combined truthy conditions with param, fine I guess, but you've removed the ability to have distinct falsy conditions
here's some I came up with:
isGuildUserisGuildClientinCachedGuildinRawGuild
having both inCachedGuild and inRawGuild could work
I like raw better, because caching is hell (':
We could separate out the logic to that method then
it would have to be two methods, since the inverse of inCachedGuild doesn't 100% imply that inRawGuild is true
Well, it depends on what the two methods are
You can have inCachedGuild and inRawGuild, and if both are false its DM
Or a more generic inGuild then one of the two above to determine type of guild-related parameters
so inGuild({ cached: boolean, raw: boolean }) as another option?
Ehh I still really hate the idea of putting this in one method
inGuild({ cached: true, raw: false }) // Guild, GuildMember, GuildChannel
inGuild({ cached: false, raw: true }) // APIGuild, APIInteractionGuildMember etc....
inGuild({ cached: true, raw: true }) // ???
inGuild({ cached: false, raw: false }) // ???
``` What would the last two permutations be checking here? What are the defaults?
I guess you can throw an error on true/true
And false/false could either error, or simply rule out DM and not care what type of guild?
I still think two explicit methods is a FAR more intuitive, readable interface
yeah I agree
if(i.inCachedGuild()) {
// great, cached
} else if (i.inRawGuild()) {
// k do some raw handling or whatever
} else {
// dm
}``` This really just feels like the easiest interface. I'd be somewhat okay with an `inGuild()` helper that did `this.inCachedGuild() || this.inRawGuild()` too
Though its also easy for devs to do that on their own so idc
I feel like this has been brought up a lot
No like it’s fine to ask I just don’t remember the reasoning against it
It has? O_o
There's Message#resolveComponent that takes a custom id to resolve against
Does that not help?
oh im thinking of the components thing in the message payload, ignore me
All good, thought that would indeed clear it up haha
as buttons and select menus now enforce
customId
By the way, this has always been enforced - it's just it's recently enforced that custom ids must be unique in a message (previously, there were no checks for uniqueness)
Except a row is actually ordered
Maps/Collections are for storing unordered data
The index of a button is (or at least should be) its position too
And yes - link buttons dont have a customId makes that difficult
Just wondering, Is there a reason builders isn’t a part of modules?
why does printing out a MessageEmbed reveal that all of its data is stored in field objects rather than in the properties laid out for it?
not sure what you mean by this, fields are shown as fields object array - what else would you expect?
those aren't fields though, those are the title and description
the actual embed looked like this
your title is "Embed Command Used" and you don't set a description though? I'm confused.
your screenshots can't really relate to the same embed object, one depicts a title/description (or title/value (on a field)) pairing, while the other depicts an embed where both gibberishs are in individual field values
editing guild commands doesn't seem to update the cache 
creating and updating does tho
this is really weird:
initial: cmd1, cmd2
renames cmd2 to cmd3
cache: cmd1, cmd2
deletes cmd1
cache: cmd1, cmd3
oh thats prob just because im fetching before renaming/deleting
so renaming/deleting just doesn't update the cache
creating does though
oh.. looks like the code is explicitly set to not update cache for guild commands?? tf
according to the code create also shouldnt cache guild cmds, but looks like it does 
looks like @ruby terrace changed it from (patched) to (patched, undefined, guildId), and @floral hinge changed it to (patched, !guildId, guildId)
I had changed the command methods to not modify the cached commands in place, and instead when you received command events these would modify the cache. Only the methods for global commands would modify the cache since these didn't receive command events. So the issue here is a regression from when support for command events was removed
the code should be updated to modify the cache again
yeah but i mean, typically the cache gets modified even for managers with events
so this behavior was inconsistent anyway, just didn't really matter until they removed the events
cache would get modified twice if both managers and events modified it
You can have guild commands in the global manager! The only problem that could happen is when you have both managers, you could have duplicates where one is an outdated version of cache, because we don't get events to keep cache up to date
Didnt command events get removed from the bot websocket though
So now the manager has to modify it
Should it also modify the guild cache then if its coming from the global one?
...somehow?
They were never emitted (for bots)
and the guild + global thing is kinda hard
we could update both, but usually people won't have them in both
bots did receive them
So how does a guild command get into the global cache?
eh, I dont see the harm in just caching if the guild exists
I think with interactions, that DJS should take into account the <interaction>.member.permissions that get sent with the interaction, especially now that DJS has such powerful caching capabilities. Currently, it gets completely ignored. Discord sends the guild member's exact permissions in the channel that the interaction occurred in, taking all of their role permissions into account.
To compare, if I'm not caching roles or channels, and need the guild member's permissions in the channel that an interaction occurred, I have to:
• Fetch the channel (for the overwrites)
• Fetch @everyone (for the global permissions)
• Fetch all of the roles for the member (for their global permissions)
• Adjust the global permissions to account for the channel overwrites
Meanwhile... Discord already sent me the info:
https://discord.com/developers/docs/interactions/application-commands#slash-commands-example-interaction
The caching is exactly why we had to ignore this - because we cant put the value on the GuildMember object
I'd probably suggest InteractionGuildMember extends GuildMember or something with its own property
Oh, so it had been at least mentioned before. :-). Your idea of InteractionGuildMember would be great. My easy-way-out, I just added a ._memberPermissions to Interaction until it gets discussed and/or implemented.
Yeah fair enough, could also go on the interaction classes
it needs to be on something that isn't cached, for sure - otherwise that information is held but can be immediately invalid again
they were
i have a question why did a deprecated event (interaction) come out in v13 and it wasnt in v12
not too sure what you mean?
"interaction" - as part of the interaction feature came out with v13
after the fact (in 13.1) * mixed that up, correction below
we kept "interaction" because people already used it plenty when switching to v13 when it was still in dev to not introduce a breaking change, where not strictly necssary
a deprecation warning was added to both "interaction" and "message" in favour of the more api-true naming convention xCreate
the "old" event names still operate as one would expect, but will be removed in the next major version (14.0.0)
deprecation notices are used to ease over transitions into breaking changes
People were already using interaction in the dev build so we thought we'd be nice and keep it
"interaction" - as part of the interaction feature came out with v13
after the fact (in 13.1) it was decided to add a deprecation warning to both "interaction" and "message" in favour of the more api-true naming convention xCreate
Not exactly, it released both in version 13
^^ that'd be why
This is just a slight inconvenience in a bunch of classes on the library but I'll be using the example of the Role class here
When printing out a role object, the very first thing you see is the guild data because this is the first thing that is set on the file (since it needs to be called through the constructor) but this makes it so that if you want to, for example, print this data on an embed, you end up not seeing any real data about the role itself since you have size limitations. My question is, could we move "extra" data to the bottom of the file (or at least below the important stuff) and keep important data about the actual class we're accessing at the very top?
no
😐 why not
printing out objects is not supposed to - in any way - be a replacement for documentation or typings, further objects are key-value associations and the order of keys should not play any role
this "problem" also applies to getters, which aren't even listed in printing instances to begin with
also wouldn't "important data" differ depending on use case? so getting data should just be, idk, an array of properties to go through to actually display?

