#archive-github-djs
1 messages ยท Page 2 of 1
type RoleMention = '@everyone' | '@here' | `<@&${Snowflake}>`;
@here is not a role, while @everyone is the role that everyone has.

Sorry for the empty commit but there was a problem with npm.
the @everyone role is actually unrelated to the @everyone ping; actually mentioning the @everyone role outputs @@everyone and doesn't ping anyone.
would probably be best to remove that if/return tbh
Well maybe, but I didn't change anything on that method. This is just to add types and Role.toString() can return @everyone too so I added it...
Please describe the problem you are having in as much detail as possible:
Assume a situation where a text channel is in a category, with the channel's permissions set in Discord to sync with the category.
Accessing GuildChannel#permissionsLocked for that channel will confirm this.
Now, assume that the permissions overwrites in the category are updated, and you have an event listener set for channel updates.
First, you will see the update come through for the category permiss...
Please describe the changes this PR makes and why it should be merged:
This PR fixes an issue where you'd be able to pass an array of MessageComponents in the components property for MessageOptions where, in fact, you need to pass an array of arrays of MessageComponents. This also makes it so that initializing a MessageActionRow with an empty object in the constructor will now throw an error.
These scenarios will still work:
new MessageActionRow ();
new MessageActionRow({ compo...
I thought these were meant to be sorted alphabetically but at least leave an empty line between them
I can sort them alphabetically but I didn't add a line because I saw some other types without it... I'll check this later.
Then those should probably have it cuz there's an empty line between almost everything in this file. And yeah you should sort them alphabetically within the typedefs region
Please describe the problem you are having in as much detail as possible:
When Using Util.splitMessage if char is array, it not splited. it's like join ','
Include a reproducible code sample here, if possible:
> Util.splitMessage(`${'a'.repeat('10')}\n${"b".repeat('10')}`,{maxLength: 10, char: '\n'})
[ 'aaaaaaaaaa', 'bbbbbbbbbb' ]
> Util.splitMessage(`${'a'.repeat('10')}\n${"b".repeat('10')}`,{maxLength: 10, char: ['\n']})
[ 'aaaaaaaaaa,bbbbbbbbbb' ]
**Furth...
If you could add type tests in the typings/index.ts file, it'd be a nice addition to this PR.
this.channel = this.message?.channel ?? options.channel ?? null;
this.guild = this.channel?.guild ?? options.guild ?? null;
๐งน This can go and pass options directly, as the two properties are assigned in it.
Because the other properties are always overridden in createMessageComponentCollector, we don't need to duplicate them again.
const _options = { ...options, max: 1 };
You can also inline it like it was before.
Mmh looks like it was splitted and then stringified.
@kyranet I have added tests, let me know what you think
Please describe the changes this PR makes and why it should be merged:
This PR adds @links to the isX() methods (isText, isThread, isButton, isSelectMenu, isMessageComponent, isCommand) and also fixes one outdated example in interaction.reply()
Status and versioning classification:
- Code changes have been tested against the Discord API, or there are no code changes
- This PR only includes non-code changes, like changes to documentation, README, etc.
I think I've found the error but it's very weird. When passing an array as char it uses a map method on an array like [text] and it splits the text but this will means that the new array will be [[chunk1, chunk2]] (string[][]) and then it uses it like an array of strings (string[]), which is not.
Ok I (hope to have) solved this problem. I'll make a PR to fix.
Some small nits, LGTM otherwise.
// @ts-expect-error
await interaction.reply({ content: 'Hi!', components: [button] });
Also move invalid ones to the bottom so we test valid code first, and invalid ones later.
// @ts-expect-error
void new MessageActionRow({});
The void here is to not create an unused variable, while also not making a useless expression.
This should probably be named actionRow to match its type's name.
fix #6006
Please describe the changes this PR makes and why it should be merged:
This PR fixes a problem with Util.splitMessage which doesn't work when the char option is set to an array. This is because the array of messages is mapped and messages splitted again causing the creation of an array of arrays. This PR adds a .flat(1) to prevent this from happening. I also tested this with all options but let me know if there are still problems.
*Sorry for too many commits but I ac...
splitText = splitText.flatMap(chunk => chunk.split(currentChar));
splitText = splitText.flatMap(chunk => chunk.match(currentChar));
fbdad6e docs(*): add class links to isX() methods (#6007) - ImRodry
190e4ac Docs build for branch master: fbdad6eac38e262a7... - iCrawl
27e217c chore(Constants): added new error codes (#5975) - kyranet
3a718d8 fix(Typings): Improve components typings in Mes... - wasdennnoch
c7a08d0 Docs build for branch master: 27e217caeeebd3354... - iCrawl
4c996cb Docs build for branch master: 3a718d8c625ab45bc... - iCrawl
also not sure if it was intended but partial will always be false since the type property is always being added to the class.
public fetchUser(): Promise<User | null>;
public readonly partial: boolean;
yes, i know this issue is technically voice related but im submitting it here because i believe the code that needs to be fixed is in this repo
Please describe the problem you are having in as much detail as possible:
Since #5941 the typings for @discordjs/voice are included in the main discord.js package. This breaks typescript support for the actual voice library, because typescript just picks up the exports that are declared in the main package. Since this is just a...
Other than kyra's comments, LGTM
Other than kyra's comments, LGTM
Please describe the changes this PR makes and why it should be merged:
message->messageCreateinteraction->interactionCreate
:warning: Old event names (message and interaction) will still work even after this PR, but a process warning will be emitted. |
|---|
Status and versioning classification:
- 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)
Please describe the changes this PR makes and why it should be merged:
This PR Fixes the ClientUser#setAFK typing where the return type was still set as Promise and was missing the shardID argument.
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
const _options = { ...options, max: 1 };
It's actually missing max: 1 but I wouldnt have noticed without this comment, so thanks.
This was also merged over a week ago so not sure why it matters to this PR that docs were released.
Please describe the changes this PR makes and why it should be merged:
This PR fixes the fetchAll check for private Threads in ThreadManager#fetchArchived.
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
Do we have "Use xyz instead" support here?
The question was about the website, not the JSDoc Tag
I have no idea, MessageEmbed#type is the only thing deprecated before this PR.
cc: @iCrawl
Please describe the changes this PR makes and why it should be merged:
- All managers are actually managers now:
- Hierarchy is `BaseManager <: DataManager {
if (holds === Message) return new LimitedCollection(0);
return new Coolection();
}
});
- Hierarchy is `BaseManager <: DataManager {
- Breaking changes in summary:
- The new managers' hierarchy and methods and constructors.
- `ReactionUserManager`'s constructor, cus it was weird.
- Moved options related stuff out of `Constants` into `Options...
this.cache isn't always available, I think resolve needs to go on CachedManager, but resolveID could stay here.
Use a djs custom error string (function type)
It's an abstract class; it on the implementor to make it exist.
Bleh, tell whoever made tester1000 about it.
Docs could be clearer yea, but this isn't just for those weird ones. CachedManager extends this, too.
But...that has its own description (also that says it "holds a cache" which...feels wrong too.
Nah, you're not "getting" any data. It just is what it is.
yeah, if people actually care about what these managers do (since each manager that extends them has its own description) they should be able to understand that.
I'd argue options.default is better than options.createDefaultOptions()
I believe getters should be used for properties, not glorified lazy evaluation. The method call makes that part obvious.
Is this not just a glorified property? Heck you could even store this in a static property if you wanted. There isn't any evaluation going on in this function, only within the returned object.
A property of what? And there is evaluation, in particular the requires are nested inside to avoid a circular dependency,
Static properties exist, and that evaluation is done in a function that happens to be called here, which is no different from this, which you are clearly fine witht:
Object.defineProperty(this, '_cache', { value: this.client.options.makeCache(this.constructor, this.holds) });
No, look at the arrows. The methods return a function and that gets evaluated there. The requires are not.
Otherwise this throws when it's unset:
if (typeof options.makeCache !== 'undefined && typeof options.makeCache !== 'function') {
It should throw when unset, it needs to be set (either via defaults or user) otherwise caching wouldn't work at all (probably hard crash)
Wait, nevermind, the options are merged beforehand.
e4be666 fix(ThreadManager): fixed wrong private and fet... - HerrTxbias
dc21817 Docs build for branch master: e4be666c2c273c56f... - iCrawl
c40b06c types(ClientUser): updated setAFK signature (... - BannerBomb
1242c54 types(VoiceState): fix optional params (#5993) - PraveshKunwar
a4ffb71 Docs build for branch master: 1242c5434d441f3f7... - iCrawl
c92f507 Docs build for branch master: c40b06cac90b02f01... - iCrawl
56b5b7e types(MessageOptions): fix components being opt... - ImRodry
485a9f5 Docs build for branch master: 0dc5dd5808af213ac... - iCrawl
243ec7e Docs build for branch master: 56b5b7ee820c8be36... - iCrawl
Please describe the changes this PR makes and why it should be merged:
This PR brings two new formatters from https://github.com/discordjs/builders/pull/4:
hideLinkEmbedhyperlink
And alongside them, it also adds docs so they're visible in the docs website, however, something I'm unsure of, is whether @namespace works.
cc: @iCrawl
Status and versioning classification:
- Code changes have been tested against the Discord API, or there are no code changes
- I know how to ...
Please describe the changes this PR makes and why it should be merged:
Threads fixup part 2: electric boogaloo
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)
We don't seem to have an empty line between the class and its jsdoc anywhere else
That's an oversight when I was trying multiple things (see previous commits), thanks for catching this one ๐
Are these visible anywhere except when looking at these lines in this file?
They're only visible when you look up this property in the types, but doesn't show up when using client.on('message', cb); and others.
Please describe the changes this PR makes and why it should be merged:
I stumbled upon Collector#endReason not appearing in the documentation, so here is a fix.
(Something about the parser not picking up @name'd properties after the last method?)
I added jsdocs to the deriving classes so the now implement property is no longer abstract.
I also marked Collector#endReason as readonly in the typings, all deriving classes do that themselves already however.
**Status and...
* The the type of component to collect
I'm unable to reproduce that behavior, I'm seeing the suggestions just fine.
Okey, it's been sometime and I didn't noticed any missing events so I guess we can say that it's fixed. If later one i notice any missing events I will simply re-open the issue again, but for now we can close it.
In both cases the changing PR does not explain why this change was made:
There doesn't seem to be a circular require issue and nothing seems to break when using the appropriate classes instead of this dummy object.
I suppose it's fine to supply the classes again then, although this is probably outside of the scope of this PR.
I'm not too sure how to feel about this.
This is going to "break" pretty much everything except dms.
Maybe at least add a warning about that?
Please describe the changes this PR makes and why it should be merged:
The type for targetType in https://discord.js.org/#/docs/main/master/typedef/CreateInviteOptions was wrong, so I fixed that (now leads to https://discord.js.org/#/docs/main/master/typedef/TargetType)
Status and versioning classification:
- Code changes have been tested against the Discord API, or there are no code changes
- This PR only includes non-code changes, like changes to documentation, README, etc...
* Data that resolves to give an Invite object. This can be:
Since this is no longer used ๐งน
I don't think Partial is supported by our docs site? CC @iCrawl
Shouldn't we rename this to _add now, or is that outside the scope of this PR? CC @discordjs/the-big-3
Not an issue with this PR, but in the future we should probably look into implementing a sweeper on all cache types?
98e45a5 feat(Formatters): added new URL utilities and d... - kyranet
4adfc45 docs(CreateInviteOptions): fix TargetType link ... - ImRodry
568691c fix: correct permissions checks and cache on up... - ckohen
b8e37a1 Docs build for branch master: 98e45a59957842fd1... - iCrawl
7dd1a8d docs(Collector): properly document endReason (#... - SpaceEEC
bf0a9b9 Docs build for branch master: 4adfc45b5a3c916ae... - iCrawl
9c7f17a Docs build for branch master: 568691ce6a7994adc... - iCrawl
a11a105 refactor: rename events to be consistent with W... - kyranet
a0ea4e8 Docs build for branch master: 7dd1a8da08830525d... - iCrawl
acfc64c Docs build for branch master: a11a10525b39fb057... - iCrawl
e7ad2fe feat: PermissionOverwriteManager (#5318) - extroonie
c84ab9b Docs build for branch master: e7ad2fe20772915dc... - iCrawl
2446ff5 refactor(Util): make class extend null (#6000) - kyranet
bd25ff5 fix(Util): splitMessage not working with array ... - DTrombett
189c44c Docs build for branch master: 2446ff525145afa3d... - iCrawl
28aa11c Docs build for branch master: bd25ff59133ba3171... - iCrawl
It would just be a string and not link to anything.
IMHO yes, but not sure how comp feels about it.
It doesn't, I was adding the type in #5144 but that PR is going nowhere fast. (MessageEmbed already attempts to use it)
All I did was add this typedef
/**
* A `Partial` object is a representation of any existing object.
* This object contains between 0 and all of the original objects parameters.
* This is true regardless of whether the parameters are optional in the base object.
* @typedef {Object} Partial
*/
374c779 feat(InteractionCollector): reworked to be more... - monbrey
264a5f1 Docs build for branch master: 374c779f7f8bbaa9b... - iCrawl
This issue has been stale for a while, if this problem still exists or you can still easily replicate it on v13 (current master or discord.js@dev on NPM), please reopen it as a new issue.
This won't happen before a complete rewrite of the library, so I'm going to close this as we move forward and decide how we will implement this.
This won't happen before a complete rewrite of the library, so I'm going to close this as we move forward and decide how we will implement this.
This issue has been stale for a while, if this problem still exists or you can still easily replicate it on v13 (current master or discord.js@dev on NPM), please reopen it as a new issue.
This issue has been stale for a while, if this problem still exists or you can still easily replicate it on v13 (current master or discord.js@dev on NPM), please reopen it as a new issue.
This issue has been stale for a while, if this problem still exists or you can still easily replicate it on v13 (current master or discord.js@dev on NPM), please reopen it as a new issue.
This issue has been stale for a while, if this problem still exists or you can still easily replicate it on v13 (current master or discord.js@dev on NPM), please reopen it as a new issue.
This issue has been stale for a while, if this problem still exists or you can still easily replicate it on v13 (current master or discord.js@dev on NPM), please reopen it as a new issue.
This issue has been stale for a while, if this problem still exists or you can still easily replicate it on v13 (current master or discord.js@dev on NPM), please reopen it as a new issue.
This issue has been stale for a while, if this problem still exists or you can still easily replicate it on v13 (current master or discord.js@dev on NPM), please reopen it as a new issue.
This issue has been stale for a while, if this problem still exists or you can still easily replicate it on v13 (current master or discord.js@dev on NPM), please reopen it as a new issue.
This issue has been stale for a while, if this problem still exists or you can still easily replicate it on v13 (current master or discord.js@dev on NPM), please reopen it as a new issue.
This issue has been stale for a while, if this problem still exists or you can still easily replicate it on v13 (current master or discord.js@dev on NPM), please reopen it as a new issue.
This won't happen before a complete rewrite of the library, so I'm going to close this as we move forward and decide how we will implement this.
This issue has been stale for a while, if this problem still exists or you can still easily replicate it on v13 (current master or discord.js@dev on NPM), please reopen it as a new issue.
Users should never call Manager#add unless they know what they're doing, so yes, it should be _add.
I guess you can backport that part into a new PR, so we don't have to wait for it.
091d6d1 fix: Remove connection.url from open debug me... - vladfrangu
Please describe the changes this PR makes and why it should be merged:
Fixes #5590
Status and versioning classification:
- Code changes have been tested against the Discord API, or there are no code changes
I'm unable to reproduce this issue with 374c779 using the following code:
// src/shard.js
import { ShardingManager } from 'discord.js';
const manager = new ShardingManager('./src/index.js', {
respawn: false,
totalShards: 1,
});
const shard = manager.createShard(0);
shard.spawn();
// src/index.js
import { Client } from 'discord.js';
const client = new Client({ intents: ['GUILDS', 'GUILD_MESSAGES'], shardCount: 1 });
void client.login...
Please describe the changes this PR makes and why it should be merged:
After #5318, actual permission overwrites data is accessible via cache of PermissionOverwriteManager, this structure hasn't changed even since the PR. Therefore, attempting to use the latest dev version results in numerous errors.
This PR adds missing cache property to GuildChannel structure, and resolves error caused by unchanged structure.
Status and versioning classification:
- Code changes have be...
shardCount is not longer a valid option in v13's ShardingManager's options, so this is fixed in master.
Since we're not releasing new versions of v12, please upgrade to v13 (master or discord.js@dev in npm), and if the issue persists (once adapting the code), please open a new issue.
I can take care of it but I would need help with typing.
I did not understand how to separate them into two "overloads"
There isn't any await in this function, why should it be needed?
The function is full of promise rejections that happen by using return Promise.reject(new <>Error()) and that could be a lot cleaner by writing throw new <>Error() instead.
Also, in case something ever throws a synchronous error, such as reading a property of undefined, it'd be a promise rejection instead of a regular exception.
Something like the following:
public fetch(options: { ..., channelID: Snowflake }): Promise<Collection<Snowflake, Invite>>;
public fetch(options: string | { ..., code: string }): Promise<Invite>;
* @returns {Promise<Invite|Collection<Snowflake, Invite>>}
Is it not just possible to edit FetchInvitesOptions with optional channelID?
The returned value is the same ๐ค
interface FetchInvitesOptions {
channelID?: Snowflake
cache: boolean;
}
ESLint is not likely to be against if there is any await?
Likewise I have this issue as well just to raise awareness a bit more and mine is completely awaited and the request goes through but the user simply doesn't get the roles added sometimes and other times it works fine and it isn't ratelimit or anything like that as I don't use it that often.
It shouldn't if there are throws, but who knows.
Sure thing, as long as the second overload takes strictly either a string (invite code), or an object with a required code.
Also, is cache not optional?
Also, is cache not optional?
Yep, I change it ๐
Please describe the problem you are having in as much detail as possible:
In the ClientUser file the shardID properties say they can be null in various jsdocs however in the typings file it does not.
The below jsdocs say it can be null
https://github.com/discordjs/discord.js/blob/374c779f7f8bbaa9bf06fa2b5b16f60da5095b5c/src/structures/ClientUser.js#L100-L107
https://github.com/discordjs/discord.js/blob/374c779f7f8bbaa9bf06fa2b5b16f60da5095b5c/src/structures/ClientUser.js#L130-L138
...
If it breaks too much for reasonable use we can just remove it, let people figure it out.
Yes, outside the scope of this PR. Better to do once the dust settles.
Yep, we had some talks about more collection types and ways to compose them ergonomically. Future PR.
I told you dummies that Managers would be useful one day ๐๐๐๐๐๐๐
Weird, doesn't seem to work for me. Using { cache?: boolean } for second overload makes it not suggest force for the first one too:

39db953 fix: Remove connection.url from open debug me... - vladfrangu
2af3d2b Docs build for branch master: 39db95352c91faf17... - iCrawl
I just realized that we can solve this issue by using Conditional Types. We can merge the overloads and let conditional typings do its work:

I tested it and it works nicely. It suggests both cache & force when options is ThreadChannelResolvable and only cache when it is FetchThreadsOptions.
I don't know why it's not showing up for you ๐คท

I don't think the .type check actually guards, maybe thats why.
I don't think the
.typecheck actually guards, maybe thats why.
It doesn't work for me even when I write the exact same code that Space showed above.

Please describe the changes this PR makes and why it should be merged:
Why the parentheses are required:
Let's use ClientApplication#owner as an example of a union type without parentheses
Instead of the type being shown as "?User or ?Team", it's shown as "User or Team"
: Add missing 'cache' property... - SkyFlags
619cd84 Docs build for branch master: 7e3001191c1529b9d... - iCrawl
The reason why is explained in #6021
* @property {?(CategoryChannel|Snowflake)} [parent] Parent channel
Seems like it's just me ๐โโ๏ธ. Updated the second overload to only suggest cache for cacheOptions.
4bf4980 refactor: improve typings and docs related to t... - iShibi
1d35a44 Docs build for branch master: 4bf49809f24043098... - iCrawl
Please describe the problem you are having in as much detail as possible:
I don't know if this is an API issue or discord.js, please let me know if I should report it somewhere else.
When entering anything that's not a number id, the API times out, instead of throwing an error/ignoring the id.
Include a reproducible code sample here, if possible:
guild.members.fetch({user: ['202510746058358784', '330357883713748994', 'abcd']})
Output:
Error [GUILD_M...
ec06ba7 docs(*): wrap optional properties with union ty... - almeidx
b309275 Docs build for branch master: ec06ba7ad04d21e61... - iCrawl
I'll do a followup to this PR then, maybe even before this gets merged (obviouslly will draft if so)
What is the difference between position and rawPosition? In issue #5379, it was stated that this could be a Discord API bug. However, I tried to reproduce this issue with the provided code and succeeded - even though it was stated that the Discord API bug would've been fixed by now (https://github.com/discord/discord-api-docs/issues/2640). However, all seems to work fine when using the channel#edit function.
Maybe add a cache parameter here?
I also think that a CategoryResolvable type would help work with categories since it is a little confusing having them as a channel This feature would definitely help clarify some things.
It might be worth a consideration to make LimitedCollection public again, otherwise you'd have to reimplement it yourself if cacheWithLimits doesn't cut it for somereason.
Missed renaming the MessageComponent methods in a few places so they weren't being documented properly.
Status and versioning classification:
- This PR only includes non-code changes, like changes to documentation, README, etc.
It's a Discord API error so we can't really do anything about this. You should ask in DDev server probably.
Previously this method would automatically include the bot scope - it's now required that the user provide scopes in the options, including one of either bot or applications.commands.
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 includes breaking changes (methods removed or renamed, parameters moved or removed)
Please describe the problem you are having in as much detail as possible:
When trying to remove a user's permissions from a channel, the api returns a 404 error.
Include a reproducible code sample here, if possible:
let channel = bot.channels.cache.get("channel_id");
channel.permissionOverwrites.delete("user_id");
Further details:
- discord.js version: 13.0.0-dev.7e30011.1625338909
- Node.js version: v14.17.1
- Operating system: Windows 10 Pro
...
Alright, I sent it on the server but I believe the devs are on break until the 12th so I might have to post it again after the 12th.
Regardless of the API I think it is possible to add a number check on https://github.com/discordjs/discord.js/blob/ec06ba7ad04d21e61f3e734e489607a1a5ab3568/src/managers/GuildMemberManager.js#L129
or on
https://github.com/discordjs/discord.js/blob/ec06ba7ad04d21e61f3e734e489607a1a5ab3568/src/managers/GuildMemberManager.js#L346
to solve this issue.
Someth...
I would write this off as user error.
We probably can check, but it seems redundant if the developer itself could just sanitize and check the input before passing it to the library.
Before I noticed this issue I was under the impression it would be treated the same as an invalid ID, would be nice to let the developer know, but you are right; its not needed per say and the discord API should just respond with error code 400 or something instead of time out the application.
I guess I should wait for the discord developers to fix this issue. Thank you @iCrawl and @DTrombett for explaining!
This is the expected behaviour from the API when there are no permissions overwrites found to delete.
I agree but currently I'm trying to remove the permissions of a user from a channel (the user has the following permissions: VIEW_CHANNEL and CONNECT) but the api returns a 404.

I just tested with Postman, the api returned 204 as expected.

: add customizable caching for ma... - 1Computer1
8077e4f fix(PermissionOverwriteManager): pass ID to API... - monbrey
610b0b4 docs: fix some missed MessageComponent collecto... - monbrey
4b8bfd5 Docs build for branch master: 8c7cb0eff8e169836... - iCrawl
f4f3e1a Docs build for branch master: 8077e4f4f132f95c4... - iCrawl
c18ae3c Docs build for branch master: 610b0b4dd6b6e66c0... - iCrawl
Please describe the changes this PR makes and why it should be merged:
Replace this mess that is prone to errors and doesn't compose:
Structures.extend('Thing', Thing => {
return class NewThing extends Thing {
get getter() { ... }
method() { ... }
}
});
With this non-hacky, actually good practices, simple to understand:
function getter(thing) { ... }
function method(thing) { ... }
๐ฅ๐ถ๐ฅ๐ถ๐ฅ๐ถ๐ฅ
Status and versioning classification:
...
Reflect.defineProperty(Message.prototype, 'property', { get() { /* ... */ } }); goes brr
Because we didn't have enough breaking changes already. ๐ฆ
๐ Completely break commando.
Please describe the changes this PR makes and why it should be merged:
So you want better typings huh
Status and versioning classification:
- I know how to update typings and have done so, or typings don't need updating
- This PR only includes non-code changes, like changes to documentation, README, etc.
Please describe the changes this PR makes and why it should be merged:
:)
Status and versioning classification:
- This PR only includes non-code changes, like changes to documentation, README, etc.
Unless you're supporting enumerators, which would make it throw in the previous lines, this isn't necessary:
query.set('scope', scopes.join(' '));
INVITE_MISSING_SCOPES: 'At least one valid scope must be provided for the invite',
I'd suggest moving those hardcoded scopes into an array or something, so we can extend them more easily in the future.
Just the rebase, otherwise LGTM.
This comment seems counter to your suggestion though...
Will do this but with correct spacing
Can't make this change - the TypeError returns invalidScope to the user
I see how people can get mad at this, but I personally agree.
That said, I've been using structures, do as I say, not as I do
A library should not let its users touch to its own structures, because as @1Computer1 said it is likely for people to break stuff. One example, that doesn't run into the Structures case but still, is extending Client and overwriting Client#options. Many people came in the discord.js server to troubleshoot that weird infinite recursive call that makes node ...
Please describe the problem you are having in as much detail as possible:
TypeError: newParent.permissionOverwrites.map is not a function error when calling the .setParent function
Steps to reproduce
- Create a new channel
- Try updating the parent (.setParent())
Include a reproducible code sample here, if possible:
import { OverwriteResolvable, Permissions, Snowflake } from "discord.js";
const DEFAULT_PERMS: OverwriteResolvable[] = [
...
Please describe the changes this PR makes and why it should be merged:
The options param for MessageManager#edit is documented as optional, which isn't correct as the typings for it states that it is a required param. Also, the said method calls MessagePayload#create, which requires the second param to be always defined, which is options in this case.
**Status an...
Please describe the changes this PR makes and why it should be merged:
fixes: #6030
Status and versioning classification:
Please describe the problem you are having in as much detail as possible:
I created an invalid embed message, where I tried to include a link on the title of a field. That apparently is illegal and both message.reply() and message.channel.send() errored from the API.
The problem was that this error was uncaught despite having them wrapped in a try-catch statement.
The error should bubble up instead of being uncaught.
Include a reproducible code sample here, if poss...
Hello! I wasn't able to reproduce this one master branch latest commit, can you try this on master branch once?
Your code snippet doesn't seem to align with the error provided.
Under normal circumstances the API would not error if you attempted to put masked link markdown in an embed field title - I just wouldn't render as a masked link.
Your error instead says that fields 1, 5, 9 and 13 failed Discord's validation because they were over 256 characters in length, a seemingly unrelated error. I also don't see any indication that this rejection was unhandled.
This very valid bug report aside:
GuildChannel#edit allows a parentID as part of the ChannelData, making the call to GuildChannel#setParent a superfluous API request.
Isn't that redundant? Line 417 asserts that it's an array and no array is falsy.
if (options.permissions) {
๐ Completely break commando and any bots that use
Structuresproperly.
True
Yeah this is a carry-over from when I thinking about having default scopes.
Should we only bother with permissions if the bot scope is included? It doesn't matter if they're in the URL, Discord just ignores them for applications.commands.
๐ Completely break commando and any bots that use
Structuresproperly.
Sorry to break it for you, but you're a bit (+10 semver-major PRs) late, Commando doesn't work with v13 at all not even without this PR.
Also, it requires you to overwrite discord.js typings for your IDE to work with them properly, which I've never found a good thing to do (no matter what library we're doing that to).
I repeated this like a lot of times, you don't override types, you can't. The correct way ...
Apologies, the issue was that I forgot to add the await in front of the message.reply() and thus, that's why the error was unhandled.
All good now.
Please describe the changes this PR makes and why it should be merged:
This PR allows fetching channels from guilds that do not exist in the client cache (applicable mostly when sharding, but also possible to have guilds uncached via intents limiting or the new collection based limiting)
A big red flag warning here: channels obviously rely on guild internally a lot, however I did not want to change types when the majority of times the values will be present. I would expect people us...
GUILD_CHANNEL_UNOWNED: "The fetched channel does not belong to this manager's guild.",
Other than Space's review, LGTM
d58f0d2 fix(GuildChannel): use map method on cache not ... - iShibi
2ab32e6 types: better fullPermissions typings (#6028) - ckohen
db60e36 docs(MessageManager): document options param fo... - iShibi
c6703f4 Docs build for branch master: d58f0d243c9bbd803... - iCrawl
dc5fb87 Docs build for branch master: 2ab32e6bc62a5326d... - iCrawl
ab0b3b9 fix(Structures): remove Structures (#6027) - 1Computer1
153d777 Docs build for branch master: db60e367b4a455ae0... - iCrawl
f0c10cd Docs build for branch master: ab0b3b9a07f5e4987... - iCrawl
Please describe the changes this PR makes and why it should be merged:
This PR changes channel types from snake_case to UPPER_CASE to be more consistent with other types across the library and because we didn't have enough breaking changes already!
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 includes breaking c...
and the second I create this there's a merge conflict!
Because it contains a '. This is how eslint/prettier handle's that.
A question I had when changing this is: isn't a GROUP_DM channel text-based? I didn't add it because I wasn't sure but I feel like it would make sense
Bots can't actually interact with those (e.g. send a message to one) so it makes no sense for them to be text-based as it doesn't have any text-based methods. The only reference to them that exists in the lib is a partial for the data from invites to group DMs.
This should probably be changed to include all text based channels, TextBasedChannelTypes.includes(channel.type) I believe
While you're at it, this should take a number, I'd much like to be able to pass in ChannelTypes.GUILD_TEXT
Ditto but reversed, and same for all the other checks
I don't think that's possible due to this line:
https://github.com/discordjs/discord.js/blob/ab0b3b9a07f5e4987e4f25e41b2a007f2db06322/src/managers/GuildChannelManager.js#L131
Unless you want me to change that as well?
- added GuildStickerManager (Guild#stickers)
- added some methods to Stickers
- added
stickerCreate,stickerUpdate,stickerDelete - renamed
GUILD_EMOJISintent toGUILD_EMOJIS_AND_STICKERS
had to update APIRequest.json to get sticker creation working:
Please describe the changes this PR makes and why it should be merged:
Did somebody order a pizza? Well, sorry to break it for you, it's another dish of breaking changes.
Barely any bot works untouched when switching from v12 to v13 and Sapphire is still unaffected, even by this.
Basically, the gist of this PR is that all instances of ID have been changed to Id, that includes resolveID -> resolveId, messageID -> messageId, channelID -> channelId, guildID -> `guild...
* @property {Snowflake} [before] The message's id to get the messages that were posted before it
* @property {Snowflake} [after] The message's id to get the messages that were posted after it
* @property {Snowflake} [around] The message's id to get the messages that were posted around it
I think we can document it like this: "Get the messages that were posted around this message id" and similar for the other two.
There are other places in the lib where we have done it like this to avoid the weird sentence structure.
Please describe the changes this PR makes and why it should be merged:
This is a small nit from #6027
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
Please describe the changes this PR makes and why it should be merged:
This PR adds failIfNotExists to ClientOptions. The reason why is: some devs may not want errors when the referenced message does not exist. Setting this option to false to every ReplyMessageOptions seems like a poor idea, easy to forget, so I added this option to ClientOptions.
Status and versioning classification:
- Code changes have been tested against the Discord API, or there are no code changes
- I...
https://github.com/discordjs/discord.js/pull/6027
Hello, I am writing here as a user of the structures and I agree that the structures should not be changed much but they should stay here. You are an open-source library so you should take a look from people as well. More people wanted the structures to stay but you changed them anyway. Structures also have a lot of advantages when, for example, you just want to get the prefix in your handler via .prefix instead of `.getGuildPrefix(guild....
Structures also have a lot of advantages when, for example, you just want to get the prefix in your handler via <guild>.prefix instead of <database>.getGuildPrefix(guild.id)
I see no advantage here, merely a preference.
It's especially better in that it's simpler and for npm packages when someone is doing a handler for example
Due to the destruction of the structures, npm packag developers will have to completely redo some things and it will be maximally more difficult for people...
Structures also have a lot of advantages when, for example, you just want to get the prefix in your handler via .prefix instead of .getGuildPrefix(guild.id)
I see no advantage here, merely a preference.
It's especially better in that it's simpler and for npm packages when someone is doing a handler for example
Due to the destruction of the structures, npm packag developers will have to completely redo some things and it will be maximally more difficult for peo...
Please describe the problem you are having in as much detail as possible:
Hi hi! Select menus, oh yeah.
Hey though, when I'm sending across nothing for a select menu, values is undefined.
At first I thought this would be a feature request, but when I looked at the data sent across for a CommandInteraction, an empty options Collection is present as well as the data sent over by the websocket doesn't include anything. I noticed discord.js nicely puts an empty `Collect...
Thanks for helping, I realised that I forgot to define totalShards in the ShardingManager options.
Stupid mistake of me and thanks everyone for helping.
You install a library that overrides a class's send method to add internal tracking for auto-editable messages, you also install a library that also overrides it to construct an extended version of MessagePayload so you can send other fields (that we don't support).
Which one would you be using? The one with auto-editable messages? Or the one with the extended MessagePayload?
Furthermore, Structures was always limited, there are structures we can extend, and structures th...
Okay, I acknowledge that you're right but I still think it would take something to allow people to just make
<Guild>.prefix or <Guild>.language in a different way than if I were to fork all the guilds and put guild.prefix = "!".
That's all from me.
Goodbye, Hyro.
Just a few things I'd like to see clarified. Also if you're doing this for consistency with casing across the library, why not change URL -> Url?
Shouldn't this and all the other JSDoc descriptions be kept as-is?
Shouldn't this specific ID be upper case?
I don't see the issue with mutating the object and add those properties, it works fine, and I assume you can't even load them automatically because database interactions are usually asynchronous (and constructors synchronous).
Of course, you can always go for not storing that information in every guild and message, as that results on higher memory usage.
URL stands for Uniform Resource Locator, it's an acronym, which go always uppercase.
I don't see the issue with mutating the object and add those properties, it works fine, and I assume you can't even load them automatically because database interactions are usually asynchronous (and constructors synchronous).
Of course, you can always go for not storing that information in every guild and message, as that results on higher memory usage.
Okay, thank you. And if I may ask, how do you plan to handle this in Commando? After all, that's also where you use the stru...
As of now, there are more plans of replacing Commando with Sapphire, than there are to maintain Commando itself.
24d99d9 Docs build for branch master: a7c6678c7246025c4... - iCrawl
ID -> Id changes required.
target_user_id: this.client.users.resolveId(targetUser),
Arf I was already working on it ๐
* @param {Snowflake} id The sticker's id
Additionally this needs a rebase.
Additionally this needs a rebase.
Okay, I'm going to close the issue because this is more of a discussion and when I do I'll possibly open the discussion. Or is there any way to transform an issue into a discussion that you would do that?
Not sure what else is there to discuss about, so feel free to close it. ๐๐ผ
Please describe the changes this PR makes and why it should be merged:
At first, we used module augmentation so the types could be linked with the actual library's types, however, that ended up not working correctly (and I suspect it's because the type definition, which unlike interfaces, they can't be augmented).
I moved the definitions into discord.js and prefixed them with Internal to not conflict with the /voice's definitions, as well as marked them as @internal with a descr...
185e376 types(Voice): move types to the library's defin... - kyranet
8a4fb66 Docs build for branch master: 185e37602b0fabf6f... - iCrawl
please keep those breaking changes and stop doing so kind of fucking shit to the library
Please describe the changes this PR makes and why it should be merged:
The Options class extends null in the javascript file, but not in the typings.
https://github.com/discordjs/discord.js/blob/185e37602b0fabf6f06a02886128aead9239c5d9/src/util/Options.js#L92
https://github.com/discordjs/discord.js/blob/185e37602b0fabf6f06a02886128aead9239c5d9/typings/index.d.ts#L512
Status and versioning classification:
- Code changes have been tested against the Discord API, or there are no c...
To disallow constructing from TS:
export class Options extends null {
private constructor();
c4aa9fe types(Options): should extend null (#6042) - BannerBomb
2d7fa21 Docs build for branch master: c4aa9feee238db453... - iCrawl
Please describe the changes this PR makes and why it should be merged:
Closes #4274, I don't know why it isn't exported
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)
same thing in other places ? if channel.type is a string then TextBasedChanneltypes['GUILD_TEXT'] is 0 making it falsy ?
if (channel.type in TextBasedChannelTypes) channel.stopTyping(true);
Other than requested changes, LGTM
Imo, we can just add it, don't have to check the presence of bot ourselves
CC @discordjs/the-big-3
Other than requested change, LGTM
We don't have to, it could be that in a near future, Discord adds support for permissions in slash commands.
Please describe the changes this PR makes and why it should be merged:
Fixes the typings for
Team#owner - the return type was missing null
Team#iconURL - the return type was missing null
TeamMember#toString - changed the return type to UserMention as for PR #6003
and changed the JSDOC for Team#ownerId to be type {?Snowflake} instead of {?string}.
Status and versioning classification:
- Code changes have been tested against the Discord API, or there are no code changes
- ...
Please remove the @private docstring in the file
Please remove the
@privatedocstring in the file
Removed
9e08b02 feat(Managers): โจ Add GuildInviteManager (#5889) - DraftProducts
c247c72 Docs build for branch master: 9e08b02df2c9b31cf... - iCrawl
c6e5521 feat(Client): enforce passing scopes to generat... - monbrey
Closes #6040
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)
1d51ad0 Docs build for branch master: c6e55216874f18927... - iCrawl
fe5d56c fix(TeamMember): Fixed incorrect return types. ... - BannerBomb
82c39b2 Docs build for branch master: fe5d56c9b11b3e5f0... - iCrawl
Please describe the changes this PR makes and why it should be merged:
Only TextBasedChannel#lastMessageId is given by Discord (data.last_message_id), User's and GuildMember's were extensions from our side.
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 includes breaking changes (methods removed or renamed, pa...
Please describe the changes this PR makes and why it should be merged:
This cleans up the exported typings. Because the diff is not helpful at all, I split it up into multiple commits, so this should be reviewed commit by commit instead.
Status and versioning classification:
- There are no code changes
- I know how to update typings and have done so (Obviously)
I love how the type at SelectMenuInteraction#15 was wrong all this time, and now it's right.
Please describe the changes this PR makes and why it should be merged:
- improved library performance
- minimal breaking changes
- new features
- voice support
- well documentated https://abal.moe/Eris
- passed tests
- lightweight
- really flexible
- really up-to-date
Status and versioning classification:
- 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)
- T...
everything that you have listed will be released soon! https://github.com/abalabahaha/eris/pull/1216
As long as there's minimal breaking changes I'm all for this
LGTM, but Isn't the class name SelectMenuInteraction? I'm sorry if I did something wrong
was this actually tested? it seems to not actually add the Guild#invites property, breaking all the places which now try to access it ๐ฌ
Adds the new GuildInviteManager to Guild as Guild#invites
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)
Shouldn't GuildInviteManager extend CachedManager and not BaseManager ?
Please describe the changes this PR makes and why it should be merged:
- improved library performance
- minimal breaking changes
- new features
- voice support
- well documentated https://abal.moe/Eris
- passed tests
- lightweight
- really flexible
- really up-to-date
Status and versioning classification:
- I know how to update typings and have done so, or typings don't need updating
- This PR changes the library's interface (...
There is still the issue with implicitly creating new instances of LimitedCollection through its methods, e.g. clone, filter.
TS will say those are LimitedCollections, but they actually are Collections.
(Creating new LimitedCollections is not possible without modifying Collection and thinking of a way to derive new arbitrary child instances)
I don't know of a way to make TS aware of Symbol.species and overwriting all methods to specify that actually a Collection is retu...
Yeah, moving the declaration for LimitedCollection would be nice, @PanSzelescik.
I would expect people using this option to know exactly what they are doing and which properties can be accessed.
We'll see about that ๐
e3d877d fix(Guild): add invite manager property, extend... - monbrey
3790b3a Docs build for branch master: e3d877d542518d0f8... - iCrawl
Please describe the changes this PR makes and why it should be merged:
- โ ๏ธ remove
Intents.ALL - โ ๏ธ remove
Intents.PRIVILEGED - โ ๏ธ remove
Intents.NON_PRIVILEGED
We currently provide static shorthands on the Intents bitfield wrapper (inspired by Permissions when implementing). This raises multiple issues:
- End users are lead to just pass
Intents.ALLno matter what they actually need for the bot to work, as evident from library support channels - Discord might change th...
676118a refactor(typings): general cleanup (#6047) - vaporox
b224eb2 Docs build for branch master: 676118ab0f5cc36cf... - iCrawl
This needs a rebase for the typings ๐
1a27f57 refactor: remove lastMessage properties from ... - kyranet
2883361 Docs build for branch master: 1a27f57950d51597f... - iCrawl
Please describe the changes this PR makes and why it should be merged:
This utility is useful for checking whether classes that use mixins don't get any unintended property.
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 only includes non-code changes, like changes to documentation, README, etc.
Discord sends last_message_id for text-based channels, which those are.
34708d6 fix(SelectMenuInteraction): set values to empty... - monbrey
5e96bac Docs build for branch master: 34708d6d18f94b5c8... - iCrawl
31d3129 feat(LimitedCollection): export LimitedCollecti... - PanSzelescik
28c5724 feat(Message): add 'failIfNotExists' to ClientO... - PanSzelescik
2746efd Docs build for branch master: 31d31293d31449256... - iCrawl
50a1cfb Docs build for branch master: 28c57246d1d3cd7a2... - iCrawl
This needs a rebase.
At this point, I'm 99% convinced you do this deliberately. finding something to merge before so I have to rebase :angy:
At this point, this is more of an issue to track that this plan technically exists, rather than anything that's happening any time soon, so this will very likely be completely refactored, if implemented. Accordingly not going to merge any suggestions.
If you can still reproduce this on discord.js@dev please open a separate issue and provide the exact version (discord.js@13.0.0-dev.commithash.timestamp, you get this from npm list discord.js) and detailed steps on how to reproduce this issue, including the code you run in the format of a minimal, reproducible code sample.
If you think it's related to this issue feel free to mention that in the issue body.
Please provide a minimal reproducible code sample so we can attempt ...
IMHO this is basically user error - we require users to always pass Snowflakes (numeric strings) to the entire library, and since members.fetch relies on on WS, it's a lot harder for errors to be caught.
If you want this error to not persist, we recommend you validate your user input, specially since Discord can restrict your bot's access to the API if it gets too many errors in a brief period of time.
Closing as the PR is stale, we don't plan to validate strings, and the issue has been marked as user error.
Please describe the changes this PR makes and why it should be merged:
The bot invite scope was missing from the typings and from the docs.
The description of the bot scope on the docs might not be the best, let me know.
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
3022b0f refactor(Intents): remove computed shorts (#6050) - almostSouji
03fe6ee test(Types): add notPropertyOf type-only util... - kyranet
93e2c04 fix(InviteScope): added missing 'bot' scope (#6... - almeidx
36ecb62 Docs build for branch master: 3022b0f5b1bcdd069... - iCrawl
7024121 Docs build for branch master: 03fe6ee4e4daabebf... - iCrawl
b2bf9b5 Docs build for branch master: 93e2c04ec27c44a8c... - iCrawl
Please describe the changes this PR makes and why it should be merged:
This PR fixes the docs for ThreadChannel#setLocked ๐งต ๐
Status and versioning classification:
- This PR only includes non-code changes, like changes to documentation, README, etc.
Readonly property "client" was missing from type definitions for class Presence.
Please describe the changes this PR makes and why it should be merged:
Seeing as the client property is still being defined and is also still listed in the docs, this looks like it was missing. Feedback on PR is welcome, as I'd like to continue to contribute/do so properly. Thanks!
https://github.com/discordjs/discord.js/blob/master/src/structures/Presence.js#L41
**Status and versioning classifica...
as well as on Client#presenceUpdate
Please describe the changes this PR makes and why it should be merged:
This PR:
- removes
User#presenceas it was a hack traversing the guild cache in order to find a presence of any member representing the given user. - makes
GuildMember#presencenullable. That way you can distinguish between "This member is offline" and "The presence of this member is unknown" without having to check the cache yourself, rendering this getter pointless.
...
162d89a fix(Presence) missing client property definitio... - iAmZiNc
dd2b025 Docs build for branch master: 162d89a42fe33ab32... - iCrawl
Please describe the changes this PR makes and why it should be merged:
This PR brings a bit of consistency to PresenceManager and Presence with the other structures and managers.
Presence more or less implemented Base's stuff itself in combination with PresenceManager patching it itself, while CachedManager could do that just fine.
Carefully going with semver: patch here, since I am not sure what making Presence extend Base could break.
**Status and versioning ...
super(client);
Please, my heart can't take it.
Now that's interesting behavior.
8d9ab74 docs(ThreadChannel): fix documentation for setL... - iShibi
ee08ac8 Docs build for branch master: 8d9ab741c8037c2f6... - iCrawl
Please describe the changes this PR makes and why it should be merged:
This PR changes the types for all spread arguments from unknown to any, introduced in #6047 basically meant that any conditions with these types would always return false (for example, partial channels)
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
...
afbd5db refactor(Presences): remove from User, nullable... - SpaceEEC
ded93fe refactor(PresenceManager): have Presence extend... - SpaceEEC
cc3b8ec Docs build for branch master: afbd5db404c711fd9... - iCrawl
13b33fc Docs build for branch master: ded93feb5759ded88... - iCrawl
Why have all unknowns been replaced with any?
public setInterval<T extends any[]>(fn: (...args: T) => Awaited<void>, delay: number, ...args: T): NodeJS.Timeout;
public setTimeout<T extends any[]>(fn: (...args: T) => Awaited<void>, delay: number, ...args: T): NodeJS.Timeout;
public setImmediate<T extends any[]>(fn: (...args: T) => Awaited<void>, ...args: T): NodeJS.Immediate;
Before ESLint kills me
Not all unknowns were replaced with any, just the ones that served as function arguments
isn't that unrelated to the PR though? I have no idea why that's not there
Yeah, but... I don't think it's too much different...
It is, it fixes the bug I explained
Well I think this is the right opportunity to add them ๐
I'll let the big bois decide @discordjs/the-big-3
Please describe the changes this PR makes and why it should be merged:
This changes the type of the collector event parameters from unknown to something actually helpful.
Status and versioning classification:
- 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:
This PR fixes several incorrect typings and the JSDoc return type for MessagePayload#create.
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
Activity does not seem to be extending Base.
If you replace the T with T extends unknown[].. don't you achieve the same? since TS will (hopefully) infer it
This should remain as unknown, same with once and off
Same, should be unknown, or the function should be turned into a generic one? CC @kyranet
Ah, I meant to do the Application class
Iโm not sure since Iโm not experienced with this syntax so Iโll tag @vaporox and @1Computer1
To force you to cast your data or check its type
Doesn't matter because we're not using the output.
IMO we should declare the names of the constants the same as their types to avoid name conflicts.
declare const messageCollector: MessageCollector;
messageCollector.on('collect', (...args) => {
declare const reactionCollector: ReactionCollector;
reactionCollector.on('dispose', (...args) => {
4c0426c docs: fixed several typings and MessagePayload#... - BannerBomb
c0a814f feat(Collector): better types for events (#6058) - vaporox
91bb9fd Docs build for branch master: 4c0426c469304d7ce... - iCrawl
dbea872 Docs build for branch master: c0a814fdb35cb1fa7... - iCrawl
Please describe the changes this PR makes and why it should be merged:
Cus names conflict. Have fun reviewing.
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 PR includes breaking changes (methods removed or renamed, parameters moved or remov...
2e078e4 types(*): revert incorrect unknown type changes... - ImRodry
24810bb Docs build for branch master: 2e078e44883c1ef5f... - iCrawl
Rebased
Also prettier decided it had to format some stuff in the typings file so that also went in the commit
Shouldn't this be called ChannelTypes to be consistent with other enums?
There were two enums: ChannelType and ChannelTypes and I had to remove one so I went with that but it can be renamed yeah.
While weโre at it, should I also change the only other enum with a singular name to plural (InviteTargetType)? @discordjs/the-big-3
I have recently installed discord.js via npm for a production level project. After installing discord.js and starting up server for first time, I get below error in terminal.
`node_modules/discord.js/src/sharding/ShardClientUtil.js:237
const shard = Number(BigInt(guildID) >> 22n) % shardCount;
^^
SyntaxError: Invalid or unexpected token`
When I remove the n from the equation at "22n", The error is corrected and the library works as ...
Node.js version: 10.2.1
Heres your problem. For v12 we require at least Node.js version 14+
Please describe the changes this PR makes and why it should be merged:
This PR resolves some unreachable method overloads in some classes, which caused some type inaccuracies.
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 you're at it, why not rename patch to _patch?
There has not been any activity on this issue for 8 months, and I am unable to find anything that would allow the use of proxies. For this reason, I recommend that this issue be closed - if new information regarding this topic is found, the issue can be reopened. @kayotimoteo
Please describe the changes this PR makes and why it should be merged:
The force parameter is used only in line 88:
Which is always unreachable for line 86, where this assignment is at.
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 ...
Premature clicking of the green button aside, isn't this invalid? It'd default force to false if undefined in id, but keep it as true if specified.
Example:
fetch({ guildId: '123', cache: false }); // force is set to false by default, since it's undefined
fetch({ guildId: '123', cache: false, force: true }); // Force is set to true
While you're at it, why not rename patch to _patch? Or maybe even rename all private properties and methods to add a _ at the beginning
If you're talking about Message#patch, it'd need a proper rename, since it's the function called from MESSAGE_UPDATE ๐, something like _messageUpdatePatch or such
Hm Iโm not sure thatโd be necessary since there are other _patch functions in other classes, would just be for the sake of consistency and doesnโt need such a big name
Message also already has a _patch
The bot enters and does nothing does not even give an error the piece of code to run the file is as follows:
var channel = message.guild.channels.cache.get("842859974324518913")
if (!channel) return console.error("The channel does not exist!");
channel.join().then(connection => {
const dispatcher = connection.play('./audios/private.mp3');
dispatcher.on("end", end => {
channel.leave();
});
});
and i dont understand beaucose, can help me everyone
discord.js v12's voice is not longer maintained and does not receive any updates for bugfixes or any other. Please consider using @discordjs/voice, which is a newer voice module for discord.js with better stability and performance.
Something similar to #4151 I guess?
Please describe the changes this PR makes and why it should be merged:
Renamed Constants.OPCode for consistency with recent changes, also moved enum-like objects to the enums file and added tests to ensure they don't receive properties that shouldn't exist.
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 includes bre...
This is not an enum, but TS allows compiling something like Colors[Colors.RED], yielding a string, however in runtime it's actually undefined.
We could make it an enum however, createEnum could be modified to accept objects too.
export interface ThreadMemberManager
extends Omit<CachedManager<Snowflake, ThreadMember, ThreadMemberResolvable>, 'add'> {}
In the typings, the CachedManager class doesn't have the add method anymore, thus there is no need to omit it here for creating the ThreadMemberManager interface. That line can be removed completely and the ThreadMemberManager class can ...
755c180 feat: allow channels from uncached guilds to be... - ckohen
13c839c Docs build for branch master: 755c180659c125532... - iCrawl
I'm not even going to complain. Also this is probably the best time to delete it. Creating a new version is anyway mostly full of breaking changes and other libraries have a lot of time to become compatible to v13. I mean personally i had to rewrite a lot of stuff so i've experienced the problems.
Sorry I hope I'm not asking too much, but should I change the code structure?
Please describe the changes this PR makes and why it should be merged:
This PR adds the type AllowedPartials for structures that can be partial. It also adds the support for partial reactions (the only partial structure without types) and changes how the Partialize type works (it should be only used by djs), so that it can easily extend partials structures.
Tests included!
Status and versioning classification:
- This PR only includes non-code changes, like changes to d...
Please don't remove Structures. My bot's entirely dependent on it. If someone adds something that doesn't work, its them to blame, not you. They should've known what they're messing with before updating the structure.
The number of people who want structures are larger than the number of people who don't.
Please don't remove Structures
They already did...
You'll need to change quite a lot of your voice-related structure with the new voice library, yes.
You can get more support and information in the #djs-new-voice channel from the Discord server.
My bot's entirely dependent on it
I'd imagine most bots are also dependant on the <Message>.send() method, which received a breaking change in v13 - yet I don't see many complaints about that as with Structures being removed :lul:
Well it's not the same... <Message>.send() was changed to make it easier to use and easier add new features. Structures were totally removed...
Being honest here, I have used and abused structures to hell and forth since they were ever released in v12's master branch, I also personally use Message#send like @TwilightZebby has shown, however, as much as structures made our lives easier, they also carried a number of issues, from libraries being able to easily break our bots by assigning properties used by the library, to potential libraries taking advantage of this feature to register malicious code in bots without one knowing.
L...
@ImRodry The WSCodes names below needs to be reverted.
oops I did a mass replace and didn't notice those, will fix!
So these are new changes:
Moved the partial getter from DMChannel to Channel so that people can use <Channel>.partial even if the channel is not a dm (Shouldn't change a lot for non-typescript users).
Fixed cleanContent being not nullable in Message for docs.
Added all the necessary tests and fixed some properties being nullable in typings even if they're not when the Structure is not partial.
Please describe the changes this PR makes and why it should be merged:
This PR just fixes an error in Typings where the option permissionId was types as permissionsId.
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 only includes non-code changes, like changes to documentation, README, etc.
I'm fixing this, I don't recommend trying to send quick requests without at least checking the rest of the code
my code likes to thinks so, TypeError: Cannot read property 'parent' of null
at Object.run (/home/tha/workspace/discordWeeb/src/commands/user/user.js:10:29)
the line is interaction.channel.parent.name.toLowerCase() === 'staff'`
or am I missing a intent // partial
Null is not undefined. That happens likely because you ran that in a DM channel that wasn't cached
The channel is a normal guildChannel and not a dm could be that its not cached tho
Yeah, my bad had something to do with cache and I went back to using intents.all
Intents.all is no longer a thing, you need to actually specify intents
Yeah, I saw that with other updates so I just got my old package-lock and installed that version, As I will fix the setPermissions and intents and whatever else changed locally and not on my vps :p
That's a really interesting feature. I think this can be done with a getter or a function that checks with regex(s) unicode and custom emojis in the message content filtering not cached emojis (or actually with partial emojis) but as said above it wasn't added because the API doesn't and doing it on our side could lead to problems...
Are you still able to reproduce this bug with the Dev version?
This won't be added to the library for a few reasons:
- The data isn't in the message payload.
- Maintaining a regex that matches all unicode emojis isn't desirable, even if from an external dependency.
- Performing a highly complex regex on every message payload is absolutely horrible for performance.
Problem: I am trying to make a discord bot in VSCode with discord.js and I want it to respond to me if I say something but for it to not always be the same as the last time, here is an example,
me: Hello or Hi or Sup or Yo (case insensitive)
bot: Sup or Hello or Hi or Yo (case insensitive)
this is my code so far:
let repliesHi = [โHiโ, โHelloโ, โYoโ, โSupโ];
let randomHi = Math.floor(Math.random() * repliesHi.length);
client.on("message", message => {
if (/\bhi\b/...
Your regex test doesn't cater for all possible inputs. You could just check if the message content is an element of the array you have initialised rather than using regex.
You are generating your random number once, and storing it as a constant. This never changes, so it will always refer to the same response.
Generate a new random number each message event.
call the random function inside client.on
let repliesHi = ["Hi", "Hello", "Yo", "Sup"];
client.on("message", message => {
if (message.author.bot) return;
if (/\bhi\b/i.test(message.content)) {
let randomHi = Math.floor(Math.random() * repliesHi.length);
message.channel.send(repliesHi[randomHi]);
}
});
this way, each time the callback function for the message event is called, a new random number would be generated, instead of having it be generated one tim...
The partial property should be below packId
I think the title says something but there's an example.
There're some requires inside the send function.
Isn't it bad to require files within functions? Shouldn't it be at the root of the file?
The code you're referring to was last touched three years. It's not that it was added for v13, it's more of something that hasn't been changed.
This is intentional - scoping the require avoids creating circular imports.
Isn't ID an abbreviation? So, following camelCase, shouldn't it be capitalized (xID)?
Reference: Microsoft Abbreviation Guidelines
The word id, which following camelCase would be xId, has a different meaning.
Since this PR is touching it, ThreadMemberManager#_add can be cleaned up a bit (should've done it better to begin with, sorry). Basically remove everything inside it and replace with return super._add(data, cache, { id: data.user_id });. If that feels out of scope, I'll do it in another PR.
Please describe the changes this PR makes and why it should be merged:
Two patch methods, both private, second often gets missed during changes. No more!
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 PR includes breaking changes (methods remo...
I don't see where in the website says that it should be ID over Id. Also quite funny you quote MSFT's guidelines when the 2 biggest .NET library for Discord uses Id, as you can see in Discord.NET's MessageReference and [DSharpPlus's DiscordMessageReference](https://github.com/DSharpPlus/DSharpPlus/blob/master/DSharpPlus/Entities/Channel/Message/DiscordMessageReference.cs...
The guidelines seem to tell us not to use an abbreviation at all. The final sentence "If you must use abbreviations, use camel case for abbreviations that consist of more than two characters, even if this contradicts the standard abbreviation of the word."
Admittedly this abbreviation is not more than two characters.
But we can do what we want regardless.
It's better to do another PR for it, @ckohen
It could be moved to the bottom, which also fixes the circular:
Circulars only happen because A requires B, B requires A, and A's exports weren't available, which is why that require is below the export.
call the random function inside client.on
let repliesHi = ["Hi", "Hello", "Yo", "Sup"];
client.on("message", message => {
if (message.author.bot) return;
if (/\bhi\b/i.test(message.content)) {
let randomHi = Math.floor(Math.random() * repliesHi.length);
message.channel.send(repliesHi[randomHi]);
}
});
this way, each time the callback function for the message event is called, a new random number would be generated, instead of having it be generated one tim...
i have this problem when i upload files in the server.
any solution?
The first comment is the solution:
Discord.js v12 requires a minimum Node version of v12
Could you also fix the name here?
https://github.com/discordjs/discord.js/blob/755c180659c125532fe6f8e33e6c3b56e275311b/src/managers/ApplicationCommandPermissionsManager.js#L350
nameof when
This getter could just always return false and have dm channel (the only one that can be partial currently), do this check:
return false;
This method should be restored.
Could you also fix the name here?
https://github.com/discordjs/discord.js/blob/755c180659c125532fe6f8e33e6c3b56e275311b/src/managers/ApplicationCommandPermissionsManager.js#L350~nameof when~
Sure
This is missing in the typings, I'm also not sure if this really should be an enum, since their values are incorrect.
Maybe just go with an array like with ThreadChannelTypes?
This is missing in the typings, I'm also not sure if this really should be an enum, since their values are incorrect.
Maybe just go with an array like with ThreadChannelTypes?
I didnโt know this had to be in the typings but sure, Iโll add it. As for the enum/array it doesnโt really make a difference since these are only used to check if the channel type is inside that enum but for the sake of consistency with thread channel types I can change that too. Same for the other comment
Should I add in the jsdoc a note to say that this is always false if it's not a DMChannel?
fix #6020
Please describe the changes this PR makes and why it should be merged:
This PR fixes some jsdocs where shardId was showed as nullable while it isn't, in fact, passing null as shardId throws a TypeError. However, it's still marked as optional and types are ok.
Status and versioning classification:
- This PR only includes non-code changes, like changes to documentation, README, etc.
- Code changes have been tested against the Discord API, or there are...
shardId shouldn't be nullable but optional. Opened a PR to fix it. #6072
You failed to reproduce it because the issue appear to be present when x members have been reached in that discord server. I assume x to be 1000, but it could be less.
The event is fired, but the role is never granted to the client. You can loop it and add the role thousands times, no role will be added.
My post on stackoverflow while ago did not brought any answer either.
The c...
You can loop it and add the role thousands times
This seems like a very good way to reproduce the error - it's called a rate limit and it will prevent the API from responding, if not get your bot banned.
You can loop it and add the role thousands times
This seems like a very good way to reproduce the error - it's called a rate limit and it will prevent the API from responding, if not get your bot banned.
Please just stay focus on the issue we are trying to bring. It's already hard to get attention on it and we are dealing with this crap for years now. Adding roles manually because the discord API failed to grant them properly.
I obviously over reacted when mentioning "thousa...
Souji's comment was focused on this issue - he asked if you could reproduce it on the latest discord.js release.
If your focus is still on the role appearing in the client rather than the execution of API calls, then the issue doesn't appear to lie with discord.js, and you should follow this up with Discord directly.
Otherwise, I've just tried to reproduce this myself also, and we aren't able to with any of the code samples provided in this thread. If you still can on the latest `discor...
Well, what here is missing is a working example with a good circumstance. If you are sure that you're able to reproduce this bug (which actually doesn't seem to be related with djs itself) try adding a console.log(member.user.tag) at the start of the event, and if you see that a member doesn't receive the role, check that the console logged the user tag. If it wasn't, so most probably Discord didn't send the event.
4eb3a2a refactor: rename Constants.OPCode to Opcode... - kyranet
98a5b52 refactor(ApplicationCommandManager): remove unu... - kyranet
c673d00 Docs build for branch master: 4eb3a2a885efd480a... - iCrawl
ce23b57 Docs build for branch master: 98a5b52d8bb09ccca... - iCrawl
58bbcd5 types(ApplicationCommand): fix option name (#6067) - DTrombett
4230ce7 Docs build for branch master: 58bbcd591e0189459... - iCrawl
Please use for-of and Object.entries
* @property {number|number[]} [shardId] Shard id(s) to have the activity set on
* <info>This is always false outside of DM channels.</info>
Isn't this technically wrong? What if a message has flags, we get a MESSAGE_UPDATE for god knows what, and the flags don't change? Won't this make the cached flags invalid with what they actually are?
This doesn't seem to do the same thing anymore?
Previously, if attachments was present, it'd clear the collection and fill it in with the new attachments, otherwise cloning the existing attachments.
Now, if we get a partial update, we clone the previous attachments and append to them / overwrite some of them.
Am I reading the code wrong?
This isn't set anywhere anymore, unless I missed it

