#archive-library-discussion

1 messages · Page 8 of 1

lofty birch
#

the solution might just have to be making some queue system that runs on a cheap VPS that handles these across all shards, as those obviously make this a lot harder to handle

oak quail
#

is there a reason u arent just sending via the bot

#

would it really hit 50/s?

lofty birch
#

I mean it has

#

when night helped me debug it the first time it happened, almost every one of the ratelimit requests occurred on webhook routes

oak quail
#

hmm

#

do webhooks have ratelimit headers now

lofty birch
oak quail
#

u can still send cross server via the bot tho? 🤔

lofty birch
#

the bot isn't guaranteed to be there

oak quail
#

ah

#

so the server provides the webhook url?

lofty birch
#

yes

ornate topaz
#

cough didn't that go slightly offtopic?

lofty birch
#

you're right, was just asking here to find out if it was a lib thing and it turns out there was a PR for master, just obviously not on V12 yet lol. thanks for the input

spiral oak
#

can MessageType be updated to include all the new ones?

wild flax
#

You need to be a bit more specific than that

spiral oak
#

These are the current djs ones

unknown.png
#

But the discord doc has a load more now, including ones like reply which would be very useful

unknown.png
slate nacelle
#

Those will come with v13, for example reply and application command are already there.
The thread types will come with threads, which will still take some time and no idea what the last one is.

spiral oak
#

👍

tacit crypt
#

INVITE_REMINDER is related to a system channel flag

remote wasp
#

The InteractionReplyOptions links to WebhookMessageOptions in docs, which isn't completely correct as the latter one has some extra fields. Vaporox and I had a talk about it (#djs-help-v14 message) and the problem was that making a new typdef would result in code duplication for the third time.
One potential solution that we arrived at was creating a new base typedef that will have all the common fields which MessageOptions, WebhookMessageOptions, InteractionReplyOptions, and ReplyMessageOptions (yet to be merged) can extend. This will result in no code duplication and a correct documentation.
I wanted to discuss about it first before working on it just to make sure that this is what we want.

outer raven
#

Don't really know where to put this but is it possible to improve the embed sent with discord.js.org links so that it shows more information about that link?

wild flax
#

Not really no. We can't really do SSR and pre-generating all the pages depending on stable/master/version/branch doesn't seem necessarily worth it.

#

It would also make the embed unnecessarily big, any reason why this would be particularly useful?

outer raven
wild flax
#

Yeah but there isn't necessarily a big benefit in this

outer raven
#

It would just look nice and would help people quickly understand what they're gonna find once they click the link

wild flax
#

The benefit doesn't really outweigh the work required for it here sadly

outer raven
#

Fair enough, I'm not sure how these docs are even generated so it might be harder than it seems, thanks for the feedback!

remote wasp
outer night
#

it's been 12 hours, give it at least another day before bumping

pale seal
remote wasp
pale seal
#

I'm having the issue too. Seems to be an issue that comes back all the time xD

outer raven
#

Quick question: what's happening in the options.types type in the ApplicationCommandOptionData interface? It has 2 values and 1 of them seems to link to the other and, when writing in TS, we don't get autocomplete like we do with permissions, intents, etc

unknown.png
vivid field
#

ApplicationCommandOptionType are the strings that you can pass, ApplicationCommandOptionTypes their corresponding numbers

outer raven
#

ah gotcha, why aren't they autocompleting then?

vivid field
#

they should be

outer raven
#

Could you try to reproduce this? Maybe I'm doing something wrong

vivid field
#

oh, could actually replicate

#

but i guess that's a problem with typescript then, not with discord.js

outer raven
#

Well I can't get to the value of ApplicationCommandOptionTypes since it's an import and for some reason my IDE doesn't let me open discord-api-types/v8 but maybe there's something wrong with that?

#

You could try declaring the types directly in index.d.ts instead of importing, not sure if that would fix it tho

vivid field
#

you can open it, just ctrl+click the import

outer raven
#

yeah I know but it doesn't work

#

just doesn't do anything

vivid field
#

but it shouldnt really matter where the enum is declared

outer raven
#

I can't find a folder called discord-api-types in my node-modules either

vivid field
#

even tho it will have to be declared locally anyway with discord-api-types v0.19

#

then you didn't install it probably

outer raven
#

I think I did tho

#

lemme try again

#

yeah just reinstalled and the import still has any value 🤔

unknown.png
#

I can ctrl click all imports except for discord-api-types/v8 and ws

#

I think the package isn't declared as a dependency

ruby terrace
#

I was having some weird issues with ts imports too, both in master and -next (it is a dependency and is in the modules folder though)

outer raven
#

Is it a dependency? I can't find it in my package-lock.json

ruby terrace
#

dev

vivid field
#

it's a dev dependency

outer raven
#

well those don't show up, that might be why

#

They're not getting imported when installing the package

vivid field
#

yes, you have to install discord-api-types and @types/ws separately if you don't want them to fall back to any

outer raven
#

ooooohhhh

#

it works now

#

it was that simple huh

lone vector
#

I'm curious on the decision for how Role#edit() is made to work, since from what I can tell reading the code for it, it always sends the permissions field to the API although the API considers it optional, so just trying to edit a role's colour or name can cause a Missing Permissions error if the bot doesn't have at least the exact same role permissions as the role it's attempting to edit, or maybe I'm just missing something/doing something wrong to cause this?

solemn oyster
#

Continuing from #archive-offtopic message

@old kelp proposed merging create and edit into upsert, as it's the term for "create or edit".

However, since the edit part isn't a patch, but rather a full rewrite (override, if you will), it matches set's description, which also creates.

This also wouldn't break consistency with existing methods in the library, e.g. member.roles.set. While I don't recall upsert being used anywhere else.

What are your thoughts? @tacit crypt

tacit crypt
old kelp
#

so are we going with upsert?
cc @solemn oyster @tacit crypt

tacit crypt
#

thing is, with permission overwrites, create and edit do the same

unique axle
#

no BOYEbomb

tacit crypt
unique axle
#

no

tacit crypt
#

Souji dear

unique axle
#

vlad dear, i broke that discussion loose 2 times, and every time i in the end saw that space was right and i was wrong, they are not the same

tacit crypt
#

Look at the source code for the overwrite methods, they do 1:1 the same code??

old kelp
tacit crypt
#

Casein point

old kelp
#

bump again kyra, vlad, so are we going with upsert now or..

tacit crypt
#

iirc i said upsert too at some point, I can't speak for kyra or crawl tho

old kelp
#

@unique axle could you elaborate on your point?
is it not same just for making it more verbose to users, because they internally work the same, otherwise i'm missing something?

unique axle
#

nvm, that was GuildChannel#createOverwrite and GuildChannel#updateOverwrite (they don't do the same, hence why they still both exist)
which:

thing is, with permission overwrites, create and edit do the same
sounded like potatodetective

tacit crypt
#

Souji dear..

unique axle
#

no.

tacit crypt
#

WDYM NO??

#

Look at the code

unique axle
#

i literally argued about that for hours with space and i lost

#

they don't do the same

#

update retains other bits but the ones specified, create replaces them

tacit crypt
#

Wat

#

OH, I see

#

Still, code deduplication would be ideal

unique axle
tacit crypt
#

Yeah the difference is that update appends it, as space said, while create just..creates

#

But the end API calls and checks are the same in a way

#

So, those parts should be deduplicated in a private function

ashen garden
#

add an event "raw gateway response" or something

#

basically a way to listen for everything the api sends back to us

#

ah, is it undocumented?

#

ye exactly

#

thanks

old kelp
tacit crypt
#

No, edit and create do different things, but their end code is the same except for one line

old kelp
#

so should edit call create then?

tacit crypt
#

you should have upsert as the base func, create call it, and edit call it with the existing overwrite

#

Let me get you example code

#

Think ```js
class Example {
upsert(userOrRole, permissions, reason, old = null) {
userOrRole = this.guild.roles.resolve(userOrRole) || this.client.users.resolve(userOrRole);
if (!userOrRole) return Promise.reject(new TypeError('INVALID_TYPE', 'parameter', 'User nor a Role'));

    const type = userOrRole instanceof Role ? 'role' : 'member';
    const { allow, deny } = PermissionOverwrites.resolveOverwriteOptions(options, old);

    return this.client.api
        .channels(this.id)
        .permissions[userOrRole.id].put({
            data: { id: userOrRole.id, type, allow: allow.bitfield, deny: deny.bitfield },
            reason,
        })
        .then(() => this);
}

}

class PermissionOverwrites {
update(options, reason) {
return Example.upsert(this.id, options, reason, this);
}
}``` but you'll need to make it prettier (theres a PR that makes it to where we can specify the type, so.. that might be good too)

#

I think this would be accurate-ish

#

could be cleaner, shoving everything in an object too

#

CC @wild flax @solemn oyster

old kelp
#

shouldn't the base method be in PermissionOverwriteManager and make that call in PermissionOverwrites though?

#

oh, that's what you technically did.. i'll come up with a cleaner implementation and re-ask for review, thanks 👍

tacit crypt
#

Yeah, think Example as the manager

outer raven
#

was the code link in the docs removed?

#

I can't seem to find it for some reason

oak quail
#

also in the "Links" section of the welcome page

outer raven
oak quail
#

this?

#

never knew it existed tbh, thats useful

outer raven
#

ye I can't see that

#

lmao really

#

but I don't see that button for some reason

oak quail
#

try hard reloading?

outer raven
#

yep did exactly that and it worked

#

thats odd

#

ty

unique axle
#

resize your window, something weird happens there sometimes that pushes it farther out

outer raven
#

it was maximized ¯_(ツ)_/¯

grave tree
#

What discord gateway link is using discord.js?

wild flax
#

gateway link??

grave tree
# wild flax gateway link??

when you are connecting to the gateway and receiving payload with the websocket, you use a link like wss://gateway.discord.gg/?v=8&encoding=json

wild flax
#

Yes, well that very much depends

#

Encoding depends on if you have zlibsync installed, but overall we are on gateway version 8

grave tree
#

oh thank you

warped crater
wild flax
#

lol, the 2nd is not so relevant

#

You'd be better off just looking in the Constants or WebSocketShard

warped crater
#

yeptune fair

wild flax
#

Convoluted mess

warped crater
#

one day

grave tree
#

is discord.js master branch updated to gateway v9?

keen cosmos
#

there's a PR for it

loud jayBOT
solemn oyster
#

There are some backwards incompatible changes with gw v9 that will be released over time, and stable doesn't even use v8 yet

keen cosmos
#

oh, gateway, not api, my b

silk wren
#

How does D.js get the GuildMember#joinedAt ?
Of course it has to be exposed by the API itself, but I'd like to hear where x)

unique axle
#

joined_at ISO8601 timestamp when the user joined the guild

grave tree
next inlet
#

@solemn oyster mind jumping in a VC with me for a sec?

solemn oyster
#

Is this going to be related with the library?

next inlet
#

yes

#

give me a sec, gonna restart discord

solemn oyster
#

Ok

solemn oyster
#

We concluded a structure called ApplicationCommandOption (as opposed to a plain object with a typedef) would be a sensible way to approach this

#

And it'd also refactor away ApplicationCommand.transformOption (they'd be transformed inside ApplicationCommandOption's constructor) as well as allow us to add isEqual in them for fast deep comparison

#

The idea behind checking for equals recursively is so we can dynamically build a framework which updates the registered application commands on Discord automatically, without us needing to write migrations or pushing all commands in every log in, which can be rather inefficient

copper laurel
#

So it would load files like a regular framework, then fetch API and compare?

next inlet
#

yes that is pretty much the thought

vivid field
#

Sounds reasonable for received options, but how would that approach handle options passed by the user?

solemn oyster
#

Isn't that pretty much framework independent? It's not like regular users can update one bot's slash commands

vivid field
#

I mean the users of the library

#

You shouldnt need a framework to create/update application commands

copper laurel
#

Need, no, but you never needed one for regular commads either

#

It just makes it easier

vivid field
#

That's why I'm asking, because from what I understood, for commands.edit()/.create()/.set() you would still need a transformOption method or similar

sly forge
#

The ApplicationCommandOption structure sounds great, but handling received interactions should be left out for the user to implement.

ruby terrace
#

I assume you would then need to pass it an instantiated ApplicationCommandOption which would have a toJSON method for readying it for discord. (not sure if I'm a fan of this)

ruby terrace
vivid field
#

I guess that would work, but constructing a new class instance only to convert it back to an object right after also sounds a bit expensive

ruby terrace
#

yeah, that's why I'm not exactly a fan

solemn oyster
solemn oyster
tawdry pasture
#

Will the BLURPLE string in
ColorResolvable be updated to match the new blurple?

wild flax
#

Yes

#

Mind you, this will most likely happen in a non-backwards-compatible fashion since we are increasing the major version

tawdry pasture
#

So Ill have to switch my v12 bots to using the new color manually then?

wild flax
#

No. It means we’ll switch the color and when you update you automatically have it

#

Usually you aren’t allowed to do that as a library, since users might still want the old color without us forcing it on them

unique axle
#

will have to do some figuring out regarding the new default icons, they're not numbers anymore nkoBruh

#

eh, v13 is a major anyways, might as well flip colour codes and avatars

tawdry pasture
#

Ah got it. thanks!

oak quail
#

the client has always used /assets instead of the cdn ones

outer raven
#

I noticed the default avatar URL no longer works. Is this a bug with the library or discord?

#

By "no longer works" I mean it links to the old one(s)

ornate topaz
#

you could read messages just above yours, and judge on your own why it links to old ones

outer raven
#

oopsie, didn't notice, sorry

ornate topaz
#

yes, that is /assets

outer raven
#

Adding the bigint type for RoleManagers made things slightly more annoying for typescript devs, is it possible to remove this type for this and other managers that have this?

unknown.png
vernal atlas
#

what

ornate topaz
#

what are you talking about

outer raven
#

Whenever I try to access a guild member's roles, the manager has those 2 types which makes it so TS always throws an error when trying to remove/add roles for example

#

Talking about the master branch btw

wild flax
#

Please post the associated code with it

outer raven
#

ok sorry I missed some context. I'm getting this when accessing a guildmember through an interaction, for which the roles object is a Snowflake type sometimes, which comes with that `${bigint}` type

#

the line is just this

unknown.png
wild flax
#

Yes.

outer raven
#

Is this intentional?

ornate topaz
#

fairly sure it is, and it's array of snowflakes when there is no bot

outer raven
#

How would there be no bot?

ornate topaz
#

interactions don't need a bot

wild flax
#

Interactions don't require a bot connected to the gateway or in the guild

outer raven
#

even if it's a commandinteraction?

wild flax
#

of course

ornate topaz
#

what difference does that even make here

outer raven
#

that we have to specify the type for the rolemanager every time we want to add or remove roles which is slightly annoying

wild flax
#

well, it is accurate thats for sure

#

your code will break if you don't check first

outer raven
#

well in my case my bot is only in 1 guild and I'm sure it will always be there and have access to interactions so I don't think any checks would be needed

wild flax
#

Sure, whatever, but that doesn't mean we can change the typings just because you have no use for it

outer raven
#

Yeah of course but it seems like such an edge case that will cause so much trouble for other users and isn't even documented properly on your docs website

ornate topaz
outer raven
#

Yeah exactly, doesn't specify any properties for that "Object" so it's hard to know

wild flax
#

How is it an edge case? If someone invites your commands via the oauth scope without inviting your bot, you need to check.

outer raven
#

You can do that?

wild flax
#

Yes.

outer raven
ornate topaz
#

but it's an Object. it does not have any methods GuildMember would

outer raven
#

it could be the APIInteractionGuildMember object which is what is given in TS

untold python
#

I dont know if this fits here, but is there a version of discord.js that doesnt use the fs module? I need to run it in the browser, which doesnt offer the fs module

frank turret
#

webpacked versions of d.js aren't supported anymore and don't work

untold python
#

aw

#

ill write my own wrapper then, thx anyways

remote wasp
#

@untold python I don't think you can make any request to the discord api in browser now

remote wasp
#

yeah

cloud nest
#

Would it be thinkable to add an APIEvent enum containing all currently available events? That would simplify event handling implementations. Possible benefits of such an implementation (and the issue I am currently facing) are described at https://github.com/microsoft/TypeScript/issues/10570#issuecomment-769442192

I do see that solely supporting such an enum in the library itself would be a breaking change. However, one could merely provide support for using the enum for listener registrations as an alternative way to the current one.

Admittedly, this is a bit of a minor inconvenience, but it bothers me enough to propose such a feature.
I am quite new to d.js and apologize if such discussions have already taken place.

Also, I'd be happy to create a GitHub issue if need be. Thanks!

slate nacelle
empty viper
#

:/

cloud nest
# slate nacelle Would `keyof ClientEvents` not be sufficient here?

I initially thought so too, but

abstract class Parent {
  abstract event: keyof ClientEvents;
}

class Child extends Parent {
  event = "message";
}

throws an error. TS cannot infer that event in the Child class is indeed a keyof ClientEvents, but interprets it as a string instead.

Instead, you need to assert the type manually each time:

class BetterChild extends Parent {
  event: keyof ClientEvents = "message";
}

It works, but it is an inconvenience that could be avoided by using an enum that would allow for TS to automatically infer the correct type

slate nacelle
#

Using event = "message" as const; seems to work.
This seems more like some "TS is not smart enough to infer that properly" than something we can do.

cloud nest
#

That's totally true, see the issue I referred to above. The enum is only a workaround to TS being incapable of figuring out the obvious on its own

outer raven
#

Would it be possible to create a latest pre-release with the latest commit from master and publish that to NPM so that we can more easily use that version? The website I'm currently hosting my bot on doesn't seem to support installing repositories as dependencies

remote wasp
#

That's not possible but you can fork the repo and publish your own fork of djs on npm under private scope

outer raven
#

How is it not possible? I've seen multiple packages do this

remote wasp
#

I don't know about that but publishing unstable changes doesn't sound like a good idea and it will also mess the versioning

outer raven
#

You can have a latest release that always gets updated with every commit to master and label it as a pre-release. This wouldn't affect the stable version and thus the version that would be installed through regular npm i discord.js

ornate topaz
#

which packages do that?
do they have breaking changes between commits that are published under that pre-release?

outer raven
#

Unfortunately I can't find one anymore but I remember seeing a pretty common package with a latest release on github and npm

outer raven
wild flax
#

Thought about it before already, decided against it

outer raven
#

Any reason why?

wild flax
#

Yeah, if we ever have some sort of hotfixes because our master isnt stable, we need to think about re-releasing it constantly

#

It's not worth it, you are much safer just pinning a commit that works

outer raven
wild flax
#

Yeah thats not really desirable for us

#

We don't want a new release on every commit

outer raven
#

Fair enough :/

real pilot
copper laurel
#

It's by design. Slash Commands are designed to be usable with a bot - headless functions running on CloudFlare workers for example

ornate topaz
#

*without

copper laurel
#

yeah ty, without a bot

real pilot
#

That makes sense, I just put a message in the interactions channel too, but is there a way to handle when someone adds your commands to a server even if they don't authorize the bot scope? Like a webhook, etc.? If so, can the library handle it and emit an event?

copper laurel
#

No, not in discord.js

ornate topaz
#

don't think there is a way to get an event for when someone adds an interaction without a bot

copper laurel
#

...unless it emits the ws event anyway?

ornate topaz
#

what ws event

copper laurel
#

well any of them

ornate topaz
#

i mean, there is intehration create, not sure if it's relevant

copper laurel
#

INTERACTION_CREATE, APPLICATION_COMMAND_CREATE etc

ornate topaz
#

but then again, if there is no bot, there is no ws

copper laurel
#

Yeah that I wasnt sure on, makes sense

ornate topaz
#

In many cases, you may still need a bot user. If you need to receive gateway events, or need to interact with other parts of our API (like fetching a guild, or a channel, or updating permissions on a user), those actions are all still tied to having a bot token. However, if you don't need any of those things, you never have to add a bot user to your application at all.
https://discord.com/developers/docs/interactions/slash-commands

wild flax
#

Thats not true

#

the WS event emits either way

ornate topaz
#

well, but if you don't have the bot app, you don't get the event (unless you connect to ws on your own, obviously)

#

and do you get the ws event from guilds you aren't on?

real pilot
#

Got it, makes sense. My app does still have a bot user since it needs it for some functions, but it also has commands that work perfectly fine without the bot user. What I'll just do is check each interaction, and if it needs a bot user it'll reply saying it needs additional authorization and send the oauth link for a server admin to fix it. Thanks guys!

lofty birch
copper laurel
#

@oak quail moving discussion
TextBasedChannel handles it like this

apiMessage = APIMessage.create(this, content, options).resolveData();
if (Array.isArray(apiMessage.data.content)) {
  return Promise.all(apiMessage.split().map(this.send.bind(this)));
}

So I guess reply with split would have to be

if (Array.isArray(apiMessage.data.content)) {
  const split = apiMessage.split();
  return Promise.all([this.reply(split[0]), ...split.slice(1).map(this.followUp.bind(this))]);
}```
#

Unless you can just send everything as a followup?

ruby terrace
#

You have to send a reply first (or edit the deferred reply)

copper laurel
#

I think followUp edits a deferred one, but if it can't send an initial it'd be this

#

If it's an editReply with split data they can all be followUps

#

...no nvm

ruby terrace
#

edits shouldn't take split options IIRC

#

followUp did edit a deferred one in the past, but I think that was for backwards compatibility, I think it has changed

copper laurel
#

So use case - deferring, then sending a split message

#

Can that be handled and if so how?

ruby terrace
#

It could be handled, but you'd run up on weird situations where there are messages in between

#

followUp should honestly be calling .webhook.send with the created apiMessage after data and files have been resolved, and Webhook#send line 172-174 should move outside the else statement

kindred lagoon
#

I really have a very huge bot and it is known as well and there is play sound when it starts the result is a very large pressure on the server so if you have a solution I will not reprogram it in c ++ language I am sure that you have a problem playing sounds so always the huge bots do not use your library

strange igloo
# kindred lagoon I really have a very huge bot and it is known as well and there is play sound wh...

discord.js voice is not designed to be the most powerful broadcast solution
If your needs are above the expected target, feel free to design your own solution or use an existing one (Lavalink for the most popular one)
There are no flaws in how discord.js handles voice features
Also, sending encrypted audio data will always require some resources (in CPU for the most) no matter if it's being made by discord.js or any other library/solution, so the issue of the pressure will stay as long as you don't split your bot logic and your audio between two machines, or if you don't upgrade your current machine resources.

kindred lagoon
real jetty
#

Would it be possible to make an auditLogEntry event for Client?

warped crater
#

No.

#

the client only has events for websocket dispatch packets that come in from Discord

#

there is nothing to signal audit log creation

real jetty
#

alright, i'll try to manually make it then

copper laurel
ruby terrace
#

you can, if you resolve the data and files in followUp, it will use that resolved data and files in Webhook send, it doesn't re-resolve

copper laurel
#

Hmmm fair enough, I'll take another look.

real jetty
#

Not sure if this has been brought up before, but something that would be really useful are hooks. Here is a use case:

When discord.js gets the users, you would have a $beforeUserLoad(UserManager) hook where you can inject your own data into users. Then if you have sharding, it would shard all the users with your injected data
It would be the same for guild, so $beforeGuildLoad(GuildManager)

ruby terrace
#

Extendable structures are discord.js's way of doing exactly that

real jetty
#

You can extend the structures but you cant add the data before it gets sharded afaik

copper garden
#

Wdym when it "gets sharded". When you shard, all events and results of api calls are sent directly to the corresponding shard process

real jetty
#

Essentially when all the discord users are cached, i would want to have a hook where i can make a request to my own api and map that data to users

copper garden
#

The only issue I see with that is that it’s async. Constructing/caching a user wasn’t made to perform async calls

#

Can’t you just fetch the data on demand?

real jetty
#

yeah i could shrug

quiet viper
#

I have a suggestion, regarding too the broadcastEval in the Sharding Manager, you should add a optional option, where the promise should be resolved/rejected after a certain time, bc when this does not happen --> we have to many event listeners and this could cause a memory leak

ornate topaz
#

imo such timeout should be there by default

quiet viper
# ornate topaz imo such timeout should be there by default

no there isnt, I can reproduce the error, go on worker mode, use a code which causes a dom expect error, broadcastEval(this.guilds.cache) --> error, no response.
Do this 10 times and voila, most of the machines will give a event listener error or crash

ornate topaz
#

what that has to do with my answer

#

i said "should" not "is"

#

in response to you suggesting there being one only if you pass the timeout time as the parameter

#

locking you out for no real reason if you forget to pass it

maiden loom
#

Hi, how can I download the v13 version ?

ornate topaz
#

there is no v13 version yet. you can however install the version from master branch, more info in #djs-help-v14

maiden loom
ornate topaz
maiden loom
ornate topaz
maiden loom
quiet viper
ornate topaz
#

i didn't say anything as to if it will be there or not. it was a suggestion

quiet viper
#

okay, sorry for the misunderstanding

clever spoke
#

it already does tho.... but just on master so i dunno if that counts

manic thistle
#

the typings for PermissionOverwriteOptions seem to not match the actual js implementation

unknown.png
#

wait whoops i forgot to put the typings, sorry

unknown.png
#

there's also this function which uses a completely different type in the options parameter?

unknown.png
remote wasp
#

that PermissionOverwriteOptions interface is defined in typings but isn't used anywhere. Whereas the typedef PermissionOverwriteOptions (plural) is defined as PermissionOverwriteOption(singular) in typings. weird 🤔

manic thistle
#

OH

#

actually nevermind, i didn't realize the definition was created in the same commit so it couldn't have been the parameters changing or something
it seems to have been a mistake that was added when the function was created and nobody really noticed lol

remote wasp
#

I looked through all of it and I think the current interface for PermissionOverwriteOptions (plural) should be removed from the typings (I searched it up, this interface isn't being used anywhere in the codebase) and the interface PermissionOverwriteOption (singular) should be renamed to PermissionOverwriteOptions so that it matches its jsdoc typedef. Just want to make sure that I'm not missing anything here. 🧐

manic thistle
remote wasp
#

that's fine but it doesn't solve the issue above

manic thistle
#

my bad
yeah, it seems like the interface PermissionOverwriteOptions was only used as a parameter for GuildChannel#overwritePermissions anyway, which was replaced by OverwriteResolvable (More specifically it was replaced by the interface OverwriteData, as it has the exact same properties, minus the new type property and the fact that allow and deny are now optional) so there should be no problem with it being removed, with PermissionOverwriteOption taking its place to match the documentation

ruby terrace
slate nacelle
#

Sounds good to me

oak quail
#

since members might not have joined_at now, should this be changed?

#

i suppose they still arent "full members" but it is a member object

manic thistle
#

I was inspecting the typings when I noticed the function Permissions#serialize returned the type Record<PermissionString,boolean> and that there was an interface PermissionObject (which wasn't used anywhere in the code) with the exact same type .
After inspecting the history of the function and interface, I found out that it was in fact previously used as the return type, but was removed (along with the function) when the Permissions class extended BitField<PermissionString> and later added back with this type.
Since these are the only two instances of Record<PermissionString,boolean>, should PermissionObject be removed?

unknown.png
strange igloo
manic thistle
real jetty
#

What is the point of removing timeout?

image0.png
raven juniper
#

Keeps it in line with other methods, also to prevent some problems that arose (eg if it was deleted before the timeout)

strange igloo
wild flax
#

No

#

The output isn't stable

#

And may change in the future depending on our needs

strange igloo
#

Oh okay

wild flax
#

If you want to parse an emoji, we do expose the regex itself on the class

#

to at least get the id

outer raven
#

@copper laurel do you know what the new buttons will look like? Asking bc of your draft pr

copper laurel
#

Yes

#

They look like other Discord branded buttons. Can be blurple, green, red or grey

remote wasp
#

Found this while working on the nsfw_level PR. Same issue there. When I move the property assignment inside #_patch it logs DEFAULT correctly otherwise it's just undefined

slate nacelle
#

It should be in _patch. Must have slipped through jynEHEH
Discord only sends unavailable guilds in ready, which we then patch with their relevant guild creates.
So only newly joined guilds would have that property set if it's in the constructor.

remote wasp
#

I see, I'll update the PR. Thanks 👍

real pilot
copper laurel
#

Not that I'm supposed to share

#

Sorry! Should be available soon

real pilot
#

Ah okay, I didn't know it was private info still haha

outer raven
#

They’ll probably be “released” on Tuesday

#

Why does CommandInteraction#channel have a Channel type instead of a text based channel type (TextChannel, NewsChannel or DMChannel, maybe ThreadChannel idk)?

copper laurel
#

Because it's a getter for this.client.channels.cache.get(this.channelID) which is a Collection<Snowflake, Channel>

#

And its inherited from Interaction

fringe star
#

Where can I post bugs?

solemn oyster
#

What bugs?

fringe star
#

.permissions doesn't work correctly

#

For some members

#

It returns bitfield 0

#

Even if they have certain permissions

#

I really need a statement on this, please

slate nacelle
fringe star
#

Ohk

fringe star
#

Can I send a reproducible example here

slate nacelle
#

sure

fringe star
#

I have almost all permissions still the bitfield is 0

#

This thing worries me when I check for permissions in certain commands

#

All checks return false

#

bruh moment

remote wasp
#

can you do npm list discord.js and send the hash here

fringe star
#

Ok

#

discord.js@12.5.3

#

This has been happening with me since months

remote wasp
#

Can't reproduce the bug on stable. You should open an issue like space said and it would be great if you can also drop a link to your bot's repo if there is one in the issue.

sleek apex
#

what's the point of this? can't we just have in ./DJSError.js's module.exports Messages = require('./Messages');?

Screen_Shot_2021-05-23_at_3.37.40_PM.png
wild flax
#

Circular references

sleek apex
sleek apex
#

also is my vscode broken or is the entirety of /src/errors/ used for nothing? oh nevermind i see now

#

im confused

sleek apex
#

wish me luck

vagrant holly
#

👋 Not sure if this got discussed anywhere, but it seems the lockfile in master is now v2, which is Node 15+ by default?

#

Node 14 still ships with npm 6 by default, and the project claims to be Node 14+, but if you actually want to develop on the project this is not the case and you need Node 15, or to manually update npm in your Node 14 install

sleek apex
#

most package managers ship the latest version (v16) and brew upgrades all packages whenever you run a command

wild flax
#

npm 6 can work with v2 of the lockfile, and the library still works with 14

vagrant holly
#

Off the top of my head, won't npm 6 overwrite the lockfile back to v1 if deps are modified?

wild flax
#

maybe

vagrant holly
#

Would it not make sense to at least define npm >= 7 in engines.npm in package.json?

wild flax
#

maybe

elder reef
#

Not sure where else to put this... the invite in the org's description is outdated

unknown.png
outer night
#

it still works

hallow ocean
#

Yes, it just doesn't use the vanity url so it's fine if it isn't changed

wild flax
#

Maybe refresh your browser

unknown.png
fringe star
remote wasp
#

yeah

gusty tide
#

Hey, apologies if this is the incorrect channel to ask such a question, but can someone here give me an idea as to when v13 is released, as it apparently has support for the new slash commands? Thanks!

real jetty
copper laurel
patent needle
strange igloo
patent needle
#

Ah alright

raven juniper
strange igloo
#

I meant that it hasn't been released in stable yet

grave tree
#

What gateway V is using djs v12

wild flax
#

7

grave tree
#

Oh ok

outer raven
#

I'd like to propose a change to the docs to make it so that the "Default" column in the parameters table displays the default value set by the discord API, even if the code itself doesn't have any default values. This way it would be easier to understand what would happen when leaving certain optional parameters out. Would this be a good idea?

unique axle
#

no, re-documenting things is almost always a terrible idea, because upstream docs changes could very easily make the information displayed wrong

outer raven
#

It wouldn't be re-documenting as the current docs don't link to the respective page on the Discord API docs

wild flax
#

our docs represent our wrapper, not the discord api

outer raven
#

what I'm saying is that currently it's quite hard to find the default value for stuff because most are left empty

wild flax
#

so the default values are the ones in our code, not from the discord api

outer raven
#

ye that's how it works atm, but why not change it?

wild flax
#

if we start mix-matching it it would become quite confusing

#

also we would need to keep it up2date with discords docs

#

thats also why we don't document what perms you need for certain actions

outer raven
#

wouldn't be too hard, I doubt they'd change values all the time and if they did it would be rarely

wild flax
#

what about the first point

outer raven
#

I don't see how it would be confusing

wild flax
#

how are you going to discern what default value is ours or theirs

outer raven
#

you're not because it doesn't really matter in the end

#

if you have a default value on the code, you use that on the docs, otherwise you use the one from the API

wild flax
#

yeah it does, we have functions and methods that have default parameters that have nothing to do with discord

outer raven
#

yeah I know that's what I'm saying

#

we'd prioritise the default values used in the code

wild flax
#

so how do you document 2 default values then

outer raven
#

you don't, you just document the one used by the library

#

because that one will always have priority in the code over the one the API uses

wild flax
#

and what happens to the one the api uses (just in case they are different)

#

now you decide arbitrarily what to use when

outer raven
#

it's ignored because from the moment you have a default value in the library, the default value given by the api is ignored

wild flax
#

"oh no this isnt a default from discord, this is ours"

#

"oh no this is a default from us, not discord"

outer raven
#

it doesn't matter to the user, they just need to know what value is gonna be put there if they don't specify that parameter

#

and we'd put the one with the highest priority

wild flax
#

yeah, the user can just open the discord api docs too for that

outer raven
#

which is library > api

#

yeah but the discord api docs are way harder to navigate than the djs ones and its easier to have it all in one place

#

because saying there is no default value is essentially misleading because the result you will see on discord will have a default value

wild flax
#

its not misleading

#

we don't claim that the discord api doesnt have defaults

#

its just that we don't have any in the library

outer raven
#

yeah but if the library is an API wrapper, it should also document what the API does in certain situations

unique axle
#

hmm.. no

wild flax
#

no, not really

#

thats what the API documentation is for

outer raven
#

but it's easier to have everything in one place

wild flax
#

yeah, thats fair

#

doesn't mean we are doing it

outer raven
#

why not make the docs more accessible instead of telling users to go search in a million places?

outer raven
wild flax
#

the docs are plenty accessible

#

downgrading their value simply because we don't do this one thing doesn't make them any less good

#

we still have, to this date, the best auto generated library documentation

outer raven
#

that is true but there's always room for improvement

wild flax
#

improvement is great, more things to maintain is not

outer raven
#

If any default value changes, people will most likely hear about it quickly from the discord staff themselves and make a PR to change it

wild flax
#

just like how interactions were released and we needed 2 PRs for it and a 6 month delay right?

outer raven
#

I see PRs changing little things that the API changed all the time

wild flax
#

I can't imagine that for something thats even more hidden and less important

outer raven
#

and I don't think that delay was because people didn't know about them

wild flax
#

I say that specifically because interactions could have been done in a 2 week window

#

No, it was because no one was simply doing it. We don't get a lot of contributions for things the API changes

outer raven
#

but their release was also quite weird and a lot of things changed

wild flax
#

That was also not the reason, this discussion is pointless overall

#

As it stands right now we arent doing it

outer raven
#

fair enough I guess, I'd be willing to do it if you change your mind in the future

outer raven
#

you can technically put any type on an embed description but objects and maps will look weird and I doubt people would want to put that intentionally so would it be possible to change the embed description type to string | number | string[] | number[]? It's currently set to any

ornate topaz
#

the fact that they look weird doesn't mean that they can't be passed

outer raven
#

Yeah I'm saying they can but no one would want to put [object Object] in an embed description and it would help them identify errors if they do this accidentally (in TS of course)

ornate topaz
slate nacelle
outer raven
#

that's different because message.member.toString() exists

outer raven
ornate topaz
#

well, so why not add all other variants like GuildMember | User | Channel to that huge type as well

outer raven
#

you don't need to because it runs toString() automatically

ornate topaz
#

but your type would mean that it cannot be passed there at all

#

i didn't pass a member.toString(), i passed member

outer raven
#

but since the toString() function exists, I think ts doesn't detect that as an error

ornate topaz
#

which type are you talking about

#

the param to setDescription?

outer raven
#

yep

ornate topaz
#

why the hell would it care about completely random properties on passed object if the object itself doesn't fit

outer raven
#

the only reason why it throws an error is because of the number type, but it is assignable to a string type

unique axle
outer raven
#

wdym?

#

is that gonna change?

unique axle
#

space literally linked it

outer raven
#

I didn't see that it would require you to run the function

unique axle
#

we aren't doing any string conversion for you anymore, you have to actually provide a proper string (once that lands)

outer raven
#

why tho :/

ornate topaz
#

you can't really do const x: string | GuildMember and use x only as a string. if x would be GuildMember, it would require you to call the toString() manually every time, it won't call it for you.

#

it doesn't matter that it has a function to resolve into string

#

it literally isn't a string

outer raven
#

it does though

#

I just tested it

ornate topaz
outer raven
#

yeah it doesn't do that

#

it only conflicts with number, not string

ornate topaz
#

what doesn't do that

outer raven
#

if you have a string type and pass a GuildMember, it works

ornate topaz
#

what works

outer raven
#

passing a GuildMember object

slate nacelle
#

Yes, because we forcefully resolve everything you (don't) pass into a string.

outer raven
#

yeah and TS doesn't detect that as an error

#

so its all good

#

but it still won't work due to the number type, which is stupid

#

and for some reason passing a number to a string errors

ornate topaz
#

am i missing something

unknown.png
outer raven
#

hmm I didn't test it like that, I modified the StringResolvable type to string | string[] and it worked

ornate topaz
#

the c literally isn't a string, otherwise the type would be useless

#

so anyway, the method works (atm) because it resolves

#

but you narrowing the type from any to your string | number | string[] | number would mean that you cannot pass anything that you currently can

outer raven
#

yeah I know I believe that would be benefitial

ornate topaz
#

if the change that requires strings lands, yes

#

right now? not really, as the method handles passing some objects (some as in literally anything that has a toString(), so pretty much everything)

#

technically needing to list them all in the type

unique axle
#

since the type is literally going into the bin, i'm not sure what to improve about it and why

outer raven
#

well yeah i wasnt aware

#

thanks for the explanation

remote wasp
vivid field
#

Looks like another remnant of the webpack build support

remote wasp
#

hmm, that's what I was suspecting too, just wanted to be sure. Thanks 👍

haughty anchor
#

Any word on when library will be brought in line with button update?

unique axle
haughty anchor
#

Thanks sorry

wild flax
#

It’s maybe been 24h since release. At least a little bit of patience would be appreciated

haughty anchor
#

Im not trying to hurry anyone I was just wondering what the general timeframes are normally like, this is the first API change that will actually affect what I work on for the time being

#

The activity on that PR is nuts

#

Is better news than I was hoping for

copper laurel
#

I've just marked it as ready for review and testing now

haughty anchor
#

Yeah i saw you are a madman

copper laurel
#

There was a lot of base structure and classes to be built - but it should make future components a lot easier

haughty anchor
#

Thankyou for your service

loud jayBOT
copper laurel
#

Buttons are now ready for review and testing, but may not be stable

fair yarrow
#

nice

copper laurel
#

Just pushed breaking changes to it, FYI anyone already using it

sage owl
#

To someone who actually works in the industry, “When it’s ready” is such a cop out response. It allows Scope Creep to become a real problem which v13 is starting to show signs of. So I think many of us, who are relying on new features being implemented, would like a little more effort in that part of the department. We understand things come up and things get pushed back but no reason to set goals for your releases. Setting Target dates is important in any software lifecycle, especially when people actively use your codebase and count on these new features. Anyway, this is just some words of advice from someone who works in the industry as a Software Engineer. Take it or leave, ignore if you like.

real jetty
#

A key thing to keep in mind is that you can still use it if you really want it. Installing from master does work and you can choose from which commit.

manic zinc
#

@sage owl have you considered using your professional experience to help move the project forward so it gets done faster? I'm sure the team would appreciate the addition of a Software Engineer helping out on the project!

outer raven
outer raven
#

Also for the server avatar feature, should the guildmember object have a displayAvatarURL() function or just the avatarURL() and avatar properties?

copper laurel
#

What would the defaulting be

#

Server avatar > Global avatar > default Discord avatar?

fair yarrow
#

monbrey

#

attaching Imge file in embed in interaction response won't work

ornate topaz
#

Fairly sure it's on API on this one, someone brought that up before

#

@outer raven typescript also doesn't follow semver, but that's different topic

fair yarrow
#

Ohk

#

but can i attach files on interaction reponse

copper laurel
#

Only in the edits

#

Dunno why

copper laurel
# sage owl To someone who actually works in the industry, “When it’s ready” is such a cop o...

We know we have a huge community that are excited for new features to be released, but Evie is right. A lot of the staff, myself included, and particularly the maintainers are professionals, we do work in the industry - that's exactly why we don't have the time to manage this like some sort of enterprise scale product.

We don't have a dedicated testing team, we don't do sprints, and the majority of the people who use the library are, to put it bluntly, amateurs. They don't understand how to handle semver major breaking releases.

That ties into a lot of decision making around what goes into a major release, how we can be prepared to support it (eg v13 changes guide) and ultimately, when we are ready to release it.

I get that "when it's ready" might seem flippant and dismissive, but setting a date that we don't meet is pointless. Alternatively pushing out a buggy mess that hasn't been properly tested just because a date was set is even worse.

fair yarrow
#

oh k so no way to attach a file nor show in embed

solemn oyster
#

Also keep in mind Discord also likes to introduce breaking changes from time to time, which screws our release cycle at times

#

@fair yarrow you might want to use the support channels for this, this one is reserved for discussions regarding the library

echo fog
#

when will message components be implemented?

solemn oyster
#

There's a PR for it

echo fog
#

ah

#

nice

clever spoke
#

?buttons

rich iglooBOT
clever spoke
#

worked on there

echo fog
#

epic

fair yarrow
outer raven
#

I made the PR meanwhile and added the display avatar url method which sends the server avatar or the user’s display avatar

outer raven
ornate topaz
strange igloo
#

Major . Minor . Patch*

#

Major for breaking changes
Minor for features
Patch for bug fixes basically

strange igloo
wild flax
#

Very unlikely

outer raven
#

I don't see why they wouldn't be able to

wild flax
#

What lol

strange igloo
#

Since it's going to be restricted to their $10 Nitro apparently, I don't think they'll allow that

wild flax
#

Can’t wait for some mods to set my image to something I don’t want

ruby terrace
#

I'd find it unlikely they unlock that feature to bots

wild flax
#

You really can’t see how this isn’t abuseable?

ruby terrace
#

while those "self host" bots would love it, that type of data storage for large bots seems like a bad idea

wild flax
#

Oh, the idea of the bot having one

#

Puh.

outer raven
wild flax
#

Not even sure that’s smart

outer raven
wild flax
#

I can totally see someone setting a different avatar on their 300k guilds

outer raven
#

well yeah

ruby terrace
#

yeah....that

wild flax
outer raven
#

yeah true

#

well ignore that comment then lol

strange igloo
#

About Nitro perks for bots, I don't think they'll grant perks from the $10 one
Not even sure if they might allow any more perk from any of both Nitros (well yes animated avatar is an example)

copper laurel
#

bots have global emojis

#

No other nitro features

tacit crypt
#

IIRC they get upload limit based on the guild's boost level

ornate topaz
#

like every other member of that guild, so irrelevant

oak quail
#

any chance of changing CommandInteraction#options to a collection with the option name?

copper laurel
#

I dont think discord enforces uniqueness

real jetty
#

The options are send in order as you'd expect them, so i appreciate the array here

copper laurel
#

oh it does enforce

remote wasp
#

It's much better to work with collection, so if it's possible (which it should as names are unique) I'm all in for this 👍

strong heath
#

will we have buttons with author only funtion?

tacit crypt
#

Buttons are added just like discord did. You can handle author-only buttons yourself

outer raven
#

Is it possible to link a method in the docs by using (for example) {@link User#displayAvatarURL}?

wild flax
#

youd use @see for that

#

just search the repo for it

outer raven
#

talking about something inside a sentence

#

@see is a parameter in jsdoc

wild flax
#

in a sentence probably not

outer raven
#

oh I found it somewhere else, seems like it is possible

obtuse hazel
#

Why does d.js don't support editing an attachment?

wild flax
#

If your question is why we don’t support a certain feature, the answer is most likely because no one PRd it yet. This doesn’t only apply to this, but pretty much every “why doesn’t d.js support this”

copper laurel
#

But we do support it don't we? That PR was changed to allow you to edit with a new attachments array

ruby terrace
#

haven't tested it, looks like it should be possible, but the jsdoc string needs edits if so

remote wasp
#

@real jetty You still haven't explained why are you confused about #5705. If you have any questions about it then ask. Your reaction just made others to react too without leaving any meaningful feedback. So, It would be really helpful if we can discuss what needs to be changed in the PR using words

obtuse hazel
#

Oh well it'll be hard to answer if you don't ping me

remote wasp
#

@obtuse hazel How am I supposed to know you're not using your main. Anyway, that's not the point here. So, what is it that you found to be confusing?

obtuse hazel
#

I removed it, as I thought it would be annoying if the order matters but you can still convert it to an array and the order will be the same. Sorry for this

tender surge
#

const user = await message.client.users.fetch(userId)

user_id: Value "a b c" is not snowflake.
would it be an idea to provide a isSnowflake utility function when dealing with user input?

loud jayBOT
tender surge
#

Hm alright thanks

outer raven
#

What do you guys think of the idea of adding a type called TextBaseChannel and VoiceBasedChannel so that we don't have to update our code so often when a new channel type is added

#

TextBasedChannel would be TextChannel, DMChannel, NewsChannel and (soon) ThreadChannel, while VoiceBasedChannel would be VoiceChannel and StageChannel

#

would only affect typescript users of course since only the typings would be changed, no actual code changes

ornate topaz
#

isn't that what isText() does

outer raven
#

that's not what I wanna do though, I wanna set the type of a channel when fetching it or something similar

#

instead of doing as DMChannel | TextChannel | NewsChannel I'd do as TextBasedChannel

ornate topaz
#

when you fetch, you don't do the first one at all, library does it for you

#

and what would that TextBasedChannel even be? a type union? that still doesn't solve the problem of having to check if it's a dm or not, or if it's a specific type

#

not sure what would even be the use case for such thing. isText() can be used to somewhat narrow the type to channels you can for example send to. sure, there isn't stuff like isGuild or isDM but you can check that yourself with one line (and if done properly, also narrows the type further)

outer raven
ornate topaz
#

...and what exactly would be the benefit?

# 
  property 'guild' does not exist on type DMChannel | TextChannel | NewsChannel | ThreadChannel | WhateverElseChannel
    property 'guild' does not exist on type DMChannel```
#

if you are fetching/getting by id, you can literally just cast to a correct type already.
if you are requiring a user input for an id, you can either assume that if you ask for "log channel" you didn't get a voice channel, or just check while you're in that form, and then just have only TextChannels anyway

#

there is 0 point in casting it to multiple types and then complaining that it has multiple types

#

and your union would be exactly that - multiple types that are just a fairly big subset of a Channel, and still need narrowing

#

true, there is a hassle every time new channel type is added, but there's nothing stopping us from adding the type, especially considering both how infrequently new types are added, and that it's almost sure that new channel type will have new features that would have to be added anyway

outer raven
#

It's as simple as adding any new channel types to the proper type declaration and updating them as new ones are added.

ornate topaz
#

and what would be the use case for such type

copper laurel
#

I still don't see how this is different to isText(), which asserts that the generic Channel is one of the three. Type guarding functions are better than casting wherever possible. If the argument is for a way to easily cast what a guard already does for you, I don't agree

keen cosmos
#

Sorry for my review, I thought we used flatMap elsewhere as well, should've checked first

copper laurel
#

No worries, it was worth looking at because I forgot it existed

wild flax
#

@remote wasp im not a huge fan of this pr

#

because we slowly want to migrate over to discord-api-types

#

how were the types imported? and what was the error?

remote wasp
#

yeah, I also don't like this fix myself but the issue can't be fixed without it.

remote wasp
#

It's like djs doesn't even export them

#

I have reloaded VSCode and have the latest commit installed (that re-exports the snowflake)

slate nacelle
#

Maybe we should export all of those interfaces and everything that's actually exported then.

remote wasp
#

yeah that could be a fix that I was thinking too but I had a question in my mind too, which is:

#

There might be a correct way to re-export types which might fix it but one thing that I don't get is, why are we re-exporting Snowflake. We use a lot of other typings package like for node, ws and other but don't re-export anything. The end-user installs those for themselves and use it. Shouldn't they install discord-api-types and import Snowflake from it?

ornate topaz
#

couldn't that be explained with the fact that snowflakes are basically the most common thing you use to interact with library?

#

wouldn't make sense to make a type for getting stuff from every single collection/manager and not reexport it in the lib

#

for the node typings, im fairly sure almost every project installs those anyway, and i think ws ones changed from being required to install manually to being installed by lib

wild flax
#

it depends

#

usually yes

#

I would agree if it wasn't such a common type

#

also uh, it doesn't look like the Snowflake export is at fault here then

#

if we don't export those interfaces, you usually can't import them. I have no idea why it worked before lol

vivid field
#

Because we use declare module

wild flax
#

whens your PR making a return

vivid field
#

I can do it now ¯_(ツ)_/¯

#

That'll break basically every other pr though

#

Or at least the ones that touch typings

wild flax
#

yeah we prolly want buttons first then

#

and then your pr

worthy coral
unique axle
#

yeah! discord can also randomly send typing events to voice channels

worthy coral
#

That is very strange. I've never heard of that or experienced that before. (probably just lucky?)

wild flax
#

If you use a library it won't really happen to you

#

But if you use the raw api it can for sure happen

#

and you need to handle it

worthy coral
#

Working on my own and taking inspiration from Discord.js which is why I asked. I will definitely keep these in mind, though. Very helpful to know

unique axle
#

this is the type of thing you find out when it happens, you investigate the issue, nothing makes sense, you ask very carefully, because it's a horrendous question and then get
"oh yeah, you need to handle this" as response kek

worthy coral
#

Not fun so far. Send help hidethepain

copper laurel
ruby terrace
#

I'm adding guildID to many of the methods in ApplicationCommandManager rn so you can manage commands on guilds that don't have a bot user / aren't cached and I was noticing something.
Would it be desirable to turn all of the manager#fetch method parameters into an object (for those applicable, still accepting resolvables as the only parameter) for consistency?

Current managers that use this structuring are ApplicationCommandManager (with my PR, and therefore GuildApplicationCommandManager), GuidBanManager, GuildManager, GuildMemberManager, ReactionUserManager
Those that do not and would be changed: ChannelManager, GuildEmojiManager, MessageManager, RoleManager, UserManager

copper laurel
#

You mean like MessageManager#fetch({ message: MessageResolvable }) or something?

#

Because I really hate that

ruby terrace
#

No, it would still take bare MessageResolvable, but if you want to not cache or force, you need { message: MessageResolvable, force: true }

#

granted, it could be fetch(message: MessageResolvable, options: BaseFetchOptions )

#

or something

copper laurel
#

okay that I dont hate

#

the second one

#

fetch(message: MessageResolvable, options: BaseFetchOptions)

ruby terrace
#

yeah, okay, need to change some of those other ones to follow that style then too, but I think that would be better for consistency

hushed sedge
#

Idk if suggestions are allowed here, its the most relevant channel i could find

wild flax
#

We aren't discord.

#

We have no control over what is allowed and what not, or what will be.

hushed sedge
#

Oh, alright. I didnt know that.

#

well i knew that

#

but i thought you had the ability to change what you could send

#

to an extent of course

copper laurel
#

You probably can send it, and then the API will reject it or the Discord client wont render it

hushed sedge
#

I see. Thanks for clearing that up.

copper laurel
# 
public on<K extends keyof ClientEvents>(event: K, listener: (...args: ClientEvents[K]) => Awaited<void>): this;
``` This change to use `Awaited<void>` in the Client event listeners effectively prevents you from returning anything from the function, eg
```diff
- return message.channel.send("..."); // will error
+ message.channel.send("...");
+ return;``` Is this intentional, and required for some reason? Could we not do something more generic like `Awaited<unknown>` because it doesn't matter what a listener returns (or does it)?
ruby terrace
#

Hmm, EventEmitter doesn't care about return values, in fact there is no way to get them. The @types for EventEmitter define it as void, but I do think unknown would be better.

solemn oyster
#

If return message.channel.send("..."); were to throw, you'd get a stack trace, but not the async part, because the caller (EventEmitter) isn't asynchronous

copper laurel
#

Okay, cool, thanks

solemn oyster
#

np

strange igloo
#

Shouldn't the library prevent methods such as VoiceChannel#join to be executed if the client has not subscribed to the required intent? Or complete documentation by saying "to use this method, you will need to subscribe to that intent"?
Several people have been running into issues related to these (the example I have in mind is VoiceChannel#join throwing connection timeout).

wild flax
#

Probably not, no.

#

We don't do it for anything else.

slate nacelle
wild flax
#

Perms yeah, but we never check for explicit intents no?

slate nacelle
#

No, those didn't exist back then after all.

#

Point is to avoid timing out, since that's a poor (and slow) error.

remote wasp
#

yeah, the error takes 15 seconds to throw. We can make it quick by checking for the required intent (GUILD_VOICE_STATES?) in the VoiceChannel#join and throw if not found. We do check for intents while logging in so I don't know why we can't do this too. Now this takes me to the question:
Why do we set ClientOptions#intents to the resolved bigint instead of an intents object?

slate nacelle
#

I don't think there is a reason for that.

remote wasp
#

hmm, then we should make it an intents object, then we can easily check whether the intents user chose have an intent. Currently we will have to make a new intents object from the bigint everytime we wanna check

wild flax
#

I'm not sure if checking for specific intents is the right path here.

#

Theres a fine line between good user experience and "well thats kind of your own fault, the vacuum cleaner won't put dirt into the bag if you dont have a bag"

#

It will still turn on however, and leave a big mess

remote wasp
#

yeah, I understand. It would have been the user's problem to fix if the error would be quick & clear but it takes 15 seconds for the error to throw and on the UI side the bot still shows in the VC. The error also doesn't help: "cannot make connection within 15 sec...something..." Which mean that the user has no idea what's causing it

wild flax
#

Also its a bit problematic, because technically speaking we want to move away from our internal voice code anyway and mostly delegate things to @discordjs/voice

#

Where you can handle those errors a lot more gracefully yourself or even increase the timeout (in case it really takes longer to connect)

#

There is technically speaking nothing stopping you from waiting 30s or however long you want, we just assume 15s as a default currently

ornate topaz
#

but doesn't that still not touch the topic of intent at all?

#

does the new voice know that there is no intent and throws due to that?

#

or at least mentions that in timeout error

wild flax
#

Yeah it does not.

#

Mentioning it would be an appropriate step I could get behind. Maybe something generic as "Check if you have the correct intents enabled" or something.

#

So we don't lock ourselves into a specific name (though I am not sure how careful we need to be with this. Realistically speaking discord hasn't changed any names on us so far that are problematic, apart from MANAGE_ROLES I think, that used to be named differently)

ornate topaz
#

additionally, how far is new voice from being added? if there is code that has to be removed from library anyway, i don't see many reasons to not add such mention in current error (unless of course that would count as semver major)

wild flax
#

Adding /voice to d.js is a minor (even while keeping old code), so its debatable

#

Only the removal of the old code would be a major

#

Thats why I am unsure if v13 or v14

#

Since /voice can be plugged into v13 easily already

#

Even as 13.1

real jetty
#

Why is CommandInteraction#isCommand only function?

ornate topaz
#

?

remote wasp
keen cosmos
#

He may be wondering why it's not a getter when it easily could be, but I believe that's due to TS assertions can't be getters

sharp wigeon
#

Are there any plans of -next yet?

#

Submitted a pr a while ago, but was blatantly copying some of the types from the current version of discord. I understand that it would be a rewrite of discord js (if I’m not wrong), but how?

copper laurel
#

The benefits of rewriting it fully in TS is to leverage much more than just types, especially copied ones. We can do better inheritance, application of interfaces, dependency injection, all sorts of stuff.

keen cosmos
#

it can also better allow for division of packages for both microservicing and monolithic packages, though I'm not sure this is an idea d.js maintainers want to embrace

copper laurel
#

We are, if you look at the structure of the repo

mighty sequoia
#

how / where are tests run?

#

i see the test/ folder, but past that I can’t find anything

wild flax
#

There isn't much testing since all we do is pretty much running against the discord API and mocking that is quite the nightmare

#

So we are pretty much on-par with other API wrappers in other languages with that

oak quail
#

oh options is a collection now nice

subtle oxide
#

do you guys think discord will ever add video-in-embed support?

#

like an inserted video

wild flax
#

It doesn't really matter what we think lol

#

But considering they didn't for the last 3-4 years, unlikely.

kindred yoke
#

i want to help with library dev, but idk where to begin with understanding how the library works (ik how the underlying discord api works, but i want to understand how the library implements this api)

#

where should i start?

copper laurel
kindred yoke
#

alr cool ty

wild flax
copper laurel
#

Hmm yeah I guess. Project is fully open source, but the internals are not well explained lol

outer raven
#

why don't you guys use CODEOWNERS instead of having someone request reviews from others when a pr is made?

copper laurel
#

Because the same four people who need to review would be the code owners anyway

#

They generally review anyway, the requests are more like "hey I want to merge this soon, you need to review too"

outer raven
#

It usually doesn’t happen that soon tho and you could just set those 4 ppl as codeowners for the entire repo

amber ridge
#

someone can say me why types/ws is on dependecies and not in devDependencies? ||sorry for the mention, discord goes crazy with the @ ||

unknown.png
vivid field
#

Because people were complaining that they had to install it manually when using typescript

amber ridge
#

:weird:

#

Okay

solemn oyster
outer raven
solemn oyster
#

It's fine

ornate topaz
#

except this isn't really project like typescript where you have tens if not hundreds of people looking at the code

solemn oyster
#

And IMO using codeowners for that feels like using a tool for it's unintended purpose, to gain one of its intended features

outer raven
#

unintended purpose? why

solemn oyster
#

Because even if we're the same 4 reviewing (almost) all PRs, we're not the code owners

outer raven
#

well no one's gonna come after you for that xD

wild flax
#

Yeah but it’s not reflective of the “owner”

outer raven
#

eh fair I guess

wild flax
#

@remote wasp your PR actually seems to work but breaks in the IDE 🤔

#

actually no, its not your PR, all good

outer raven
#

Can someone run the publish action so that the latest commits are uploaded?

wild flax
#

yeah will do

outer raven
#

Thanks :D

remote wasp
zenith oracle
#

If you want to set a param as optional you can add square brackets around the param name but if you want to use the type null you need to add it manually (e.g. string | null)

remote wasp
#

yeah, that's what I was going for

#

@vivid field We have a problem here blobStare

vivid field
#

Seems to be a docgen bug then ¯_(ツ)_/¯

#

{?type} should be universal

#

But in the meantime you can change it i guess

zenith oracle
#

Btw there aren't any params null in discord.js other than this Message#edit 😂

ornate topaz
#

fairly sure that's how you remove embeds in edit, at least on stable

zenith oracle
#

Ye I saw

#

I think there should be something else to remove embeds

late iron
#

Is there a library to implement buttons? Some devs made a library for buttons but it's only for python (discord.py) so I was wondering if there was anything similar for discord.js

clever spoke
#

theres a pr

rich iglooBOT
late iron
clever spoke
#

pull request

late iron
#

oh ok

#

I will take a look at it

outer raven
#

Would you guys like to change the default options for image URLs in the future so that the format defaults to png and dynamic to true? I feel like it makes more sense for it to be this way as png is a more easily readable format, and people usually want their images to be animated if they are. There might be a reason it's this way though so I'm not sure

solemn oyster
#

No, we try to stay as close to Discord as we can

wild flax
#

Our default of webp already allows that

#

webp supports static and animated

solemn oyster
#

Discord uses webp mostly because it's more optimised than png

outer raven
outer raven
solemn oyster
#

It is, to both of the affirmations

#

webp is something Google created for web, why would it not be supported in Google's browsers?

ornate topaz
oak quail
#

imo the defaults should be format: webp and dynamic: true

ornate topaz
#

isn't webp problematic on "certain platforms"

copper laurel
# oak quail imo the defaults should be format: webp and dynamic: true

This was discussed before - if those were the defaults, what should specifying format: "png" do to the dynamic param?
If it forces png format, then dynamic isnt always the same default - undesired
If it is still dynamic, then the format you passed isnt guaranteed - a little better because you'd have to override both defaults, but still undesired
Since neither of these was ideal, was decided to keep the existing defaults

#

That way - you always get the format you ask for, unless you choose for it to resolve a gif if possible

solemn oyster
ornate topaz
#

do .webps finally display in discord app? woah

remote wasp
#

Shouldn't the gen-esm-wrapper be run on commit? People who install from master and use import/export won't be able to run djs as there is no index.mjs in the repo now. If doing so might create a big diff then is there a way to run it when the user installs from git. Is that what prepare is for?

vivid field
#

That was a concern at first but it was resolved by the dev publishes to npm we have now

remote wasp
#

I see, it won't be a problem for most people then but still does the dev get published on every commit or after some interval?

vivid field
#

It's published every 12 hours

wild flax
#

Or manually if need be

remote wasp
#

It might become an issue when we want to test something really quick after a commit tho. Why is the interval, some kind of npm ratelimit or what?

#

rn I'm running the gen-esm-wrapper inside the installed djs folder blobStare

wild flax
#

Yeah it’s not worthwhile to “test something real quick” for the majority of people

#

If you need to do it, obv you can just run it manually

#

Which is a fair trade I would assume

wild flax
remote wasp
#

right, makes sense neptuneWink

mighty sequoia
#

How long on average does it take for me to get a review on a pr after someone requests it from someone else?

mint flint
tacit crypt
sleek matrix
#

they've already talked about what's new in the new version of "discord.js v13" or what we'll need to change in our apps so we can run on lib v13?

zenith oracle
#

?v13

rich iglooBOT
#

Version 13 is actively being developed on the #master branch. To test new features and see what's being worked on, check the pins in #djs-help-v14

zenith oracle
sleek matrix
#

Ok

copper laurel
#

That guide is missing things

devout relic
#

@zenith oracle look damn nice

#

are they using docz

#

for discord.js

copper laurel
#

I don't understand your question

mighty sequoia
copper laurel
#

Just put part of it on a new line?

mighty sequoia
copper laurel
#

I think so yeah

mighty sequoia
#

Ah cool, all tests passed, ty

copper laurel
#

They run automatically

wild flax
#

Not for new contributors

mighty sequoia
zenith oracle
remote wasp
#

It's Vuepress, if you're talking about guide

ruby terrace
#

For PR https://github.com/discordjs/discord.js/pull/5695 if it is merged, I think we are at the point where permissions should get there own manager, accessible via ApplicationCommandManager#permissions (GuildApplicationCommandManager#permissions for that PR ) and ApplicationCommand#permissions although this manager would be without a cache. I think it would fit better within the rest of the library structure. As a side benefit, it would help 5729 out immensely as well. Any input on this?

radiant glacier
#

do you think they would make a small change to v11? Since stage channels were added, it now throws an error which can be easily solved by doing an if check inside one of the djs files

#

node_modules/discord.js/src/client/ClientDataManager.js:81:9

Before:

guild.channels.set(channel.id, channel);

After:

if (guild) guild.channels.set(channel.id, channel);
#

it's not that important, just a bit annoying

remote wasp
#

Just to be clear, you want bug fix for djs v11 here?

wild flax
#

v11 has been unsupported for almost over a year now.

#

Good luck.

radiant glacier
#

I know I'm pushing my luck, but thought I'd ask anyway. Don't know if I don't ask

remote wasp
#

can't happen, only fix is to upgrade

radiant glacier
#

yeah unfortunately v11 is the best lib 😦

wild flax
#

v11 will stop working any day anyway.

#

Once Discord decides to shut down the v6 API.

#

You refusing to upgrade only contributes to your bot being offline forever.

radiant glacier
#

v12+ doesn't have what v11 has

#

if you get what I mean

wild flax
#

Yeah it does and more.

radiant glacier
#

I do prefer v12

solemn oyster
#

Then why are you on v11

radiant glacier
#

but it's not possible to use for certain things

wild flax
#

You can prefer whatever you want, it will stop working lol. Is that so hard to understand.

#

It's literally out of our control and your bot will stop working.

radiant glacier
#

yeah I'm aware of that

#

and prepared

solemn oyster
#

v11's codebase is ancient, and many of us contributors just don't want to maintain it any longer

wild flax
#

You should have been prepared over a year ago, because v12 will be deprecated soon too and v13 will be released.

radiant glacier
#

I heard it was getting shut down last year but its stayed open for a long time

wild flax
#

So your v12 update will be out of date too.

solemn oyster
#

v12's and v13's internals are a lot cleaner and superior (async stack traces ftw), as well as pretty similar

#

That being said, what are those things you claim v12 can't do, that v11 can?

radiant glacier
#

it should be pretty obvious

#

but like

#

if I need to spell it out for you

manic zinc
#

It's not obvious for anyone.

wild flax
#

We maintain this library, so we would know.

#

Thats why we ask.

radiant glacier
#

👨 🤖

manic zinc
#

Oh you mean you want to keep breaking the terms of service??? Good luck with that.

solemn oyster
#

This is precisely one of the reasons why we can't and don't want to maintain v11, we can't support code that breaks Discord's Terms of Service

radiant glacier
#

that's what I meant when I said I prefer v12

manic zinc
#

You will not get support for breaking the ToS with any library that is allowed to exist on Discord's API.

radiant glacier
#

I never said I was using it

manic zinc
#

You're implying it extremely clearly.

radiant glacier
wild flax
#

So why do you want us to patch v11?

#

I don't follow

manic zinc
#

Do you have any legitimate example?

wild flax
#

If you don't use it, it should not be of your concern what errors it throws.

manic zinc
#

when your only justification for using a year old unsupported version is "I wanna break the ToS". blobguns

gloomy bluff
#

Would it make sense for embed setters to have optional params

ornate topaz
#

wouldn't that mean that they default to something?

gloomy bluff
#

Default to null/empty as if they weren't used
Right now they are marked as mandatory so if you have a function that returns string? you have to do something like
embed.setThumbnail(user.displayAvatarURL() ?? '')

#

in TS

ornate topaz
#

well, not really

solemn oyster
#

They absolutely allow null and undefined, iirc

gloomy bluff
#

I looked at the code and the jsdoc params are mandatory

#

So TS compiler complains

ornate topaz
#

param being mandatory and param allowing undefined to be explicitly passed are 2 different things

gloomy bluff
#

if you don't OR it with an empty string

vivid field
#

You can also do .stuff()! instead of .stuff() ?? ''

#

But shouldn't it allow null anyway to remove a value?

strange igloo
#

I see the point, but that's against the logic
You say setX on some embed, it means you want to set something
If you want to setX only when some condition are met, it's up to you to put your code inside some conditional statements in order to let it run only when it can

For user avatar as an example, it's as simple as

if (user.avatar !== null) embed.setThumbnail(user.avatarURL());```
gloomy bluff
#

Alright

outer raven
#

Would it be possible to update the typings for ApplicationCommandData#options to specify that, if a SUB_COMMAND or a SUB_COMMAND_GROUP type is specified, all other types are invalid?

#

So basically this would throw an error

[
  {
    name: "test",
    description:"A sub command",
    type: "SUB_COMMAND"
  },
  {
    name: "parameter",
    description: "This is wrong",
    type: "STRING"
  }
]```
#

Either that or something in the documentation could be added to warn users about this, since discord will throw this error

ornate topaz
#

if discord throws the error, and the error is descriptive, why would we mention that

outer raven
ornate topaz
#

i wasn't talking about typescript

outer raven
ornate topaz
#

you were talking about 2 things

#

typescript, and docs

outer raven
#

either update the typings or add a warn in the docs

#

those were my suggestions

#

bc idk if updating the types to say that is possible

sharp wigeon
copper laurel
#

I don't quite understand your question - the PR shows you exactly what properties they'll have and where

outer raven
#

it's waiting for Discord to deploy this to all users and then it'll be merged

loud jayBOT
smoky thunder
#

is there a contributing guide for @djs/collection or does it follow the same one the main lib uses?

wild flax
#

Yup

fathom aurora
copper laurel
#

already have

fathom aurora
#

as in, in djs v12?

copper laurel
#

no, in v13

#

the in-dev v13

fathom aurora
#

ah awesome

#

can't wait to utilize it

copper laurel
#

?master

rich iglooBOT
copper laurel
#

You can install it using npm i discord.js@dev

fathom aurora
#

ah nice, will take a look then

copper laurel
#

subject to change though

outer raven
#

Would it be possible to add a parameter inside ApplicationCommandData for permissions and make setting and fetching permissions easier?

#

By making it easier I mean having a permissions parameter in ApplicationCommand instead of having to fetchPermissions()

ruby terrace
keen bone
#

it would be great if had a function to check if the bot can send message on a channel before try to send it. ( An boolean type, like message.channel.sendable ) i know it's a terrible name, just example haha

clever spoke
#

channel.permissionsFor or something exists already

zenith oracle
#

Yeah you can just check if you have the send messages permission

remote wasp
#

The getPayload method in Actions.js calls ChannelManager#add with cache as second param, which is fine with most of the other managers but for ChannelManager#add the second param is guild. Now this doesn't break anything since channels are always cached hence the method never get called but I thought I should let you know about this. Also, what was the reason to put guild before cache in #add here?
https://i.imgur.com/kgqThNr.png

#

I'm asking this because I have a similar situation in the new StageInstanceManager#add

slate nacelle
#

I suppose the reason was because the parameter is optional, but we probably want to keep it consistent with the others?
Although I may not be aware of all edge-cases we may have somewhere.

remote wasp
#

It would have been consistent with other managers if it was like add(data, cache = true, guild)

slate nacelle
#

Something like that

remote wasp
#

yeah, the guild can go inside the extras of the last optional object instead

strange igloo
#

Is a PR only modifying typing falling into these cases or not Thonk

- This PR changes the library's interface (methods or parameters added)
- This PR includes breaking changes (methods removed or renamed, parameters moved or removed)

Or the non-code change category

wild flax
#

non-code

hallow ocean
#

Does the non-code case related with the "I know how to update typings and have done so" sentence?

wild flax
#

I would assume so if you update the typings that you know what you are doing