#archive-library-discussion
25217 messages · Page 26 of 26 (latest)
Ty
that note isn't true at all, should we suggest to set it to 8 in order to disable the command?
0 does the exact opposite of disabling the command
The warning in the DDocs says otherwise
where's that
I'm pretty sure I tried this earlier and it was fine
nop
0 is no permission
if you don't require any perms to use a command its enabled for everyone
what they meant to put there is 8
I just tried it again, I cannot reproduce that
i can't get neither 0 or 8 to change anything at all
Maybe your members are all administrators (x
crying
Also supposedly permission 0 disables it for everyone except admins+owner
but that doesn't make sense
ok so it seems like it does work, it just doesn't change anything in the integrations tab which is why it gets confusing
default member permissions never changed anything in that tab, its a stupid oversight that makes the UI 50% useless
supposedly they wanna work on it but time
might as well do a permissions v3 cuz v2 was so disastrous it needs an entire rewrite again
everything is slower, commands take ages to populate and glitch out when you're writing them and it's no longer as easy as simply enabling or disabling a command for a role, you can't even do that through the API now so you can't automate most systems without an oauth token
- Haven't seen it
- They appear instantly

- Disabling a command for a role is literally going to the cmd in the ui, adding the role and toggling it to off
- That's an ANNOYANCE but not a groundbreaker and I doubt it'll change any time soon too
You can easily notice how when you type / the menu goes black and only gets populated a few seconds later, similar to how autocomplete works too and this didn’t use to happen before v2
Yes you can still disable commands for roles but it’s way harder because it has to be done manually and becomes quite annoying when you have over 40 commands so it’s easier to just enable the command for all roles and do perm checks on the bot iself
the disabling commands for roles is better imo, gives the owner/admins control over who can use certain commands instead of having to rely on the bot
Way too often now I try to /ban someone and it defaults to Discord's own slash command because I forget to wait for Yuu's to load
the first thing you mentioned is because of the slash command backend rewrite, it was separate from perms v2 but they both landed almost at the same time
the ui not reflecting perms v2 is a known issue and they are working on it iirc, i made a github issue about it and it got the synced label and assigned to someone
How much of this is actually related to d.js 🤔
can confirm this with 400+ shards / 439k servers
patched: https://github.com/discordjs/discord.js/pull/8082
this might help
Are backports on v13 branch even tested?
Their should also be a separate dev release for v13...
Did you find an issue?
Kinda sounded rude, apologies, meaning the identify issue. When Core parts are affected, they somehow should be tested on production...
you can actually install the v13 branch from github, it's not a monorepo
You can run npm install discordjs/discord.js#v13 to install it
i can put this in prod if u like, to test
got it in production, 448 shards, 440k servers
I had that tested with two huge bots
All of the pr's by me Voxelli [github:legendhimslef] are actually being tested thoroughly in production with two bots [35k 43k guilds | 35 shards/43 ] shards for few days.
I only push codes when testing is done so yeah..
have a check for new identifies calls and reconnects with 4009.
I’m saying mistakes can happen and testing sharding is the most difficult task generally
Because you do need someone willing to test and you might need a big number of shards, not always but sometimes
Sharding is rarely something you can test on a tiny server by yourself
Yeah, I was just trying to make it clear that I take stuff seriously and push it after being tested properly
Like everything else in the lib
I am always ready with my bot [38/43 shards bot] to test new codes so you can ping me if there is ever a need.
ill let ya know if itll crash or not
okay
there are certain message types that dapi will throw an error 'Cannot execute action on a system message' if attempted to delete them (for example: RECIPIENT_ADD, RECIPIENT_REMOVE), yet Message#deletable doesnt seem to have a check for it. Is this intentional by design?
we could test which ones do it currently, but that can change at any time without notice
The problem with system message deletions is that it's inconsistent at which ones you can delete
Does the roll out of auto mod issues with v13?
try it and see, and report bugs if you find them
why are none of the audioplayerstatus events typed https://github.com/discordjs/discord.js/blob/main/packages/voice/src/audio/AudioPlayer.ts#L160
I believe the same is true for VoiceConnection
I only added the ones that had documentation before I adapted the docgen
So they were missing before
Most likely just an oversight
And I wasn’t going to add them just to fix the docgen in the same pr
ok
also voice in general has a ton of eslint-disable overrides, for everything that's documented can that/ should that be changed?
Preferably
But it will be a big undertaking I assume
The codebase isn’t a huge mess, but fixing those overrides can be a bit tedious
This channel is for important discussion about developing discord.js, please go to #archive-offtopic , moreover this server is for discord.js not for steam bot builders
Will content moderation support be added to discord.js? (New feature)
#7938 in discordjs/discord.js by Jiralite created <t:1652824011:R> (review required)
feat: AutoMod
📥 npm i Jiralite/discord.js#feat/auto-moderation
thanks
In the future, the answer will always be yes
^ unless it's not available to bots
your patch seems to work 🙌
448 shards / 441k servers
🎉 Seems fine on my side as well
any way to fetch all the friend ids?
if there were it'd require oauth2 and even with that i don't think there is
but definitely not in djs
relationships.read even needs discord approval
it's possible on python
then you are running a selfbot, which is against discord terms of service
you are not allowed to automate non-bot accounts
Fair nuff
you can get friends with rpc
source?
I'm not able to commit bcz of this error. Does anyone know why it's happening? I've committed by adding --no-verify for now
reinstall all deps and try again? 
is there a reason for VoiceChannel not having nsfw property because api returns it while djs doesn't
i wanted to ask here before i make an issue on gh
It was prob overlooked when tiv was added to d.js
Feel free to open the issue and I (or someone else) will make a PR for it
damnit how did i miss that
@upper moss
i opened an issue
export interface ChannelData {
name?: string;
type?: Pick<typeof ChannelTypes, 'GUILD_TEXT' | 'GUILD_NEWS'>;
position?: number;
topic?: string;
nsfw?: boolean;
bitrate?: number;
userLimit?: number;
parent?: CategoryChannelResolvable | null;
rateLimitPerUser?: number;
lockPermissions?: boolean;
permissionOverwrites?: readonly OverwriteResolvable[] | Collection<Snowflake, OverwriteResolvable>;
defaultAutoArchiveDuration?: ThreadAutoArchiveDuration | 'MAX';
rtcRegion?: string | null;
videoQualityMode?: VideoQualityMode | null;
}
does anyone know what type resolves to?
asking because it doesnt matter if i try to edit with { type: 'GUILD_TEXT' } or with { type: ChannelTypes.GUILD_TEXT } theres always a ts error about types not matching
That type is incorrect
What djs version your using
13.8.0
sadness
type should be ChannelTypes.GUILD_TEXT | ChannelTypes.GUILD_NEWS right?
it is that in main~~, yes~~
No
It should be 'GUILD_TEXT' | 'GUILD_NEWS | ChannelTypes.GUILD_TEXT | ChannelTypes.GUILD_NEWS
Basically, https://github.com/discordjs/discord.js/pull/8089 needs to be backported
Make an issue @pallid ridge if you want, then perhaps someone will add it for the next 13.x
it should definitely be only the enum values, considering there is no check (at least as of now) and DAPI accepts type: integer
i might make a pr
No it should be both. If there isn't, that'd be a bug
https://discord.js.org/#/docs/discord.js/13.8.0/typedef/ChannelData
It's documented to take a string too, that needs to have a number after it
i get an DAPI error by trying 'GUILD_TEXT'
That’s resolved to num by d.js
The string isn't sent across to Discord - it's resolved
Hence
If there isn't, that'd be a bug
Resolving should be like this
https://github.com/discordjs/discord.js/blob/13.8.0/src/managers/GuildChannelManager.js#L146
That doesn't exist in the edit method for some reason, so... yea
If it's a number, leave it as it is, else, it's a string, so convert it to a number. And then the default type is a text channel
Then it's sent to the API
ill make a pr later
why?
Bc it’s a bug?
oh wait I missed a few messages
v13 should still support string for channel.type
hey @tacit crypt (think its better to talk here? about discord-api-types#502)
even tho the docs says it, i tested myself and it doesn't work, you can test in this url: https://cdn.discordapp.com/banners/277496071897481216/a_114df53592ae20557666470b5e741966.gif?size=
cc @outer raven (you were also in the discussion)
well iirc they don't support resizing gifts
Was that change reverted or did it never land
I know for a fact Discord supports more than just powers of two and ive seen prs to add that on djs
but i still can't get the image with static images 👀
tested with vladdy's banner (only with power of two, of course)
https://github.com/discordjs/discord.js/pull/6844 this is what I was talking about, guess it never landed on discord’s side but was merged on djs
It was asked to be reverted in both linked pull requests, but that never happened
Reverted? When
Those aren’t linked but alright
https://github.com/discord/discord-api-docs/issues/4031#issuecomment-963456127 apparently discord doesn’t like these
Did anyone ever revert these tho
Oh it wasn’t “reverted” just was never added to rest and thats what djs uses now
Alright guess I was behind on the news then
They "work"/worked, that is true, but they're not recommended
so I will leave it with number type and use the docs to say it only accepts numbers power of two between 16 and 4096, thanks guys :)
Pls make the type specific 
I don't see Vlad changing their stance anywhere
Lol, my apologies. I've never had to do that before lol
I would have reopened it but I deleted the branch without thinking.
It's been a long day. 😁
Did you still want to make the PR?
As long as you didn’t delete the fork you can restore the branch
I opened another one
I wasn't thinking at all to be honest
@vernal rose are you sure your root hoisting also makes it possible to run the commands inside the packages too
without having to run them on the root
or use the workspace focus cli from yarn
I know for sure you can't make the changes to the /website directory
Since we use npm on vercel to install stuff from that folder
because yarn doesn't work there correctly
eslint, prettier are installed inside of the package too so you can run the command from there. For release, yarn workspace or turbo can work from root. If u want I can add the cliff-jumper inside of all the packages again but those eslint plugin and config can be used in root
yeah its mainly the binaries I need
since for releases I execute most stuff inside the packages folders
and not on root
but youll have to fully revert the changes to the website
done btw ci is failing but ig it's not related to my changes
https://github.com/discordjs/discord.js/blob/65d1879/packages/builders/src/messages/formatters.ts#L54 Why do these formatter functions use the generic type C extends string and not directly string as a parameter?
look at the return type.
its so underscore('abc') returns '__abc__' rather than string
it's just a stricter type
got it thanks
is djs ever going to remove support to just do channel.send(string), so you need to do channel.send({ content: string })?
I think it's a very commonly used way of sending a message in a channel and it's the only single helper overload so... possibly not? But idk
For my opnion, it can stay as it is.
I dont see a reason for removing it
same
It won't be removed.
Why did you do this update that needs to specify if it's content or embed??
I also don't understand, could you explain?
that's what discord requires
When creating a message, apps must provide a value for at least one of
content,embeds,sticker_ids, orfiles[n].
I think they're referring to why we don't allow .send(embed) and it was because overloads like this were unintuitive and break easily, particularly when they then had to send another object for message options.
The content string is friendly enough for both users and maintainers to keep
can i ask, why does https://discord.js.org/#/docs/discord.js/main/class/TextChannel?scrollTo=awaitMessages return a Collection? how are you supposed to index a collection of data where you cant know the keys. wouldn't it make more sense to use an array?
the idea is that you collect things you want to process, iteration is a valid construct for that, what would indexing help there?
at the end of the day collections are used whenever we can associate a unique key with an instance in a "collection" of structures
if you want to index it, you can just spread the iterator, or you can iterate to process the elements in order
A
Mapobject iterates its elements in insertion order
in 9/10 cases where people want an array in here they probably don't need one
And a map is easily convertible to an array whereas the opposite isn’t true
It is true, using the Map's constructor, just requires a few more characters
You can’t just slap any array in the map constructor, you have to map it
new Map(arr.map((e) => [e.id, e]));
is there any updates or planned things going on with https://github.com/discordjs/discord.js/pull/7204
There's a new RFC for it, and I'll implement it in its due time
oo, havent heard of that, can you link it please? sorry for taking ur time
or is this it?
https://github.com/discordjs/discord.js/issues/8084
Yes, it is
okay, thanks
Any news on this? And is this something that will be implemented correctly in the discord.js library?
I think it's still in development
There is no reason for it to not be implemented
Moved to tagged post in #992669226403909652