#archive-library-discussion

1 messages · Page 9 of 1

copper laurel
#

Half of that is true for my PRs

tired valve
#

I just changed that to 'pretend'

outer raven
#

Would it be possible to add a VoiceState.user property that represents the User object of the member that state is attached to?

#

I know it's possible but would it make sense to do so?

slate nacelle
#

No

outer raven
#

And why not

slate nacelle
#

Because users can be connected to multiple voice channels across guilds.

outer raven
#

Yeah but almost every class has both the user and member properties, I think it makes sense for consistency because you often need properties from the user object

wild flax
#

And how would you solve the aforementioned problem

outer raven
#

yeah I know I can use voicestate.member.user but it could also be added imo

slate nacelle
#

Oh, I misread that, I though the other way, whoops.

wild flax
#

Where do we put users where we also have members consistently?

#

If you are referring to msg.author and msg.member, those are a bit of a different case

outer raven
#

same thing goes for interactions, I can't think of a class that has member and doesn't have user besides voicestate but i could be wrong

wild flax
#

iirc thats the case because it comes with the actual payload

slate nacelle
#

Also that there might be no member (i.e. interaction in dms)

#

So far there are no non-guild voice states, I think even for instances you get "member", although I could be wrong here

outer raven
#

yeah true but it's just as a shortcut, the same way that client is present in every class as a shortcut

wild flax
#

we don't really do shortcuts anymore

#

we used to, but at one point you just ask yourself "but why doesnt this have one, or this, or this"

outer raven
#

fair enough

wild flax
#

Thatd prolly fall into the same category as why we dont have permission getters for every single permission you might want to check

outer raven
#

btw crawl can you explain exactly what is gonna change in regards to the .send and .edit PR? (enforce the options object and when exactly we're gonna be able to not use an object)

outer raven
wild flax
#

Yeah but thered be a shit ton more if we fully comitted

#

Uh, not much really

#

You can just check the issue thats linked to it

#

the 3rd codeblock

outer raven
#

ye but I saw you comment about .send(embed) and how that would work but it would be undocumented? Maybe I misread that

ruby terrace
#

I said that it would be undoucmented, that was unintended per crawl

outer raven
#

but that means it would throw an error in TS right

ruby terrace
#

yes, its been removed already anyways

outer raven
#

can't you just keep that 1 exception though? I believe a lot of people send their messages as embeds whenever they can and thus they use that method

wild flax
#

I explained why not

outer raven
#

is it because of interactions and webhooks?

wild flax
#

yes

outer raven
#

you could keep that for messages though, they don't exactly need to be consistent

wild flax
#

I explained why they should be

#

Are you sure you read the issue?

outer raven
#

Yeah I did, I just don't understand how "too much flexibility" is an issue

#

I understand it could be confusing from the library's side, but it's much easier for the end-user

wild flax
#

its quite confusing

outer raven
#

yeah when converting from sending messages to interactions it can be confusing and I totally agree with the change for interactions, but as long as the docs mention specifically that you can't use .send(embed) it should be fine right?

#

although some people like to not read the docs but that's something else

strange igloo
#

Imo the more consistent you are, the least confusing you are (thought hard on this one)

Issue with .send method & co. is that people (especially new programmers) might think they can pass absolutely anything they want inside since most of things they will usually pass (content, embeds and for some attachments) will produce the expected result

Now, is it too late? No idea but if this change gets pushed I think this server will need a bit more of 2 general help channels to absorb the flow of people coming for the same errors

ornate topaz
#

we have tags for that

tired valve
#

It's better then people just having no idea what overloads are valid and which aren't, the amount of (embed, options) I'm greeted with in support is insane

mighty sequoia
wintry karma
#

Is it intentional that Interaction. fetchReply (Webhook.fetchMessage) returns raw webhook data in when the channel is a DM (on master)?

copper laurel
#

I'll have a look

#

Hmm, its because DM channels arent cached

wintry karma
#

Is there a reason to not use channels.fetch here instead of a get?

copper laurel
#

The library generally never does any internal fetching

remote wasp
wintry karma
zenith oracle
#

This will delay the Promise, even if it's ready, only without an element

outer raven
#

Can we change MessageActionRow#components to a collection of buttons mapped by their customIds or url in the case of link buttons?

wild flax
#

I don't think that would be very beneficial

outer raven
#

would be easier to find a specific button since (I believe) all buttons must have either a customId or a URL

wild flax
#

For most useful commands you save custom data inside the buttons custom id, so it would not really be easier retrieving them

tired valve
#

The key being a URL also seems like a bad idea

wild flax
#

Let me just retrieve the button for ban:237812371237878:12938712932819389

#

seems like a terrible idea

outer raven
#

oh I didn't know that was something that was done, I just name mine after the action they represent

#

usually a word or two

tired valve
#

Now make that a key of 100 chars

#

Which is possible

#

That'd be awful

wild flax
#

How do you know who to ban with that, for example

#

In case you make some confirmation action

outer raven
#

I guess you'd have a variable with the member object that you pass initially through the interaction

wild flax
#

So what if 2 mods issue 2 bans

#

Which button is for which interaction?

#

If they are both named the same

outer raven
#

you'd have button collectors and each one only fires for a specific message

wild flax
#

That works if you exclusively use collectors

outer raven
#

yeah which seems to be the easiest and most accurate way

wild flax
#

That doesn't matter in this case

#

You can't just make one use case the "correct", and the others barely possible anymore

outer raven
#

eh fair enough

wild flax
#

@outer raven there is no point in asking for merges

outer raven
#

Vlad said he would wait for the feature to be released, I was just asking if now was a good time or not

wild flax
#

vlad doesn't speak for all of us

#

generally speaking we only merge when general availability hits and all reviews have been through

tacit crypt
#

What did I do

#

Oh, I see what I "did"

outer raven
tame whale
#

I assume the new thing with the buttons is going to come in the next update?

copper laurel
#

yes, it already merged into the dev release

tame whale
#

Epic.

worthy coral
#

The code returns this, so I would assume it's not intentional and the class was renamed

copper laurel
#

ahh, yeah thats a copy and paste mistake in the JS docs

#

easily fixed

fossil prairie
#

hello awesome community ;). So i have some concerns about discord.js interface for Message Embeds. I am developing a bot and when i wrap a text into a code block, i get a different appearance on desktop and mobile as seen below.

desc-disc.png
#

My question is: Is there any way to develop something like "media queries" and render different messages in mobile (with different formatting), cause as it seems, code blocks arent working as intented in mobile.

wild flax
#

No

#

None of this concerns us as a library

#

It’s all discord’s doing how things are displayed

fossil prairie
#

hmm i see, thats what i thought. Thanks anyways.

grizzled field
#

for djs devs: are you planning on adding a further layer of abstraction for the discord buttons api? It seems a lot less organized than I think people would like it to be, with buttons being added on messages, but implementations of the button functions being done in a completely separate place.

wild flax
#

Can you further elaborate on this

tired valve
#

You can stash them in an array of arrays if the actionrow bothers you

grizzled field
#

currently, we would add buttons to an actionrow and set a customID for it. however, we would only implement what the button would do on the interaction event, which i think is not as organized as it should be

tired valve
#

I don't understand the problem you are proposing, what exactly is bothering you?

grizzled field
#

I guess, the separation in declaration and implementation is bothering me

wild flax
#

You can create the buttons anywhere you want really. It doesn't have to happen in a specific "event".

#

Or any specific place inside of your code.

#

If thats what you are saying

grizzled field
#

yes, but implementing the function for the button needs to be done on event

tired valve
#

You can just create a componentcollector for that

strange igloo
#

Have a kind of array of buttons with a function associated to them
When a button gets pressed, see which item of that array it corresponds to and execute its corresponding function
You can use message component collectors too, which is suitable for a lot of situations, and would not require you to listen to the interaction event

tired valve
#

the collector does listen to the event and forwards it so to speak

wild flax
#

You can also have a function that listens to "componentType 3" and off-load everything there.

#

And split that up further however you want.

#

We don't make any assumption as to how you write your code.

#

But if your question is to have something like other modules, an event named clickButton which you can listen to, I do not think thats the right approach at all.

grizzled field
worthy coral
#

in ClientApplication#flags, are the flags supposed to be Readonly<ApplicationFlags>, because they're never frozen in the ClientApplication._patch

It seems to break consistency with other Structure.flags in terms of typings and functionality since everywhere else is Readonly<*Flags>;

slate nacelle
#

Sounds like an oversight, it should be frozen.

faint cipher
lone vector
#

I noticed that discussion and put in a pr for it since it seems like an unintentional byproduct of another change

faint cipher
#

cool to know, can you send its link?

lone vector
faint cipher
#

ty

worthy coral
copper laurel
#

Im not quite sure what you mean

#

oh nvm I see

#

Yeah I think that typedef should say id

ruby terrace
#

it probably should, but that reduce operation is occuring on fetched data from discord, where it is perm.id, so nothing wrong there

copper laurel
#

Yeah the typedef is still wrong

worthy coral
copper laurel
#

The object users pass in expects id

#

yes

worthy coral
worthy coral
ruby terrace
#

oh, its being done twice, the one you linked is returned from discord, but it happens before with passed data smolFp

worthy coral
#

oh whoops. My bad

#

I see now

ruby terrace
#

I can actually handle that in #5729...done

wide sand
#

I tried it on djs and found this ->
when i disconnect the bot from vc it still shows channel id which should be null but when i disconnect other user or bot from channel it shows channel id as null

I am not sure if this is djs thing or api thing

#

okay so it's fine from api side. It is happening when i am using erela.js for voice when i connect using erela then on manully disconnecting via discord interface it shows channelID. But if i connect the bot to channel and restart the bot then disconnect from vc manually it shows channelId as null

#

also to note when i use erela.js player.disconnect() function it shows channelID as null

#

However if i have one more instance of bot running the other instance shows null which this one still shows the channel ID

ornate topaz
#

does it happen without erela?

#

if no, seems like erela is messing stuff up.

wide sand
sly forge
#

Got redirected here from #djs-help-v14, so it seems like the PR https://github.com/discordjs/discord.js/pull/5565 introduced a bug that wont let you add permission overwrites to channels/etc. without supplying a valid PermissionResolvable to both the allow and deny parameters (which should be optional by default).

I tried to modify the resolve method of PermissionOverwrites structure shown below and it works but i dont know if this is a worthy PR fix.

/**
   * Resolves an overwrite into {@link RawOverwriteData}.
   * @param {OverwriteResolvable} overwrite The overwrite-like data to resolve
   * @param {Guild} [guild] The guild to resolve from
   * @returns {RawOverwriteData}
   */
  static resolve(overwrite, guild) {
    if (overwrite instanceof this) return overwrite.toJSON();
    if (typeof overwrite.id === 'string' && overwrite.type in OverwriteTypes) {
      return {
        id: overwrite.id,
        type: OverwriteTypes[overwrite.type],
-        allow: Permissions.resolve(overwrite.allow).toString(),
-        deny: Permissions.resolve(overwrite.deny).toString(),
+        allow: Permissions.resolve(overwrite.allow ?? Permissions.defaultBit).toString(),
+        deny: Permissions.resolve(overwrite.deny ?? Permissions.defaultBit).toString(),
      };
    }

    const userOrRole = guild.roles.resolve(overwrite.id) || guild.client.users.resolve(overwrite.id);
    if (!userOrRole) throw new TypeError('INVALID_TYPE', 'parameter', 'User nor a Role');
    const type = userOrRole instanceof Role ? OverwriteTypes.role : OverwriteTypes.member;

    return {
      id: userOrRole.id,
      type,
-      allow: Permissions.resolve(overwrite.allow).toString(),
-      deny: Permissions.resolve(overwrite.deny).toString(),
+      allow: Permissions.resolve(overwrite.allow ?? Permissions.defaultBit).toString(),
+      deny: Permissions.resolve(overwrite.deny ?? Permissions.defaultBit).toString(),
    };
  }
velvet tundra
#

we can trigger the same actions on webhook_events as well as schedule right?

#

because i was wondering why djs uses 2 different workflow

ornate topaz
#

wdym

strange igloo
velvet tundra
#

one that runs every 12 hours

#

another which runs on push and pr

outer raven
clever summit
#

when updating from a master commit before 2f5424bdac7c97d0a371dd72084ac02d5e774f1a to this one or later I noticed that all GuildChannel#permissionOverwrites are empty
I think the issue is that in https://github.com/discordjs/discord.js/pull/5796 the permissionOverwrites get set to an empty Collection in the constructor (https://github.com/discordjs/discord.js/blob/93b0a4e005b5b1d371f7936238556db2e36cc982/src/structures/GuildChannel.js#L40) after _patch from within the super call already populated them with the data from the API, removing this line restored the previous behaviour

vagrant holly
#

Ohhhhh

#

I was just digging into what was causing this, and yes, that'll be it I think

vagrant holly
real jetty
#

Will v13 support changing a guild’s vanity code? I’m pretty sure that still exists in the API but is just undocumented

wild flax
#

We generally don't implement non-documented features

real jetty
#

aww okay

ornate topaz
# velvet tundra one that runs every 12 hours

If you're talking about publishing dev which runs every 12h, then it's supposed to be like that. Doesn't make much sense to release 4 dev versions whenever you merge 4 PRs in a span of 2 minutes

velvet tundra
#

@ornate topaz I understand that. But what about the test-cron.yml

ornate topaz
#

what about it

worthy coral
copper laurel
#

Yeah, because as far as I know we don't directly support passing flags. The only two end user usecases are supressing embeds, and ephemerals, both of which have their own options/methods

analog oyster
#

@fringe temple any reason why you didn't make the second argument just BroadcastEvalOptions<P>? because as is the context is always unknown

unknown.png
#

I guess because of the shard option, but take could just be another generic type

fringe temple
#

it felt unnecessary to introduce another generic type there

analog oyster
#

right, however, the type is incorrect

fringe temple
#

How so

analog oyster
#

the context is always unknown

#

because you're not passing the P generic type to it

fringe temple
#

Oops!

#

feel free to PR a fix for that, otherwise I'll make one later today or tomorrow

analog oyster
#

will do

outer raven
#

If there isn't a reason for that I could remove them in #5696

unique axle
#

default user avatars

outer raven
#

ye thats for the default user but the others need snowflakes right?

#

in fact ill change the id param to discriminator since thats less misleading

#

and the type for that can never be a snowflake

unique axle
#

nkoHmm that makes no sense though

wild flax
#

I don't see whats wrong with the current approach

outer raven
#

so the typings are technically incorrect

wild flax
#

Stop putting stuff into your PR that has nothing to do with your PR

#

make a new one if it bothers you that much

outer raven
#

lol ok

unique axle
#

it's not used

outer raven
#

but it will be right?

wild flax
#

We don’t know

unique axle
#

so far nothing indicates that it will

outer raven
#

hm alright

solemn oyster
#

omg, I love that one

tender field
#

Hey i just needed to sync the permissions of a channel with its parent channel, and it took me a long time to find it because i was looking for "sync" (which is the word discord uses), but it turns out it is "lock".
Is there any reason why it is called like that? What about renaming it to "sync", to make it perhaps more clear? because afaik it does not really lock them, then can still be changed right ? afaict it just overwrites the existing ones with the parent's ones

remote wasp
#

can't because discord uses "lock" for syncing in api

ornate topaz
#

technically yes, and due to how discord handles that, that will sync permissions with parent

ornate topaz
wild flax
#

the naming of the api uses lock

remote wasp
#

yeah, it's just like saying change "guild" to "server"

wild flax
#

also technically speaking, discord can take the liberty and change names like that on the client all the time

ornate topaz
#

well, there is no "lock" param or anything like that for editing a channel. only lock there is is for moving to a parent

wild flax
#

if we would constantly switch around naming as they do on the client, wed be in for a bad time

tender field
#

Yea i see, but i did not mean « use the same naming that in the client », but rather maybe a clearer and more explicit name, so you can understand and find it more easily

#

Not a big deal anyway ig

#

btw this is just about make it clearer, so ig it could also be added to the doc, because i really find "lock" to not be explicit at all : i had to check the code to be sure that it indeed synced the perms 😅

outer raven
#

Since the required value for ApplicationCommandOption is set to undefined by Discord when it's false, can I make a PR so that it defaults to false?

velvet tundra
#

a lot of bots are gonna break due to this new change to the old channel.send(<MessageEmbed>)

wild flax
#

Yes

#

A lot of bots are also going to break because of hasPermissions to permissions.has

remote stream
remote wasp
#

It did, also v13 as itself is a major breaking change. So, it is expected that users will have to update their code in order to not break it

worthy coral
wild flax
#

@outer raven yeah I honestly don't care enough if its used both ways

#

I was just thinking it might be for only sending

#

which you could argue you might be sending a useless prop because the default on discords side, if the key is not provided, is false

#

I guess you get my point

#

But if its also for saving it on our side, it might be more beneficial to have it an explicit value

outer raven
#

Yeye I know. For my bot I prefer having it always set explicitly so that we know what is required and what isn’t

#

But I just thought of an edge case that I’ll need to fix when I get home, which I commented on the PR about

wild flax
#

yeah I saw your comment

oak quail
#

afaik there are currently no plans to use it again

outer raven
#

oh

#

that's sad, I liked that one

#

but makes sense

outer raven
empty viper
#

Hi, I have a question, why does the Client class has setTimeout/setInterval and setImmediate (with their clear version) methods ? 🤔

copper garden
#

It will kill the timers when the client is destroyed

empty viper
#

Oh yes, logic, thanks

oak quail
#

would be very useful if RangeError [EMBED_FIELD_VALUE]: MessageEmbed field values must be non-empty strings. said which field had the invalid value

fallow crater
#

^would be useful for all errors where possible 😅

oak quail
#

also would be good to not log full image data when its logging the request body lol

ruby terrace
real jetty
empty viper
outer raven
#

doesn't really matter how small it is

outer raven
#

What's the progress on #5692? Is it going to be merged soon-ish?

loud jayBOT
zenith oracle
#

Aren't select menus still in private beta?

unique axle
#

yes

#

no need to ask status on pr's either

#

they are merged when released and ready

outer raven
#

oh sorry, I saw a linked api docs pr that was merged and thought that was it

copper laurel
#

Unsure what you're referring to, I haven't linked any API docs to that one

outer raven
#

Why is the patch function in Message.js called patch instead of _patch like in most other structures?

solemn oyster
#

@remote wasp you missed Guild

remote wasp
#

oh, I'll fix it. 👍

solemn oyster
#

Everything else looks fine to me thumbsup

remote wasp
#

umm, I just realized since we are building the _data object here, we do have to check it this way. In the earlier case we were passing the param directly.

solemn oyster
#

Oh

#

Approved thumbsup

outer raven
#

shouldn't these error codes be in Constants.js? A lot of them are missing so idk what the criteria is really

unknown.png
solemn oyster
#

No criteria, just nobody PR'd them

outer raven
#

so they should all be added?

solemn oyster
#

Yes

outer raven
#

well that's gonna be a fun job

solemn oyster
#

An option, though, is that we re-exports discord-api-types's enum

#

Since that's always updated, and sometimes faster than d.js itself

outer raven
#

wouldn't it be better to just import them from there and not have this export?

#

cuz this is clearly heavily outdated

#

I'm willing to make the PR adding all of these btw, just wondering if it's worth it or not

unique axle
remote wasp
#

yeah, I saw it too. The current PR is already done tho. Should I add this to it or make a new one? ThinkO_O

outer raven
#

Can someone run the publish action once this round of merges is done pls?

slate nacelle
#

Is that what the invite_code property on the instance is for? Thinkeng

solemn oyster
#

@remote wasp I unresolved the comment about update because upstream PR in API docs, btw

remote wasp
#

yeah, saw it. Should I change the update to edit now?

solemn oyster
#

I'd wait for the docs to be reviewed, tpcstld is on it

remote wasp
#

okay

solemn oyster
#

He approved and merged it

#

So no wait needed

remote wasp
#

lmao, that was fast neptuneWink

solemn oyster
#

Yeah, I asked them before making the PR, and told me to ping them back once the PR was created

remote wasp
#

aight, I'm on it prettythumbsup

solemn oyster
#

I'll approve as soon as that's updated

#

Everything else looks good to me

solemn oyster
#

@remote wasp just 2 docs things and I'll approve

#

(Also, #5843 needs a rebase)

remote wasp
#

okay 👍

solemn oyster
#

Shibi~

#

I just noticed a small thing, sorry 😓

#

StageInstanceManager#24, missing final dot

#

@remote wasp ^

#

Wait, it's a property

remote wasp
#

but that's same for all mangers, I checked and none of the manager have dot at the end. ThinkO_O

solemn oyster
#

Yeah, properties don't have final dots, my bad

remote wasp
#

lol, it's okay neptuneWink

solemn oyster
#

I thought it was a typedef because they're blocks of docs without any code below them

remote wasp
#

oh

solemn oyster
#

Approved thumbsup

remote wasp
real jetty
#

Is there a pull request (and if not is it useful?) to compare the local command with the registered one (name, description, arguments, required field, etc...) in order to update or register the command only if necessary

strange igloo
real jetty
copper laurel
#

I think generally the consensus is that's what belongs in a framework, not the core lib

graceful steeple
#

Hello everyone! i have tried to run discord.js in chrome extension. this is the boilerplate i've created and im using right now https://github.com/fxnoob/browser-extension-boilerplate. i'm using webpack 5 so its asking for the polyfills. when i am requiring web build of discord.js, its giving me 403 on console.
I've read in the github issues that due to cors web build is not working but its not the case for browser extension. they can do cors fetch from background pages.
Is it possible to use the Discord.js in chrome extensions background pages? is there webpack config for webpack 5 for this project so that polyfill error can go away?

strange igloo
#

I don't see any use case that would require discord.js to be used in a Chrome extension (or in a web browser in general)
If you only need some API requests I think it'd be better to directly interact with the Discord API

raven juniper
#

discord has dropped support for webpacks

graceful steeple
wild flax
strange igloo
graceful steeple
wild flax
#

Would this be an extension for you alone?

graceful steeple
wild flax
#

Because you are not allowed to request a users account or their token to send the message from their user

#

This would fall under the "user bots" category which is not allowed by ToS

graceful steeple
wild flax
#

It would not be

remote wasp
wild flax
#

But its surely not possible with our library

#

How would you make sure the token you distribute is secure?

#

What shibi suggested would be the proper way to handle this 👍

graceful steeple
remote wasp
#

You can look into CF workers

graceful steeple
#

what does cf stands for ?

remote wasp
graceful steeple
wild flax
#

Whenever you feel like it.

#

But then again, you might as well switch to the best discord lib: discord.py.

#

Oh, I was assuming you were memeing.

#

There is no reason to switch to Eris to be "worth" anything really.

#

Yeah people have been saying that for years now. Its a dumb circlejerk.

#

Benchmarks have shown that there is no significant difference between those 2 if used properly.

#

And big bots run their own forks of eris too, don't be swindled.

#

Big means >50k here btw.

#

Yes, 50k+ servers.

#

What about it? Are you looking for some numbers or something else?

#

Depending on what your bot does, @rich igloo runs on this server only, which sits at around 50k people. With a lot of cache, uses around 130MB of RAM.

#

Which is a joke really.

#

No.

#

Eris is not matter. It doesn't matter what they will tell you.

#

The only difference I know for a fact by now is that Eris is behind when it comes to features quite a bit compared to us.

#

So if you need interactions, buttons, select menus, threads. You will get them faster with us.

vagrant holly
solemn oyster
quiet viper
#

nah, there isnt a big difference.
see the orange and blue one

bench.png
wild flax
#

Eris is not in TS, and it has worse typings.

#

lol

#

Also that graph isn't saying anything about our library

#

This is why I hate graphs like this.

#

The following test is a ~3 hour run (each tick is 10 minutes), with ~3700 guilds total (4 internal shards), with all intents enabled (including presences), and with message caching disabled (messageCacheMaxSize:0).

#

No one would enable all intents on their bot.

#

The introduction of intents also made that light fork completely obsolete.

icy trout
#

Hey Crawl,
I accidentally pushed one commit to my pull request that I meant to have in a separate pull request...
Do you know how I can undo the most recent commit?

wild flax
#

Might as well rename the PR and description

#

Instead of making 1 line changes in so many separate PRs

#

also less overhead for us to review

icy trout
#

Thanks for the help 👍

quiet viper
wild flax
#

Which is useless to compare.

#

You will never use everything

quiet viper
#

"Big Bots" such as Dyno would use nearly every Intent

wild flax
#

No they wouldn't.

#

And they use a modified version of Eris too

quiet viper
wild flax
#

They wouldn't use all the intents, no.

quiet viper
wild flax
#

They don't :D

tacit crypt
#

Realistically, at the scale they operate on, they would have custom almost everything, from cache to who knows what else

solemn oyster
#

@icy trout I requested a change, just an easy copy+paste fix

unique axle
#

more intents
-> more websocket events
-> more data that gets cached + bandwidth used
with intents you control which ws events you want to receive

rustic boughBOT
solemn oyster
#

I hope you know we don't endorse discord.js-light as it's not official

wild flax
#

The introduction of intents also made that light fork completely obsolete.

#

lol

solemn oyster
#

Pretty much the only benefit of light is customisable caching, although I have no idea how it works and how might it be more memoy efficient than what we have

#

However, by using it, you also lose the benefit the official discord.js ecosystem gives you, such as more active support, up-to-date features, etc

wild flax
#

I tried reading their source in the past one time

#

Its very convoluted lol

solemn oyster
#

Well, it's a bit to be expected, discord.js's review and maintenance process is pretty good

#

And is something forks and alternatives don't get. In most of the libraries at least, I see 1 or 2 people reviewing, of course that's going to slip in more messy code, here we have 4 people, so even if it takes longer than 1 or 2 people, the overall code quality is just a lot higher

icy trout
solemn oyster
left moat
solemn oyster
#

I made it a suggested change so you can commit it from the browser

left moat
#

u dont have to circle jerk a lib just bc ur in their server

#

grow up

wild flax
#

You don't have to continue in this channel do you?

quiet viper
# left moat shut up

Thx for the constructive critic, when you think that eris does something better than discord.js, then you can provide me the info on my dms.....
I just made a git compare and must structure and file names were similar. "looks like", that was my opinion.
But let us move this in an another channel.

raven juniper
#

that's because, if i remember right, eris started as a fork of d.js v8 or something

manic zinc
#

Eris actually started when Abal left the discord.js development team back in v6, about 5 years ago, because he did not like the class-based/OOP direction hydra was heading towards.

unique axle
#

thanks, and with that, back to topic and away from djs history lesson, thanks catThumbsUp

vagrant holly
#

So I have an issue with GuildChannel#permissionsLocked -- if a channel parent permissions update, this then causes a permissions update to the channel itself, and it also appears as if permissionsLocked has changed because the parent has changed at the same time? Not sure what the best solution to this is really

#

I was thinking maybe having permissionsLocked be an actual method instead of a getter, so you can pass an updated parent into it for the calculation if needed?

worthy coral
#

I noticed BaseMessageOptions now includes the files field, but does not include the embeds field. Is there a *Options T that doesn't accept embeds?
I looked through and only found ReplyMessageOptions which should be incorrect as it routes through TextableChannel.send which accepts embeds and not embed

ruby terrace
#

Not anymore I believe, PR 5860 seems like a great candidate to fix that, feel free to make a comment on that.

smoky thunder
#

Can't the event listeners' return types be Awaited<unknown> instead of Awaited<void> so we can do things like return message.reply({ content: 'Unknown command' })?

ornate topaz
#

there was a PR to do that, but it was decided against that

#

however, as far as i'm aware, that's going to change to accept void | Promise<void> after we switch to node 15 or later

#

since uncaught promise rejections are a throw on there

smoky thunder
#

seems like a pretty harmless change, there's no way to access the return values anyways

ornate topaz
#

while true, consensus was that such type would indicate that library handles whatever you return for you, in some way

#

while the library takes nothing

wild flax
#

Because they can not be caught

smoky thunder
#

Oh, didn't know that

wild flax
#

Yeah, thats mainly why we did it

#

A lot of libraries allow it, but in this ecosystem I think a lot of people also don't understand the fundamentals of this stuff

#

Not saying we are clearly superior, but if we find something could definitely backfire on the user, we try to fix it and make sure they don't make that mistake

smoky thunder
#

Alright, thanks

real jetty
ornate topaz
#

Message already has one

#

though not sure what would be the purpose for the channel one, as well as why add it; you can't really get one in the client, as far as i'm aware, without taking message one and removing message id

#

url gives no benefits over mentioning the channel, both inter-server and cross-server

real jetty
#

I use channel links when my bot sends a DM to a user so that the user can click on the link and get to the channel quickly

ornate topaz
#

you can mention the channel instead

#

as i said, there is exactly 0 benefit of using an url over using a channel mention

real jetty
#

Thx ❤️

drifting knot
#

for voicelink: fastify is good but keeping the types on each route in sync with the JSON schema is very annoying to maintain
i strongly recommend you find a schema builder library in typescript which can output valid JSON schema (which fastify consumes) and also a TS type (which the RouteOptions generic accepts)

#

and it really should be a schema builder library, don't try writing .d.ts files and compiling those to JSON schemas, the community tooling is very lacking in this area

wild flax
#

The schema here is mainly for swagger honestly

#

I don't do any real validation with it, because its just a perf decrease

drifting knot
#

that's still the same issue

#

documentation is getting duplicated in every route and still needs to be manually kept up to date with the types

wild flax
#

Yeah but I wouldn't need any library for this really. VoiceLink is rather a done deal after the initial footwork is there, since if you look at the LavaLink repository, there isn't really a lot of code.

#

It's really just a wrapper around discords voice sending capabilities as a server

#

So the chances of us updating it a lot is very minimal

#

And my experiences with that kind of stuff aren't really on-par either.

#

I have used joi a lot, but I don't think joi is applicable here

#

Since thats more of a validator than json shema

drifting knot
#

yeah if this is never getting changed again it's reasonable to leave it as-is

wild flax
#

I'd argue probably 80% of the routing code will stay the same after the initial MVP

#

Though I wish fastify had some good 1st party fs-routing capabilities PepeHands

drifting knot
#

nextjs api routes win again

wild flax
#

I like doing my routes in the file system as /[id].ts etc

drifting knot
#

yeees

drifting knot
wild flax
#

mongo though

rough arrow
#

How does the ratelimiting work in discord.js?

I understand that we have the parent class, RESTManager. It has a global count that gets scheduled calls to reset it (this seems to be handled by RequestHandler right?), this makes sure we don't hit the global rate limit. RESTManager also has a collection of routes (for example /channels/id/ right, including methods?) to RequestHandlers.

That gets us to RequestHandler, it has a queue of promises (so requests that want to be made) and ratelimit information. That is, each RequestHandler represents a Discord API bucket correct?

When the request is to be made, it first makes sure we're not ratelimited by checking the global info (the count is 0 and if a reset has been scheduled) and local info (remaining is 0 and if a reset is scheduled). If any of those 4 are true, it will sleep until that is to be safe. Then actually make the request, and use the ratelimit information retrieved to update local values.

Does this mean discord.js does not use X-RateLimit-Bucket to for example differentiate the endpoints/routes that share (or don't) buckets across the methods they use? Additionally, am I right in that this implementation disallows concurrent requests (which is an acceptable drawback)?

oak quail
#

Does this mean discord.js does not use X-RateLimit-Bucket
afaik yes that is correct

copper laurel
#

djs-next's handler uses buckets

solemn oyster
#

^, we also need to update REST to catch up with the new features from v13's

iron pier
#

I have a request about the buttons, please use the npm package discord-buttons as a guide so that the code that was written with this package still works
I hope it's the right place for this^^

solemn oyster
#

discord-buttons has never had, and will never have official endorsement from us

ornate topaz
#

i think that was more of a "write in in the way that package is done so i dont' have to rewrite"

copper laurel
#

Buttons is already complete, it will not change to match an external package

solemn oyster
#

Not happening

iron pier
#

Ok, I didn't know this

solemn oyster
#

Kinda your fault for using a third-party package knowing there was an official one on the way, tbh

#

(And if you didn't know... I'm pretty sure support members have been pretty persistent about it, so it's a bit hard to believe)

rough arrow
copper laurel
#

No specific version but yes, a TS rewrite

tacit crypt
#

Additionally, am I right in that this implementation disallows concurrent requests (which is an acceptable drawback)?
Yes? Concurrent for different buckets, sequential for the bucket itself

#

if that makes sense

rough arrow
#

Yes I get what you mean. You cannot make concurrent requests that use the same handler

hushed sedge
#

Is v13 changing alot to break v12 code?

solemn oyster
#

Yes

hushed sedge
#

like, for example i believe message.channel.send() will break

#

:/

#

thats like - everywhere!

solemn oyster
#

For the better

hushed sedge
#

What is it getting changed to?

solemn oyster
#

Something more consistent

hushed sedge
#

okay.

#

:/

oak quail
#

its still staying message.channel.send, but it might stop working for you depending on how you're using it

hushed sedge
#

Ohhhh, i see.

oak quail
#

so is it gonna be user or author? (for emojis and stickers)

hushed sedge
#

what

oak quail
#

different conversation from earlier

hushed sedge
#

Ah.

wild flax
#

User def

outer raven
# wild flax User def

I know the user object from messages is called author on the API's side but wouldn't it be better to call it user to make it consistent with everything else?

sharp wigeon
#

does the lib have some kind of utility function to check the language of a codeblock?

#

for instance

# 
const num = 2;

the codeblock has js highlighting to it, so I was wondering if there was a function that would return the language of a codeblock that has syntax highlighting to it?

#

ofc I could just do this with some simple string manipulation, but was wondering

covert flint
#

No

sharp wigeon
#

ok was thinking of making a pr that would add something like a Util.containsCodeBlock() function, idk if it would be necessary tho

copper laurel
winged dust
#

Can d.js v12 no longer delete other people’s link previews?
I’m getting this error: DiscordAPIError: cannot edit a message authored by another user
msg.suppressEmbeds()
It’s been working okay for 10+ months but about a week or two ago it started giving errors and not deleting the previews

copper laurel
#

I've just opened a PR

#

Though thats a v13 issue, not v12

#

I'll try again on v12

#

Okay yes, I do get that

#

Fixed in master then, I guess

copper laurel
#

PR already open for that one

winged dust
#

Thanks!

sharp wigeon
#

Would a Util.codeblocks(text) be a necessary method? Essentially, the method would be used to get all the codeblocks of a message, which syntax it was highlighted with, and then the content inside it. It would return an Array<CodeBlockData> | null

Where CodeBlockData would be an interface like

interface CodeBlockData { 
content: string
highlightedWith: string: //I would add better types for this
}

And null would be returned if the text contains no codeblocks?

rough arrow
#

To be honest, that sounds more like something you would do yourself in your code.

#

There's no CodeBlockData from the Discord API at all

zenith oracle
#

Also why should it return null instead of an empty array if there are no code block

#

However I don't see any implementation of this. Why would djs use this?

clever spoke
#

couldnt people just use regex?

kindred yoke
#

yeah probably

copper laurel
#

Yeah, util methods don't really exist just for end users - they all have a specific purpose that the lib uses I think

sharp wigeon
#

Ah ok

rough glacier
#

Is there still a discussion about a deep comparison between registered and current ApplicationCommandData for automatically updating if there are spotted changes? Last i heard of it was #archive-library-discussion message or did it conclude that it should be left for the user to implement?

wild flax
#

The latter

#

We don’t do automatic stuff in this lib

copper laurel
#

The automatic updating would be up to the user to implement, but would an ApplicationCommand#isEqual(data: ApplicationCommandData) method make any sense to have?

ruby terrace
#

It would make sense to have, it would be hard to implement

outer raven
slate nacelle
outer raven
#

ok ty
btw does the name MessageFile for the typedef sound good?

outer raven
#

Shouldn't this say discord.js@dev on the master version? There's also links to the WIP guide so I think it would make sense

unknown.png
wild flax
#

We generally don’t modify the readme for dev

#

More changes to make when we release

outer raven
wild flax
#

Yeah but that will generally stay

#

The “this is still for stable” I can’t remember anymore

#

But probably shouldn’t be like that

#

Not that it matters rn, since it’s already like that

outer raven
#

I think at least that should be removed cuz stable will be v13 once it's out

#

but yeah fair enough

outer raven
#

@solemn oyster there aren't that many types to update but I can import them from discord-api-types and add them, want me to do that?

solemn oyster
#

Yeah

#

We should always use discord-api-types for raw objects

real jetty
#

Is there a reason why embeds field aren't in BaseMessageOptions ?

ornate topaz
#

it seems more that it's an oversight

#

since bots weren't allowed to send multiple embeds before, so those wouldn't be in MessageOptions, but would be in WebhookMessageOptions

real jetty
#

Oh a little PR to make 🙂

real jetty
#

But I don't know how to do it if someone want to "correct" it :/

sharp wigeon
#

aren't errors of type DiscordAPIError?

ornate topaz
#

?

loud jayBOT
remote wasp
real jetty
#

I was also wondering, why there is no BaseMessageOptions type in the index.d.ts file?
P.S. thanks shibi for the PR 🙂

zenith oracle
#

Because it's not needed probably

outer raven
#

can we change all collections that hold ApplicationCommand's to be mapped by their names instead of ids? Most of the time we know the name of a command and not it's id or at least this is the case whenever i need to access an ApplicationCommand

#

I know it's a sort of rule to map everything by it's id when it exists but I feel like this scenario would make sense

rough glacier
#

its not a great idea, especially when you can have a sharing name between guild and global ones, and although they're in different CommandManagers if someone decided to merge them somewhere, there would be a conflict

cobalt comet
outer raven
outer raven
cobalt comet
#

Plus, I would be assuming that you'd be storing some kind of per-server config if you're going to be deploying commands per guild instead of globally, otherwise there's gonna be a lot of commands getting overwritten repeatedly (on the assumption servers can effect the functionality of a bot based on slash command input).

zenith oracle
#

So when setting the status of the bot we can use the setStatus method (or the status property with setPresence) and the string passed must be online | idle | invisible | dnd (PresenceStatusData), but when accessing the status of a user, with <User>.presence.status, we can receive online | idle | offline | dnd (PresenceStatus). Why are these types different for the offline option? Why is called invisible in the first but offline in the second. Wouldn't it be better to use the same word for both?

unique axle
#

there is a semantic difference in offline and invisible
bots can not receive invisible for other users (so you can't discern it from offline)
bots can also not set offline, but just invisible

zenith oracle
real jetty
#

like when someone says "how can I set the bot's status to invisible?" people supporting could trip up and say client.user.setStatus('offline')

#

bots can not receive invisible for other users (so you can't discern it from offline)
meaning if someone is offline but still on Discord, the client receives it?

unique axle
#

you receive both invisible and offline as offline, you can not receive invisible

#

bots known when you are offline and when you are "pretending" to be offline would be a terrible idea privacy wise, you only ever receive "offline".

#

and adapting the setStatus to accept offline would be a bad idea as well, semantically offline is - offline, not able to participate or read conversations, where as invisible means the offline indicator but still being able to interact with the app

#

naming two fundamentally different states the same would be a terrible design decision

real jetty
#

but invisible in PresenceStatusData?

#

oh wait I see now

real jetty
unique axle
#

i don't understand how this is so hard to discern
offline: you close discord
invisible: you set your status to offline
as a user you don't want people to know when you are offline vs. when you want to be shown as offline, so discord sends out "offline" even if you are "invisible"

outer raven
#

For some reason, User#system is always null is the user isn't part of the urgent message system instead of being false. This is due to the fact that system doesn't come in the User object from Discord and d.js checks for that. Should we change this so that it's declared as false instead of null?
A similar thing goes for User#bot where it's always false for partial users when it should be null because it's checked if typeof this.bot !== "boolean" and then a boolean is created from that value. Since this.bot is undefined, it becomes false. Should this be changed as well?

oak quail
#

didn't user#bot get a lot of changes to work properly? does it still not work?

outer raven
#

partials are the only scenario that I found where it doesn't work as expected

#

I have a fix for this so just let me know if I should open the PR for it or not

wild flax
#

iirc jake said any null/undefined/non-existent-key value that is supposed to be a boolean should default to false on those cases

#

if true isn't being sent

#

cc @unique axle

unique axle
outer raven
#

yeah but I'd assume not for partials right?

wild flax
#

always

#

it being null has no meaning really

outer raven
#

because you don't know who the user is in a partial, so saying they're not a bot could be incorrect

outer raven
copper laurel
#

We don't know if it wasn't sent because it's partial or if it wasn't sent because it wasn't sent by Discord

#

We've have to start adding isPartial to all our constructors to know where/why the instance was being created and stuff.... which is eww

#

Thats the logic I couldnt remember hence directing the convo here

outer raven
copper laurel
#

exactly

#

So we set it to null, because if its missing, we dont know if its a partial for a system user or not

zenith oracle
#

What will happen after v13 is released? like, the master branch will work for a new version? Will be there to fix bugs and add feat to the actual v13? And what about djs next?

copper laurel
#

Nothing really changes, yeah. The stable discord.js version on npm just gets updated to v13. Bugs will get merged into stable in the form of minor or patch releases. Major breaking changes will wait for a v14.
djs-next has nothing to do directly with the version numbers, its a separate TypeScript rewrite.

zenith oracle
#

Okk, thanks!

outer raven
#

but not this

unknown.png
copper laurel
#

I believe so

oak quail
#

643945264868098049 and 669627189624307712 are the system users

oak quail
outer raven
#

Yeah so just by fetching their messages I can see that system is true for the first and not present for the other

outer raven
oak quail
#

ik what it is, that feature is powered by channel following

outer raven
#

ah alright

#

then when does the first user send messages?

#

i only got one when i enabled community on my server

oak quail
#

the discord system user only sends dms

#

the community updates system user is for whenever there's something for just one server

tacit crypt
#

I mean you can see in your screenshots that one has a SYSTEM badge, the other has a SERVER badge

outer raven
#

ye ye ik

oak quail
#

should be system without a checkmark

tacit crypt
#

The checkmark doesn't hurt

oak quail
#

looks like they broke it lol

#

yeah I mean it was that before

outer raven
#

but yeah so I don't think system being present or not depends on whether it's a partial or not so it would be safe to set it to false when it's not there

#

unless it's a partial

oak quail
#

so vlad wants me to add sticker.fetch but we disagree on how to implement it

#

so theres a /stickers/:id route (implemented in the djs pr as client.fetchSticker) and a /guilds/:id/stickers/:id route (not currently implemented as I didn't add a GuildStickerManager in the pr)

unique axle
#

i don't see how this is significant for discord.js library devlopment
(re: system)

oak quail
#

I assume that to get sticker.user, you need to use a guild id route, and you need the manage emojis permission (edit: has been confirmed)

#

vlad says that if the sticker is a guild sticker, djs should always try to fetch it with the guild id, and just error if the bot isn't in the server

#

imo it should just call client.fetchSticker(this.id), or the user can optionally choose to fetch with the guild id if they want

tacit crypt
oak quail
#

yeah

oak quail
outer raven
#

cuz if so, the typings need updating I think

zenith oracle
#

Iirc it's null when the interaction is in a DM, with the DM Channel not cached

outer raven
zenith oracle
#

I saw it

#

👍

copper laurel
outer raven
#

Which is actually how I found the bug

copper laurel
#

But it's a getter so it should have always been nullable

#

Yeah weird

outer raven
#

Yeah exactly but you can add it to that PR

vivid field
#

But it does include null?

unknown.png
#

Or am I missing something

slate nacelle
wicked rain
#

Whats the new activity type competing ?

clever spoke
#

competing in (whatever)

wicked rain
#

Nice that, ok bro

outer raven
#

btw why is it readonly?

ornate topaz
#

getter

copper laurel
#

Was there a reason we didnt make ApplicationCommand an extendable structure?

oak quail
winged dust
#

or is this feature discontinued

ornate topaz
loud jayBOT
copper laurel
#

This one also

#

Is the v13 fix

winged dust
#

will the fix come to v12 master?

clever spoke
#

v12 master?

copper laurel
#

v12 isnt master

#

It will come to master

#

Its up to the maintainers if we continue patching v12 or not

winged dust
#

ignore the "master" part of the question xd

copper laurel
#

lol, Crawl just merged the v13 fix

winged dust
#

niceee. is it also a v12 fix?

ornate topaz
winged dust
#

oh 😔

copper laurel
#

Theres different bugs and different reasons they happen in each version

#

The suppressEmbeds one is not related to editing out embeds

sharp wigeon
#

For discord js -next

#

Since I know it’s supposed to be vastly different from discord js

#

What are some ways it could be different? Like how could we create a new instance of client and stuff? I know kyra had some good ideas

ornate topaz
#

afaik -next doesn't even have any shape or form yet

copper laurel
kindred yoke
#

its going to be completely written in ts right?

#

nvm pins

sharp wigeon
copper laurel
#

But its not going to be "vastly different"

outer raven
wild flax
#

but we all missed it, and it pretty much broke all bots

#

lol

outer raven
#

oh shit

wild flax
#

No unrelated changes in PRs please, even if they seem like a no-brainer next time

#

👀

outer raven
#

yeah noted, sorry

#

I thought that was transforming the type into a string, not the other way around

copper laurel
#

That method is for getting the data to send to the API, so needs to be an int

outer raven
#

yeye got it now

#

On a completely unrelated note though: what do you guys think of merging sub command options into the main interaction's options? Let me explain:
When you run a command with a subcommand or subcommand group, the only option in the main collection will be the sub command that you ran, so if we manage to merge them all into the first there should be no issue (unless an option has the same name as one of the sub commands, which i don't know if it's possible)

copper laurel
#

merge how?

#

you still need to know which subcommand was run, are you proposing moving that property up to CommandInteraction#subcommandName or something

outer raven
copper laurel
#

I dont like the idea of breaking the hierarchy, no

outer raven
#

imo it made sense since you'll never have more than 1 option with sub commands and groups but sure then

copper laurel
#

hmmm actually yeah maybe

#

I think the part I'd find awkward is that if the subcommand is kept, you'd be getting it essentially like a boolean option I guess? Just checking that its... there, and then you know what the other options are?

outer raven
#

When you have multiple subcommands you'd be checking which one the user ran. I usually do this with interaction.options.find(o => o.type === "SUB_COMMAND")

honest barn
#

why is code option in #5918 being removed? there's no other clean way to do it without manually writing it into the string

outer raven
#

this seems clean enough to me

unknown.png
#

although you need a bunch of \ there

honest barn
#

yeah thats why code was very useful for me

outer raven
#

but why is adding \ an issue?

honest barn
#

its an issue when you're using the `` type of string

#

too many \ affects readability

outer raven
#

not that you would need to read a lot from a bunch of slashes

#

you can even put that in multiple lines if you prefer

ornate topaz
#

for the codeblock to be formatted properly, you need a single newline after language. no matter if you use ` or ', it has to be there

#

however, template strings (`) have a bonus of being able to be multiline themselves

wild flax
#

It just wont be a message option anymore

honest barn
#

oh then it's a good change

#

that would be allowed for any string right?

wild flax
#

yeah it will just be a function you wrap your string with

outer raven
#

will that be included in that PR?

wild flax
#

no

solemn oyster
#

We talked about adding that in /builders and then re-exporting in d.js

outer raven
wild flax
#

just open it if you think its useful

#

doesnt mean well accept it

outer raven
#

alright

copper laurel
#

If there's only one possible sub-command at a time, why make people find it as an option when it could be bumped up to a property though

#

I feel like you could have
interaction#commandName
interaction#subcommand
interaction#subcommandGroup
and then just the options or something

outer raven
#

so maybe remove it all together would be a good idea and much easier

#

actually nah even then I have no clue how to do this in a smart way since I'm not familiar with the way djs patches stuff, could you try to do this?

winged dust
frank turret
#

AFAIK, there are no additional releases for v12, so you'd have to install from dev. npm i discord.js@​​dev

copper laurel
#

Not fixed in v12, no

#

I dont think that issue relates to v12

oak quail
#

thats due to sending embeds

copper laurel
#

The suppressEmbeds bug is different to the empty embeds bug

#

sort of

#

It probably shouldnt be closed though

wild flax
#

Yeah we have no more releases for v12 planned.

solemn oyster
#

Are you gonna do the largest rebase ever before continuing a lot further? Or split the changes in smaller PRs?

vernal atlas
#

well i was at first going to rebase and continue, but now im thinking that splitting the changes is a good idea

wild flax
#

Yeah, smaller ones are also easier to review and merge

outer raven
slate nacelle
#

I wouldn't call the bot property being invalid expected behaivor.
Or at least hope it's not.

outer raven
slate nacelle
#

Patching with partial data should not invalidate the state of the object.

#

If you are not sure a change has to be made, make none.

outer raven
copper laurel
#

I think I'm missing exactly what you think is incorrect here. You kinda lost me right from the start when you told me you were re-assigning properties to things they aren't meant to be. The identifier on a custom emoji will be its name:id format, while on a unicode emoji, it will be the unicode. It's not ever meant to be the id, which yes, will be null on unicode emojis.

#

The ReactionEmoji class is kinda like a partial guild emoji, eg when the reaction came from a guild the bot isn't in so it can't get full data I think

#

yes, but it wont have an id if its unicode

#

If you need to store them in a database for whatever reason, const unique = emoji.id ?? emoji.identifier

#

Because it is the identifer at the time

#

Youre just misusing the property

#

Its not supposed to be a primary key for a database

loud jayBOT
wintry karma
#

Is there a reason for skipLibCheck being set to true in the tsconfig.json?
Would it make more sense to set that to false to catch errors in the typings?

solemn oyster
#

I have never tried but... I suppose we could add a stub augment

#

Something likets module '@discordjs/voice' { interface TheInterfaceWeRequireFromIt {} }

#

If the module is installed, then it'd merge an empty interface with the full one

#

That way we can use that interface from a module that's otherwise missing, without getting compiler errors

#

That must be inside declare module 'discord.js' {}, btw

#

cc: @tacit crypt @fringe temple

vivid field
#

Why do we even have @types/ws and discord-api-types as dependencies now, but not @discordjs/voice?

wintry karma
#

Typings are currently broken on master because there are interfaces imported, that don't exist in the used discord-api-types version.
And with skipLibCheck: true that could easily be missed.

vivid field
#

What interfaces exactly?

wintry karma
# 
typings/index.d.ts(142,5): error TS2305: Module '"discord-api-types/v8"' has no exported member 'APIActionRowComponent'.
typings/index.d.ts(147,5): error TS2305: Module '"discord-api-types/v8"' has no exported member 'APIMessageComponent'.
typings/index.d.ts(1634,12): error TS2416: Property 'options' in type 'ReactionCollector' is not assignable to the same property in base type 'Collector<string | `${bigint}`, MessageReaction>'.
  Type 'ReactionCollectorOptions' is not assignable to type 'CollectorOptions<[MessageReaction]>'.
    Types of property 'filter' are incompatible.
      Type 'CollectorFilter<[MessageReaction, User]> | undefined' is not assignable to type 'CollectorFilter<[MessageReaction]> | undefined'.
        Type 'CollectorFilter<[MessageReaction, User]>' is not assignable to type 'CollectorFilter<[MessageReaction]>'.
typings/index.d.ts(1640,12): error TS2416: Property 'collect' in type 'ReactionCollector' is not assignable to the same property in base type 'Collector<string | `${bigint}`, MessageReaction>'.
  Type '(reaction: MessageReaction) => Promise<string | `${bigint}`>' is not assignable to type '(...args: any[]) => string | `${bigint}`'.
    Type 'Promise<string | `${bigint}`>' is not assignable to type 'string | `${bigint}`'.
      Type 'Promise<string | `${bigint}`>' is not assignable to type '`${bigint}`'.
vivid field
#

Oh that's intentional I think, it's going to be released with the next version

wintry karma
#

They exist on discord-api-types main so probably.
But I personally think that they shouldn't be ignored in the CI, like they are now, so they don't get missed.

copper laurel
#

Not on main, on next

#

I think

flint zephyr
#

Please add better documentation for FriendlyError and CommandFormatError in Commando 😦
I really want to use something that lets me customize the command format error but there is no clear documentation

#

Like add use cases and examples

wild flax
#

Commando is currently unmaintained

rough roost
#

why are snowflakes not just bigints?

cloud kraken
#

Because that's how the api sends them

wild flax
#

you can't serialize bigints

rough roost
#

that's unfortunate

ebon radish
#

How does Discord.js achieve seamless ESM-CommonJS interop?

vivid field
ebon radish
oak quail
#

pretty much everyone uses commonjs though?

ebon radish
#

but why? I guess that's my real question. why have we not fully embraced ESM?

#

we meaning the node.js ecosystem

wild flax
#

Because requiring cjs inside of mjs is problematic

#

Or rather the other way around

#

So our lib couldnt be used outside of mjs anymore

#

Which is rather problematic

#

We would have to supply cjs builds

#

And lets just assume we have a big typescript userbase, the standard tsconfig.json tsc generates does not set the compilation target to ESNext by default either

#

So we would get daily questions about that 100%

#

Thats not to mention all glitch/replit users

ebon radish
#

is it problematic for reasons other than that?

oak quail
#

node esm doesn't support json

wild flax
#

No, but I would argue this is a big problem indeed

ebon radish
#

other than users not knowing how to switch, I mean

oak quail
#

which is why I've tried esm multiple times and have had to go back to cjs

vivid field
#

Yeah, some things are still experimental

ebon radish
#

hmm can't you read the json the normal way

vivid field
#

JSON modules are stage 3 but node doesnt have them yet

wild flax
#

Its a lot of work honestly that is not very clear

ebon radish
ebon radish
copper laurel
#

I still really dont see any reason to just drop support for something that is still in such widespread use

ebon radish
#

thanks for your answers, my questions were not rhetorical

oak quail
#

since discord deprecated Message.stickers and is switching to Message.sticker_items (presumably to not break .stickers), should d.js keep using Message#stickers (with the .sticker_items data) or use Message#stickerItems or similar? (sticker_items contains partial sticker objects)

#

(personally I like Message#stickers and think Message#stickerItems sounds dumb)

copper laurel
#

Agreed, we can still make breaking changes to Message#stickers so go for it

oak quail
#

vlad says that if it knows that the sticker is in a guild, it should try to fetch with the guild route (which will only work if the bot is in the guild) to try to get sticker.user
I say that it should just run Client#fetchSticker, and people can use Sticker#fetchUser (or GuildStickerManager when that's added) if they want the user

copper laurel
#

Is it possible for the bot to have/receive a sticker without being in the guild

oak quail
#

yes

#

in messages

#

or by fetching with the non-guild route (which works for all existing stickers)

#

itll probably not be in the sticker's guild most of the time

#

and I think Sticker#fetch should work in that situation

copper laurel
#

what message would it receive if its not in the guild? or are they like emojis and can be used globally?

oak quail
#

latter, if the user has nitro

copper laurel
#

right

oak quail
#

u can already use them if u have android alpha

copper laurel
#

yeah while it might be nice to be able to have it know where to fetch from I think that would introduce inconsistency in the expected behaviour

#

Since people will need to call fetchUser anyway?

oak quail
#

well if the bot is in the guild and it did the check, you could just do (await sticker.fetch()).user and it would work

#

but the sticker.fetch() would error if the bot isnt in the server

copper laurel
#

but it should fallback to the other fetch right?

oak quail
#

vlad seemed to want it to let it just throw the DiscordAPIError

#

but ig we could fallback

outer raven
#

Is there a difference between using the @readonly tag or making a type Readonly<> in the docs?

zenith oracle
#

I think only with the tag @readonly this can be showed

Screenshot_20210628-133236_Chrome_Beta.png
copper laurel
#

Readonly is a typescript type, not something jsdocs would understand

vernal atlas
#

Readonly<T> means that all the properties in T are read-only, but the object can still be 'overwritten' to put it simply

surreal geode
wild flax
#

No

#

Why?

#

Also non-standard headers

surreal geode
#

I thought for type safety/intellisense. What additional headers are used other than these three?

wild flax
#

anything can be a header

#

as long as the server on the other end handles/implements it

surreal geode
#

Makes sense, thanks

outer raven
vivid field
#

As sugden pointed out, @readonly means that the property on the class can't be overwritten, Readonly<T> means that the returned object itself is frozen

#

So they're not the same

outer raven
#

and how can we tell those two apart in the code?

vivid field
#

Tell apart where exactly?

outer raven
#

Which ones should have @readonly, Readonly<T> or both

vivid field
#

Readonly<T> when you use Object.freeze() or a similar method
@readonly usually when you have a getter without a setter

outer raven
#

Alright. I just found this odd because Readonly seems to be the only thing the docs don't link

unknown.png
#

is it worth linking this to ts docs maybe?

flint zephyr
sharp wigeon
#

Why don’t I get the proper intellisense for ColorResolvable

# 

type ColorResolvable =
    | 'DEFAULT'
    | 'WHITE'
    | 'AQUA'
    | 'GREEN'
    | 'BLUE'
    | 'YELLOW'
    | 'PURPLE'
    | 'LUMINOUS_VIVID_PINK'
    | 'FUCHSIA'
    | 'GOLD'
    | 'ORANGE'
    | 'RED'
    | 'GREY'
    | 'DARKER_GREY'
    | 'NAVY'
    | 'DARK_AQUA'
    | 'DARK_GREEN'
    | 'DARK_BLUE'
    | 'DARK_PURPLE'
    | 'DARK_VIVID_PINK'
    | 'DARK_GOLD'
    | 'DARK_ORANGE'
    | 'DARK_RED'
    | 'DARK_GREY'
    | 'LIGHT_GREY'
    | 'DARK_NAVY'
    | 'BLURPLE'
    | 'GREYPLE'
    | 'DARK_BUT_NOT_BLACK'
    | 'NOT_QUITE_BLACK'
    | 'RANDOM'
    | [number, number, number]
    | number
    | string;
``` it doesn’t show these color names with intellisense, maybe it’s just a problem on my end
fallow crater
#

had a similar issue before, I think it's bc of the | string. Not sure tho

solemn oyster
#

It is

sharp wigeon
#

Yeah that’s what I was thinking too

solemn oyster
#

Fixing that rn

loud jayBOT
#

pr_open #5950 in discordjs/discord.js by kyranet opened 19 seconds ago (review required)
types(ColorResolvable): change string to #${string}
📥 npm i kyranet/discord.js#typings/strict-type-string-color

solemn oyster
#

@sharp wigeon @fallow crater ^

sharp wigeon
#

thank you

solemn oyster
#

np meowthumbsup

vernal atlas
outer raven
#

Why can’t we just link it like a promise or an object?

vernal atlas
#

rafShrug i guess so

outer raven
#

although im not sure because most people don't use typescript (mostly beginners) so it might confuse them

#

and readonly is pretty self-explanatory by itself

#

so ill let that be for now

glass cypress
#

there should be a way to view the old design of the website

#

I find it easier to navigate

wild flax
#

Won’t be a thing

oak quail
#

for threads

Error [GUILD_CHANNEL_RESOLVE]: Could not resolve channel to a guild channel.
at GuildMember.permissionsIn
i sent this to ckohen over a month ago, looks like its still unfixed in master?

copper laurel
#

Assuming this happens when you pass a ThreadChannel?

wild flax
#

Yeah this needs a bit more info

ruby terrace
outer raven
#

Why was it decided to create the thread channel types with _ instead of the camel casing that is used basically all across the library?

#

Talking about public_thread, private_thread and news_thread which could be publicThread, privateThread and newsThread

#

the only places I see _ being used are in full caps names that usually come from Discord's docs

solemn oyster
#

cc: @ruby terrace ^

outer raven
#

Also it would be relatively easy to switch to a date-based version number for dev releases. Can I open a PR to change this so that dependabot starts working again and people stop getting confused when they install an old version with npm up? @wild flax

#

this is my proposal (YYYYmmddHHMM)

unknown.png
solemn oyster
#

No

#

The hash is handy because it prevents duplicated releases (aka releasing the same commit twice)

#

And it also helps identifying the commit in GitHub as well

outer raven
solemn oyster
#

It's extra steps, and also refer to the first point

outer raven
#

Ye I know but that doesn’t happen very often since a PR is usually merged every x hours

#

And even if it does it’ll be once and doesn’t hurt that much

#

It’s just that I’ve seen way too many people in #djs-help-v14 saying they have the latest version when they don’t because they used npm up

vivid field
#

That could also be fixed by deprecating outdated dev versions automatically

wild flax
#

Which they are

vivid field
#

Oh they are now?

#

I thought you just did it manually once

outer raven
#

Are they?

wild flax
#

I still do but it should only have 1 not deprecated

vivid field
#

At the moment yes

solemn oyster
outer raven
#

Well yeah but that doesn’t seem to fix the npm up issue unfortunately

#

Nor dependabot

vivid field
#

It did work for me in a test environment Nvm, installing an outdated version and then running npm update won't update to the latest commit

outer raven
#

ah ok cuz I was testing and it wasn't working for me

#

is it really that big of an issue if a "duplicated" version is released? Imo the pros outweigh the cons here

#

Its also easier for the user to know when the version they have is from

tacit crypt
outer raven
#

They have to go on GitHub and find the commit

solemn oyster
#

No, just paste the hash

outer raven
#

Way more complicated than looking at a number and getting the day from it

solemn oyster
#

e.g. https://github.com/discordjs/discord.js/commit/5ad83a6a65e5944ceb3a41fee2df40ba1f5b03e4

outer raven
#

Yeah it’s still more complicated than looking at a date

solemn oyster
#

Looking at a date is unreliable because GH shows local time while GHA uses another when releasing

obtuse hazel
#

There can be several commits on the same date so it won't be unique too

outer raven
#

Only 2 unless it’s manually ran

#

And the date is the least relevant, the day is enough and accurate enough as well

solemn oyster
#

We do multiple releases a day sometimes, tho

outer raven
#

The CI runs twice and Crawl sometimes runs it manually. I’ve never seen more than 3 releases in a day

wild flax
#

make it 7 SHA and a unix timestamp and I accept it

solemn oyster
#

But that doesn't offer de-duplication, Crawl

wild flax
#

13.0.0-dev.7_SHA.UNIX

outer raven
#

Fine by me

wild flax
#

thats fine, don't care enough, as long as this whining stops

solemn oyster
#

And not like the UNIX timestamp is readable at all

#

I could find the date a commit's from faster than getting the full date from the timestamp

outer raven
#

Wait yeah why not a date

wild flax
#

because dates suck

#

honestly

solemn oyster
#

I prefer keeping the system as-is, maybe reduce sha to 7, but that's all

wild flax
#

Dot seperation is nice

#

- separation is not

outer raven
#

But you can have both

#

Or none

#

My proposal was YYYYmmddHHDD but you can add dots in between

wild flax
#

yeah but if you do 20200628 you might as well do a unix timestamp

#

its not for the user anyway

outer raven
#

Why not?

wild flax
#

its to fix npm

#

I really don't want to discuss this, its a temporary thing anyway until we have proper pre-releases

outer raven
#

Will there be dev releases after v13?

wild flax
#

I'm not going to heavily invest into a system thats gone in less than 6 months

outer raven
#

Possibly for v14

outer raven
wild flax
#

I just don't like it

#

As much as you don't like the current system

outer raven
#

Fine then, I’ll try to find a way to get the unix timestamp and PR

#

So this is good right

unknown.png
wild flax
#

sure

outer raven
#

aight, will open rn

wild flax
#

Actually, now that I think about it, --short might be better

#

but it doesn't matter

outer raven
#

with the 8 chars?

#

sure

wild flax
#

it won't be staying "alive" for too long

#

its mainly to guard against collisions

outer raven
#

so should I change it

wild flax
#

but we arent a repo like the unix kernel lol

#

nah just keep things as is

outer raven
#

aight

wild flax
#

ah, vaporox brings up a good point

#

so I guess you might as well commit his change

outer raven
#

what does --verify do?

wild flax
outer raven
#

alright, will commit then

real jetty
#

wouldn't it be a good idea to create some guild webhook manager in master, just like how <Guild>.fetchBans() and BanInfo were removed and replaced with a GuildBanManager in v13?
maybe same for invites, integrations, templates, etc?

wild flax
#

We don't put managers everywhere on purpose

#

Only if it adds a real benefit

wild flax
#

A new dev version has been released with the changes.

outer raven
#

hmm npm up doesn't seem to be picking up on it but it doesn't downgrade either, lemme try dependabot

#

alright can confirm dependabot is working again, thank you!

remote wasp
ruby terrace
ruby terrace
#

only docs for startMessage need to be changed

outer raven
#

there are not many places that I'm aware of where lower_casing is used

ruby terrace
#

We're fighting two different library conventions, parameters are typically camelCased, whereas Constants are UPPER_CASED. I think the lowercaseing of channel types may have been an interesting (unsuccessful) attempt at ensuring camelCase for the properties. Not opposed to changing it, its just a very large whole library refactor

ornate topaz
#

Wait, where are we using lower_case instead of camelCase?

outer raven
#

more specifically news_thread, public_thread and private_thread

ruby terrace
#

channel types get .toLowerCased so I used that for all _thread types everywhere

outer raven
#

Yeah I don't blame you and I know it's a large change but so was changing to camelCasing in v10 or whatever it was so, for the sake of consistency, I think we should go for it

ruby terrace
#

just so you know, I'm going to do something about this, don't know what yet though, should have a PR within a day though

lone vector
ruby terrace
#

Looks like it got removed accidentally in the last rebase

lone vector
#

Seems like the changes in that PR weren't applied to that function too, unless that function wouldn't need them, I could potentially PR a fix though it may be easier for someone who already has an environment set up

copper laurel
#

I just fucked up a rebase there and deleted an extra line. Add the type back

#

That function doesnt need the changes

lone vector
#

Alright, will do

tender field
solemn oyster
#

Not really, because we're exporting ButtonBuilder, EmbedBuilder, MessageBuilder, and a few more, in later PRs to /builders

#

Which we'd like to expose separately (and outside Formatters, as they're different things)

#

An alternative, though, is to namespace them in /builders

#

But that might be bothersome if you use it directly

remote wasp
#

I was testing thread creation to decide how to document the params and believe me I had to bring out my notebook to write down all the possible ways in which startMessage and type param can be combined. I would share it but it looks horrible. This mess can lead to a lot of potential issues in the support. The solution I want to propose is to have two seperate methods for thread creation just like there are two seperate endpoints for them. For eg: ThreadManager#create and ThreadManager#createFromMessage or something along that line. This will remove all the issues that arise due to possible combinations of startMessage and type param.

ruby terrace
#

It could work, I highly anticipate people to never start a thread from a message using that function, instead using Message#startThread(). That paremeter exists so that can work.

all the possible ways in which startMessage and type param can be combined.
What do you mean by this though? They can't?

remote wasp
#

Yes correct, they don't as passing one specific param will do nothing in a particular case as it acts like a noop because something else will get passed no matter what you pass as value for that param. Which is where the issue is. The behaviour is weird because that params will matter sometimes and won't sometimes. We are mixing two endpoints into a single method and hence why this behaviour. I know I'm not making much sense here so I'll make a table to clear what I'm trying to say.

remote wasp
#

https://i.imgur.com/J4mfNr5.png
As you can see in the table the type param only matters when startMessage isn't provided. This means that type affects nothing in the other three cases. As you pointed out Message#startThread doesn't even talk about type because it takes the type from the message there and that's why it is much more clean. I was thinking about doing the same for manager. A method that creates threads from message and another that creates using type (just like the endpoints). This will seperate these two params into two different methods where their presence/absence does affect the result.

ruby terrace
#

The news _ + type column is wrong, its always news thread

remote wasp
#

right, my bad

ruby terrace
#

you see the problem here? type really only matters if provided on a text channels thread manager, and technically news_thread is an invalid parameter.
If you create a new function, createWithMessaage for example (cause I think it would be the less used one, called internally mostly) then you still have much of the same issue with create, always creates news in a news channel, but can have errors etc in text

#

Technically speaking doing this could make it much more type safe for ts users though since news doesn't extend text in that case. You just can't separate it in the actual code

#

With that, I say do it, adding something like

export class ThreadManager<AllowedThreadType> ... {
  public create(options: { ... type?: AllowedThreadType };
}
export class NewsChannel {
  public threads: ThreadManager<'news_thread' | 10>;
}
export class TextChannel {
  public threads: ThreadManager<'public_thread' | 'private_thread' | 11 | 12>;
}
#

to make it very type safe

#

it'll be hard to do for docs, but for ts users? worth it

remote wasp
#

So, just to be clear you want to:
Restrict values for type depending on type of channel the ThreadManager is on ✅
Want to divide the thread creation on manager into two methods redcross
Is that correct?

wild flax
#

I’m against 2 methods too

#

It kinda of goes against libraries design

#

We tried so hard going in a direction where we have a nice single method style

#

Throwing that overboard seems like a bad thing here

remote wasp
#

All right then restricting the values for type is what we are going to do

ruby terrace
#

By all means, give a shot to making the docs more clear too, I definitely understand it being confusing but I couldn't think of a better way to document it, the warnings being my best attempt.

remote wasp