archive-library-discussion

[paper furnace]

anyway i'm using constants which are made for it

is that normal to not being able to compare Message.channel.type to Constants.ChannelTypes ?

the first contains the API keywords as value, the second is numeric, why DJS don't use the same values everywhere?

[tacit crypt]

the ChannelTypes object is more of an ENUM (so we can go from number -> string and string -> number)

[paper furnace]

I don't see a mention about moving Guild.region info in the migrating doc, currently the value is not defined and I don't find it back 🤔

[raven juniper]

iirc regions are on voice channels now

[paper furnace]

maybe should i go to #archive-updating-to-v13 😅

oh ok, so each channel can have it's own region? that's pretty cool

anyway, v13 is awesome, seeing true typing is a real pleasure, I'm in love, tyvm for your awesome work ❤️

[outer raven]

@wild flax you commented on https://github.com/discordjs/discord.js/pull/6278 saying you weren't sure about it. The upstream PR is now merged and they said that default_auto_archive_duration is only intented to be used by clients and not the API so do you agree with defaulting autoArchiveDuration to that or should it be closed?

[lapis echo]

why does d.js use const enum over enum?

afaik const enum only exists now for legacy support.

[outer raven]

Scroll up just a bit, we talked about that earlier today

[lapis echo]

The thing is you can use enum as constants and manipulate them just like an object does, which const enum cannot.

[dawn merlin]

tldr; const enums allow users to use djs enums during runtime, without stuff crashing

[lapis echo]

crashing?

[dawn merlin]

yeah because you can't import regular enums without you getting an import exception during runtime

[lapis echo]

I could've sworn TypeScript enum can be used to manipulate as an object, unless I'm missing something?

[dawn merlin]

I'm talking in terms of djs, keep in mind djs isn't transpiled from ts to js, it just offers typings, if you have a 100% ts project then it'll work like a charm

[lapis echo]

oh wait, so the typings do not overlap for d.js' js constants?

[outer raven]

Which is why djs exports Constants which has all those enums. You’re not supposed to be using the enums from ts

[outer raven]

The enums in the typings represent those constants but you should use the constants and not the enums

[lapis echo]

damn, that kinda sucks

that's why i see so many people confused about it.

[dawn merlin]

yeah basically without const enums we were mapping enums to values that didn't actually exist, hence the changes

[lapis echo]

aha

[outer raven]

Why lmao

[lapis echo]

that makes a lot more sense why

[dawn merlin]

I mean unless you want reverse mapping you don't actually have to use Constants

[lapis echo]

Then my only question is why doesn't the typings just map over the Constants that are actually being exported to avoid confusion?

[outer raven]

The enums are literally put in a separate file to avoid that confusion

They’re not meant to be imported

You should just be using Constants, it’s the exact same

[dawn merlin]

bc there's no way to tell TS that it corresponds to another arbitrary enum that happens to be an object in JS

[lapis echo]

Then why does the enums exist if there not meant to be imported? Are they just private typings?

[dawn merlin]

they're meant to be used in the type declarations

[lapis echo]

Let me take a look at src code rq

[outer raven]

I really don’t understand why there’s so much confusion on this topic

[dawn merlin]

If you don't use the already declared enum types, then your method parameter types (in the typings) would have to be number or string

thats relatively loose typing compared to using enums

[lapis echo]

In typings/index.d.ts couldn't you just use a namespace? e.g.```ts
export namespace Constants {

// objects

export interface Package {
name: string;
version: string;
description: string;
// ...
}

// enums

export enum ActivityTypes {
PLAYING = 0,
STREAMING = 1,
LISTENING = 2,
WATCHING = 3,
CUSTOM = 4,
COMPETING = 5
}
}```

[dawn merlin]

honestly the might work, but as I said earlier most people are just going to not use Constants bc they don't need reverse mapping. But if that code above actually works during runtime I'd say that's a definite improvement.

[lapis echo]

I'd have to do some testing for sure, but I think that could definitely clean up that section of typings.

[dawn merlin]

also small nit: namespaces are deprecated in favor of modules now

[lapis echo]

Yeah, but this is just typings, if it were a full TypeScript project I would totally go with that approach. This approach shouldn't make a difference afaik.

[dawn merlin]

im pretty sure ts/eslint won't let you, but you can try

[lapis echo]

dang, well then I'll probably just leave it then, because tbh whoever wrote that section like that probably tried a namespace approach. I'd rather not go against elint rules.

[dawn merlin]

why not just use module instead?

[lapis echo]

Could give me an example of what that looks like?

[dawn merlin]

it's pretty much just like namespaces but you replace 'namespace' with 'module'

[lapis echo]

oh, hmm

I'll do some testing later then. If it works, I'll probably make a PR for that improvement.

[dawn merlin]

tested this out bc I was curious, can confirm that it does work, and properly finds the enum values during runtime 🎊

[lapis echo]

that's awesome!

[lapis echo]

are you ok with me making the pr or do you want to?

[dawn merlin]

nah, you came up with it you can make the PR

[lapis echo]

awesome, ty!

i'll make it tonight then.

[dawn merlin]

For reference this is what the syntax should look like:

export declare module Constants {
  enum ChannelTypes {
    GUILD_TEXT = 0,
    DM = 1,
    GUILD_VOICE = 2,
    ...
  }

  ...
}

[lapis echo]

ah, ok then, no need to export inside, that's nice.

[outer raven]

@dawn merlin my only question about #6840 is how can you be sure that user is never null on partial guild members, specially on the guild member remove event?

[dawn merlin]

in the ticket, @opaque vessel stated the ID is always present on all three of the events, so wouldn't it have to be non-null?

[lapis echo]

I'm not going to make the PR for that because most of the Constants contain property value types that are named the same as their key so I can't really do anything to avoid it except to put the type in their manually. It adds too many lines. The only way it would work properly is if we did more files so I could rename types exported from the file when importing them, but I'm not sure if that's something we'd want to do as there is a minimal amount of declaration files.

[opaque vessel]

The daunting issue is that the .id seems to be typed as always there, but .user is possibly null. I have no idea why these typings are conflicting - that's why I made the issue. It's weirdness

[dawn merlin]

oh so you were referring to the static types not the runtime types?

in that case my PR should probably be inversed

[opaque vessel]

I'm also unsure when the .user is possibly null. No idea when that may be

[dawn merlin]

so basically, it can be null, so therefore id should also be?

[opaque vessel]

Maybe? Maybe not. I don't know

[dawn merlin]

for what it's worth its documented to give a user object back

[opaque vessel]

All I know is that the typings are wrong. The id cannot be always there yet the user be possibly null

[outer raven]

Yeah I think the bug here is that id should be nullable

But more testing should be done on this cuz from what I understood, Jiralite’s issue was only covering types and not actual return values

[dawn merlin]

yeah I misread it, I had assumed that was runtime types

[opaque vessel]

But this is rather... weird? How the heck can we we receive a payload of a user/guild member without their id

[dawn merlin]

I mean I am reading the docs wrong, it gives a user back on the events? It's referencing the full user schema as well: https://discord.com/developers/docs/topics/gateway#guild-member-remove-guild-member-remove-event-fields

[opaque vessel]

Looks like it wasn't always null. It happened in a recent addition?
https://github.com/discordjs/discord.js/pull/6066/files#diff-4f45caa500ef03d94d3c2bfa556caa1642df95d4e2b980d76b876a8fd2e8c522L3831

[dawn merlin]

Hmm ok, I'm going to assume that, that diff is a regression

[opaque vessel]

I guess so

[dawn merlin]

@oak quail I thought bots didn’t get command C/U/D events?

[oak quail]

they dont anymore, correct

this updates cache when u use the c/u/d methods on command manager

[dawn merlin]

Ahh ok

[tender field]

in #6838, why not override channel to be GuildTextBasedChannels too?

[dawn merlin]

@tacit crypt what is the policy on empty interfaces that may or may not have properties added later in the typings. Should they just be type aliases or remain as empty interfaces?

[tacit crypt]

I'd say keep them as interfaces

[dawn merlin]

Ok

[dawn merlin]

Good point

[outer raven]

Could we maybe have an object in every message that includes all the text in between formatting tags (so all the italic text, all the bold text, all the spoilers, etc)? I just wouldn’t be sure what to call this but it would work similarly to mentions

[unique axle]

why? that seems like a lot of additional memory, unless you want to make them getters which just throw a regex against the content and even then i can only think of edge use cases

[outer raven]

well I have a very specific edge case so I'll explain that
there's a bug in discord that allows you to hide text in a message (mentions included) by spamming a lot of empty spoilers and then writing after them. I don't know what the exact amount is but I'd like to delete these messages automatically and that would help, but it's obviously possible without that
If it were to be a getter, do you suggest one getter for each type of formatting or one getter that returns an object with all?

[unique axle]

i think that that's a good use case, but something very easily solved on your end and does not need a library solution

[visual hornet]

couldn't you just use (or make i guess) an external library to parse the Message#content

[outer raven]

well yeah what I can do is simply check if the message has an empty spoiler and delete it, but I thought this feature could possibly help others

[unique axle]

it's a super specific and super narrow use case to support in the base library

[outer raven]

wouldn't require an external library, a simple solution to my problem specifically could just be a simple .includes() function, this is just an idea I had from that case

[outer raven]

fair, thanks for the feedback

[visual hornet]

sorry should have been more specific, i meant the original question (of parsing the entire content for markdown)

[outer raven]

ah I see
well still, that could just be done with a series of regexes

[bitter peak]

Could something like this be useful?

[dawn merlin]

I don’t think djs does command handling

Is there a reason that toJSON on structures don't return the discord api types, but instead return the djs object with camelcased keys?

[real jetty]

The toJSON() methods existing on the structures only return a JSON-serializable (JSON spec complaint) object of the original object so it can be consistent and spec complaint, for example it converts bigint literals to strings as the JSON spec does not have a way to serialize them, and to not get users confused when they store the object as a JSON, so the properties and method names would be consistent, but only for now; the return values of the methods might be changed later

[analog oyster]

this doesn't explain why, but it suggests changing the methods to return the discord api types objects
https://github.com/discordjs/discord.js/issues/6567

[solemn oyster]

It's a proposal for v14 at this point

[dawn merlin]

idk if it's just me, but I can get @Typescript/eslint to successfully parse and report linting errors on .d.ts files 👀

[outer raven]

Yeah those errors do exist and there’s actually a tslint ignore comment on the typings file, but did you change anything?

[real jetty]

i dont see one

[outer raven]

It is there tho

[real jetty]

what line?

also, tslint and eslint are different so that would be a // eslint-ignore line

[outer raven]

tslint ignore on line 1036 in master

[outer raven]

Is there anything in discord-api-types that holds all the rtcRegion ids?

[dawn merlin]

Yeah I set up/installed the typescript eslint plugin

I was under the assumption that eslint didn’t parse declaration files, that’s why tslint was still used

[outer raven]

we use dtslint tho and yeah I thought so too, but if you managed to get it working with dtslint uninstalled that would be amazing because microsoft themselves say thats not meant to be used

[analog oyster]

dtslint uses tslint, which has been deprecated for a while. so yeah, switching to eslint would be great

[wild flax]

Good luck replicating the dtslint rules

[opaque vessel]

No, mainly because it's not documented on Discord's side

[outer raven]

Well its an endpoint and it rarely changes, so maybe it could be added? I was gonna add this to djs anyway in a pr, but could use dapi if it had those

One thing I’m not sure about is if we should put deprecated regions in there because my guild still has it’s region set to central-europe but this doesn’t appear in the endpoint

[wild flax]

If theres no publicly known list, we don't put it

[outer raven]

it is publicly known if it's in the endpoint

and it's reliable enough that we can put it in the docs and types and update it when/if it does update

[wild flax]

Not really

That list could be dynamically updated

[outer raven]

if there's people noticing new flags before they're even released im sure someone would notice those too

[ornate topaz]

that's not exactly what "dynamic" meant here

[wild flax]

If its not on the docs, I don't see why it would be documented

What is that argument here?

Flags and new errors get documented

[outer raven]

that while they're not documented, someone would notice they changed and could update them

and kyra seemed to like the idea too

[wild flax]

And why would you randomly or consistently, 1x a week, call an endpoint and check?

lol

We implement the API based on the docs not the information returned from the api via endpoints

[outer raven]

why not? I mean saying that we can pass any string to that is not exactly true so having some sort of suggestion would be nice

[ornate topaz]

can you document content of last message in a channel?

[wild flax]

Because if something is not documented, its not meant to be

[opaque vessel]

At the very least you should think about documenting it at Discord's API documentation before here

[outer raven]

Guess I’ll try that then

[dawn merlin]

Anyone know the answer to this? 😅

is there any circumstances where the message is sent in a guild but the guild happens to not be cached?

[wild flax]

Not if you don't mess with the client cache

which is unsupported

[dawn merlin]

Ok ty

I believe if you don’t have the message intent, you don’t receive message events at all

[visual hornet]

if you don't have GUILDS you won't recieve messages from that guild either
even with GUILD_MESSAGES

so the only thing should be messing with cache

[outer raven]

Does anyone know why we export the api types as RawX?

Wouldn’t the name from dapi types be just fine

[dawn merlin]

It might be because Dapi types aren’t a dep on djs, and the only way to expose them would be to reexport them? But I’m not sure

Yup

[ruby terrace]

Most of the api types need to be unions because they come from as many as 6 different places in the API, so for conformity

[outer raven]

But there are a LOT of Raw types that are literally just an API type renamed, I’m talking about those

[outer raven]

It is a dep tho

[ruby terrace]

1. I don't think its "a lot" by any sense
2. As I already said, consistency
3. Ease of maintaining it, it's a lot easier to add to / adjust a union in one place than all over the place.
4. As far as I'm aware, vsc doesn't even ever surface the "raw" types, instead displaying the underlying type / union

[outer raven]

I get that unions need to be there but I don’t get why some types are literally just renamed. And yes I’m not using these on my project, just talking about development really because I’ve used the raw API types before and had no idea these existed like this 🤔

[ruby terrace]

Its not all raw API types, its specifically the types that are used as data when constructing a structure

[outer raven]

@ruby terrace just a question: is there really no other way to do this?

like having 2 properties documented that do the same

if anything that should be mentioned on builders jsdocs right?

also you missed the types on your PR

[dawn merlin]

Typings are not yet updated due to a potential issue with choices and min / max that I will be noting upstream

[outer raven]

ah aight

[ruby terrace]

I could do an info block at the top:

In addition to the listed properties, when used as a parameter, API style snake_case properties can be used for compatibility with generators like @discordjs/builders. Note that providing a value for the camelCase counterpart for any snake_case property will discard the provided snake_case property.

[outer raven]

yes please

[outer raven]

Why not just have that all in the info block

Seems more logical

[ruby terrace]

I debated that originally, decided to do it that way

(comment that on the pr, I'm interested in opinions)

[outer raven]

Aight, will do

[opaque vessel]

https://github.com/discordjs/discord.js/blob/579569ae18d5a2dbcb39ad5e5adfe486315467ea/src/managers/RoleManager.js#L140
What's the meaning of restricting this to the current guild this is being called in?

[opaque vessel]

*Technically it resolves ReactionEmoji and GuildEmoji no matter where it came from before it attempts to look into the cache, so the warning block here isn't accurate.

Anyway, it will work without being restricted to the guild as the URL is uploaded, so there's no need for restrictions here, so...

[outer raven]

I suggested using client emojis but they said the cache is too big and would be a useless performance hit for bots in lots of guilds

and also the client only shows you emojis from that guild when applying a role icon

I assume it wouldn't be accepted now if it wasn't accepted when I suggested that on the main PR

lemme find the discussion

https://github.com/discordjs/discord.js/pull/6633#discussion_r719722149

none of the maintainers replied tho so idk

[opaque vessel]

Okay, well, the warning is a lil' inaccurate - only the id needs to belong to the guild, other resolvables don't need to be

[outer raven]

EmojiResolvable does need to belong to the guild, that is correct

Not sure what u wanna change here

[opaque vessel]

The description says the "same guild"

[outer raven]

Which is correct

[opaque vessel]

I said this already :P but no, because resolver methods return if it meets an instance, which means you can pass in an emoji from another guild

[outer raven]

what are you looking to change I still don't get it

the warning is completely accurate in my eyes

[copper laurel]

only the id needs to belong to the guild, other resolvables don't need to be
This. Not every type that is part of EmojiResolvable needs to belong to the guild, only string

[outer raven]

ah I see what you mean

eh I guess it could be changed but doesn't make that big of a difference

[opaque vessel]

A provided Snowflake must belong to the same guild as the role.
This is a better description of how it's handled internally

[outer raven]

Could we start adding deprecation messages to the types?

[vagrant holly]

They exist for the deprecated client events already

eg. https://github.com/discordjs/discord.js/blob/579569ae18d5a2dbcb39ad5e5adfe486315467ea/typings/index.d.ts#L3511-L3512 https://github.com/discordjs/discord.js/blob/579569ae18d5a2dbcb39ad5e5adfe486315467ea/typings/index.d.ts#L3545-L3546 https://github.com/discordjs/discord.js/blob/579569ae18d5a2dbcb39ad5e5adfe486315467ea/typings/index.d.ts#L3565-L3568

[gentle folio]

Canvas is not compatible with v13?

[raven juniper]

If is, please see #djs-help-v14 if you have specific questions about the lib. You can also search in the channels, someone just asked about canvas on node 16

[outer raven]

well yeah only those ones do (and I'm not sure if they display correctly), but wouldn't it be better for all deprecation tags to have messages associated with them?

[vagrant holly]

Sure, if there's an associated jsdoc deprecation notice that has a message, I guess it makes sense to also have it in the typings deprecation flag

[outer raven]

ideally we'd have all jsdoc comments in the typings file so they show up in the editor. but that's way too much work

[vagrant holly]

get an IDE that actually reads the source and so knows about the jsdoc comments, as well as the typings

[opaque vessel]

The one I just did has one too. Managed to make it a cute lil' link

[outer raven]

the link doesnt work tho does it

[opaque vessel]

It does, doesn't it for you?

[outer raven]

oh my god it works

i had no idea

ok will pr to add it to all the other deprecation tags

only one I will not add is MessageEmbed#type since idrk what to say and the docs don't have a description for that either

wait most deprecation tags have descriptions and there's only 8

well nvm i guess

[dawn merlin]

Wait should we be deprecating types that we remove in favor of other types?

Bc I have not been doing that 😅

[outer raven]

what exactly do you mean

he's deprecating that because it will be removed in a semver major update

breaking type changes usually aren't classed as semver major, only if the actual code changes in a breaking way

[dawn merlin]

Yeah ik, but I didn’t know if we needed to offer deprecation notices for breaking type changes, while they’re not semver major, they can still break ts projects

[outer raven]

they can break but in a way that should've already been broken before
imo if its an easy fix you shouldn't mind if, otherwise maybe consider a deprecation warning

[outer raven]

@dawn merlin if you’re gonna open a new pr to move the types you can probably just repurpose that one right?

Just gotta undo the changes in the non ts files

[dawn merlin]

no I'm gonna do it in 6867

it's small enough to tack on

[outer raven]

Wait which one is that

[loud jay]

#6867 in discordjs/discord.js by suneettipirneni opened <t:1634750646:R> (review required)
typings: cache types cleanup
📥 npm i suneettipirneni/discord.js#typings/cache-type-cleanup

[outer raven]

Ah gotcha

[real jetty]

Could we get some type narrowing for interaction#member so we don't have to do this?

[dawn merlin]

yup it already exists, interaction.inCachedGuild()

also ironic you and daro have very similar pfp's

[real jetty]

oh lol, whoops

[paper furnace]

Is DJS 13 compatible with ES2020 ? I need BigInt support for my bot but when I'm setting up the project I'm always encountering this issue from DJS files:

ERROR :  C:\Wumpus\discordjs-bot\node_modules\discord.js\typings\tests.ts:1
import {
^^^^^^

SyntaxError: Cannot use import statement outside a module

When I'm creating a whole new project without deps it works well, once DJS is added to the project this error appears. IDK if opening an issue for it is relevant, 'cause I don't know if it's really related to DJS source code, or Jest which currently seem encountering some issues with Node 16 🤔

[vernal adder]

Yes, it is fully compatible with ES2020.

[dawn merlin]

Djs is es2020 compatible if you want assistance please use a help channel

[paper furnace]

@dawn merlin in fact I'm mainly asking about a potential issue related to a dep you're using for your tests, to see if it can be relevant to point it out in a new issue or not

[vernal adder]

I am using ES2021 with discord.js v13.

But I am not using ts-node.

[dawn merlin]

We aren’t using any deps for our ts tests other than well, typescript

[paper furnace]

ok, so moving to node16 lead my setup to this error, pretty weird, then i'll continue to dig into

[dawn merlin]

@tacit crypt do you wanna steal #205 in dapi-types from me, I feel like it would be faster, because I don’t know where some of the types would go

[tacit crypt]

Whats #205 again?

[dawn merlin]

Autocomplete types

Ig anyone familiar with the types can take it over

[tacit crypt]

I mean the PR looks fine, you just have to fix your compile errors

and the inconsistency between AutoComplete and Autocomplete

[split elm]

Hey, plz add a function to "reset" a select menu (that is to say, the select menu returns to the form it had before selection)

instead of having to edit the message to reset the select menu

[ruby terrace]

That seems like a feature request for Discord, not djs

[outer raven]

iirc if you don't touch a message's components when editing a message it won't change the select menu if thats what u mean

[split elm]

no, I'm just asking for a function that would actually remove the selection from the menu

[outer raven]

that's just resetting the default property on the option

[split elm]

that is to say ?

[copper laurel]

Editing the message is the correct way to do it though. Are you proposing a method like Message#resetComponents() that would just do a no-change edit for you?

Most of the time you want it to be part of an interaction response though

[split elm]

Exactly ! It’s for a « role menu » for example

[copper laurel]

So it would really be more of a SelectMenuInteraction#reset() method, which would behave like an update with no changes

[split elm]

Yes 👍

[fallen pasture]

can bots send and receive messages between eachother in DMs?

[unique axle]

no

[fallen pasture]

saved me a lot of effort thank you lol

[dawn merlin]

What’s the purpose of having bots dm each other lol

[fallen pasture]

lmao it’s a very interesting reason

there’s a website that has stats for this game called DayZ, and there’s a discord bot connected to it and a command will display your stats, i wanted to have my bot send the command and display the response on a webpage

the dude that runs the site doesn’t wanna take the time to add a “daily stats” function so i’m doing it myself lmao 😭

he put a lot of work into it tho i’m not complaining. just a qol i want

[slate nacelle]

We do not filter any members out.
You might not have had all those members cached at point in time of kicking.

[severe sun]

member.roles.add(["901232121149018112"]) // This is an invalid role id

On v12 this code gives an TypeError [INVALID_TYPE]: Supplied roles is not an Array or Collection of Roles or Snowflakes. error
however on v13 it doesnt throw any errors ?

[opaque vessel]

On version 12, an actual role is attempted to be resolved. On version 13, the id is only extracted. So, this is expected behaviour. It's a bit strange you would pass an invalid id in the first instance

[severe sun]

its an invalid id because the role was deleted

[slate nacelle]

I'd expect this to error on Discord's end however.

[outer raven]

Are you guys aware of any bugs with creating channels with positions? I'm currently trying to create multiple category channels and sometimes the rawPosition and position properties are different and, on Discord's side, there are 2 or more categories with the same position until one of them is manually moved through the client

[slate nacelle]

I only remember Discord ignoring the position if it's 0.

[outer raven]

weird because that's not the case, I have two rawPosition 4 and no rawPosition 5 then a category at rawPosition 6 sometimes

and this is weird because on the client they don't even show up in those positions (the duplicated ones)

[slate nacelle]

rawPositions can be duplicated, since category channels even more

[outer raven]

but should they be duplicated among categories? I know they are different from categories to regular channels and voice channels but im exclusively working with raw positions here

[slate nacelle]

If Discord wants it to be that way, then sure I guess.
If they are equal, compare the ids instead.

[outer raven]

So do I have to make subsequent calls to update the positions after I create the channels? That sounds like a Discord bug imo

[slate nacelle]

One, since you can bulk-update positions, can't you? Might be a bug though, since the client doesn't allow you to create a channel on a specific position it might have gone unnoticed.

[tacit crypt]

Positions as a whole are a headache

[outer raven]

you can through the API but there is no method to do that on the manager 🤔

there is channel.setPosition tho

[slate nacelle]

It's one the guild still.
https://discord.js.org/#/docs/main/stable/class/Guild?scrollTo=setChannelPositions

[outer raven]

oooohhh I thought it would make sense for that to be on the manager

will have a look, thanks

[slate nacelle]

I too think so, probably an oversight, since those are very niche methods.

[vernal adder]

For it to be in guild#channels#setPositions would be better, in my opinion.

[outer raven]

could be something for v14, not worth the effort atm to duplicate the method

[tacit crypt]

you wouldn't duplicate, move the core logic in the manager and keep/deprecate the guild method with making it call the manager one

[vernal adder]

That is a status. These things:

[visual hornet]

(except the "custom status", that's also an activity)

[vernal adder]

You are looking for this: https://discord.js.org/#/docs/main/stable/typedef/ActivityType

[outer raven]

will do then

[outer raven]

Since Discord sends the timestamp of when a rate limit will expire in the x-ratelimit-reset header, could we use that to provide a date object in the RateLimitData object received in the event?

[manic thistle]

hey it seems like there's a problem with creating stickers.
it looks like it defaults to treating it as a jpg file, which makes discord throw an Invalid Asset error.
shouldn't passing stream or buffer data without the file name for context be disallowed to avoid this issue?

[loud jay]

#19 in discordjs/docgen by xHyroM opened <t:1634930049:R> (review required)
fix(Tsukabi): remove
📥 npm i xHyroM/docgen#master

[wild flax]

Why though lol

[outer raven]

why is readfileSync being promisified if readFile exists

[dawn merlin]

Gonna work on making docgen accept TS types at some point, I think typescript-eslint/estree-parser would come in handy here

[outer raven]

What would be really awesome would be to move all jsdocs to the typings and have docgen read that instead so that we can get jsdoc comments in the IDE

[dawn merlin]

I think the ts rewrite will be a better time for that

[primal prairie]

hey, not discord.js but, does anyone know a npm package that can fetch a whole channel and send it as an html transcript? all of the packages i found are able to fetch 100 messages only, but i know this is possible cuz ive seen it done on ticketing bots.

[outer raven]

what you see on ticketing bots is either some sort of data storage in a database or keeping all messages in cache, discord does not allow you to fetch that many messages

[primal prairie]

oh, the ticket tool bot has transcripts that contain all of the messages in a channel tho

[vernal adder]

This channel is for developing discord.js, not asking about downloading a channel

[outer raven]

yeah you should've stopped at the "not discord.js"

[primal prairie]

oh, ooh my bad, sorry thought it was for external discord.js libraries 😭

[patent widget]

Slash commands add limit must be increase

[ornate topaz]

nothing is a "must", and since we are not discord, this is not in our control.

[outer raven]

If you were at the DDevs Q&A you’d know that they are looking into ways to improve this and possibly increasing the limit, but this is definitely not a topic for this channel nor this server

[patent widget]

Thank you for responding. I apologize for misusing the channel.

[real jetty]

Is there a possibility for the library to support SlashCommandBuilder objects for command creation (guild and global)?
Currently, it is not possible to create a slash command with the builders (discordjs library) because of the incompatibility of the types.

[dawn merlin]

This was fixed in 13.2 I believe

[real jetty]

I didn't see it in the patch note, I have to check it then

[dawn merlin]

https://github.com/discordjs/discord.js/pull/6621

[real jetty]

Hummmm, this is not fixed...

"discord.js": "^13.2.0",
"@discordjs/builders": "^0.7.0"

[dawn merlin]

can you provide the error message it's giving you?

[real jetty]

Maybe we should move in #archive-builders if this is a development problem on my side :/

[outer raven]

Don’t you just need a non-null assertion?

[dawn merlin]

Go ahead and create an issue ticket for this, and I'll take a look later

[dawn merlin]

it's saying that ApplicationCommandType.Chat input isn't assignable to ApplicationCommandType.Chat | undefined, it looks like an enum mismatch maybe?

[tacit crypt]

You're just encountering a version mismatch between -types in d.js and /builders

[real jetty]

Ho yes, discordjs use 0.23.1 and builders use 0.24.0. But the result is that the two modules are incompatible and it's a pity especially since they are made by the same organization 😂 I will create an issue in few minutes

[outer raven]

Solution: bump on djs

idk why no one bumped it yet

usually crawl does on release but if someone prs they can have that on the dev versions

[dawn merlin]

If you’re comfortable you can just make a PR, just gotta edit the package.json version and ur set 😄

[tacit crypt]

and lock file

[dawn merlin]

Tru run npm i before pushing 😅

[outer raven]

speaking of lock file, why doesnt that have the "name" property on the first object? I always get that when running npm i for some reason

[vivid field]

a recent pr added that I think

yeah, #6809

[outer raven]

oh really

ah i see it now

didn't even notice that but finally lol

[vivid field]

(you're supposed to run npm ci anyway)

[outer raven]

when there's no node_modules yeah I do that, otherwise npm i which is the recommended

[woeful rain]

• why tsukabi when you can use the built-in module.

[outer raven]

Using the built-in module would just be importing readFile

[woeful rain]

okay

[outer raven]

Commits are done in bulk so I don’t think so but it should definitely be improved on because commits were happening much more often when this was first added

[outer raven]

Stuff might be a lot different with readFile tho since you gotta pass a callback to that

[woeful rain]

done

[visual hornet]

can't you just use fs/promises
that already has a promisified version

[woeful rain]

so require('fs/promises') ?

[visual hornet]

i guess?
i haven't been following what you're trying to do

[dawn basalt]

How long is the ETA for Autocomplete to land in D.js?

[copper garden]

Wdym? d.js already has typings

[dawn basalt]

Autocomplete, in the sense of what was said/shown in #announcements

[slate nacelle]

That's waiting on https://github.com/discord/discord-api-docs/pull/3849

[dawn basalt]

[uneven rain]

https://discord.js.org/#/docs/main/stable/class/GuildMember?scrollTo=send the example shows how to send a message to a channel, not a member

[zenith oracle]

The documentation is the same for all the send methods related to a TextBasedChannel

It's actually just one. The one from GuildMember inherits the documentation from TextBasedChannel#send

[vernal adder]

It's just a short-hand for sending to their DM-channel. It still sends a message to a channel, but I can see it being somewhat weird.

[vernal adder]

Same thing applies to guild#setRolePositions

[outer raven]

@vernal adder did you see #6875?

[loud jay]

#6875 in discordjs/discord.js by ImRodry opened <t:1635031757:R> (approved)
refactor: move Guild setPositions methods to managers
📥 npm i ImRodry/discord.js#refactor-managers-setpositions

[vernal adder]

Not yet, will look soon

Looks good! 👍

[outer raven]

Noice

[outer raven]

Hey @wild flax https://github.com/discordjs/collection/pull/46 has been lying there for quite some time and it didn't get any attention from maintainers so could you take a look at it please? Sorry for the ping

[wild flax]

Thats actually just an error in tsubaki

I flipped the important parts:

    "exports": {
        "import": "./dist/index.js",
        "require": "./dist/index.mjs"
    },

👴

[woeful rain]

Yes, but then I actually said why is Tsukabi there, so I made a fork, and I made a PR.

[wild flax]

Because the docgen runs at node 8+

and it was written when it was running like... 6+?

and tsubaki automatically falls back to using promisify anyway if you are on 8+

Oh and the other reason this happens is because the CI uses npm i and not npm ci

so it automatically installs higher patch versions lol

its fixed though

no need for me to re-release the docgen this way

[lofty birch]

I think I found a bug with the library. When the client is first added to a server after being logged in, Guild#available is undefined, when it should instead be true. This behaviour did not exist in v12.x

It's also documented to be a boolean, not boolean|undefined

[opaque vessel]

Fixed in 13.3
https://github.com/discordjs/discord.js/pull/6769

[wild flax]

not yet released though

[lofty birch]

Ah

This caused me several hours of pain, wish I knew that

[outer raven]

can we make a PR about a new discord feature if the dapi docs pr isn't up yet?

there's a thing that started rolling out but no one bothered to PR and i dont really like doing PRs to the docs but I'd be comfortable with the djs pr

well yeah i know that

[wild flax]

setPremiumProgressBarEnabled is a really mouthful name for a method

[tacit crypt]

It's also a big property, so I don't see an issue with it

[wild flax]

doesn't a boolean indicate a state already?

setPremiumProgressBar should be ok here for the method no?

[tacit crypt]

Removing the enabled can mean many things - set it to a number, to a goal, to something

[wild flax]

I agree that we should stick for properties with the API naming

but since we wrap things, I don't see why we would need to keep the explicit naming for methods

Well yes, but for that documentation exists too

[tacit crypt]

I mean this to me sounds like we can change the progress bar to something custom, not toggle its enabled state

[wild flax]

hmm

[tacit crypt]

true but ideally you should know from the method name what you expect to change

[wild flax]

I guess its whatever

But for v14 id def like to get rid of some of that ugly naming we have for those things

[tacit crypt]

And change it to..what

just remove utility functions like these no, someone will kill me for daring to bring that idea up

[wild flax]

not in this specific case, but we could also go with togglePremiumProgressBar()

if you supply a bool, its getting sent, if not, it flips the current state

[tacit crypt]

Hmm..we could, sure

[wild flax]

im ok with leaving it like this for now

but we have a lot of those ops, where we could name them toggle and flip states

[tacit crypt]

Definitely something for v14, although i know people will rage due to it 🙄

[wild flax]

I wanna build a good wrapper though and not be a people pleaser :P

[tacit crypt]

I want a mix of both

Although if it was after me I wouldn't even add these shortcuts because it's just extra code that adds little benefit other than a shortcut

[wild flax]

I think its important and makes code more idiomatic

instead of always calling edit() with a different partial object

[tacit crypt]

GuildEditBuilder

I suppose that's true, anywho

[outer raven]

Thing is you’d have to keep set methods for things that don’t take booleans so wouldn’t that look inconsistent then?

[wild flax]

not really no

those helpers aren't really meant to represent the edit values 1:1

but rather have them being used as a more idiomatic way

[outer raven]

So what else would you name them?

[tacit crypt]

.

[woeful rain]

Well, it was useful back then, but now it's useless to support such old versions of nodejs, after all even djs switched from v12 support to v16.

Now Tsukabi is completely useless in docgen, because docgen requires a minimum version of nodejs 8.

[outer raven]

but I'm talking about methods that don't take boolean values, those would still have to be setX right?

[dawn merlin]

Can’t you use the js “set” modifier for those?

[outer raven]

You can’t have a property and a method with the same name, even if it’s a set

Because then it would be
this.nsfwLevel
set nsfwLevel

For example

[dawn merlin]

well if we're talking in the context of v14, which may or may not have es2022 support, this is possible with private fields:

class A {
  #prop;

  set prop(value) {
    this.#prop = value;
  }

  get prop() {
    return this.#prop;
  }
}

[outer raven]

why would we make everything getters? And still, can we have a get and a set with the same name?

[dawn merlin]

yes you can have getters and setters of the same name

[dawn merlin]

This is how the design works, if you want "truly" private props, you can't expose them publicly, they have to be behind a getter. Any other solution still allows anyone to “arbitrarily” edit the value, even though they shouldn't

[outer raven]

hmmm would have to be discussed then, I'd rather see a PR with that later on so that I can judge better

and of course, would also like to see what the maintainers say

[vernal adder]

Sounds unnecessary to make every private prop a getter/setter.

Don't see the point of that.

[dawn merlin]

Not every value needs to be private. Ones that can be edited without side effects, don’t need to be. However I was pointing out if we want truly private storage get/set is the only way to go about doing that, otherwise you can’t access it. Otherwise you just have props on an object that can be edited without using the proper setters. I’m just throwing in my 2 cents, we’ve been doing pseudo-private props so it’s up to the maintainers if they want to continue that or use another method of private storage.

[vernal adder]

IMO it's the end-user's fault if they mess with private properties. If they're marked as private you should not mess with them. If you do, that's your fault.

[solemn oyster]

Problem with true privates is that they're incredibly inefficient, both CPU and memory wise

Since it relies on WeakMap

[dawn merlin]

that is a good point

[outer raven]

Was looking at the code of GuildMember#manageable and this seems wrong: if the logged in user is the user in question and is the owner, why should this be false?

[slate nacelle]

I don't think it made much sense to declare the owner being above the owner, looking at the description of the getter.

[outer raven]

from what I can see the third if should be moved to the top right?

[slate nacelle]

No, that'd make GuildMember#kickable return true for the owner if the bot is the owner. You still can't kick yourself however.
(Same for GuildMember#bannable)

[outer raven]

maybe the issue is those getters depending on this one then, because as-is, this will return false when checking for the bot's guild member in a guild they own

[slate nacelle]

This behavior sounds about right, when looking at the description.

[outer raven]

technically yes but the point of using this "for moderative actions" is to know if you can run certain methods on the member in cause, which you can if the member is the clientuser's member object

[slate nacelle]

What else is there, aside from the two above, which would break here?

[outer raven]

wdym?

[slate nacelle]

The certain methods you mentioned.

[outer raven]

oh no they wouldn't break, I'm just saying that if you have, for example, a function that relies on member.manageable to be ran and the value turns out to be inaccurate it won't complete

[slate nacelle]

It's accurate however.

[outer raven]

say for example member.setNickname

[tacit crypt]

A bot cannot act on its own users - it can't kick itself, it can't ban itself, it can only add roles to itself that are lower than its highest role

and the setNickname has a different endpoint for the bot user vs normal members
technically space we were tied

[slate nacelle]

Setting your own nickname is, in the api, something else than setting another member's nickname.
too slow again

[outer raven]

well but the method is the same on djs isn't it

[vernal adder]

Doesn't look like it.
https://github.com/discordjs/discord.js/blob/26340acad946989e9a8825966b76c506d82fc641/src/managers/GuildMemberManager.js#L252-L260

[outer raven]

well yeah it is

talking about the method, not the endpoint

[tacit crypt]

Makes a difference how

setNickname calls edit

edit calls the function Drango just linked

[outer raven]

yeah exactly

[wild flax]

Pretty much everything calls edit

[outer raven]

but say you have a generic function to edit any member's nickname, and that relies on member.manageable (so you don't have to catch every time), that will not run when the member in question is the client user, but it should

[tacit crypt]

But it would make every other check inaccurate or outright wrong

And even then, manageable doesn't even get into the permissions side of things

[outer raven]

oh yeah I know I'd also have to check for MANAGE_NICKNAMES here, but both checks would need to be ran

is there a better way to do what I'm doing without using manageable?

[tacit crypt]

Except its not MANAGE_NICKNAMES for own member

[outer raven]

yeah ik

[tacit crypt]

Then what are you trying to get at??

Manageable is strictly role hierarchy wise

I mean we can guesstimate that if user.id === client.user.id, its manageable, but it's not 100% accurate

[outer raven]

hmm I guess this breaks more than what it fixes so it's better to leave it as-is ig

will do my own checks for the client user

[tacit crypt]

I mean.. cogwheels are spinning... wouldn't moving the client.user.id === guild.ownerId above then checking the user.id === client.user.id and returning true... that sounds like it'd make sense but either way we're still not 100% accurate

You might have a point, hold on I need to check things now

[tacit crypt]

It wouldn't, since first check is if user.id == guild.ownerId, which will make manageable return false

[tacit crypt]

Neverminddd this

[outer raven]

wait i didn't see this, so what's the veredict?

[tacit crypt]

It's correct the way it is rn

[outer raven]

aight

[hollow crest]

Could anyone tell me why the MessageComponentCollectorOptions type in index.d.ts omits the message option from InteractionCollectorOptions? Passing a message option to createMessageComponentCollector is extremely useful, I have been doing so for a while as I find it far more elegant that using the filter option to filter interactions that came from a specific message.

It is possible in JavaScript so I am confused as to why it is being omitted from the type for typescript.
These are the relevant lines from index.d.ts:

[copper laurel]

uhhh, createMessageComponentCollector is a method you call on a Message instance (or TextChannel). It binds to the Message/Channel you're calling it on, not the one you pass in

If you want to construct a generic MessageComponentCollector you should be able to with those options though, so it does seem odd that it would exclude them.
@dawn merlin is this one of your typings?

[outer raven]

doesn't seem to be his, at least not after the rewrite

[copper laurel]

Oh I see why

Yeah, MessageComponentCollector isnt a class. Either you're constructing a generic InteractionCollector in which case those options exist and are entirely valid in InteractionCollectorOptions, or you're using <Message|TextChannel>#createMessageComponentCollector in which case it binds to the instance on which it's called, not the passed options

[dawn merlin]

I don’t know if passing a message option in js is actually doing anything. iirc There’s no equivalent js typedef so it uses the base interactioncollector. For reasons monbrey stated the type was made stricter for typescript

[uneven rain]

GuildStickerManager#create should throw a error saying You didn't provide any tags or something like that when you didn't provide any tags

[hollow crest]

It is definitely doing something, I tried removing it and I got different results, it tried to collect interactions from buttons on other messages and threw an error. However, the solution you guys have brought to my attention is just to call createMessageComponentCollector on the message instead of calling it on message.channel and passing in a message parameter.

[raven wind]

what exactly is your mission here?

[hollow crest]

Thank you

[opaque vessel]

Seems some files import @discordjs/collection without respect to the import/order rule from ESLint, which isn't being picked up from npm test. Example of this is at src/structures/interfaces/Collector.js on line 4:

[outer raven]

what does it say currently?

[outer raven]

nope, thats an issue in your IDE, it is correct

[uneven rain]

it throws a error

[outer raven]

which error lol

[uneven rain]

saying cant read property name of undefined

[outer raven]

ah

then yeah sure

will look into doing that

[outer raven]

to elaborate on this: VSCode and more specifically eslint comes with a bundled node version that is set to node 14 by default and thus your IDE sees a "node:X" import as a regular package and not a built-in module. If you update the node path to use your node installation this will be fixed. Also you wouldn't even be able to commit that because eslint --fix reverts the change

@wild flax I saw that you bumped collection to use node 16, but why not 16.6? The PR that adds #at needs 16.6 to apply the suggestion given by vlad

[dawn merlin]

Well if doesn’t allow you to use it on a channel that’s also a type bug

[wild flax]

Because that’s just formality. 16 installs 16.6

Like lol

Nothings released yet

[outer raven]

but you specified 16.0.0 and not >=16

[wild flax]

Again that doesn’t matter

You needed the CI bump

[outer raven]

aight if you say so

ill rebase the PR now

[opaque vessel]

I'm experiencing an issue ~~caused by https://github.com/discordjs/discord.js/pull/6084~~. This pull request allowed APIMessage to be passed to the interaction collector so it could be used via webhooks.

When you create an interaction collector on a message that's within a thread and delete the parent channel, the collector still has bound events (it continues collecting), but the thread no longer exists. If you do not pass a time, this is indefinite.

The interaction collector only caches the ids and allows raw messages to be put in. Since an APIMessage can be passed, I don't see a way to link it to the thread's parent channel. Before this pull request, this is easily doable.

Anyone got an idea of how to detect that if a channel is deleted to stop the interaction collector on the message within a thread? Right now, it's the same issue as https://github.com/discordjs/discord.js/issues/6895 and can cause possible event leaks

[outer raven]

well APIMessage still has a channel_id so couldn't you check for that?

[opaque vessel]

I don't think so. That would be the thread's id, and this implementation allows bots that aren't in the guild to use this collector so it wouldn't be in their cache

[outer raven]

ah good point

not sure then, that might be hard

[opaque vessel]

Actually it's just outright unfixable because both the message and channel parameters are optional lol. Looking further, it seems it's not caused by https://github.com/discordjs/discord.js/pull/6084.

A fix can be made for the reaction collector and the message collector, but I don't think the interaction collector can be fixed

[outer raven]

Maybe @ruby terrace knows?

[ruby terrace]

I don't do collectors, sorry

[outer raven]

who does? I forgot

[wild flax]

I don’t think that’s too high priority

Maybe just open an issue so it’s on the radar, detailing that

[opaque vessel]

Alrighty (:

[wild flax]

We could think about an info block

Detailing that long running collectors with that type of structure is a bad idea because of the implications it brings

And that one should set a timer

[opaque vessel]

Ya, that sounds ideal for now

[opaque vessel]

Does this seem alright?

[wild flax]

no need for the ! but sure

[...] or manual cancellation

[visual hornet]

what about the idle option?

[opaque vessel]

That works too, so I've amended it to this:

Interaction collectors that do not specify time or idle may be prone to always running. Ensure your interaction collectors end via either of these options or manual cancellation.

[wild flax]

hey @dawn merlin , iirc you wrote most of the <"cached"> stuff right?

[dawn merlin]

Yeah

[wild flax]

Could you take a look after the most recent commit

into the test.ts file with all the assertions

im not sure if typescript in my editor is tripping

or if the types or tests don't properly grip

gives me like

Argument of type 'MessageComponentInteraction<CacheType> | MessageComponentInteraction<"cached"> | SelectMenuInteraction<"cached"> | ButtonInteraction<...>' is not assignable to parameter of type 'ButtonInteraction<"cached">'.
  Type 'MessageComponentInteraction<CacheType>' is not assignable to type 'ButtonInteraction<"cached">'.
    Types of property 'componentType' are incompatible.
      Type '"BUTTON" | "SELECT_MENU"' is not assignable to type '"BUTTON"'.
        Type '"SELECT_MENU"' is not assignable to type '"BUTTON"'.ts(2345)

since I extended and made the rules more strict in the tsconfig.json

in help of maybe catching some issues

if its some hackery we do, we can just // @ts-ignore them with a comment too I guess

[dawn merlin]

thats really strange, I just tsc'd and it compiles fine on my end, what version does tsc --version say?

[wild flax]

We don’t use tsc on the test file

Only on the index one to see if it even compiles

So only the editor shows those errors

Or you tsc the test file specifically

My editor uses ts 4.5 though

The repo uses 4.4

[dawn merlin]

Yeah I ran tsc manually on the test file, and my editor doesn't show any errors, I'm on 4.4 so maybe try switching to 4.4?

[wild flax]

huh ok you are right

4.5 seems to introduce some big breaking changes

lets hope its not gonna end up that way

actually maybe not

after switching back to 4.5 they are gone

oh well

[dawn merlin]

#justTSthings

[dawn merlin]

I just switched 4.5 and I'm getting the same errors, I have a feeling this has something to do with it

[wild flax]

I feel like we did rename it though 🤔

[dawn merlin]

what's strange is it's not on just the cache types, it's affecting a bunch of other types as well

[dawn merlin]

going to chalk this up to beta bugs: https://github.com/microsoft/TypeScript/issues/46506

[outer raven]

@wild flax sorry for another ping but was rebasing a pr and noticed you removed .vscode from gitignore. Is this intentional?

its pr #6666 btw, in which i modified it to exclude every file from .vscode except for the extensions.json file

[real jetty]

https://discord.com/developers/docs/interactions/application-commands#message-commands

is this going to be addded?

thats the context menu?

[hasty bluff]

Yes

[real jetty]

oh

i see

[outer raven]

Do we support an endpoint for fetching the invite background?

[analog oyster]

aka the splash url

no, and theres no specific endpoint for fetching it

[outer raven]

Ah, right

It’s odd that the name doesn’t include invite

[analog oyster]

¯_(ツ)_/¯

[opaque vessel]

It's called splash on Discord's documentation too

[analog oyster]

the guild feature for it is called INVITE_SPLASH, but the property itself doesnt mention invite at all

[opaque vessel]

Best leave it, and you can document that it's the invite splash if you really want to

[analog oyster]

it has been like that for years, don't think it matters that much

[outer raven]

Would be nice

[opaque vessel]

Then we're all good!

[real jetty]

It’d be nice to have a shortcut for getting the client’s role on RoleManager

maybe call it clientRole?

[dawn merlin]

I don’t think perm shortcuts are really being considered anymore in the main djs lib, but I might be wrong

[wild flax]

yeah we dont like it as much

try to keep it low on those

not even a huge friend of like the whole TS checks

but they are absolutely necessary sadly

[real jetty]

I see, fair enough

[dawn merlin]

The type guards?

[wild flax]

yeee

I wish we didn't have to do them

[dawn merlin]

Yeah this is what happens when instanceof can’t be used with interfaces or types

[vivid field]

that already exists as guild.me?.roles.botRole and guild.roles.botRoleFor(client.user)

[outer raven]

Could you guys enable reviews on the #858855149643497493 webhook? It currently only posts comments not approvals/changes requested/comments

[vernal adder]

Should guild#vanityURLCode and guild#vanityURLUses be moved or otherwise have a presence in guild#invites?
Maybe as a guild#invites#vanityInvite?

[visual hornet]

invites#vanityCode?

wait, hasn't this been discussed before lol

[vernal adder]

I don't know

Didn't check

[jade creek]

how do i shard my bot?

[vernal adder]

See: https://discordjs.guide/sharding/

Ask in #archive-offtopic next time.

[tacit crypt]

I don't see why we'd move it off of the guild object

[outer raven]

not sure if this is a good example but probably for the same reason why there's member.roles.color instead of member.colorRole

[tacit crypt]

That's our property/getter tho

While vanity data is on the guild object itself

Idk

[vernal adder]

Then something like that might be an option

Just found it odd that there is no "easy" way to get the vanity invite url

[tacit crypt]

Because its discord.gg/guild.vanityURLCode

[vernal adder]

Yes, but we have role#toString()

even thought it's just <@&id>

I think there should be a getter for the invite, but 🤷‍♂️

[opaque vessel]

An InviteGuild doesn't have an GuildInviteManager, so the property is exposed on the class itself. Only proper Guilds do. If we were to move it to the manager, the same problem will exist on other classes unless you're wanting to make an invite manager on the InviteGuild & AnonymousGuild, right?

[vernal adder]

If a getter were to be added it wouldn't affect InviteGuild and AnonymousGuild

But I see the point, yes

[loud jay]

#42 in discordjs/builders by Khasms created <t:1632414577:R>
feat(SlashCommandBuilder): add autocomplete
📥 npm i Khasms/builders#feat/autocomplete

[dawn basalt]

Why was this closed?

[dawn merlin]

Because the author said they couldn’t figure out the types, and said it would be better if someone else tried to implement it

[outer raven]

What's the most common reason for prs to be ignored? There are quite a few atm and some are quite interesting

but prs are being reviewed daily and then there's some that are 20 days old that haven't gotten an update since

[wild flax]

most likely because they are very low in the priority list

we usually don't look at PRs if they arent on a milestone thats soon to be released

[outer raven]

Well they were on the 13.3 milestone

Talking about https://github.com/discordjs/discord.js/pull/6782 btw

You moved this to 13.4 just now, I was just wondering why

[wild flax]

Because in the timeframe we wanted to release 13.3 there was no resolution

And this PR comes with a huge perf hit

[outer raven]

I understand, but the initial concerns were replied to and then nothing else was said, I believe a solution could’ve been worked out or a decision could’ve been made (since the only alternative to that PR without the performance hit would be semver major)

[wild flax]

IMO it was pretty clear that the perf hit is pretty much a no-go

so yeah

[opaque vessel]

Hihi, I'm unsure if https://github.com/discordjs/discord.js/issues/6905 actually has a pull request per its tags :thinking:

[wild flax]

does not, is mislabeled

[opaque vessel]

Thank you for correcting it (':

[outer raven]

Well then if no one can come up with an alternative it should be closed? Tbh I’d rather if it wasn’t but if it’s the only option then it’s better than leaving it hanging

[wild flax]

the perf and memory hit is not acceptable honestly

for such a niche fix

like

the fix would be for <20% of people probably

but affect 100% of people

[outer raven]

Thing is the current behavior is not following discord’s behavior, and it has been said in this channel that it is not ideal

So instead of removing userupdate events completely (or almost completely) it would be better to have them both work

I understand that the performance hit is not acceptable, but if feedback was given maybe other solutions could be found

[wild flax]

I honestly think over overestimate the ability for us to give feedback

certain things cant be magically fixed with some sort of solution honestly

[outer raven]

Yeah I know you don’t have the answers for everything, but I thought someone might do

Either way saying nothing at all doesn’t seem right, specially for a “first” time contributor

[wild flax]

If theres nothing to say, im unsure what to elaborate on

[outer raven]

Close maybe? Idk I think it can’t stay open forever right

But if its closed it should be explained to the author maybe

[outer raven]

Apparently the collection repo says the latest release was 0.2.4 even though there's a 0.3.2 tag, could someone update this? (maybe even release a new version for the new method)

[outer raven]

Any reason why the return type of MessageEmbed#toJSON is set to unknown? Pretty sure this could be safely set to APIEmbed right?

[opaque vessel]

I think it's because nearly all others type toJSON() the same. It should be fine

[outer raven]

other toJSON methods don't have interfaces but this one does, so it should be used imo

unknown types are annoying to work with

and the docs even document it that way

[dawn merlin]

It might have been set before dapi-types were integrated into djs

[outer raven]

I don't think so, it was just done to all because the other toJSON methods can't have the API types

so we'd have to be making tons of interfaces

unless there is a way to make an interface out of a class in TS

[dawn merlin]

Interfaces can extend declared classes

[outer raven]

we'd still have to declare them all though, I'm talking about like a type or something that turns a class into an interface

[tacit crypt]

wrong

iirc

because it has our camelCased properties in footer/author

[outer raven]

it doesn't, I tested

didn't test with all fields, but the ones I did did have snake_case

will test with all actually

[tacit crypt]

From an embed you made or you got from the api?

[outer raven]

from an embed in a message that I called toJSON on

[tacit crypt]

Ah

We made toJSON act like the old _apITransform

[outer raven]

apparently yeah

[tacit crypt]

then yes that type could be corrected

[outer raven]

oh wait there is an issue

some props are snake cased some are camelCased

[tacit crypt]

toJSON returns api data

[outer raven]

nope, not for image for example

[tacit crypt]

then that should be fixed

wait

it doesn't even matter

proxyURL cannot be set by the end user

and the API ignores it

[outer raven]

so is it fine to keep it like this?

I mean others like author have their icon_url typed in snake_case so guess thats fine

[tacit crypt]

I think you can safely type it as APIEmbed, tho it will mean that proxy_url won't be set

[outer raven]

if it doesn't get set by us nor the API I guess it's fine right

[tacit crypt]

the API sets it derp, but it ignores it if we provide it

which is what I said

[outer raven]

aight then that's fine as it is

[dawn merlin]

@tacit crypt is this what you're suggesting in the builders PR?

    public setAutocomplete(autocomplete: false): Omit<this, 'setAutocomplete'>;
    public setAutocomplete(autocomplete: boolean): Omit<this, 'addChoice' | 'addChoices' | 'setAutocomplete'>

[tacit crypt]

.....no

Stop Omitting anything if autocomplete is false

and definitely don't omit setAutocomplete for a general boolean set

[dawn merlin]

So have the overload return this? and remove the setAutocomplete omission from the general boolean method?

[tacit crypt]

The overload should return the original class

without omissions

[dawn merlin]

ohh ok, now I see my misunderstanding, this is mutated whenever an Omit is returned, it's not static

hmm, the only workaround I can think of for this would be to do something similar to SharedSlashCommandOptions<ShouldOmitSubcommandFunctions = true>, and add a SharedSlashCommandOptions<ShouldOmitSubcommandFunctions = true, ShouldOmitChoiceFunctions = false>

[tacit crypt]

that won't help at all

the omit is done already

Just return the original class

or just don't omit it if this makes it so complex

[dawn merlin]

but how do you return the original class without a polymorphic this? If you change an overload to return the original class without using this it's an error:

do you mean return this & { addChoices(), addChoice() }

[tacit crypt]

you shouldn't add it there..

In the setAutocomplete base class

this & Pick<CommandOptionBaseWithAutoCompleteOrWhateverItIsCalled, 'addChoice' | 'addChoices'>

[dawn merlin]

Ok, so this?

public setAutocomplete(autocomplete: false): this & Pick<ApplicationCommandOptionWithChoicesBase, 'addChoice' | 'addChoices'>;
public setAutocomplete(autocomplete: boolean): Omit<this, 'addChoice' | 'addChoices'> { ... }

[tacit crypt]

yes

Probably, test it

make sure everything builds and works

[dawn merlin]

got it to work with conditional types:

public setAutocomplete<A extends boolean>(
  autocomplete: A,
): If<
  A,
  Omit<this, 'addChoice' | 'addChoices'>,
  this & Pick<ApplicationCommandOptionWithChoicesBase<T>, 'addChoice' | 'addChoices'>
>;
public setAutocomplete(autocomplete: boolean): Omit<this, 'addChoice' | 'addChoices'> { ... }

[tacit crypt]

That's..why

That's overkill

Makes the second overload useless

[dawn merlin]

Because if you use just the top overload, you have to cast the return to any ie return this as any

this is a TS type limitation, ref: https://github.com/microsoft/TypeScript/issues/33912

[dawn merlin]

This doesn't work because I get this error:

The call would have succeeded against this implementation, but implementation signatures of overloads are not externally visible.

Even though everything is exported

[burnt cradle]

couldnt I just do ```ts
public setAutocomplete<T extends boolean>(
autocomplete: T,
): T extends true ? Omit<this, 'addChoice' | 'addChoices'> : this { ... }

[dawn merlin]

You can but the issue is that you have to cast the return type as any

Return this as any

[burnt cradle]

its not making me

I can use it fine without casting

[dawn merlin]

hmm you're right, I could've sworn it didn't let me before

[wild flax]

can anyone test running npx tsc typings/tests.ts --noEmit

not sure if its TS thats being unreasonable here (again)

[ruby terrace]

uh....this seems weird

[dawn merlin]

I'm erroring out, but the strange thing is that #6913 doesn't?

[wild flax]

different file

[ruby terrace]

Does the tsconfig somehow not include tests.ts?

[dawn merlin]

oh I see

[wild flax]

yeah I found it by accident

[ruby terrace]

uh, why is skipLibCheck enabled again?

[dawn merlin]

I wanna say that there is a misconfiguration somewhere, because the typings work when djs is used in another project, and within tests.ts my intellisense is accurate

[wild flax]

it was never disabled

🤔

yeah but I dunno if I wanna trust the editor over the cli

[ruby terrace]

The editor doesn't show errors because those files aren't being included properly it seems

[wild flax]

also eslint errors

have to add them to an eslintignore file too

[ruby terrace]

ts will still error over eslint, but yeah, we'd need the typescript parser for eslint to not error

[ruby terrace]

skipLibCheck is false by default and wasn't in the tsconfig until 2 days ago

[dawn merlin]

ok I included the typings dir and the editor now shows the corresponding errors, these are legitimate errors

[ruby terrace]

although this was previously enabled

[opaque vessel]

I see it in the git blame for 2 years :thinking:

[ruby terrace]

it keeps changing

for context why that's a problem: #archive-offtopic message

That reaction from space feels appropriate

[wild flax]

feel free to disable it again

it seems that its defaulting to true in the common tsconfig we use

[outer raven]

it's actually true by default if you run tsc --init

[ruby terrace]

by default I mean when its read as undefined in the file

[outer raven]

ah then yeah

[dawn merlin]

it's strange that when you run just npx tsc in the root directory it successfully compiles test.ts because it spits out test.js file. When you do npx tsc typings/test.ts it fails

[ruby terrace]

@wild flax OH, i forgot this...tiny little detail

https://www.typescriptlang.org/docs/handbook/tsconfig-json.html#using-tsconfigjson-or-jsconfigjson

also it appears vsc does not fully execute tsc since doing so with no files does generate the files prop

[dawn merlin]

It still doesn’t compile with those options for me

[rocky latch]

Would it be okay if I add a setting in the client options then?
So peeps can opt-in to this feature.

[rocky latch]

Cause I agree it would affect everyone, hence why I think making it an option is better

(if you have a better name for the option, let me know xD)

[dawn merlin]

so I figured out the TS errors, it'll compile properly if you pass in --strict

that was also the cause of the 4.5 beta errors

[tacit crypt]

That makes..a sliver of sense?

I've had and seen several projects where strict mode was necessary

[dawn merlin]

I'm confused as to why it doesn't use the tsconfig.json

strict is set to true there

Well actually now that I think of it I know why, if you compile a single file it's obviously not going to the tsconfig in the root dir.

So actually npx tsc -p . typings/tests.ts is probably the best way to do it

[wild flax]

but if we add the files array?

does that solve it 🤔

its like super annoying

I also tried like

include: ["typings/**/*"]

but then I don't think it picks up the test.ts file

not sure

[dawn merlin]

the issue is that when you run tests.ts individually, it's not using the tsconfig at all

thats why npx tsc compiles successfully and npx tsc typings/tests.ts fails

[wild flax]

so there was never an issue to begin with 🤔

and the PR that lints the typings its pointless

is what you are saying

is there no debug option for tsc to see which inputs it tries?

im sure there has to

so we can see what happens if you run npx tsc right now

without any changes

[dawn merlin]

#6913? yeah that PR isn't going to change anything

this is correct to being with "test:typescript": "tsc --noEmit"

[wild flax]

ok so we dont need to change anything then

sounds good

how come those changes slipped through then 🤔

[dawn merlin]

I lied, the changes slipped through because of skipLibCheck, index.d.ts is just straight up being ignored if skipLibCheck is enabled

#6913, is trying to manually check that file

[wild flax]

right so all we need to do is disable the lib checks 👍

disable the skipLibCheck oops

[dawn merlin]

or if skipLibChecks causes issues for users, we can simply only use the CLI options for the GH workflow, so npx tsc --skipLibCheck false

bc I think someone said earlier it caused compiler errors when disabled for some users

[burnt cradle]

@dawn merlin sorry but at what point would this not have addChoice when it should

[dawn merlin]

#archive-library-discussion message

Basically if you omit things from this, you mutate its type

[burnt cradle]

yeah but why is that a bad thing here

The only omitting that's happening is when it should happen

[ruby terrace]

that doesn't work, you cannot use a tsconfig when passing a file / path

[dawn merlin]

Yeah I just realized that but running tsc without any explicit source files and disabling lib checks is how to get it working

[ruby terrace]

yeah

the weirdest part is that (after disabling skipLibCheck) adding all ts files manually using the files property causes those errors to show back up

in tsconfig

[dawn merlin]

If you set the autocomplete to false and then set it to true, you’ve lost some properties in your original “this” type

[dawn merlin]

I’m pretty sure it’s just ignoring tsconfig entirely, that’s why the js file is outputted in the same directory instead of dist/

[burnt cradle]

yeah, as you should, because you shouldn't be able to addChoice if autocomplete is true

though I see now the issue if you set to true then false

[ruby terrace]

when I edit the tsconfig to include the files, vscode gives me ts errors in editor

[dawn merlin]

But if you set autocomplete to false afterwards (although somewhat unnecessary) it should still have the addChoice and addChoices props

[dawn merlin]

Same here

[burnt cradle]

yeah ok I get it now sorry about the hassle

[dawn merlin]

No worries

[dawn merlin]

does your tsconfig have strict enabled?

actually removing include entirely removes the false positive errors, but still keeps the true positive errors in the editor

[ruby terrace]

oml I'm stupid, I was using files instead of include, and files doesn't match globs, so vsc was using the default tsconfig

[dawn merlin]

do you know if it's possible to disable skipLibCheck without the side-effects previously mentioned?

[ruby terrace]

Just only disable skip lib check

And that doesn’t even affect the test file

[dawn merlin]

so disable skip lib check and keep skipdefaultlibcheck enabled?

[ruby terrace]

Yes

[rocky latch]

@wild flax Could I have your thoughts on that please, thanks in advance 🙂

[opaque vessel]

Does discord.js use ?type as nullable or nullish? I believe it should be just nullable as intended use from JSDoc? I see some documented as ?type but actual values may include undefined, hence the question

[slate nacelle]

I think we use it for both, I don't know if that's what we want to do though.

[opaque vessel]

I plead for documenting undefined instead, people like me do if (X === null) and expect it to work as such, and not account for undefined

[wild flax]

Doesn't seem feasible

Instead you should just do == undefined

which covers both cases

theres nothing our wrapper I think where undefined or null is really being distinguished

it both means theres either no initial value, or theres no value being sent explicitly

[opaque vessel]

I'm not sure it's for me to change my code style because discord.js doesn't take JSDoc's nullable as... nullable?

To answer if values are being distinguished, an example is on the user class where the recent properties there are undefined if not fetched, null if fetched and not existing and a value otherwise. Or, the message references where it's typed as type | undefined but documented as ?type so it should be null here, not undefined. This is more about being consistent than anything, no?

[wild flax]

It'd be a lot to go in and change all the types now

If you are up for it, please feel free, but I don't think its in any of the maintainers interest to do that work themselves right now

[wild flax]

No thoughts yet, and I won't be deciding that alone either

[opaque vessel]

Alright, thank you for your thoughts

[rocky latch]

Yea I understand that, just wanted to see if you think that would be a better option if in the end you guys decide to add it, should I commit the option or nah?

[wild flax]

You should def put it in the PR

but maybe not commit yet

[rocky latch]

[tacit crypt]

iirc in JSDoc, ?type is type | null, and [name] = possibly undefined

[outer raven]

[name] is optional, not undefined tho

[vernal adder]

Isn't that the same thing?

[analog oyster]

no

[vernal adder]

optional = value or undefined, no?

[outer raven]

not at all

[vernal adder]

What is it then?

[outer raven]

https://www.typescriptlang.org/tsconfig#exactOptionalPropertyTypes

[vernal adder]

So... it's either the value(s) or undefined?

[outer raven]

but optional is not the same as undefined

[visual hornet]

wait wasn't this about jsdoc

[outer raven]

yeah but the explanation is there

[vernal adder]

"possibly undefined" = optional to me

[outer raven]

did you read the link?

[visual hornet]

so it's value(s) or nonpresent

the latter just turning into undefined when you access it, the only difference would be how in behaves, no?

[outer raven]

yeah

[wild flax]

Which makes no sense for the documentation

So yes, [name] means optional and undefined

In JS if you pass nothing as a value and try to access it, it ends up being undefined

[dawn merlin]

Should we enable noEmit in the djs tsconfig?

[outer raven]

but then you can have properties in an object set to undefined, which is different from them not being set at all

[wild flax]

Nah I like to keep that separate

[opaque vessel]

https://github.com/discordjs/discord.js/pull/6838
:thinking: am I missing something or how come Message#inGuild() doesn't make Message#guild non-nullable?

[vernal atlas]

because #guild is a getter

bot leaves the guild or doesnt have guilds intent, no guild

or just for any reason the guild isnt cached

[opaque vessel]

If the bot leaves the guild, then the typeguard would be false?
discord.js requires the GUILDS intent

or just for any reason the guild isnt cached
Only achievable through altering the cache which is unsupported behaviour

[vernal atlas]

• the typeguard only checks if the message was sent with a guild_id field - which would stick even after the bot leaves because its cached

• fair enough

• haven't used djs in a while, wanted to include any other reason it wouldnt be cached

[opaque vessel]

Rip, maybe Message#inCachedGuild() soon™️ then lol

[vernal atlas]

message.guild !== null when

[sullen idol]

We need MessageEmbed#video

[dawn merlin]

It should, it was passing the type tests so idk what’s up

[opaque vessel]

I read the pull request again and saw that it changed from checking .guild (cached) to .guildId (may or may not be cached) so... ya. An example of where it may not be cached is when you leave the guild then decide it's a great idea to check the cached messages you have there. I think it's better left alone now /:

[dawn merlin]

I was going based on what crawl said earlier: #archive-library-discussion message

Also if you leave a guild I think it’s best that messages from that guild get wiped from the cache. Mainly because of the issue being described; you can’t property represent their current state

[opaque vessel]

I was thinking that too!

[dawn merlin]

I just realized that we’re doing this anyways because when a bot leaves the guild we delete the guild from the cache thus all the messages are also deleted

[opaque vessel]

Oh huh. Wow. Great. So we can assure that the guild is not possibly null then? :D

[dawn merlin]

Yup

[opaque vessel]

Happy days (:

Hold on, on the guildDelete event, the cached guild is passed through, right? Isn't it accessible there?

[tacit crypt]

The previously cached guild is passed through*

[opaque vessel]

But it's sill possible to check the previously cached guild's cached messages via that right?

Too much thinking

[tacit crypt]

I mean I GUESS you can go deletedGuild.channels.first().messages.first(), yeah?

[dawn merlin]

The only other option I see here would to set all of the messages guildids to null, but idk about that

[opaque vessel]

The other option is .inCachedGuild() I guess o,o

[dawn merlin]

But that method relies on guild ids not guilds, so if you use it in the delete handler, it’ll give a false positive

I’m pretty sure guild ids don’t get removed from messages even if the guild itself is removed from the cache

[opaque vessel]

(Just to confirm the method I typed out above would rely on cache and not the id)

[dawn merlin]

Oh well we discussed that on the PR Vlad suggested that we use the id instead of the getter for performance. And in 95% percent of cases this is accurate

[opaque vessel]

Yeah, oh well

[dawn merlin]

I would just strip all messages out of the previously cached guild on the delete event

I don’t really see the use cases in giving users the old guild messages from a guild that they’re no longer part of

[dawn merlin]

@ruby terrace was it ever verified if min/max and choices are mutually exclusive?

[ruby terrace]

no

they are not currently but I believe they should be

[dawn merlin]

Sadness

[dawn merlin]

On the topic on regressions, the typescript devs have confirmed that the errors appearing for us on 4.5.0 but not on 4.4.4 are in fact regressions from 4.4.4: https://github.com/microsoft/TypeScript/issues/46624

[wild flax]

[opaque vessel]

Latest GitHub Actions seems to be queued for >= 25 minutes... outage? :thinking:

[outer raven]

nothing reported on github's website at least, could've been a one-time error

maybe rerun?

[real jetty]

Is there a plan to include the jsdoc comments inside the typings so they appear in intellisense?

Talking about this btw

[outer raven]

Yeah on the ts rewrite

Currently not really feasible

[real jetty]

is there any plan for the ts rewrite or is it just "sometime before 2030"? i saw djs-next got removed

[outer raven]

the djs-next repo got renamed to discordjs-modules, not sure whats being done about that but its not gonna be v14 for sure

[vernal adder]

There is no set date, but I believe the focus will be moving towards the rewrite in the coming months

[outer raven]

hope so

[ruby terrace]

working on drop ins for rest and ws first, rest I'm hoping to get into v14, ws may be a v15 thing or potentially semver minor on 14 depending on implementation. Once those are migrated over, and we're not stepping on ourselves, it should be easier to push for the main lib

[real jetty]

Probably not because voice was rewritten in TS, which djs doesn't have docgen support for

[wild flax]

I think it mainly has to do with the fact that its a pure function

which is something we should, and can add support for

will happen

[burnt cradle]

is there a point in having babel as a dep in builders after babel-jest got removed?

[digital sun]

Is there a reason the API includes bots in memberCount and no easy way to get the accurate count without bots without fetching the entire Guilds member list?

[slate nacelle]

The reason is probably that there is no need for such for their clients.

[wild flax]

Jest now directly uses Babel when a Babel config is found, so yes

[burnt cradle]

Couldn't ts-jest just be used instead?

[wild flax]

no ts-jest is trash

[burnt cradle]

fair

[solemn oyster]

Just to clarify it further, the only advantage of ts-jest is typechecking, but in reality, that's unneeded since typechecking is already done by our build step.

Babel's config is a lot faster thanks to it stripping the TypeScript types so it can be run as plain JavaScript.

[digital sun]

is there a bug with the 'remove' call back on a messageReactionCollector? Its never called and digging through the code im not seeing this.emit('remove', ...args); being called anywhere in Collector.js like i do with collect or dispose and end

[unique axle]

you need to provide the dispose option for removal to be emitted

[digital sun]

oh? is dispose called on remove?

[unique axle]

actually, is that gone from v13 or just not documented (anymore) found it, it's documented in CollectorOptions

[digital sun]

remove? its not in the code

but it shows as an option on the collector

all ik is that its just not firing at all like the other callbacks

Collector.js line 84 and 85 i see

this.handleCollect = this.handleCollect.bind(this);
this.handleDispose = this.handleDispose.bind(this);

No mention of remove

[unique axle]

no, i mean that the "remove" event only emits if the option dispose: true is provided
https://discord.js.org/#/docs/main/stable/typedef/CollectorOptions

[digital sun]

Oh??? Thats really nebulous

[unique axle]

it is documented

https://discord.js.org/#/docs/main/stable/class/ReactionCollector?scrollTo=e-remove

Emitted when the reaction had one user removed and the dispose option is set to true.

the "dispose" event emits when the entire reaction "stack" is removed in one go, also only if the dispose option is set to true
https://discord.js.org/#/docs/main/stable/class/ReactionCollector?scrollTo=e-dispose

[digital sun]

the naming is misleading i guess

you would think dispose is for the dispse call back

[unique axle]

disposal is required for either to work, hence why it's documented on each event

[digital sun]

Cool cool, I had it there before, but wasnt sure why so I removed it not thinking it would stop the remove callback lol

[analog oyster]

Why is repliedUser under Message#mentions? I feel like that's misleading since the repliedUser property will be populated regardless if the reply is mentioning the user or not. It should perhaps be put under Message#reference?

I guess the description of the property explains what it actually is, i just think its a bit odd

The author of the message that this message is a reply to

[outer raven]

definitely not under reference as that's an object sent by Discord iirc

think it should be its own property

[analog oyster]

yeah thats fine as well

[unique axle]

the mentions options object answers the question "who is mentioned"
-> roles, users
-> the user this replies to - repliedUser
-> parse all roles, users, everyone

[outer raven]

you can reply without mentioning tho

[unique axle]

yes, i don't see how that plays a role.

[outer raven]

well then it shouldn't be in mentions if no one was mentioned

[unique axle]

then i'd consider the part bug that it is there, even if not mentioned

[outer raven]

can we patch that in a semver patch?

the fix is quite easy

[visual hornet]

would fixing a bug that changes behaviour have to fall into semver major?

[outer raven]

i mean it's removing something that would be there before, so could be major idk

[unique axle]

i suppose it'd be major, since it is documented correctly

[outer raven]

well, incorrectly for that matter

[unique axle]

no, correctly. it documents the current behaviour

[outer raven]

which is incorrect, so its documented incorrectly too

[unique axle]

... no. it is currently documented correctly := documentation and behaviour match
-> a change would not be a fix
-> it does not bring any new functionality. you can find out if the user was mentioned via #mentions#users
-> it's a change in behaviour and semantics

[outer raven]

semver major it is ig

[rough roost]

InteractionResponses#update throws INTERACTION_ALREADY_REPLIED if you call it after deferUpdate, that doesn't look right

[ruby terrace]

it's right

[vivid field]

reply, deferReply, update and deferUpdate all act as the first reply to an interaction

after that you will have to use followUp, editReply or whatever

[rough roost]

ah thanks

this is a very confusing api

but discord moment ig

[outer raven]

Quick question about collection: the es2022 PR is being merged on TS and they decided not to make the argument in array.at optional, despite it working with no errors so I'd like to do this for collection too. Question is: should I remove the test that has no index or should I change it to something else? I don't think it should be expect().toThrowError() since, well, it doesn't throw an error

[tacit crypt]

if the spec says its optional it sounds like they need to fix it on TS side, no?

context is needed

[slate nacelle]

mdn documents it as required, the spec doesn't mention anything, but will treat it as 0 due to how ToInteger is defined to work

No idea if intentional or not

[outer raven]

I specifically requested for it to be made optional and they said that even if something works they’re not gonna allow it because it doesn’t work as intended

Lemme link the convo

https://github.com/microsoft/TypeScript/pull/46291#discussion_r738796155

[outer raven]

Also could someone rerun this check? https://github.com/discordjs/discord.js/runs/4080702654?check_suite_focus=true
Feel like this one is quite important since the commit only changed documentation xD

[outer raven]

So @tacit crypt what should I do about the tests?

[tacit crypt]

More of a crawl question I'd say.. specifically if we want to make .at take in a required number.. CC @wild flax

[outer raven]

Aight will wait for him then

Also noticed an awkward issue: the parameter is marked as not optional in the documentation 😬

So ill wait for his response to fix that too

[wild flax]

What documentation?

[outer raven]

this

[wild flax]

You don’t seem to understand typedoc

Check the actual docs

[outer raven]

oh right I forgot about that

nvm i guess

well then