#discord.js
1 messages · Page 13 of 1
5255862 feat(Invite): add flags - Jiralite
704ba5a refactor: register actions without using class ... - Jiralite
cd420bb fix: this is module.exports - Jiralite
Please describe the changes this PR makes and why it should be merged:
Status and versioning classification:
- Code changes have been tested against the Discord API, or there are no code changes
- I know how to update typings and have done so, or typings don't need updating
Which application or package is this feature request for?
discord.js
Feature
"Manage Permission" permission is missing on PermissionFlagsBits for channels.
ManageRoles doesn't seem to handle it since it throws:
DiscordAPIError[50013]: Missing Permissions
Ideal solution or implementation
A new enum for Manage Permissions (even if it is same number as ManageRoles) for making it clear for developers.
Alternative solutions or implementations
No response
O...
I don't know whether I like the setters in the object, but I suppose it works for this use-case here.
I suppose we could rename this variable to permissionOverwrite (now).
Only tangentially related to this PR however.
Aside from @SpaceEEC's comment, the rest looks good to me
Can we match the name of ComponentInLabelData with ComponentsInLabelData? They're both different (one is JSDoc and the other is from the typings).
Well then, considering v15 is already on collection v2, there's nothing more to be done in regards to this issue.
1991b1e feat(GuildMemberManager)!: add new modify self ... - Jiralite
Please describe the changes this PR makes and why it should be merged:
Adds new fields for modifying the current guild member.
Adding these into the existing edit method is problematic as this implies one may use these on any guild member. The method has been split up into 2: one for you, one for others!
This also means if you want to change your nickname without needing manage nicknames, editCurrent() should be used.
Upstream:
d8ad181 fix: Ensure discriminator detection respects we... - vakiliner
[discordjs/discord.js] Pull request opened: #11090 feat: label component and select in modal for v14
Please describe the changes this PR makes and why it should be merged:
Status and versioning classification:
- Code changes have been tested against the Discord API, or there are no code changes
- I know how to update typings and have done so, or typings don't need updating
While this is not problematic currently, it could potentially be if discord adds a property to available tags that has 2 words. Since transformGuildForumTag expects a discord.js object (aka camel cased) and we're passing the snake cased version here.
Might be worth doing something along the lines of options.availableTags?.map(x => toSnakeCase(blah...)) ?? options.available_tags instead to prevent future headaches.
Ditto. I don't know if this one would cause issues but I also wouldn't want to find out.
if (options.flags) {
snakeCaseBody.flags = ChannelFlagsBitField.resolve(options.flags);
}
The talk for available_tags also applies here technically, but is even more unlikely to cause issues.
Any reason for checking id specifically here? Passing name wouldn't work this way.
if (snakeCaseBody.default_reaction_emoji) {
If there is a reason for the id check then we must also check for name.
Which application or package is this feature request for?
discord.js
Feature
Hello, I think it would be interesting to add a search bar for StringSelectMenuBuilders, like RoleSelectMenuBuilders or ChannelSelectMenuBuilders.
This would allow us to avoid being limited to 25 options, as the first 25 would be displayed, and the others would have to be searched for ourselves. This could be useful when StringSelectMenuBuilders are used to display information via identifiers or simply to...
This is discord.js, a library for interacting with the Discord API. We are not Discord!
You can submit bug reports and feature requests to Discord over at https://github.com/discord/discord-api-docs.
Will the edit() method be removed?
Should it be left as deprecated?
@vakiliner Why would it be removed? How would you edit members without it?
@vakiliner Why would it be removed? How would you edit members without it?
Sorry, I meant that it was already removed, or rather it was renamed to editMember()
I'm conflicted because I hate inconsistency in the interface. I was going to point out that we don't do this for the User class before remembering we have a whole extended ClientUser to achieve this.
Not sure if ClientGuildMember makes sense though.
Per https://github.com/discord/discord-api-docs/pull/7807#issuecomment-3271904854, the response of this is not changing. Therefore, there are no new properties for the guild member object, so the hypothetical ClientGuildMember would not have anything over GuildMember.
@imnaiyar You might want to add the rest of the select menu components as well as the Text Display component to this, with https://github.com/discord/discord-api-docs/pull/7804 in mind.
I have already done some work for main branch but it is very breaking. Will probably work on v14 today. I'll see.
Please describe the changes this PR makes and why it should be merged:
Adds support of other select menus and text display
Resolves #11085
Requires:
- discord-api-types bump
- #11090
Status and versioning classification:
- Code changes have been tested against the Discord API, or there are no code changes
- I know how to update typings and have done so, or typings don't need updating
Shouldn't this be avatar instead of icon?
The pending Discord API docs points to it being avatar:
https://github.com/discord/discord-api-docs/pull/7807/files#diff-b048a45b363d01dbbaeaf7409be45b8faec5386ce0cc3e889208c737c534855fR1022
Please describe the changes this PR makes and why it should be merged:
Resolves #11084
Requires:
- #11081
BREAKING CHANGE: ModalSubmitFields is no longer exported
BREAKING CHANGE: ModalSubmitInteraction#fields is removed
BREAKING CHANGE: ModalSubmitInteraction#components is now ModalOptionResolver
BREAKING CHANGE: DjsErrorCodes#ModalSubmitInteractionFieldNotFound & DjsErrorCodes#ModalSubmitInteractionFieldType are now renamed to `DjsErrorCodes#ModalSubmitInteraction...
Should the editCurrent() method be named editMe()?
Referring to the fetchMe() method
Wouldn't it be more in line with current naming to keep this as edit() and name the other method editMe()?
I'm guessing the rest of the getters are coming too right?
Yeah, in a future pull request. This is just implementing Discord's first release.
sorry, I could be completely off base here since I haven't read everything/the types, but wouldn't your diff cause trouble if {} was passed?
emoji is only a property if it's a djs object, we only call transformGuildForumTag if the caller is passing non-api data (it's emoji_id and emoji_name to discord)
good callout, I forgot emoji's can be name only. I'll add || name to it.
and @didinele no, {} would pass through in the body. Though speaking of types, I didn't add a | RESTPatchAPIChannelJSONBody to the types for this method, but I theoretically could at this point....should I?
same thing, never done with a raw api object
the only valid value to pass as raw api data is properly resolved by the resolve function, I could realistically do either, want opinions
Is that the direction we foresee the discord.js library going in (i.e., allowing passing raw payloads everywhere appropriate)?
I think we should allow it (to better support new features that don't have real support yet), but I don't know that we should actually document it that way. It might be something we mention somewhere once, but I don't think we should specifically call it out except maybe types...my opinion will probably change once the lib is actually ts native and the underlying support for raw data is way better.
Closing for the reason listed above. This is generally why helper methods should be avoided.
Did that. I'm not too sure about the type's name though. Chose the best I can think of. Resolve this if it's okay
Its a shame we cannot easily make components the new system from main, alas
I don't get the purpose of this function. Doesn't the normal edit function support all these fields too? Why do you need to call editMe to edit some things and then edit for others (like wanting to change nickname and channel in one call [if that actually works])
The normal edit function doesn't support these fields.
/guilds/:id/members/:id doesn't support avatar, bio, banner, bots can only change their own (hence why this function uses /guilds/:id/members/@me endpoint)
the /members/@me endpoint only supports what is shown in the GuildMemberEditMeOptions interface, if you want to edit the channel_id or anything else that is part of the /members/:id endpoint you would have to use the edit function. (don't know why Discord didn't add sup...
I don't get the purpose of this function. Doesn't the normal edit function support all these fields too? Why do you need to call editMe to edit some things and then edit for others (like wanting to change nickname and channel in one call [if that actually works])
The endpoint /guilds/{guild.id}/members/{user.id} does not have the avatar, banner, and bio fields. They are only found in /guilds/{guild.id}/members/@me
You can't change, say, avatar and channel_id in a single ...
Lovely. So the /@me route doesn't support things that make sense 🙃.
How we can get actual property? Presence update not send actual member info, we can get this only for cache (which is almost the same as it's now)
I don't understand need I and how to override constructor
That's about it. If I forgot something, please remind me.
5247afe feat!: text display and other select menus for ... - imnaiyar
d8e359f docs: add APISelectMenuDefaultValue - Jiralite
Required due to #11097.
93e0f4c feat: text display and more selects in modal fo... - imnaiyar
7886d9b feat(GuildMemberManager)!: Add new modify self ... - Jiralite
5b7bedc feat(GuildMemberManager): Add new modify self f... - Jiralite
34ac913 fix(GuildMember): use editMe() conditionally - Jiralite
Conditionally chooses which edit route to use based on the user id.
Please describe the changes this PR makes and why it should be merged:
I haven't tested this yet
Status and versioning classification:
Please describe the changes this PR makes and why it should be merged:
The current way of doing it will return false for empty strings, instead explicitly check if a field is present or not
Status and versioning classification:
b3705df fix: use in operator when resolving modal compo... - imnaiyar
6f0f42b docs: use LocalizationMap where applicable - almeidx
Changed the doc string to match the typings.
#djs-help-v14 message
5efde11 docs: use LocalizationMap where applicable (#11... - almeidx
e8f2555 feat(ThreadMemberFlagsBitField): use `ThreadMem... - almeidx
The typings were already using the enum, but at runtime it was not being used.
Which package is this bug report for?
discord.js
Issue description
- Inside any interaction with a valid member object:
- Attempt to timeout a user using a number in milliseconds
- Some numbers work fine?
- But others such as the specified max (28 days converted to ms) give "INVALID_COMMUNICATION_DISABLED_TIMESTAMP" w/ invalid form body error
[2025-09-28T02:33:14.051Z] [Guild Interaction Error] Error executing mute: DiscordAPIError[50035]: Invalid Form Body
communication_d...
I cannot reproduce this on v14 or main. Tried multiple times with:
import { Client, Events, GatewayIntentBits, GuildMember } from "discord.js";
const client = new Client({ intents: GatewayIntentBits.Guilds });
client.on(Events.InteractionCreate, async (interaction) => {
if (!interaction.isChatInputCommand()) return;
await (interaction.member as GuildMember).timeout(2419200000);
});
client.login();
My example is an extremely dumbed-down version of what I actually h...
Are you assuming that without any testing or have you ran into an issue where you needed this?
Are you assuming that without any testing or have you ran into an issue where you needed this?
I saw this error while checking your code
Before creating the issue, I checked the required permissions for the voice channel
"You should use GuildMemberManager#editMe() when changing your bot's nickname instead. In future versions, due to Discord's API changes GuildMemberManager#edit` will end up requiring MANAGE_NICKNAMES in v15."
Internals ref in case this dies for a while #internals message
I cannot reproduce this on v14 or main. Tried multiple times with:
import { Client, Events, GatewayIntentBits, GuildMember } from "discord.js";
const client = new Client({ intents: GatewayIntentBits.Guilds });
client.on(Events.InteractionCreate, async (interaction) => {
if (!interaction.isChatInputCommand()) return;
await (interaction.member as GuildMember).timeout(2419200000);
});client.login();
My example is an extremely dumbed-down version of what I act...
Please describe the changes this PR makes and why it should be merged:
Allow to use native Events as key for ClientEventTypes (for examle ClientEventTypes [Events] instead of ClientEventTypes[keyof ClientEventTypes])
Status and versioning classification:
- Code changes have been tested against the Discord API, or there are no code changes
- I know how to update typings and have done so, or typings don't need updating
index.test-d.ts is full of errors due to this change.
It seems this stops strings from being used. Unsure if this is desired. @vladfrangu, any ideas?
I agree that removing the ability to use strings directly is a bad idea. But I would also like to add compatibility of the type with the Events object, since in fact they are completely identical.
As I see it, it comes down to the async_event_emitter's typing. I would like to understand more precisely what can and should be changed there in order to keep support for raw strings
Another problem. 'voiceServerUpdate' event not exists in ClientEventTypes
Please describe the changes this PR makes and why it should be merged:
messageDeleteBulk can be emitted only from guild. channel's type and discord api docs verify it.
Therefore, it's not possible to get a non-guild type of message.
Also i think no need of PartialMessage in this type and want to get feedback about it
Status and versioning classification:
- Code changes have been tested against...
Unsure if this is desired
I wouldn't want this to break normal strings, so if it does... I am -1 on this
Please describe the changes this PR makes and why it should be merged:
Function allow usage without rawData arg and has type, but in d.ts file it required and with unknown type
Status and versioning classification:
- Code changes have been tested against the Discord API, or there are no code changes
- I know how to update typings and have done so, or typings don't need updating
Why was this made optional?
Based on the function body, this parameter may not exist. See line 1128
If male param not optional, this condition have no sence because every object returns true in it
I looked again at the code executed under the condition. What's the point of rawData anyway? The first condition does not require this parameter at all, the second and third can be replaced by the properties of the Message object
Which application or package is this feature request for?
discord.js
Feature
The SetVoiceChannelStatus permission is missing from the PermissionFlagsBits enum in discord.js, despite being available in the Discord API since 2024.
Ideal solution or implementation
PermissionFlagsBits.SetVoiceChannelStatus should be available to allow bots to programmatically manage the "Set Voice Channel Status" permission when creating or editing voice channels via permissionOverwrites.
Disco...
Discord does not document this permission.^1 We only make the documented API. You have to chase Discord – not us.
Please describe the changes this PR makes and why it should be merged:
Backports #11115
Status and versioning classification:
Please describe the changes this PR makes and why it should be merged:
This should not return null
Status and versioning classification:
fcce0d9 fix: backport in operator fix from main (#11127) - imnaiyar
3b92744 docs: use LocalizationMap where applicable (#11... - almeidx
154c00d fix(ThreadMemberFlagsBitField): use `ThreadMemb... - almeidx
Please describe the changes this PR makes and why it should be merged:
Status and versioning classification:
- Code changes have been tested against the Discord API, or there are no code changes
- I know how to update typings and have done so, or typings don't need updating
- This PR changes the library's interface (methods or parameters added)
This adds (what I believe) is a missing flag from getTextInputValue, I noticed that other methods do have a required flag yet get...
This is not a bug, if there is text input component, then the value will always be present. So there's no point of having required there
Ah I am sorry about that, completely overlooked that
Also i think no need of
PartialMessagein this type and want to get feedback about it
This is incorrect as the gateway only sends the deleted message IDs.
https://discord.com/developers/docs/events/gateway-events#message-delete-bulk-message-delete-bulk-event-fields
Also i think no need of
PartialMessagein this type and want to get feedback about itThis is incorrect as the gateway only sends the deleted message IDs. https://discord.com/developers/docs/events/gateway-events#message-delete-bulk-message-delete-bulk-event-fields
But discord.js's cache can't include Partial messages
And event can't send message not from cache
Please describe the changes this PR makes and why it should be merged:
Webhooks can't send messages not in guild
Status and versioning classification:
- Code changes have been tested against the Discord API, or there are no code changes
- I know how to update typings and have done so, or typings don't need updating
cf88ef9 types(Webhook): specify message type (#11142) - Pavel-Boyazov
The partial messages are created by this
This is easily testable with a simple script like
import { Client, Events, GatewayIntentBits, Partials } from 'discord.js';
const client = new Client({
intents: GatewayIntentBits.Guilds | GatewayIntentBits.GuildMessages,
partials: [Partials.Message, Partials.Channel],
});
clie...
This simple change fixes issues when running in environments that re-define node's timers, such as FiveM, where node timers are tied to the game ticks.
The issue is that clearInterval is used in the web socket files, namely when clearing the heartbeat interval, but as it's not imported from node:timers, in the case of a FiveM resource, it tries to use the o...
v13 is deprecated. Do not use it.
Despite being deprecated, it's the most recent supported version on node v16.11
Node <20 is EOL... You should really push towards a move to newer node versions
b80dd8c types(ClientEventTypes): fix messageDeleteBulk... - Pavel-Boyazov [2c3a884`](https://github.com/discordjs/discord.js/commit/2c3a8840405920086af87404e5560be8754c60e9) Merge branch 'main' into chore/update-name - kodiakhq[bot]
6a5707c types(Webhook): specify message type (#11142) - Pavel-Boyazov
30e35d9 types(ClientEventTypes): fix `messageDeleteBulk... - Pavel-Boyazov
0df0c14 feat: bump builders in v14 (and fix runtime cra... - vladfrangu
Please describe the changes this PR makes and why it should be merged:
Fixes a crash related to Label component and the Invite bitfield class
Bumps builders in v14 for new modal components
Status and versioning classification:
- Code changes have been tested against the Discord API, or there are no code changes
- I know how to update typings and have done so, or typings don't need updating
/**
* Represents a label builder.
* @extends {BuildersLabel}
*/
class LabelBuilder extends BuildersLabel {
133ca34 chore: bump dtypes - vladfrangu
We decided to not do this for new builders in v14, to ease transition to v15 and builders v2. Don't introduce methods that will be gone again soon
cece1d8 chore: requested changes - vladfrangu
67c8953 feat: bump builders in v14 (and fix runtime cra... - vladfrangu
3b26680 chore(discord.js): release [email protected] - vladfrangu
Which package is this bug report for?
discord.js
Issue description
- Create a poll
- Start the client
- Vote on the poll
- You get a [PollAlreadyExpired] error like on the image
Code sample
client.on(Events.MessagePollVoteAdd, (pollAnswer, userId) => {
pollAnswer.poll.end()
});
Versions
- discord.js v14.23.0
- Node.js v22.18.0
- Windows 11 24H2 (KB5065789) (26100.6725)
Issue priority
Low (slightly annoying)
Which partials do you have c...
9e2b1e4 fix: ending uncached polls - almeidx
expiresTimestamp is nullable, and Date.now() > null would be true.
fd86bed fix: handle receiving new selects - Jiralite
this in the static method doesn't resolve the way we want to.
Which package is this bug report for?
discord.js
Issue description
(See code sample)
The modal appears correctly with the differents selects menus. But, when I click on the button to validate, I got :
Cannot read properties of undefined (reading 'users')
Stack:
at (\node_modules\.pnpm\[email protected]\node_modules\discord.js\src\structures\ModalSubmitInteraction.js:167)
at resolveCollection (\node_modules\.pnpm\[email protected]\node_modules\discord.js\src\structur...
67af624 refactor!: remove special cases for bot guild o... - almeidx
1c6eb0d fix: handle missing user object - Jiralite
Bots can no longer own guilds, and eventual already existing guilds owned by bots had their ownership transferred to a real user
Is this meant to be a private function? Because it's not marked as such in the JSDoc, and it's also not typed.
Additionally, why is this a static method anyways? It's only being used in this class once (besides the recursive calls) in the constructor
It is meant to be a private function. Making it private now or converted it to an instance would sadly be a breaking change.
static transformComponent(rawComponent, resolved, { client, guild }) {
Could we leave it as-is for ease? Note that this is a public method so a user may just not pass it (rightly so if they're not using the new select menus).
[discord.js] Branch fix/modal-select-resolving was force-pushed to `33d44a6`
11b236f fix(ModalSubmitInteraction): Resolve crash on h... - Jiralite
177d81f chore(discord.js): release [email protected] - Jiralite
[discordjs/discord.js] New tag created: 14.23.1
Which package is this bug report for?
discord.js
Issue description
(See code below)
- The modal is opened in a guild by a button
- The modal open properly
- After entering all the value and clicking on send, the bot crash:
TypeError: Cannot read properties of null (reading 'get')
at ModalSubmitInteraction.transformComponent (N:\Documents\Github\dicelette\discord-bot\node_modules\.pnpm\[email protected]\node_modules\discord.js\src\structures\ModalSubmitInteraction.js:1...
This code works fine (copied and pasted). Cannot reproduce on 14.23.1.
I know what the issue is though.
Resolves #11161.
The nested function would only iterate over data.values. If this is empty (possibly from a channel select menu component), data would be lost.
Strange, I created a new fresh repo (using bun) and I can reproduce:
➜ repro-djs 196ms tsx .\index.ts
[dotenv@17.2.3] injecting env (1) from .env -- tip: ✅ audit secrets and track compliance: https://dotenvx.com/ops
N:\Documents\Github\dicelette\repro-djs\node_modules\discord.js\src\structures\ModalSubmitInteraction.js:184
for (const [id, member] of Object.entries(resolved.members)) {
^
TypeError: Cannot convert undefined or nu...
Your error is different so no, you cannot reproduce. You have a different error now. That's also resolved with #11162.
Thanks, sorry, it was late and misread. Thank your for your work!
5cc13b7 fix(ModalSubmitInteraction): Better resolving o... - Jiralite
083f6ab chore(discord.js): release [email protected] - Jiralite
[discordjs/discord.js] New tag created: 14.23.2
0a28b42 fix(ApplicationCommandManager): set should use ... - didinele
in case those types ever diverge
What do permissions have to do with any of this? And if you meant RESTPutAPIApplicationCommandsJSONBody then that is already an array of commands, but this type is used an element of an array, so that's wrong too
cae3454 fix(ApplicationCommandPermissionsManager): trul... - didinele
Please describe the changes this PR makes and why it should be merged:
Closes #8096
This is indeed a bug and should be fixed. Thank you for reporting!
we discussed it internally and while everyone applauded my genius, we have instead decided to just do some good 'ole boilerplate and make 2 separate classes, essentially considering that highly abstracted monster with 4 generics is only used in 2 places
debc42e fix(GuildChannel): manageable perm check - didinele
Please describe the changes this PR makes and why it should be merged:
Closes #11116
It seems bizarre this hasn't been implemented yet given the API endpoint has existed since Sept 2023 - over 2 years ago! Perhaps Discord haven't officially documented the endpoint yet idk but given how simple it is to implement using the REST client...
client.rest.put(/channels/${channel.id}/voice-status, { body: { status: status } });
and that other clients such as discord.py have it implemented, it seems it would be v easy to add a method to the VoiceChannel object. I don't think Discord ...
What's stalling this is that it is not documented. You should voice your concerns to Discord.
What's the problem with implementing it when it's not documented, given that the endpoint has existed and functioned the same for over 2 years? What's the worst that happens in this case?
We simply do not implement undocumented features, regardless of their simplicity or apparent stability, this has pretty much always been our policy with no exceptions. You're welcome to +1 the dapi-docs PR.
BREAKING CHANGE: ApplicationCommand#options is now nullable
Please describe the changes this PR makes and why it should be merged:
Options hasn't always been present for a while now, this brings us more in line.
Status and versioning classification:
- I know how to update typings and have done so, or typings don't need updating
- This PR includes breaking changes (methods removed or renamed, parameters moved or removed)
da36bb4 fix: resolve components correctly - Jiralite
Please describe the changes this PR makes and why it should be merged:
Forward-porting #11162.
Status and versioning classification:
- Code changes have been tested against the Discord API, or there are no code changes
- I know how to update typings and have done so, or typings don't need updating
847fa99 fix(GuildChannel): manageable perm check (#11166) - didinele
I'm also for using the options, not the snake_cased value here. And the JSDoc and typings currently only accept camelCased data, so I don't see the reasoning for accounting for raw data
That doesn't change the fact that this will fail as soon as discord (and subsequently we) introduce a two-word property in tags, because that will be snake_cased at this point.
Why is this additional parameter needed, when they are only properties of this class being passed in?
489b58e fix: remove redundant parameter - Jiralite
dd79525 refactor!: remove special cases for bot guild o... - almeidx
There are already two-word properties in tags....emoji_id and emoji_name, and that's literally the entire point of the transformGuildForumTag util
see https://github.com/discordjs/discord.js/pull/11072#discussion_r2347635732 for why accepting raw data is the choice I made and why it's not currently documented that way
Ah, I see. My bad, ignore what I said, guess this conversation can be resolved then.
Fair enough. My first statement still stands, ignore the second.
There are already two-word properties in tags....emoji_id and emoji_name, and that's literally the entire point of the transformGuildForumTag util
No, there isn't because we didn't make it a two word property. It just so happens that specific case would work.
The problem is the input to transformGuildForumTag, not the output of it. Again... we're making that function with the assumption that a djs-like value is passed in, but now we're always passing in a snake cased value to it her...
but now we're always passing in a snake cased value to it here
This is wrong, we only pass a value to that function if it contains emoji in it, which means it's a djs-like value
I think I'll just go for options then
It's a djs-like value, except it has been snake cased. Making it not a djs-like value if there were any two word props
Ahhh, I see what you mean now, good catch
ah, i see what you mean, good catch
BTW, seems that in toSnakeCase(), if there are conflicting keys, the last one (by key order) takes precedence. i.e., if both snake case and camel case versions of a key are passed, the later one overwrites the earlier.
This won't be the case for these ones, where camel case will take precedence. Not sure if we should do something about it (maybe tweaking toSnakeCase to prefer the camel case version?..) or just let it be
I think I had set a precedent somewhere to prefer camel case when passsed which is why I did it this way.
I'm not exactly sure if I want to change that function in this PR, but I think it would make sense to because it would be more deterministic that way.
25b22c6 fix(ModalSubmitInteraction): Resolve components... - Jiralite
Please resolve conflicts!
Please describe the changes this PR makes and why it should be merged:
Resolves #11105
Status and versioning classification:
- Code changes have been tested against the Discord API, or there are no code changes
- I know how to update typings and have done so, or typings don't need updating
Which package is this bug report for?
discord.js
Issue description
An error occurs at startup:
TypeError: Cannot read properties of null (reading 'displayName')
The most important part: bot should not be on any server
Code sample
const { Client, Events } = require('discord.js')
const { token } = require('./config.json')
const client = new Client({
intents: []
})
client.once(Events.ClientReady, (client) => console.log(`${client.user.displayName} is ready!...
Please show the full stack trace (and never omit it–ever).
Please show the full stack trace (and never omit it–ever).
TypeError: Cannot read properties of null (reading 'displayName')
at Client.<anonymous> (...\index.js:8:72)
at Object.onceWrapper (...\node_modules\@vladfrangu\async_event_emitter\dist\index.cjs:2738:26)
at Client.emit (...\node_modules\@vladfrangu\async_event_emitter\dist\index.cjs:2504:31)
at Client._triggerClientReady (...\node_modules\discord.js\src\client\Client.js:421:10)
at Client._chec...
Cannot reproduce:
<img width="1510" height="610" alt="Image" src="https://github.com/user-attachments/assets/bd1fd4f9-35d5-4d35-ab10-12ad5c334992" />
<details>
<summary>Code</summary>
import { Client, Events, version } from "discord.js";
const client = new Client({ intents: [] });
client.on(Events.ClientReady, () => {
console.log(version);
console.log(`Logged in as ${client.user?.tag}!`);
});
void client.login();
</details>
I noticed you're using Node.js 23, which i...
Cannot reproduce:
<img alt="Image" width="1510" height="610" src="https://private-user-images.githubusercontent.com/33201955/501776896-bd1fd4f9-35d5-4d35-ab10-12ad5c334992.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NjA1Nzc1OTMsIm5iZiI6MTc2MDU3NzI5MywicGF0aCI6Ii8zMzIwMTk1NS81MDE3NzY4OTYtYmQxZmQ0ZjktMzVkNS00ZDM1LWFiMTAtMTJhZDVjMzM0OTkyLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYL...
If your bot is not in any server, have you created a bot user for it at all? Or is it a slash command only application? If so, this is the expected behaviour. client.user should be null.
If your bot is not in any server, have you created a bot user for it at all? Or is it a slash command only application? If so, this is the expected behaviour.
client.usershould be null.
Bot user is created
Apologies, I missed over that detail! Seems I can reproduce.
If your bot is not in any server, have you created a bot user for it at all? Or is it a slash command only application? If so, this is the expected behaviour.
client.usershould be null.
I also mentioned that the client is missing "application"
Which package is this bug report for?
discord.js
Issue description
After recent updates, TextInputBuilder#setValue() now throws an error when passing an empty string (''). This behavior seems incorrect, as the Discord API itself does allow an empty string as the value for a text input component. For the time being, this can be bypassed by setting the value to a string with a space character (' ')
This change breaks previously valid code that relied on setting a value that mi...
Which package is this bug report for?
discord.js
Issue description
I might've found a bug but I'm not sure if it's intended, so I'm reporting for clarification.
On the new modal components, the ModalSubmitFields has a property is an array, which is expected:
public components: (ActionRowModalData | LabelModalData | TextDisplayModalData)[];
However, the LabelModalData type has a property called component which is typed as an array:
export interface LabelModal...
Please describe the changes this PR makes and why it should be merged:
This pr fixes issue https://github.com/discordjs/discord.js/issues/11180
Status and versioning classification:
- Code changes have been tested against the Discord API, or there are no code changes
Hi @Jiralite, I'm interested in fixing this issue. But I want to ask... is it fixing the type or LabelModalData.component?
@emiedonmokumo I think just the type LabelModalData.component should be enough, but I'm not a maintainer. If it weren't for that, and the fact that I'm not that deep in the package itself (I'm just a user of it) I would've made one myself.
@The-LukeZ Yeah, I was having same thoughts. Just that your observation in particular made me to ask...
Seems the issue has been fixed already
<img width="721" height="301" alt="Image" src="https://github.com/user-attachments/assets/ec65eb05-6e00-4f52-9dbc-45181fcd63e8" />
Also it would be very useful if you could extract types from SlashCommandBuilder like type WarnData = typeof warnCommand.$inferOptions.
I'd say the better fix would be to move all the READY event handling into READY.js, not the other way around.
I'd say the better fix would be to move all the READY event handling into READY.js, not the other way around. Or at least the checkReady() call
I just noticed that the Ready event is async
None of the packet handlers are async, so calling this function won't be awaitable
While this can easily be fixed by adding "await" before "PacketHandlers[packet.t](this, packet, shardId);", but is it necessary?
I'd say the better fix would be to move all the READY event handling into READY.js, not the other way around. Or at least the checkReady() call
I believe this was not added to READY.js on purpose because the handler is async
I'd say the better fix would be to move all the READY event handling into READY.js, not the other way around. Or at least the checkReady() call
I believe this was not added to READY.js on purpose because the handler is async
Since I was the one who wrote that I can assure you that's not the reason. In v14 the checkReady check is in READY.js; this was simply an oversight when adapting to the direct use of /ws and should be reverted to check in READY.js
In v14 the checkReady check is in READY.js
Then checkReady() was not async
If we await the checkReady it should be done in Client#handleMessage(); the READY handler should not be async.
Which application or package is this feature request for?
discord.js
Feature
message.pinnable now checks if client user has the ManageMessages permission. Now that Discord added a seperate permission for PinMessages it should use this instead of ManageMessages
Ideal solution or implementation
Change ManageMessages to PinMessages
Alternative solutions or implementation...
161a635 fix(Message): update pinnable to check for mi... - sdanialraza
Please describe the changes this PR makes and why it should be merged:
Resolves #11188
For main, I would say change this completely. I doubt we will finalise our major release before 12th January 2026.
This exact change could be done for v14, however.
[discord.js] Branch fix/update-pinnable-migrated was force-pushed to `54dcfa3`
First, why check if a guild has this feature?
At the moment, even without this feature, PinMessages gives the right to pin messages
Secondly, pinning messages also requires the ReadMessageHistory permission
Which package is this bug report for?
discord.js
Issue description
Timeout not checked:
GuildEmoji.deletableGuildInvite.deletableGuildMember.moderatableGuildMember.kickableGuildMember.bannableMessage.editableMessage.pinnableMessage.crosspostable
Timeout is not checked with additional conditions:
Message.bulkDeletableWhen the message was sent by the clientThreadChannel.editableWhen the thread was created by the client- `ThreadChann...
Note: communication disabled checks are a duplicate of #9730.
There is discussion in there on paths forward, but nothing has come of it (yet).
Note: communication disabled checks are a duplicate of #9730.
There is discussion in there on paths forward, but nothing has come of it (yet).
I'll add this issue as a related one
There is also a bug with Message.crosspostable that on non-community servers the message is not crossposted, but I don't know which guild feature to check (maybe News?)
Announcement channels can be used in non-community guilds (simply turn community off). It probably still allows publishes. That is something to test.
Does this handle sending the component too>
Does this handle sending the component too>
Only thing that needed to be done in that regard was to update the typings, which reminds me, I missed updatingComponentInLabelDatain index.d.ts
[discord.js] Branch fix/update-pinnable-migrated was force-pushed to `59f3ace`
[discord.js] Branch fix/update-pinnable-migrated was force-pushed to `03bb75e`
- Because ManageMessages still works for guilds that haven't been migrated to PinMessages
- Thank you for mentioning
ReadMessageHistory, added that in the check
As of 0ff239a602aed71c74c931c975c84900cf671312, we can use GuildFeature.PinPermissionMigrationComplete!
This check is too late, it needs to be done before we do permissionsFor(), since that makes no sense for DMChannels
This should stay, as it was done for performance to not use the getter twice.
Did you test that ReadMessageHistory is explicitly required here and not just implicitly granted by ManageMessages?
Yes, it errors with Missing Access if you don't have ReadMessageHistory (even if you have ManageMessages)
[discord.js] Branch fix/update-pinnable-migrated was force-pushed to `01cf8f0`
[discord.js] Branch fix/update-pinnable-migrated was force-pushed to `b424b6f`
The migration has nothing to do with which permissions are usable - if you have either Manage Messages or Pin Messages you can pin. (as long as you also have read message history)
I thought the snake case had priority, not the camel case
The migration has nothing to do with which permissions are usable - if you have either Manage Messages or Pin Messages you can pin. (as long as you also have read message history)
The notice in permissions UI in the client seems to state differently. That's the whole point of that new separate permission afaict.
on that date manage messages will stop allowing pinning. that is separate from the guild feature
From internal discussions,[^1] we're going to require both permissions and make a release after removing MANAGE_MESSAGES.
[^1]: #internals message
public getUploadedFiles(customId: string, required: true): ReadonlyCollection<Snowflake, Attachment>;
public getUploadedFiles(customId: string, required?: boolean): ReadonlyCollection<Snowflake, Attachment> | null;
c9a9b6c feat: file upload component (#11114) - imnaiyar
5378bfc refactor: requested changes - sdanialraza
That false should be removed, admin obv allows it.
Also please for the love of god split this into multiple lines :D
104ad75 feat: handle file upload component for v14 (#11... - imnaiyar
Apart from vlad's comment LGTM
5394426 refactor: no checkAdmin and clean up the mess - sdanialraza
63417e8 refactor(makeCache)!: make params an object (#1... - ckohen
The migration has nothing to do with which permissions are usable - if you have either Manage Messages or Pin Messages you can pin. (as long as you also have read message history)
ee988e3 fix(Message): update pinnable to check for mi... - sdanialraza
On 12th January 2026, the permissions will be fully split. We should remove manage messages here if and when that happens:
16a44f8 chore(discord.js): release [email protected] - Jiralite
[discordjs/discord.js] New tag created: 14.24.0
For v14, the ReadMessageHistory permission is checked in Message.pinnable, but not in v15
8da8d65 fix(Message): update pinnable to use `PinMess... - sdanialraza
[discord.js] Branch fix/update-pinnable-use-pin-messages was force-pushed to `78e555e`
[discord.js] Branch fix/update-pinnable-use-pin-messages was force-pushed to `43d446f`
Please describe the changes this PR makes and why it should be merged:
Resolves https://github.com/discordjs/discord.js/issues/11188
Code path terminates quicker if you do this:
return permissions.has(PermissionFlagsBits.ReadMessageHistory | PermissionFlagsBits.PinMessages);
Array is passed to here:
When resolving, `Per...
8c66b53 refactor: use bitwise OR - sdanialraza
I found a new bug in Message.pinnable; in voice channels, this getter returns true, even though the voice channel doesn't support pins
Voice channels do not support pins
if (!('lastPinAt' in channel)) return false;
011c3b8 types(FileUploadComponentData): boolean - Jiralite
3048c3c types(FileUploadComponentData): required shou... - Jiralite
Which package is this bug report for?
discord.js
Issue description
Description
Several regex patterns across the codebase restrict Discord snowflakes to 17–19 digits. Since snowflakes are 64-bit integers, they will eventually exceed 19 decimal digits. When that happens, these patterns will fail to match, causing emoji parsing failures and incorrect REST rate-limit bucket grouping.
Steps to Reproduce
- Create a test file with a 20-digit snowflake ID
- Attempt to parse an ...
Obvious question that went unanswered: why, considering we are ~65 years away from this problem?
i mean if we can fix this now with very trivial changes of 5 regex, why wait 65 yrs .. the issue aint major now , but fixing it for 20 digits wont break anything in the codebase either :)
The regular expressions express certainty. If you are passing an id with 20 characters right now, that is certainly incorrect.
I understand the validation concern but the REST bucketing issue is operationally critical right now, not future-theoretical. The generateRouteData function doesn't validate user input..it normalizes routes received from Discord's API for rate-limit bucketing. When this regex fails to match a 20-digit ID (whether from a future discord response, internal test environment, or epoch migration), it won't throw an error ... it will silently create per ID buckets instead of per-route buckets, bre...
The max snowflake value according to the Discord API is 9223372036854775807, which has 19 digits.
You can get this value by making any call to an endpoint that takes a snowflake as a URL parameter, e.g., GET /guilds/:guildId, with a number with more than 19 digits.
DiscordAPIError[50035]: Invalid Form Body
guild_id[NUMBER_TYPE_MAX]: snowflake value should be less than or equal to 9223372036854775807.
e2eaec2 types(LabelModalData): no array - Jiralite
Please describe the changes this PR makes and why it should be merged:
Labels do not have an array of component.
Status and versioning classification:
- Code changes have been tested against the Discord API, or there are no code changes
- I know how to update typings and have done so, or typings don't need updating
8066821 types(LabelModalData): Singular ModalData (#1... - Jiralite
This isn't a bug right now, but in 65 years, everything could change, whether Discord shuts down or the discord.js project is archived
If Discord increases the limit on these snowflakes, then discord.js will increase it too
072fbb2 types(LabelModalData): Singular ModalData (#1... - Jiralite
Which package is this bug report for?
discord.js
Issue description
The docs state attachments and values as available properties for FileUploadModalData, but they seem to be not accessible.
Furthermore, trying to return specific properties of the Attachment files always results in returning the Attachment ID, I am unable to get the URLs.
Different approaches used, same issue:
...
I can reproduce FileUploadModalData with wrong fields. Thank you for reporting that.
I cannot reproduce not being able to get an attachment URL. This may be a user error. Your code sample has an optional chain and does not have the parameter to assert your are receiving your file upload, which leads me to believe this. You probably are testing with the wrong custom id.
c77f634 types(FileUploadModalData): update fields - Jiralite
Please describe the changes this PR makes and why it should be merged:
When transforming a component for file uploads:
We set the type, id, customId, values, and attachments. Other fields are simply wrong.
Status and versioning classification:
- Code changes have been tested against the Discord API, or the...
e636617 docs(FileUploadModalData): Snowflake - Jiralite
c7909fe types(FileUploadModalData): Snowflake - Jiralite
73104da types(FileUploadModalData): update fields - Jiralite
[discordjs/discord.js] Pull request opened: #11210 types(FileUploadModalData): Correct fields #11209
Please describe the changes this PR makes and why it should be merged:
When transforming a component for file uploads:
We set the type, id, customId, values, and attachments. Other fields are simply wrong.
JSDoc properties are correct:
https://github.com/discordjs/discord.js/blob/c77f63492e59bb3c0a80da0d819512...
f6eba5f docs: update more fields - Jiralite
56662eb types(FileUploadModalData): Correct fields (#11... - Jiralite
d317ca1 types(FileUploadModalData): Correct fields (#11... - Jiralite
Which package is this bug report for?
discord.js
Issue description
Bug Report: Race condition in Mermaid component prevents theme re-renders
Description
The Mermaid component has a race condition that causes charts to skip re-rendering when props change during an async render. The currentChartRef is updated before the async mermaid.render() completes, causing subsequent effect runs to incorrectly skip rendering.
Impact
- Severity: Medium
- **User-facing...
This PR updates the pinnable getter in the Message class to prepare for Discord's permission split scheduled for January 12, 2026.
Changes Made:
- Replaced
ManageMessagespermission check withManageChannelMessagesandReadMessageHistorypermissions - Updated the permission validation logic in the
pinnablegetter to align with Discord's upcoming API changes
Why this change is needed:
On January 12, 2026, Discord will fully split the ManageMessages permission. Af...
i want this PR to be considered under hacktober fest
This PR was obviously not tested because that permission doesn't even exist and the change won't happen before January. So definitely not gonna happen now. Do your hacktoberfest with PRs actually relevant now.
There is no such permission flag named ManageChannelMessages
Please don't make issues out of AI.
- This is not an issue of the discord.js package, despite you tagging it as such
- The page you reference as example doesn't even use mermaid, so you obviously didn't test it on that site although you state that these are reproduction steps
- The code you reference is from the guide while the page you link is from the docs website, doesn't add up either
I understand that you want hacktoberfest points, but please don't make up random stuff to achieve that.
ed143a6 fix(GuildMemberFlagsBitField): Remove duplicate... - Copilot
abb84ce docs(GuildMemberFlagsBitField): remove duplicat... - Jiralite
80d4ef4 fix(Message): check if in voice based channel f... - sdanialraza
Please describe the changes this PR makes and why it should be merged:
You can't pin messages in voice based channels: https://github.com/discordjs/discord.js/issues/11192#issuecomment-3446575607
To reach this point, it must be a voice-based channel that is viewable.
const permissions = channel.permissionsFor(this.client.user);
I think an explicit !channel check first is more readable too.
if (!channel || channel.isVoiceBased() || !channel.viewable) return false;
const { NonSystemMessageTypes, MaxBulkDeletableMessageAge, UndeletableMessageTypes } = require('../util/Constants.js');
Hi @Jiralite, can I handle this?
you can open a pull request to address issues here: https://github.com/discordjs/discord.js/compare
you can find our contribution guidelines here: https://github.com/discordjs/discord.js?tab=contributing-ov-file
Please describe the changes this PR makes and why it should be merged:
In commit https://github.com/discordjs/discord.js/commit/6df36232a05e396d31461200725755745526d2ed, handling of empty permission overwrites was added, but it was not taken into account that only @everyone should be handled
Closes #11190
Status and versioning classification:
- Code changes have been tested against the Discord API, or there are no code changes
- I know how to update typings and have done so...
Please describe the changes this PR makes and why it should be merged:
Previously, permissionsLocked returned true for any empty overwrite, causing
channels with empty user or role overwrites to appear locked. This change limits
the "locked" behavior to only the @everyone overwrite (id === guild.id), which
matches Discord's expected permission inheritance behavior.
Status and versioning classification:
@emiedonmokumo, I don't understand English very well
Could you explain what you meant?
Which package is this bug report for?
discord.js
Issue description
The current output is the RAW data received from discord:
raw GUILD_CREATE incidents_data: {"raid_detected_at":"2025-10-25T21:33:03.211032+00:00","invites_disabled_until":null,"dms_disabled_until":"2025-10-29T09:27:55.374000+00:00","dm_spam_detected_at":null}
as you may notice, this is received on GUILD_CREATE packet
client.on('raw', (packet) => {
if ((packet.t === 'GUILD_CREATE' || packet.t === 'G...
You set dmsDisabledUntil then verify a guild has it after restarting... is that all? If so, that works fine for me with your code sample. Am I misunderstanding something?
You set
dmsDisabledUntilthen verify a guild has it after restarting... is that all? If so, that works fine for me with your code sample. Am I misunderstanding something?
that is correct, through a crontab, we set it as lock; which works, the thing that doesn't work is getting incidentsData;
import Crontab from "@/crontab"
import { Guild } from "discord.js"
import logger from "@/globals/logger"
export default new Crontab()
.cron("0 0 * * *")
.listen(async (ctx) => {
...
You set
dmsDisabledUntilthen verify a guild has it after restarting... is that all? If so, that works fine for me with your code sample. Am I misunderstanding something?that is correct, through a crontab, we set it as lock; which works, the thing that doesn't work is getting incidentsData;
import Crontab from "@/crontab"
import { Guild } from "discord.js"
import logger from "@/globals/logger"
export default new Crontab()
.cron("0 0 * * *")
.listen(asy...
noticed this after fully rewriting that guild ended up being the one as undefined.
Closing this issue
before merging, we should give this a little test.
@Jiralite would you mind? otherwise, I can get to it tonight
[email protected]
if (!channel?.viewable || VoiceBasedChannelTypes.includes(channel.type)) return false;
Would prefer to not have an includes(undefined) check
cd9870a Update packages/discord.js/src/structures/Messa... - Jiralite
0dbccb6 Update packages/discord.js/src/structures/Messa... - Jiralite
99e6677 Update packages/discord.js/src/structures/Messa... - Jiralite
Previously, permissionsLocked returned true for any empty overwrite, causing channels with empty user or role overwrites to appear locked. This change limits the "locked" behavior to only the @everyone overwrite (id === guild.id), which matches Discord's expected permission inheritance behavior.
Why do I have a feeling this was written by AI?
Hi @almostSouji, was hoping to get a response from you...
94a9b4d fix(Message): update pinnable to use `PinMess... - sdanialraza
This should be changed to match the check done in the main branch
3e7c689 chore: changes from main - Jiralite
c2c8cce fix(Message): check if in voice based channel f... - sdanialraza
c303bf3 chore(discord.js): release [email protected] - Jiralite
[discordjs/discord.js] New tag created: 14.24.1
Message.pinnable now checks the ReadMessageHistory permission and the voice channel!
was a little later than "tonight", but I got to it. we should be good :)
The only way this will emit without partials is if the message was already in the cache. Perhaps you are overwriting null for the author somewhere? Was content in the message there an actual message or ''?
Also, are you still experiencing this issue? There doesn't seem to be a lot to go on, especially if this is not reproducible.
It was recently said that members from VOICE_STATE_UPDATE will have joined_at as null if the member was invited as a guest.^1
Not sure if there is anything that needs to be done now then?
Thanks for responding. I've confirmed that I'm not overwriting the author anywhere, or manipulating the cache manually. There was actual content in the message, which I removed for privacy reasons. But it was not an empty string.
I've since implemented a workaround to check for partials and return early, so as not to spam the logs. But if needed, perhaps I can log to a channel instead so I don't print to production logs.
I'm unsure if the user being a deleted user could cause this? Obviousl...
While the null case now being documented is nice, it still doesn't fix the issue from my perspective. GuildMember#partial's value depends on GuildMember#joinedAt, which means that if partial is false, that then implies joinedAt and joinedTimestamp must be present, however the typings don't reflect that - they still list those two properties as possibly being null, which contradicts whether or not the object is truly a partial or not:
declare const member: GuildMember | Partial...
Please describe the changes this PR makes and why it should be merged:
Fixes a case where if the API sends member data with joined_at being null, Date.parse() tries to parse that resulting in joinedAt and joinedTimestsamp being NaN.
Status and versioning classification:
- Code changes have been tested against the Discord API, or there are no code changes
- I know how to update typings and have done so, or typings don't need updating
178c9cb fix(GuildMember): joinedAt possibly being NaN (... - TAEMBO
return this.joinedTimestamp === undefined;
fb2b728 fix(GuildMember): joinedAt possibly being NaN - Jiralite
a036618 chore(discord.js): release [email protected] - Jiralite
[discordjs/discord.js] New tag created: 14.24.2
Which package is this bug report for?
discord.js
Issue description
Consider the following code:
const messages = (
await channel.messages.fetch({
cache: false,
limit: 100,
})
)
discord.js will create a request with the following query string: ?cache=false&limit=100 because of this line in _fetchMany: https://github.com/discordjs/discord.js/blob/main/packages/discord.js/src/managers/MessageManager.js#L120
This function should instead only consi...
96765b3 fix: only pass relevant options to API when fet... - sdanialraza
Please describe the changes this PR makes and why it should be merged:
Resolves #11227
Please describe the changes this PR makes and why it should be merged:
Backport of #11228
Status and versioning classification:
Do something like this instead:
async _fetchMany({ cache, ...apiOptions } = {}) {
f26a5ed fix: only pass relevant options to API when fet... - sdanialraza
I believe a Set would be better suited for the private member _roles collection.
I think the role cache getters will perform better by iterating over the _roles subset instead of every guild role.
Status and versioning classification:
- I know how to update typings and have done so, or typings don't need updating
Refactor stack trace capture for consistency and improve error code validation.
This pull request improves how stack traces are handled and makes error code validation safer. It does not change how the library works, only makes the internal error system more reliable and consistent across environments.
Why it should be merged:
- Works the same as before, no breaking changes
- Cleaner and safer internal code
- Better stack trace handling for debugging
Status: - No APi or behavior ch...
Can we see the before & after examples then?
makes the internal error system more reliable and consistent across environments
Can you give an example of an environment that is relevant to discord.js where Error.captureStackTrace() is not present?
As it stands, the only change that seems acceptable is the DiscordjsError -> this.constructor on the second argument.
These should never be constructed without data...
The blame seems to go years and years back. Was likely ancient logic made redundant over time.
Pull Request Overview
This PR removes the conditional if (data) checks before calling _patch(data) in the constructors of multiple structures including Webhook, ThreadChannel, Role, PermissionOverwrites, and GuildMember. The changes standardize the initialization pattern by always calling _patch regardless of whether data is provided.
- Removes conditional data checks before
_patch()calls in constructors - Affects 5 structure classes: Webhook, ThreadChannel, Role, Perm...
[discordjs/discord.js] New review comment on pull request #11250: fix: Remove data conditional check
Removing the if (data) check will cause a TypeError when _patch unconditionally accesses data.id (line 50) if data is null or undefined. Either restore the conditional check or add null/undefined handling at the start of _patch.
[discordjs/discord.js] New review comment on pull request #11250: fix: Remove data conditional check
Removing the if (data) check will cause a TypeError when _patch accesses data.token (line 46) and data.id (line 65) if data is null or undefined. The _patch method unconditionally accesses properties like data.token ?? null and data.id without checking if data exists first. Either restore the conditional check or add null/undefined handling at the start of _patch.
[discordjs/discord.js] New review comment on pull request #11250: fix: Remove data conditional check
Removing the if (data) check will cause issues in _patch if data is null or undefined. While _patch uses conditional checks like if ('user' in data), the in operator will throw a TypeError if data is null or undefined. Either restore the conditional check or add null/undefined handling at the start of _patch.
if (data) this._patch(data);
[discordjs/discord.js] New review comment on pull request #11250: fix: Remove data conditional check
Removing the if (data) check will cause a TypeError when _patch unconditionally accesses data.id (line 36) if data is null or undefined. Either restore the conditional check or add null/undefined handling at the start of _patch.
0a1d54f feat(GuildMemberManager): handle gateway reques... - didinele
5740661 chore: typo no one saw - didinele
5c7fc8c feat(GuildMemberManager): handle gateway reques... - didinele
b085059 fix: account for ws abstraction layer - didinele
6bbdc2b chore: yada yada - didinele
a040fc2 fix: cleanup listener properly - didinele
2552148 types: add missing types - Jiralite
Oversight from #10528, the added error codes were not added to index.d.ts.
dfc6d9c types: add error code - Jiralite
Shouldn't there be a /src/client/websocket/handlers/RATE_LIMITED.js for this websocket event so that
- end users can listen to it directly and
- you can use it here directly instead of having to filter the full dispatch event again
Same applies for the backport where it would replace the usage of listening to Events.Raw
The changes in GuildEmojiRoleManager#cache and GuildMemberRoleManager#cache are solid and definitely will see an improvement since it's not running a nested iteration anymore, however...
Changing GuildMember#_roles to be a Set rather than a Snowflake[], whilst it's true it'll see performance gains in large datasets, the average role count is more like 2-3 roles (tested in my bot, 3_296_963 GuildMember instances, 6_291_128 member roles excluding everyone), therefore making a negligi...
c85f18c feat: optimize role manager cache getter (#11239) - WhatCats
2da2fa0 feat: optimize role manager cache getter (#11239) - WhatCats
Which application or package is this feature request for?
discord.js
Feature
I really like djs for its compact features such as; to check if a message is deletable or if a role is editable but I cant find anything similar for threads creation. To check if if the client user can create a thread in this channel or message. I dont think this exists yet or maybe there is another easy way to check if a message is threadable that i dont know of. I now check if i have the needed permissio...
Messages are not subclassed, so it wouldn't really make sense as helper on Message.
For a channel you can just check for the existence of channel.threads.
I considered it, my objection being
end users can listen to it directly
should they (esp. if the behavior is a thrown error anyway when it happens)? would they want to? why?
Same reason we have REST#on('rateLimited',...) while also rejectOnRatelimit setting. So users can decide themselves, use it for debugging, and in general expose all events to the end user, which we do in next major anyway.
BREAKING CHANGE: WebhookClient has been removed, use @discordjs/core instead or fetch webhooks. Alternative solutions are in the works
Please describe the changes this PR makes and why it should be merged:
WebhookClient is an incredibly inefficient way to interact with webhooks (creates a rest instance per webhook, an entire client per webhook etc..). We are working on developing an alternative to this that will mimic the simplicity of WebhookClient. In the meantime, we recommend us...
Now that #11251 is merged, time to use the new class from the shared package!
[discord.js] Branch feat/mainlib-fetch-g-member-limit was force-pushed to `2528a50`
In #11251 we decided to share an error class between core and util. Naturally, that expects raw API data.
While ultimately I agree with adding the rate limit event for end users, constructing the error class becomes non-trivial after the conversion step in the RATE_LIMITED.js handler. As such, the handling here will continue listening to Dispatch/Raw (v14)
d362a34 refactor: requested changes - didinele
655c169 fix: update emitted warning - didinele
Waiting on #11252 so we know for sure what our approach is.
this.client.ws.removeListener(WebSocketShardEvents.Dispatch, rateLimitHandler);
Consistency I guess...
Wouldn't we want this warning to emit again if another unknown ratelimit happens?
This needs to be added in typings too.
I wanted both to be off actually, but with a quick search through the codebase, it seems we're doing removeListener a bunch.
My thought process was that if we have a type that's unimplemented, that will lead to the request hanging (see how request guild members currently behaves right now without this PR merged), so warning at least once will make sure the user is at least aware this could be happening if they don't have a listener.
Now that you ask, I'd go even further and do !emittedWarning && !listenerCount(...). Thoughts?
Worth removing BaseClient as well imo due to Client being the only other thing using it
[discordjs/discord.js] New comment on pull request #11266: refactor(Webhooks)!: remove WebhookClient
I decided not to unify the client class in this PR. I think we should in a PR following this one though.
This error is used nowhere else, should probably be removed from /errors/ErrorCodes.js and /errors/Messages.js and typings now.
This utility helper was only used for WebhookClient, do we want to keep it anyway for future use/user convenience?
9edfadb chore: requested changes - didinele
Which application or package is this feature request for?
discord.js
Feature
Getting a bit hard to track stuff in the internals channel, so I'm making a few issues
TBD with/after #11266
Ideal solution or implementation
why am I forced to use issue templates :(
Alternative solutions or implementations
No response
Other context
No response
Which application or package is this feature request for?
discord.js
Feature
.
Ideal solution or implementation
.
Alternative solutions or implementations
No response
Other context
No response
Which application or package is this feature request for?
discord.js
Feature
Especially after #11248, we need to ensure discord.js is well-inline with the current state of builders.
Ideal solution or implementation
.
Alternative solutions or implementations
No response
Other context
No response
Apart from typings already pointed out LGTM
Important internal convo #internals message
We're currently torn on introducing the ratelimited event or not.
We've decided to ultimately not introduce Client#ratelimited.
Lets hope nothing breaks :))
837af56 fix: Remove data conditional check (#11250) - Jiralite
84197a0 fix: Remove data conditional check (#11250) - Jiralite
This is only going to log the string (i.e. GatewayRateLimitError: Request with opcode X was rate limited. Retry after Y seconds.), is that intended? It sounds like we'd want to log the object (we lose logging meta).
[discord.js] Branch refactor/remove-base-client was force-pushed to `871f6f5`
[discord.js] Branch refactor/remove-base-client was force-pushed to `6ced9bd`
Please describe the changes this PR makes and why it should be merged:
Resolves #11271
BREAKING CHANGE: BaseClient has been removed and its functionality has been merged into Client.
Depends on:
- #11266
9f18cb2 refactor(Webhooks)!: remove WebhookClient (#11266) - ckohen
[discord.js] Branch refactor/remove-base-client was force-pushed to `514b015`
This is now a duplicate of the variable defaults defined later on and should be done only once.
options are a required parameter for Client constructor (in particular the intents are), so why have a default value defined here?
Considering we don't need nor want to be able to pass more properties to toJSON() this can probably be simplified by removing `...props’ here and on next line
3dc53c4 chore: requested changes - sdanialraza
It doesn't currently (in the existing cases)
`Hit a gateway rate limit on opcode ${data.opcode} (${GatewayOpcodes[data.opcode]}). If the discord.js version you're using is up-to-date, please open an issue on GitHub.`,
b4ae165 chore: wording - didinele
25aff7e feat(GuildMemberManager): handle gateway reques... - didinele
Aren't the channels being cached documentation & comments redundant given discord.js should always have channels cached?
7c43fc0 docs(MessageManager): update fetchPins() wording - Jiralite
This no longer returns a collection. It's a paginated endpoint. Wording has been updated.
87364c7 docs(MessageManager): Update fetchPins() word... - Jiralite
492039c docs(MessageManager): update fetchPins() wording - Jiralite
[discordjs/discord.js] New comment on pull request #11072: fix(guildChannel): better channel editing
they're not always cached, just in 99.99% of cases
7349a6e refactor(client)!: remove BaseClient (#11274) - sdanialraza
Please describe the changes this PR makes and why it should be merged:
A new import was added here from #11274:
This surfaced a circular dependency:
- Client.js -> Util.js
- Util.js -> GuildChannel.js
- GuildChannel.js -> PermissionOverwriteManager.js
- PermissionOverwriteManager.js -> PermissionOverwrites.js
- PermissionOverwrites.js -> Bas...
5ab8aec fix: linter - Jiralite
[discord.js] Branch feat/14-mainlib-fetch-g-member-limit was force-pushed to `44a2dd3`
Considering the time that has passed and the failure to provide a reproducible code sample, I'll be closing this.
0268894 fix(GuildEmojiManager): allow `CreateGuildExpre... - Jiralite
Following https://github.com/discord/discord-api-docs/issues/6543#issuecomment-3554803947, CREATE_GUILD_EXPRESSIONS also returns an emoji's user (author in discord.js), regardless of who created it.
8f988e7 fix!: update error code - Jiralite
[discord.js] Branch refactor/mainlib-for-builders-updates was force-pushed to `2207fa3`
bf43681 chore: forgotten - didinele
Apart from that question LGTM
Shouldn't we keep a test for sending a voice message instead of replacing this with a plain text file?
Unless the new code is correct
payload = await MessagePayload.create(message instanceof Message ? message : this, options).resolveBody().resolveFiles();
Both ideally (tho this is a type test not a runtime test)
If possible, updating one of the runtime test files would be appreciated
yea that was an accident, ty
77241ad fix: proper messagepayload instantiation - didinele
JSONEncodable<APIAttachment> doesn't work:
attachment = fileLike.attachment resolves to undefined, so that follows here:
Which crashes:
TypeError: Cannot read properties of undefined (reading 'path')
a...
well, I didn't add that :), but you're right
147dac5 fix: bad files type - didinele
See #1209960895141388389 message
This didn't work at runtime prior to this PR, the types were incorrect. With the current state of things, it's impossible to make it work either, so goodbye.
The one below (not included in the diff, since I didn't touch it) still has sending but without the builder
3335298 chore: format - didinele
7dbe98f chore: doc types - didinele
Please add setId() for completeness!
payload = { body: options.toJSON() };
payload = { body: options.toJSON() };
Which package is this bug report for?
discord.js
Issue description
The Collector#resetTimer method does not properly update the collector's timers after changing the idle value. Even after calling resetTimer with a new idle or time, the collector continues to use the old timers. This makes the method ineffective in scenarios where the idle timeout needs to be extended dynamically.
Steps to reproduce
- Create a collector with an initial
idletime. - Wait some tim...
Problem
At the moment methods like GuildMemberManager:fetch that have an optional string parameter are doing a falsy check for if the parameter was omitted. But consider the following typescript code:
const id: string = ""
const member: GuildMember = await guild.members.fetch(id)
According to the typings member should be a GuildMember but its actually a Collection because the empty string is falsy.
My Suggestion
Do more exact undefined/null checks.
(I might ...
b6287dd fix(GuildEmojiManager)!: Allow `CreateGuildExpr... - Jiralite
Backports #11283.
Wasn't sure if throwing a different error code would be breaking, so I only modified the description. I believe it is, because catching with DiscordjsErrorCodes.MissingManageGuildExpressionsPermission will no longer work as we'd throw with a different error code.
It's highly unlikely we'll be backporting this, unless a very good argument is presented for it. We're not particularly keen on messing with the compatibility layer in v14.
0d64ea0 fix(GuildEmojiManager): Allow `CreateGuildExpre... - Jiralite
fdac8c5 chore(discord.js): release [email protected] - Jiralite
[discordjs/discord.js] New tag created: 14.25.1
2147980 refactor(DJSError): prefer this.constructor.name - Jiralite
Errors look like this currently:
TypeError [InvalidType]: Supplied options is not an object.
at Object.
// Stack...
Using this.constructor.name will result in this:
DiscordjsError [InvalidType]: Supplied options is not an object.
at Object.
// Stack...
Seems more favourable!
db41d5c refactor(DJSError): Prefer `this.constructor.na... - Jiralite
e32f0c1 refactor(DJSError): Prefer `this.constructor.na... - Jiralite
524106f fix(DJSError): differentiate error type - Jiralite
Following from #11294, error types are differentiated (they all became DiscordjsError):
throw new DiscordjsError(ErrorCodes.InvalidType, 'options', 'object', true);:
DiscordjsError [InvalidType]: Supplied options is not an object.
at Object. (/Users/jiralite/Documents/GitHub/discord.js/discord.js/packages/discord.js/src/managers/GuildBanManager.js:226:7)
at Module._compile (node:internal/modules/cjs/loader:1760:14)
at Object..js (node:internal/modules/cjs/loader:18...
I wonder if we can remove this optional chain
It looks like both Bun and Deno support this, so I am not sure why this is optional. The blame goes back 8 years, so... let's remove it and see what happens, I'd say.
02fc101 fix(DJSError): Differentiate error type (#11295) - Jiralite
f5b3f84 fix(DJSError): Differentiate error type (#11295) - Jiralite
Which package is this bug report for?
discord.js
Issue description
Steps to reproduce:
- Replace
Bun.env.TOKENwith your bot's token - bun run sample.ts
- use /ping on the bot
- See "\ is thinking..." forever
From my testing it either awaits deferReply forever, or throws bothThe reply to this interaction has not been sent or deferred.andInteraction has already been acknowledged.
Works completely fine with node and deno
Code sample
import { Client, ...
I cannot reproduce this. Using Bun 1.3.3. Try updating and see if you can still reproduce.
Sorry, completely didn't notice bun had an update
Which package is this bug report for?
discord.js
Issue description
Issue Summary: When a file attachment with a Chinese or other non-ASCII filename is uploaded via a Discord.js bot command, the retrieved name property for the attachment only retains ASCII characters; any non-ASCII (e.g. Chinese) characters are lost. This affects filenames such as "测试文件.jpg" or "Test测试.png" which become "Test.png" after upload.
Root Cause: The problem appears to originate from the `basena...
Unfortunately, your root cause analysis is incorrect. Discord does not normalise the filenames in attachments:
<img width="301" height="181" alt="Image" src="https://github.com/user-attachments/assets/80d1f93e-4b23-451e-a48c-8126765b6bd4" />
Additionally, path.parse().name seems fine:
<img width="338" height="89" alt="Image" src="https://github.com/user-attachments/assets/1496f7bc-74c6-4ea1-a35f-8cbbd784145d" />
Disregarding this, this is not a bug. name (filename from the API) is i...
Please describe the changes this PR makes and why it should be merged:
This future-proofs against Discord potentially making the maximum bitrate for stage channels variable. Currently, it is always 64000. It is also just easier than the user manually typing in 64000 each time they need it.
Status and versioning classification:
- Code changes have been tested against the Discord API, or there are no code changes
- I know how to update typings and have done so, or typings don'...
Which package is this bug report for?
discord.js
Issue description
setLabel in the string select memu option builder should be 100 character length but it errors at 45. Encountered error within using it inside modal label
Code sample
Versions
Djs 14.25.1
Issue priority
Medium (should be fixed soon)
Which partials do you have configured?
Not applicable
Which gateway intents are you subscribing to?
Not applicable
I have tested thi...
- The issue is with the builders package, not discord.js
- I can't reproduce the problem in v14.25.1
aeb8986 fix(Client): Move client initialization code (#... - vakiliner
0aa1b40 refactor: requested change - didinele
[discordjs/discord.js] Pull request opened: #11323 docs(discord.js): less omit types for better docs
Please describe the changes this PR makes and why it should be merged:
improves docs of MessageEditOptions, GuildChannelCreateOptions and GuildChannelCloneOptions by turning them into pure interface inheritance instead of...
Personally, I think this is a step in the right direction. However, I don't think this change alone is enough, as it will potentially bring different issues. For instance, passing an empty string to RoleManager#fetch() will now make a request to the Get Guild Roles endpoint, but through the Get Guild Role path internally. This will mean the endpoint will return a different body than expected, which might create worse errors that are harder to pinpoint.
To fix that, we should make fur...
Which package is this bug report for?
discord.js
Issue description
When listening to AuditLogEvent.SoundboardSoundCreate, SoundboardSoundUpdate, SoundboardSoundDelete, the GuildAuditLogsEntry object always returns targetId = null.
For all other audit log types such as emoji, channel, role, sticker, etc., targetId correctly contains the created object’s ID.
But for Soundboard Sound Create, targetId is always null, even though Discord provides the ID inside changes.
Because of this...
But for Soundboard Sound Create, targetId is always null, even though Discord provides the ID inside changes.
These are different fields. I wouldn't conflate them.
This is how the target id is picked up:
Extremely simple: if Discord gives us one, we have it. Have you verified this? If there is truly no target id, it seems this would no...
My Code:
const soundId = changes.find((c) => c.key == 'id')?.new as Snowflake;
const sound = await guild.soundboardSounds.fetch(soundId!).catch(() => null);
console.log(soundId);
console.log(entry.targetId);
Output:
1446218492104675328
null
I actually meant from the API and not discord.js–don't worry, we'll independently verify it.
I understand, I even sent this sample to verify, good luck
const sticker = guild.stickers.cache.get(targetId!);
console.log(changes.find((c) => c.key == 'id')?.new as Snowflake);
console.log(entry.targetId);
1446218492104632358
1446218492104632358
Which package is this bug report for?
discord.js
Issue description
UserManager.send() always sends a direct message
Code sample
public send(user: UserResolvable, options: string | MessagePayload | MessageCreateOptions): Promise;
Versions
- [email protected]
- Node.js v24.11.0
- [email protected]
Issue priority
Low (slightly annoying)
Which partials do you have configured?
Not applicable
Which gateway intents are you subscribing to?
No...
hey @Jiralite , if this is open for external contributors shall i work on it ??
hey @Jiralite , if this is open for external contributors shall i work on it ??
Yes @AryanBagade, go ahead. If you need any help, feel free to ask in https://discord.com/channels/222078108977594368/937420598383108167 (discord.js Discord server invite: https://discord.gg/djs)
Which package is this bug report for?
discord.js
Issue description
newMember/oldMember never contains premiumSince but does include premiumSinceTimestamp. I'm just going to use the latter but your docs still mention premiumSince is always present on a full GuildMember (newMember) in 14.25.1.
Quick check shows premiumSince is not present in your Typescript definition either so maybe this is not a bug and is intended then?
Code sample
discordClient.on("gu...
- Why are you not using the guilds intent?
- Why are you typing events by yourself?
- Provide logs please
My intents are, you can only select 1 intent in your questionaire.
const discordClient = new Client({ intents: [
GatewayIntentBits.Guilds,
GatewayIntentBits.GuildMembers,
GatewayIntentBits.GuildMessages,
GatewayIntentBits.MessageContent
]});
I'm not Typing Events by myself, i'm importing discordjs types:
import { Client, GatewayIntentBits, Guild, GuildMember, PartialGuildMember } from 'discord.js';
Your TS does not include a field for premiumSince.
What's with the attitude pal? I'm trying to help your team out here?
Frankly, irrelevant if I explicitly state a type in the paramaters and return. It changes nothing, the field is not there.
Here's a console.log of newMember:
new member
GuildMember {
guild: <ref *1> Guild {
id: '1420866197582254175',
name: 'Classic Plus Project',
icon: '9654b47f31729dd9faff60b02c8fedec',
features: [
'GUILD_ONBOARDING_EVER_ENABLED',
'BANNER',
'PIN_PERMISSION_MIGRATION_COMPLETE',
'VIDEO_QUALITY_1080_60FPS',
'TIERLESS_BOOSTING',
'AUDIO_BITRATE_384_KBPS',
'COMMUNITY',
'ANIMATED_BANNER',
'ENHANCED_ROLE_COLORS',
'ACTIVITY_FE...
What's with the attitude pal? I'm trying to help your team out here?
Frankly, irrelevant if I explicitly state a type in the paramaters and return. It changes nothing, the field is not there.
You may be a bit defensive here. There is no attitude.
<hr>
Your logs do not prove your issue–getters do not log. Additionally, when I asked for logs, I asked for logs from TypeScript because you keep saying TypeScript doesn't have the definition.
I am closing this until something reproducible...
greetings maintainers,
I am new to the project, if someone has not started working on this, can i take this issue up to explore?
@vikramsingh117 im working on this!!
Fixes the return type of UserManager.send() to correctly reflect that it always returns a DM message.
What changed
- Updated return type from
PromisetoPromisein both TypeScript definitions and JSDoc - Added type test to prevent regression
Why
UserManager.send() always creates a DM channel and sends the message there, so the return type should indicate it's a non-guild message (Message). This makes the types more accurate and helps developers using TypeScript.
...
We don't use this generic anywhere else on the jsdocs. Not sure if there's an actual reason or if it was just missed.
* @returns {Promise<Message>}
The client being ready isn't really relevant for types here
expectType<Promise<Message<false>>>(client.users.send(user, 'test'));
808b450 feat(RoleManager): add fetchMemberCounts - almeidx
Integrates the new endpoint into the RoleManager
Upstream:
@copilot Doesn't counts.first and counts.firstKey need to be flipped?
@iCrawl I've opened a new pull request, #11354, to work on those changes. Once the pull request is ready, I'll request review from you.