archive-library-discussion

[ornate topaz]

but the question wasn't literally asking "what's in there", but was in form of "did you try looking there yourself before you complain that we moved to newer version"

[nova quiver]

ok

[outer raven]

Judging from all the activity on github it would seem like v14 is close, is that right?

[unique axle]

no eta

[stray delta]

it's ready when it's ready ™️

[nova quiver]

probably no

[stray delta]

#archive-offtopic

[fervent walrus]

Are we gonna have another v13 release for the zombie connection pr?

[honest barn]

looks like it

[outer raven]

@dawn merlin seeing as you made a PR to remove a feature I added could you let me comment on it please

[outer raven]

Seems like APIAttachment doesn't include the property name, making it impossible to use the AttachmentBuilder and give the attachment a name, could someone fix this?

not sure if the issue is in dapi types or djs

[outer raven]

can't commit due to this, what should I do?

[tacit crypt]

run yarn build

[outer raven]

right yeah that fixed it

[outer raven]

https://github.com/discordjs/discord.js/pull/8016 turns out the fix was easier than I thought so here it is

[wild flax]

might as well fix the other error too

files?: (BufferResolvable | Stream | JSONEncodable<APIAttachment> | Attachment | AttachmentBuilder)[]; in all places is missing AttachmentPayload

which didnt allow you to construct an attachment with files: [{ name: 'some_name.txt', attachment: Buffer.from(xyz, 'utf-8') }]

[outer raven]

will add that

[wild flax]

But tiv is out

[stray delta]

that's not what i'm asking

[wild flax]

We usually wait yes

But if discord is too lazy to merge stuff that won’t change because it’s a live deploy

We usually don’t care

[stray delta]

kk

[stray delta]

webhook messages shouldn't be cached if the bot can't see them right? (i.e. send through WebhookClient)

[vernal atlas]

i suppose there isnt much of a reason to cache them no

[outer raven]

Seems like v13.8.0 added a breaking change, was this intentional?

[wild flax]

Probably not

@vernal rose I don’t think we can use cliff jumper here

We don’t want or need any of its features

[vernal rose]

Yeah just closed the pr then got your message xD

[wild flax]

Is this just a type issue

Or smth

[opaque vessel]

Well I assume the event was always emitting a channel with a thread manager, so receiving a message in a voice channel will break things, as you didn't need to check if a thread manager existed before

[outer raven]

It isn’t, it’s actually breaking because voice channels indeed do not have threads

[wild flax]

I guess

But it’s either that or no TiV

[outer raven]

True ig

[wild flax]

I guess it’s a compromise we shouldn’t make, but we didn’t want a v13.8 in the first place

It’s risky to update, but I think for those who really want to stay on 13 worth the risk

[outer raven]

If v14 is near it could’ve just been released then but idk if it is

[wild flax]

It’s not

Builders needs a rework

Permissions 2 isn’t merged

Neither is the object input one

Which are all breaking

[warped crater]

is automod also breaking

havent checked if that breaks anything for whatever reason

[wild flax]

If no one backports it

[warped crater]

rephrased

[wild flax]

Right, idk didn’t look yet

[warped crater]

meant "is it breaking so it needs to be in 14.0.0"

so like, does it block v14

icic

[opaque vessel]

So far that one is a minor

Don't think anything will be breaking in it

They change that PR a lot though

[stray delta]

how is the caching logic even supposed to work? If the bot can indeed see the channel where its' own webhook message was send it gets two requests for trying to add to cache, one from returning the API request from and one from the bot actually being in that channel, if the bot tries to parse the APIMessage it crashes because it doesn't have the guild_id field at all (and this.chanels to resolve)

can i just PR a revert for the webhook APIMessage -> Message returns and not try to add it to cache like before? 7917 causes webhooks to break entirely cause of ^

[loud jay]

#8031 in discordjs/discord.js by Rygent opened <t:1654568058:R>
An error occurred while sending the webhook message

[dawn merlin]

Yeah it’s either reverting that PR or making the channel getter on a message nullable

[stray delta]

well it's not really nullable, it's just that the getter incorrectly assumes client to not be a WebhookClient so the channelmanager doesn't exist to resolve from

[dawn merlin]

yeah but it even if the Webhook client had a channel manager it would be null, so it also returns null for regular clients if your bot isn't in a guild (which is misleading).

[stray delta]

probably better to return APIMessage then yeah

same thing applies when returning the message, it could never add it to cache because this.client is a WebhookClient so it always returns APIMessage

[white hedge]

Serious question: Are the localized commands working?
Because I add them with the edit function, but when I refresh my cache and fetch the commands again, the localizedName and localizedDescription properties shows up as null

From what I'm reading in the Discord API documentation, these fields are not sent unless the client requests them (using the withLocalizations option of the fetch method), but this method only returns the fields to me if I have previously used the method edit (or create) to add those fields. But if the cache disappears (for example, by restarting the bot), they return to null on fetch

What is the point of being able to add these fields, if they cannot be obtained later?

[ruby terrace]

already was

just poorly typed

(technically not possible, but ya never know)

[white hedge]

From what I'm seeing, there seems to be a build override for localizations for three months now, so this feature is still under development. Why is it supported in the stable version of Discord.js? Why don't even the API docs warn about it?

[outer raven]

the API hasn't changed idk why it isn't on stable discord yet but it works as-is, no warning needed

[tacit crypt]

Localization is already available for commands to set in advance, the client support is supposedly coming sooner than later

[white hedge]

That is, localizations can be sent, but not retrieved from a bot client?

[tacit crypt]

Localizations can be set but your client won't render them

[white hedge]

You mean, on a user client (in the graphic interface)?

[solemn oyster]

The client we all use to interact with Discord

Localised application commands are still an experiment, so everyone sees what's on name and description

[white hedge]

There's the thing. Because I had been trying to understand for a long time why I couldn't fetch the locations of a command, if according to the API documentation it is not an experiment (https://discord.com/developers/docs/interactions/application-commands#retrieving-localized-commands), and the stable version of Discord.js is prepared for this (https://discord.js.org/#/docs/discord.js/main/typedef/FetchApplicationCommandOptions)

[solemn oyster]

Client and API are two different things

We simply support everything the API supports

But what the Discord Client supports, is up to Discord, it has its own milestones and stuff

[copper laurel]

But if in not mistaken, what you're saying is that when you fetch commands, via the API in discord.js, you don't get the localisations back in the command object?

[outer raven]

have directory channels been released publicly on the API? I saw them on 13.8 for some reason

[tacit crypt]

invites can point to them

[copper laurel]

They're part of school hubs iirc

[opaque vessel]

Directory channels have been documented for a few months now

[dawn merlin]

You do if you have the query param set

[copper laurel]

@white hedge were you setting that when fetching?

[white hedge]

Yes, with const guildCommands = await someGuild.commands.fetch({ withLocalizations: true }); (using v13.8.0)

[outer raven]

will they be accessible to the public in regular guilds?

[opaque vessel]

A directory channel is a channel containing guilds within a student hub

So a student hub is all you will ever find it in

[white hedge]

Yes, i get null on the localizations (both nameLocalizations and descriptionLocalizations), but only BEFORE editing/creating the command to adding those fields. When I create/edit the commands, both fields are correctly defined when I fetch them again with that parm set (i suppose because it's on cache)

[real jetty]

where can i find a minifed version of discord.js

[wild flax]

why

[wild flax]

Ill just leave this here, in case others haven't seen it and want to give their piece: https://github.com/discordjs/discord.js/issues/8015

[mighty bough]

I think Collection#find() and other methods that take functions as arguments should have better errors.
Like if you provide a non-function to .find(), it seems to throw this error: https://sourceb.in/zh5x7UeCs6
but I believe it could be better, like fn provided for Collection#find() must be a function, received ${typeof fn}

[opaque vessel]

I believe running node with --enable-source-maps is what you're after? Also it doesn't error for me. Just ran <Collection>.find(3) and it returned undefined

[mighty bough]

that's weird
neither of these seem to have anything checking if it's a function:
https://github.com/discordjs/discord.js/blob/main/packages/collection/src/index.ts#L240
https://github.com/discordjs/collection/blob/main/src/index.ts#L232

[analog oyster]

cant replicate

[mighty bough]

maybe you did it on an empty collection

[opaque vessel]

Ah okay, let me try with something populated

Same error as above

This boils down to what I said at the beginning, you want the --enable-source-maps option when you start your node

[analog oyster]

i was not using source maps

[opaque vessel]

Oh

Welp, flat out CNR then lmao

[wild flax]

I am unsure if we want that

The documentation states that it is identical to array.find

That does take a function too

[shell lance]

Did you get that error by providing two arguments? First being not a function and second being whatever?

Because then it’s the fn.bind that produces that error

[mighty bough]

Actually, it wasn't me who got it, but I thought I remembered getting that error before for that reason, and the person who got that error said that the problem was providing a non-function to .find()

They tried .cache.find("name")

[opaque vessel]

Well as you can see, we're not getting that error... you probably should have tried that yourself too :P

[wild flax]

That usually only happens when you either don't know js, or follow a tutorial thats rather outdated

[mighty bough]

when I did try it I had the same error as you, but idk, maybe they had an old version ¯_(ツ)_/¯

[opaque vessel]

Someone made https://github.com/discordjs/discord.js/pull/8064

[vernal rose]

This is related to this issue but not a fix for their issue. The error @mighty bough was getting was coming from a minified version of collection. But that pr makes collection.find identical to array.find

[real jetty]

https://github.com/discordjs/discord.js/pull/7204
Why is this inactive?

[warped crater]

that's a fairly difficult question to answer, lol

if what you're wondering is if it's been dropped, the answer is no

it's a p big undertaking and some things just need to get ironed out before its completed

[opaque vessel]

I believe it's also waiting on /ws?

[solemn oyster]

Partly, yes, I have something in mind, but I have finals to take care of first

[tender surge]

Why is the api for awaitModalSubmit not so user friendly? Why does it throw instead of returning a empty value when nothing was collected? You're forced to catch the error and you can't even compare against it properly because there is no instance of the error exported

Seems like you can compare against it, but still weird it doesn't return a empty value like previous collectors did

Nvm the error instance is not exported so you can't compare

[vernal rose]

wdym? non of the await* returns empty value after timeout.

[warped crater]

👎 empty value is just poor behavior here IMO

albeit the error not being exported is not ideal either, will look into that in a bit if no one else gets to it by then

[vernal rose]

agree. Error can give u more info then a empty value and u can always add a catch to return empty value

[tender surge]

Collectors used to

But you could also control what throws an error in there through the errors property..

[warped crater]

yeah I see, errors being unexported is more of a library-wide problem

@solemn oyster would there actually be any concerns in exporting from src/errors?

it's a start but it actually wouldn't fully solve the issue lol.

this[kCode] = key; the error codes are locked behind a symbol so they'd still have to check against the .message

yeahhh this feels p hard to fix without an overhaul of how errors are handled honestly

[solemn oyster]

What if you made a code getter?

Or replaced the symbol property with a regular one

[warped crater]

that'd be a bit better I suppose, except our codes are just hard coded strings

e.g. in this case for the await modal thing

        else reject(new Error('INTERACTION_COLLECTOR_ERROR', reason));

they'd need to js } catch (error) { if (error instance of DjsError && error.code === 'INTERACTION_COLLECTOR_ERROR') { // do things } }

which is less than ideal

could honestly fit in something that redos errors in v14

[slate nacelle]

There is a getter for that

[warped crater]

is there

im tired

may have missed it

oh, yes

    get code() {
      return this[kCode];
    }```

I see I see

👍 will make a PR about this tomorrow, all though it'll probably be another 500 lines changed like my last one as I attempt to rewrite this mess

[slate nacelle]

[tender surge]

Pls ping me with the pr link if u don't forget

[solemn oyster]

@oak quail What's the progress with https://github.com/discordjs/discord.js/pull/8050?

[oak quail]

oh right

i won’t be home for a while but i can add the note on sunday

is there any syntax or should i just add text to it

[solemn oyster]

I'm unaware if there's any syntax for it, since it's wrapped into a table, so possibly plain text nvm, thanks ckohen

[ruby terrace]

warn blocks work in typedefs and parameter tables

[loud jay]

#8068 in discordjs/discord.js by didinele opened <t:1654937933:R> (review required)
refactor: errors
📥 npm i didinele/discord.js#refactor/errors

[warped crater]

^

hm

yeah nvm, this should solve most issues

from here on out the only improvements we can make is make our errors more specific

e.g. INTERACTION_COLLECTOR_ERROR is used basically everywhere

it's hard to get much out of it sometimes

[tender surge]

ty

[outer raven]

@ruby terrace on #8065 why are there two awaits on this line? Are you awaiting a sort?

[warped crater]

appears so

[outer raven]

that doesn't do much does it

[warped crater]

absolutely nothing indeed

if I had to guess ckohen wrote await readdir(handlersDirectory) and then added .sort and just hit enter on the VSCode suggestion

which seems to always add another await in front since it doesn't check the methods' return type or something

[outer raven]

is interaction.options.getFocused().value meant to have all these possible types?

how can it be a boolean and undefined?

[warped crater]

what type are you expecting?

[outer raven]

just string and number

you can't have autocomplete on boolean options

and I don't understand how it can be undefined

[warped crater]

is this v14

[outer raven]

yes

[warped crater]

hmm

yeah, good catch

export type AutocompleteOption = Pick<CommandInteractionOption, 'name' | 'type' | 'value' | 'focused'>;

it just keeps the value from CommandInteractionOption

where that type is accurate

[outer raven]

not sure what this CommandInteractionOption interface is meant to represent tbh

[warped crater]

an interaction option.

[outer raven]

but an option will always have value

otherwise it's not present

[warped crater]

🤷

don't know enough to be sure, probably future proofed

[warped crater]

there you go

dapi thing.

[opaque vessel]

I don't think it's supposed to have boolean or undefined actually for a autocomplete interaction

[warped crater]

anyway, if you wanna, feel free to PR a fix to the typings

otherwise I'll do it in like 2hours

[visual hornet]

no boolean there through

[outer raven]

but what should I do about the undefined?

[warped crater]

that's because they're dumb

[outer raven]

do i just overwrite it in the autocomplete type?

[visual hornet]

which they?

[outer raven]

discord

[warped crater]

discord

[visual hornet]

oh, makes sense

[warped crater]

there's literally a boolean option type so

PR to dapi-docs

[warped crater]

- export type AutocompleteOption = Pick<CommandInteractionOption, 'name' | 'type' | 'value' | 'focused'>;
+ export type AutocompleteOption = Pick<CommandInteractionOption, 'name' | 'type' | 'focused'> & { value: string | number };```

[outer raven]

ye thats what i was thinking

alright will PR

[opaque vessel]

Thank you

[outer raven]

decided to go with this so as to fix the focused type and make type more accurate

[warped crater]

lgtm

[opaque vessel]

Fine to me too

[wild flax]

@outer raven ok hear me out

[outer raven]

hm

[wild flax]

Are you sure its safe to remove the cacheType?

I guess so

But

I think its be better if you still use Pick syntax

[outer raven]

oh

[wild flax]

And just overwrite it with & or something

[outer raven]

I didn't realize that but in this case I don't think it makes a difference

[wild flax]

like don't pick out certain things and then just do & { type: <type>, value: <stype> }

[outer raven]

that's only relevant for options with resolved properties like members or users

[wild flax]

might be better for not having all standalone types yknow

[outer raven]

if I keep Pick I'd only be picking name

I can change it if you want but it really doesn't make much of a difference

should I?

[wild flax]

That's true, but

What if they ever extend it in some way

I think itd be less of change for us then

[outer raven]

yeah fair

ill do that then

[wild flax]

coolio

ty

It also probably makes for better code consistency

And generally good practice

Also please, for the TSR rewrite, you wanted to have getters to builders right (for v14)?

[outer raven]

would be nice yeah

[wild flax]

Is there any compromise we could find where you still somewhat get what you want to achieve, so you do your mutations with some sort of structure

but not builders directly

🤔

[outer raven]

well Siris suggested an update method a while back which would only modify the passed properties and leave the others untouched

[wild flax]

Would that be on builders or djs?

[outer raven]

on builders

[wild flax]

yeah I guess we could work with that

would call it patch instead of update, but sure

[outer raven]

but if we go with that idk if the set methods would continue to make sense

[wild flax]

they can call update

we can still expose them

[outer raven]

yeah true

[wild flax]

@tacit crypt does that fit into your RFC

I don't think that'd bastardise builders

[outer raven]

btw I pushed this

[tacit crypt]

I'd be fine with possibly having an updateX method if the need is there, but the set methods should not be removed at all

[outer raven]

yeah that sounds good

[wild flax]

updateX or update in general

because then wed just duplicate the set methods no?

lol

but without clearing

[tacit crypt]

well, update makes sense only for nested objects

[outer raven]

oh yeah you can just have 1 update method that works for all

[tacit crypt]

(consider: author, footer, icon)

So I'd say updateX for all nested objects only

[outer raven]

but wouldn't that be a lot of methods

[tacit crypt]

how so?

[outer raven]

well instead of 1 update method for the entire builder you'd be making 1 for each object

[tacit crypt]

updateAuthor/setAuthor
updateFooter/setFooter
updateImage/setImage
setURL
setColor
setDescription
...etc

[outer raven]

and for embeds for example that's a lot

[tacit crypt]

Embeds have only... 4? nested objects

[wild flax]

Yeah its not that much

Sure, if we duplicate all set methods

But thats not what vlad is saying

[tacit crypt]

I dunno, a global update method then brings the question for a global set method, which would really not help with the consistent interface argument of the RFC

[wild flax]

we could probably bring in those update methods before the RFC rewrite proposal

since theyd be minor

[outer raven]

a global set method would just be a new builder instance, no point in doing that imo

[tacit crypt]

i'd say this is an alright interface, supports both use cases, and is distinct enough

[outer raven]

im fine with both tbh

[tacit crypt]

Possibly, yea

[outer raven]

@analog oyster @opaque vessel did yall delete your comments on the PR?

[analog oyster]

yeah, it doesnt really make a difference

[outer raven]

the name doesn't but the type kinda does

[analog oyster]

we were just talking about the focused prop

[outer raven]

ye ik

[opaque vessel]

Yeah it's fine to make that true 😅

[outer raven]

i pushed a commit to make it true

[analog oyster]

can you rename the type then

[outer raven]

no?

[analog oyster]

its kind of misleading, because not all autocomplete options have focused: true
the type is only being used in getFocused(), but still

if in the future that type is needed, it doesnt represent any autocomplete option

just focused ones

[outer raven]

all received autocomplete options do have focused set to true

when you receive an autocomplete interaction you only have 1 option which is the focused one

i just tested this btw

[analog oyster]

idk how else to put it, that type now represents focused autocomplete options

[tacit crypt]

You should be getting all provided options..

[analog oyster]

im not talking solely about autocomplete interactions

[tacit crypt]

I was replying to this

[analog oyster]

i was continuing this

[outer raven]

on an autocomplete interaction you dont

[tacit crypt]

That's..not true, the API definitely gives all options

[outer raven]

vlad I just tested this

[tacit crypt]

If you have a user option then an autocompletable string option and you fill in the user one first, you'll get it (or SHOULD get it)

[opaque vessel]

API doesn't send any resolved data, just those in AutocompleteOption

[opaque vessel]

You won't

[tacit crypt]

I recall this bc I also tested that

[outer raven]

ok lemme do a different test then

[opaque vessel]

That's why those getUser() etc. methods were removed from the typings on an autocomplete interaction, because there was nothing to resolve them against

[tacit crypt]

The fact its not resolved is one thing

you should still be getting the option

Even if not resolved

At least that's how I remember it

[opaque vessel]

If you have an autocomplete option, for some reason, Discord just doesn't send anything else but it

It'll send the user id, sure, but not the user object

[tacit crypt]

So you do get the option

just not resolved

[opaque vessel]

Yeah

[tacit crypt]

Phew, thought that changed too

[outer raven]

so you get all the options you've filled up already and not any resolved data

[opaque vessel]

get('user_option').value would get the id but unfortunately no user object

[outer raven]

i was getting confused because I thought you were saying you would get options that weren't filled

also interesting how they send a number as a string 🤔

[tacit crypt]

That makes sense to a degree

[outer raven]

so would value always be a string?

[tacit crypt]

Since you can type anything in the autocomplete, for instance searching case numbers by reason

[tacit crypt]

https://tryitands.ee

Although it is definitely concerning then because even in -types it would be wrongly typed

[outer raven]

ok so ill rename it and make it always a string

do you have this interface in -types?

[tacit crypt]

It's probably only a string in autocomplete scenarios

[outer raven]

yeye

once you move to the next option and unfocus it it becomes a number

[outer raven]

as shown here

alright hope thats the last commit to that PR

[tacit crypt]

Uhhh..yeah its in -types to a level...

[opaque vessel]

Isn't the integer here a number? So the value is a number?

It just seems only floats are sent across as strings, right?

[tacit crypt]

If autocompletes are always sent as strings, I have some painful types to fix

[opaque vessel]

But doesn't that screenshot show a number or am I tripping

@outer raven poke poke^ x:

[tacit crypt]

thats not focused, Jira

We're talking about the focused property

[opaque vessel]

Oh

[outer raven]

Ye that type is only for focused options

@opaque vessel

[opaque vessel]

Omg lol

[tacit crypt]

........so autocompletes have the value as string...Le fuck

Should be easy to fix tho in -types

union all the things

[analog oyster]

focused autocompletes have value as string

right?

[outer raven]

yes

my code checks if an option's value is a number sometimes, I wonder how I never noticed that break

oh wait turns out it only checks if it's a string, thats funny

[tacit crypt]

I never noticed this because I never used autocomplete for numbers... yay we caught it

[opaque vessel]

Same... lol

[unique axle]

when they first got introduced i went on that, but it makes a ton of sense, bc it's essentially an enum/id you are selecting, with some verbose name as label

[opaque vessel]

I'm shocked lol

But sure

[outer raven]

ID? 🤨

[unique axle]

yes? int ids exist, not everything is snowflakes, fam

there are multiple reasons why you wouldn't want to represent a... idk, job, in an RPG?... as a string, but rather with a job id

[outer raven]

but we were talking abt number autocomplete options

im confused

[tacit crypt]

Autocompletes can be used to also search

[unique axle]

yes, and numerical ids can make sense there, because you can assign a label to it

i could, for example, give every tag in /tags a number instead of using a string to identify it, making it a worthwhile use case for autocomplete numbers

[opaque vessel]

@outer raven can you update the AutocompleteOption JSDoc too?

Renaming it and removing the number type from the value

[outer raven]

will do

done

should probably backport this to v13 right?

[opaque vessel]

I don't believe we are doing another 13.x

[ruby terrace]

What dd said, doesn’t exactly hurt anything so whatev

[outer raven]

i heard that for the last two 13.x's so you never know

and there's 1 PR for v13

[shell lance]

That one would be a patch though, not minor version (if even merged)

[wild flax]

Don’t call me out like that

[outer raven]

lmaoo sorry sorry

but is this the last last one?

like qjuh said it could just be a patch

[wild flax]

Idk

We can do another 13 probably

The first time I said it was only because the release setup was a pain

But I fixed that

The 2nd time was because I thought v14 will be ready and TiV will be a pain to back port

Turns out neither happened

And TiV was easy

[opaque vessel]

Cool

There's already a 13.x pull request, so...

[outer raven]

then ill open the backport pr once that is merged

[wild flax]

You can open it now

And just fork or base it on that branch

So checkout that prs branch

Make a new branch from that

And work from there

¯_(ツ)_/¯

Just make sure it’s your fork

Not the persons fork

[outer raven]

i usually checkout main and just cherry-pick lol

which is why i wait for it to be merged

its quite easy

[tender surge]

Are typings missing here?

I don't see .setDefaultMemberPermissions / dm which is in the docs :/

Nvm seems like it was added yesterday so got to wait for a new release

[real jetty]

its actually on the SlashCommandBuilder

[tender surge]

Shouldn't it be available through ApplicationCommandData or something similar as well?

Idk I just prefer to have regular objects to create commands, maybe I'm missing some type here

[copper garden]

We can’t add such methods to regular objects. We add them to specialized classes

You can see from the typings that it’s just a type, not a class or anything usable by js

[tender surge]

What about a property then? Like currently I added those manually but they could be added natively and the same method would be called for them to actually apply?

[copper garden]

How do you suggest we do such thing?

[tender surge]

Well defaultPermissions is a property already

So there would be new defaultMember and defaultDMPermissions properties

[copper garden]

defaultMemberPermissions is alr on ApplicationCommandBase

[tender surge]

I don't see it 🤔

[copper garden]

Or let me check, I realized ur showing ur own typing

[tender surge]

Yup

If I can add some reference to anything that has it to make it work it's all good, but currently I see no way of achieving this

[copper garden]

It’s on v14 dev

[tender surge]

Okay then I did see it correctly, ty for checking 😩

[copper garden]

No backports to v13 atm

[tender surge]

I guess I can use the dev version since this bot isn't live

[stray delta]

which is right? https://github.com/discordjs/discord.js/pull/8038#discussion_r895067319

[void rivet]

if i'm not misunderstanding anything, you want

/**
*
*/
method(){}

/**
*
*/
method(){}


/**
*
*/
method(){}
```right? The way you're doing it, send gets the last documentation, which is for editMessage

try this out

class BaseClass {
    /**
     * Send message
     */
    send() {}
    /**
     * Fetch message
     */
    fetchMessage() {}
    /**
     * Edit message
     */
    editMessage() {}
}

class ExtendedClass extends BaseClass {
    /**
     * Sends a message with this webhook.
     * @param {string|MessagePayload|InteractionReplyOptions} options The content for the reply
     * @returns {Promise<Message>}
     */

    /**
     * Gets a message that was sent by this webhook.
     * @param {Snowflake|'@original'} message The id of the message to fetch
     * @returns {Promise<Message>} Returns the message sent by this webhook
     */

    /**
     * Edits a message that was sent by this webhook.
     * @param {MessageResolvable|'@original'} message The message to edit
     * @param {string|MessagePayload|WebhookEditMessageOptions} options The options to provide
     * @returns {Promise<Message>} Returns the message edited by this webhook
     */
    send() {}
    fetchMessage() {}
    editMessage() {}
}
```Hover above send then fetchMessage

hopefully this clears the confusion
i think i know what you mean by seeing something similar, you probably saw some seemingly out of place jsdocs and misunderstood what they were doing
i'll see if i can get an actual example

[opaque vessel]

@outer raven and anyone else, we'll make a 13.8.1 release (patch) so if there's any other fixes you want making to there, can do

[outer raven]

alright thanks! Will open the backport for that PR

[vernal rose]

@tacit crypt to resolve https://github.com/discordjs/discord.js/pull/8074#discussion_r895155705, I've 2 choices either use .setValidationEnabled when defining predicate or just before using .parse. Which one you'd like? If we use it just before .parse, then a user will be able to disable validation at run time.

[golden mortar]

its not too late to just move to json. builders are way too complicated

[copper laurel]

I personally agree. But we still support JSON everywhere anyway (it's literally what builders build for you) so this is just an unhelpful snide remark and not constructive discussion at all

Nobody is making you use builders

[golden mortar]

But we still support JSON everywhere anyway (it's literally what builders build for you)
that's what they should be doing (like Embed in v13), but they also do validation which is part of the "too complicated" remark.
Nobody is making you use builders
I'm not, not sure what that has to do with anything lol. I doubt any of the maintainers (people making all of the massive changes) use builders' structures either which is definitely another problem (feel free to correct me if im wrong here)

I also agreed with just about everything u said on the rfc, just haven't posted on it

[copper laurel]

This message before yours was about disabling the validation on a single unified builder structure rather than having the Unsafe* separation.

As for usage of builder by maintainers I don't know enough to comment - I don't use builders myself

The fact that they validate the input isn't a problem for me, and for what it's worth I think the slash command builders are excellent. Immutability lends itself well to that scenario. It's all the others that are the problem 😄

[dawn merlin]

I certainly do, I have a package that exclusively uses builders for paginating embeds. Most if not all of the embeds I use are from builders, components is a mixed bag for me. I also don’t think I’m wrong in saying Vlad uses them heavily too.

[golden mortar]

yeah true 👍

[golden mortar]

I switched from builders (v13 style) to json and Embed is a perfect example of a structure that can be done the exact same - or even easier - with json. Components are also very easy.

[copper laurel]

Is there a particular advantage you feel you get out of using them or is it just stylistic?

[dawn merlin]

Personally it’s out of habit

I don’t think one is objectively easier than the other though

As for the immutability that’s less of a builders issue and more of djs one. Djs controls the cache and decides how components are cached within messages

[copper laurel]

Im not asking to mutate cache

[dawn merlin]

Even if builders wasn’t a separate package I still would’ve made that PR

Then what are you asking to do?

[golden mortar]

the idea of having to convert a component to json to convert it to a mutable component seems very contrived to me personally.

or even if you don't convert it to json manually it still gets converted to json

[dawn merlin]

A component or a component builder?

[golden mortar]

from monbrey's example in the rfc

ButtonComponent.from(theData).setDisabled()

[dawn merlin]

I need more context here, where is theData from

[golden mortar]

I don't think it really matters tbh (it's just really complicated for changing a property on an object). You could replace that line with

theData.disabled = true

if you were using just json objects
however I do have an example:

In one of my bot's commands, it sends a message (using interaction.editReply, which apparently always sends a Message object now?) and after a collector ran and the message has been updated (dynamically adding/removing/modifying components), I want to resend its components but disable them so they can't be re-used after the command is over.

message.components returns an ActionRow structure where I can access components and whatnot, but I can't edit them. I could recreate the component using ActionRowBuilder.from, but the data would already be converted to json regardless and I could just as easily modify it directly. I think the example in the pics are equal (taking the first component of a message, setting every subcomponent to disabled) and as you can see the 2nd one is quite a bit more complicated - while also getting "worse" typings.

[copper laurel]

If you have 5x5 grid of buttons and you want to disable the one right in the centre, how would you do that using builders?

[copper laurel]

This way still edits a property of the nested action row components directly, which is supposed to be against the design of builders anyway I would have thought

e.g. if r.data is private, you're shit outta luck

[golden mortar]

apparently the .data isn't private, the example was done in ts (modifying my actual code). However idk the design of builders and it might be against every design input lol

[dawn merlin]

Factory functions; if you’re generating 25 buttons I doubt you’re making them all statically. Make a function that takes state as an input (Map) and returns component as an output. When you receive a component update the map and call the same factory again. Components shouldn’t be responsible for encoding state. An array of action rows isn’t a replacement for map-like structure. This is true for both json and builders

[copper laurel]

That sounds horribly inefficient to have to use the factory over and over again

I already have a set of 25 validated buttons, why cant they be reused

Maybe to give a real world example, I've seen implementations of tic-tac-toe with buttons where the label gets updated with an X or O based on position

[dawn merlin]

You’d be doing the same thing after every interaction anyways. You’ll always construct a new builder

[copper laurel]

Well no, I wouldnt

[dawn merlin]

Then how can you be sure state doesn’t carry over between interactions between different users?

[copper laurel]

I'm not understanding the question

[dawn merlin]

I’m saying you always have to reinit state whenever a new interaction comes in, or else you end up using the same state for all users invoking a given interaction

[copper laurel]

Why would the state have changed

[dawn merlin]

If two users are playing tic tac toe I can’t allow them to use the same components in the same state

Two separate games*

[copper laurel]

Would those two states not be in separate scopes of execution?

[dawn merlin]

Sure but they both need to created separately, right?

[copper laurel]

Once

Not on every turn

[dawn merlin]

But you can’t modify cache in place, you always need to recreate the component with .from

[copper laurel]

Yeah if you use builders

[dawn merlin]

Well the api returns immutable structures so it would be a similar story with json

[copper laurel]

But you'd already have your JSON that you used to send them in the first place, and it's mutable. I don't care what the API gave me

Hell you could even make that JSON using builders if you really wanted to, and then edit an individual property in it as needed

[dawn merlin]

Yeah the json still needs to be created every time, other than validation you’re not really saving much construction cost.

[ruby terrace]

read this again, and you'll understand what we're saying

[copper laurel]

No I dont

[dawn merlin]

ckohen who was that directed towards?

[ruby terrace]

you

[copper laurel]

...no it doesn't. What am I not explaining properly.

const ttt = [array of rows of buttons in JSON];
const game = await interaction.reply({ components: [ttt] });
const collector = game.createMessageComponentCollector(options);
collector.on('collect', b => {
  // b.customId shows that the middle button was clicked
  ttt[1].components[1].label = "❌";
  ttt[1].components[1].disabled = true;
  b.update({ components: [ttt] });
});```

I do not need to recreate that JSON

It exists in a scope where its mutable per event received by the collector, but out of scope of any other interactions that may have started games

[dawn merlin]

If you know the exact component index why not keep a reference to the builder variable and just mutate that then?

[copper laurel]

Because isnt it supposed to be private?

Hidden away behind builder methods?

And if its isnt whats the point of the builder?

[dawn merlin]

No if you know what component in the actionrow changes every single time, why not just keep a reference to the builder?

[ruby terrace]

mutating specific field indexes is incredibly difficult with builders

[dawn merlin]

The component is known since the index is hardcoded

[copper laurel]

And modify it how? spliceComponents?

[dawn merlin]

no the setters

It’s a reference to a builder

[copper laurel]

so RowBuilder.components[1].setDisabled()

I thought they were also private

Or .data.components I guess?

We're back to data being a public property again then

[dawn merlin]

You already know what component 1 is beforehand. Keep a reference to that component builder. Place that reference into the action row builder. When the collector is invoked use the cached component reference and call .setDisabled.

[real jetty]

Yup I agree

[copper laurel]

That would currently be possible, how would that still work if it changes to the row.addButton(button => style to align with slash commands?

[dawn merlin]

I have no clue

[copper laurel]

I realise now we may have been approaching this with entirely different states of builders in mind

Apologies 😄

[dawn merlin]

all good

[ruby terrace]

you could store a reference to that too, but you're storing so many references now

when maybe only one of them needs to be updated

[dawn merlin]

If you have a lot of references to keep track of intuitively a map is a good option for keep track of a bunch of references.

customid -> component reference

[dawn merlin]

Also memory is quite meaningless here when we’re taking about n <= 25 and it’s GC’d after the full interaction lifecycle completes

[ruby terrace]

*when the GC works

[dawn merlin]

I don’t see why it wouldn’t here

It’s scoped to anything in the interaction block. That’s like saying you shouldn’t allocate anything in an interaction event handler bc GC may not work(?)

If it didn’t work memory leaks galore

[ruby terrace]

naw its just slow, in my use cases its not a problem

[dawn merlin]

Deallocing a tiny map (of mapped references) shouldn’t be slow enough for like 98% of people to notice. There’s probably structures being dealloced that take more cpu time

[ruby terrace]

Let me give you an example for an embed quickly (doesn't apply currently because the builder doesn't follow the same structure)

const fields: EmbedFieldBuilder[] = []
const embed = new EmbedBuilder().setTitle('An embed');

for (let i = 0; i < 15; i++) {
  embed.addField(field => {
    fields.push(field);
    field.setName('Name').setValue(`Field ${i}`);
  }
}

// Somewhere else, after getting an event
fields[someIndexFromEvent].setName('Name (Winner)');

vs

const embed: APIEmbed = {
  title: 'An embed',
  fields: [],
}

for (let i = 0; i < 15; i++) {
  embed.fields.push({ name: 'Name', value: `Field ${i}` })
}

// Somewhere else, after getting an event
embed.fields[someIndexFromEvent].name += ' (Winner)';

In example two, I do not need to lookup the current value of the name in order to append to it, only have the overhead of storing the json object (not classes each containing their own json object), and its easier to index into

[dawn merlin]

this is quite easy to solve store the field builders in an array, set the fields to that array. On the event being recieved go the index in the cached array and change the title.

[ruby terrace]

that's basically identical to what I just did

heck I could even use the toJSON() output from the builder in 1 and use the same last line from 2, but then I lose the validation

[dawn merlin]

In your example you don’t assign the fields to the embed directly you add them all one by one

[ruby terrace]

it'd still be nearly identical

and that's not the point

[dawn merlin]

I don’t see the issue, you’ll always know the name(s) beforehand since you create the array with said names attached to each element. And it’s logical to assume these “names” would be in the same indices as the as the field builder.

[ruby terrace]

but that's exactly why its frustrating for people

another frustrating thing:
now imagine you're doing this over time and not in the same scope. Instead of storing just an embed object / builder, i have to pass around all these extra things to wherever I'm storing them

[dawn merlin]

Alternatively you can look up the index off the received message embed and look for the already existing name string

[dawn merlin]

I will reiterate a point I’ve made many times. Message components are not suited for encoding state, state should be stored in proper data structures by the bot

[ruby terrace]

i'm not storing it in a message component, i'm storing it in a Map (Map<number, APIEmbed> currently), but your way would suggest using that same map and shoving everything that I might potentially need into an object that contains references to every nested builder in addition to the top level one

[dawn merlin]

Huh? In the example you just need the array of field builders that’s it

[ruby terrace]

I need the embed itself too

[dawn merlin]

why?

[ruby terrace]

to use it in edit or send or whatever

[dawn merlin]

they’re references you change the field in one place they change anywhere they’re referenced

[ruby terrace]

I know

[dawn merlin]

you don’t need the embed

[ruby terrace]

then how do I resend it

[dawn merlin]

you edit the field and resend

[ruby terrace]

but I don't have a reference to the embed

[dawn merlin]

Exactly you don’t need one

The embed you started with is referencing the field you’re editing

You just need the field

[ruby terrace]

but if I only store the fields in that map, I don't have the reference to the original embed anymore

[dawn merlin]

It still will be edited when it’s resent bc the embed you lost the reference to is still referring to the field you’re editing

[ruby terrace]

then how does .edit() know what embed I want to send

remember, we're in a completely separate block scope here, that's the point of using the map, to transport these things between scopes over time

[dawn merlin]

When edit is called you need the embed itself regardless if you use json or a builder. I’m saying for editing a field locally it’s not necessary just like it wouldn’t necessary in json

if you’re using json an lose a reference to an embed then obviously you can’t send it

[ruby terrace]

right, but the map is just storing the entire embed, and map.get(id).fields[x] etc... works great

[dawn merlin]

why is a map being used instead of an array of fields?

[ruby terrace]

its a map of embeds

[dawn merlin]

why embeds?

[ruby terrace]

so you've lost the context for this conversation?

[dawn merlin]

In the example there’s only one embed

[ruby terrace]

now imagine you're doing this over time and not in the same scope. Instead of storing just an embed object / builder, i have to pass around all these extra things to wherever I'm storing them

so over time we have multiple

lets just say the map is on globalThis for this example

[dawn merlin]

In this map what are you trying to edit on each embed?

[ruby terrace]

unknown, may be every field, may be a single field, may be add a field

I honestly don't know how we could solve this in builders without exposing data which defeats the purpose, maybe getters for only things that can have nested builders

[dawn merlin]

ok the solution of keeping a reference to only the fields still works here

You edit the fields in place

[ruby terrace]

here, simplified so og scope: makes embed and fields, sends, separate scope: edits fields then edits message

[dawn merlin]

Is this separate scope within the og scope

[ruby terrace]

no

same event handler, different event

both have ways to access the map

[dawn merlin]

Ok then this is just a factory function problem. Have a function that takes abstract state and outputs an embed.

This function can even take in the recieved embed as input to represent updated state

[ruby terrace]

Let me try to make the point clear: yes, we can find ways to do what we want with builders, and the best part is validation. However, doing so seems arbitrarily hard sometimes, attempting to find workarounds for problems we encounter. Unfortunately, discovering and implementing these workarounds is trumped by the ease of simply using JSON instead. I.e. storing all the nested builders works, great. I didn't think of doing that because its not exactly intuitive, and it still seems like I lose flexibility with it, so give up and use JSON. Thought process goes: I lost runtime validation, oh well, haven't had issues with it before.

[dawn merlin]

Json has always been more flexible even with v13 builders, and it always will be.

[ruby terrace]

The goal I imagine would be to make it feel easy to use builders over JSON

[dawn merlin]

That’s why json isn’t validated and builders are. It’s also why you can pass in colors and emoji as just strings in builders and you can’t do that with pure json. People value certain things over other things and builders may be more useful to them. Others may find json much more useful.

Personally speaking I don’t think the goal of builders was to obsolete the use of JSON

[ruby terrace]

But if i'm using builders, I don't feel like I should have incentive to stop using it ever

whereas currently when I start using it took all of 3 minutes to decide to stop

[dawn merlin]

Let’s reverse that statement, if I’m using json I don’t feel like I should have incentive to stop using it. And to be clear I feel like giving up on something after a mere three minutes doesn’t really show an honest effort to adapt to changes.

[ruby terrace]

I don't think so either, there's always going to be reasons to use raw JSON, but I don't think a reason should ever be "because builders were to hard to use" or "because builders don't offer a way to do X"

[dawn merlin]

Some people think the the more raw nature of json makes them harder to use

Anyways it’s 2:20am and I need to get up at 8am so gn

[ruby terrace]

this was a from scratch project, not an adaptation, 3 minutes was an exaggeration, but after thinking through the logic I determined I couldn't do what I wanted with builders

[leaden obsidian]

@wild flax @tacit crypt Hi I am Voxelli @fervent walrus [github:legendhimslef] using this id cuz older one has some issues,
I think we need to have 13.8.1 as soon as possible as the code on 13.8.0 resets sessionId on close which causes new identifies. This has been patched in my latest pr. || sorry for ping it was kinda urgent I think cuz there is a chance that this will cause some users to exhaust all their login quota ie 1000 per day||

Ill get the backport ready for main [main does not have any sessionId issues]

[leaden obsidian]

I think this was mainly affecting bots with 20-30+ shards on 13.8.0.

[tight crag]

Yep

Every 20-40 minutes some shard is reconnecting with new session

[leaden obsidian]

the new patch would fix this

[tight crag]

[leaden obsidian]

did you have your token get reset?

[tight crag]

No

[tight crag]

Can you give link to your pr?

@leaden obsidian 👀

[leaden obsidian]

patched one?

or the one which got merged with 13.8.0

[tight crag]

It

[leaden obsidian]

patched: https://github.com/discordjs/discord.js/pull/8082 [13.8.1] hopefully

[tight crag]

Thank you

[leaden obsidian]

yes you can use this code and hopefully everything will be fine

idk why I never noticed this until now. My bot with 34 shards never ran out of logins per day maybe cuz of traditional sharding? but for internal sharding peeps it caused some reconnect issues [only for huge bots]

[tight crag]

I noticed this after updating to 13.8.0

[oak quail]

looks like d.js is adding webhooks to the user cache now; is that intended?

[dawn merlin]

It was, but there’s a PR to revert it now

[vernal rose]

@tacit crypt u said enableValidators should set setValidationEnabled to all the predicate (if I've understood correctly then u mean import all the assertion predicates in validation file and use setValidationEnabled on them right?) and not just before parsing but how that'll work? https://github.com/sapphiredev/shapeshift/blob/a23d15f533a234a59af54a9ed60bec778f069af8/src/validators/BaseValidator.ts#L80 here everytime we run setValidationEnabled, it makes a clone so if i add setValidationEnabled(false) on a predicate inside of enableValidators, it won't change the already present predicate

[ionic blaze]

omg thanks

[leaden obsidian]

[grizzled elk]

I've been developing a library ontop of DJS and I just wanna say great job to everyone who works on it.

It has been very easy to work ontop of. With such a big featureset, that's not really an easy thing to pull.

pat

[wild flax]

Link?

Yes you are allowed to

[mighty bough]

they put link to github in general
#archive-offtopic message

[wild flax]

Ty

[outer raven]

that note isn't true at all, should we suggest to set it to 8 in order to disable the command?

0 does the exact opposite of disabling the command

[copper garden]

The warning in the DDocs says otherwise

[outer raven]

where's that

[copper garden]

https://discord.com/developers/docs/interactions/application-commands#application-command-object-application-command-structure

[outer raven]

then thats also very wrong lol

ill make a PR to fix that one too

should be 8

[opaque vessel]

I'm pretty sure I tried this earlier and it was fine

[outer raven]

nop

0 is no permission

if you don't require any perms to use a command its enabled for everyone

what they meant to put there is 8

[opaque vessel]

I just tried it again, I cannot reproduce that

[outer raven]

i can't get neither 0 or 8 to change anything at all

[opaque vessel]

Maybe your members are all administrators (x

[outer raven]

it should still change something in the allowed roles list

also just found a bug

[tacit crypt]

crying

Also supposedly permission 0 disables it for everyone except admins+owner

[outer raven]

but that doesn't make sense

ok so it seems like it does work, it just doesn't change anything in the integrations tab which is why it gets confusing

[ruby terrace]

default member permissions never changed anything in that tab, its a stupid oversight that makes the UI 50% useless

[outer raven]

ah I see

that's quite annoying, i didn't know that

[tacit crypt]

supposedly they wanna work on it but time

[outer raven]

might as well do a permissions v3 cuz v2 was so disastrous it needs an entire rewrite again

[tacit crypt]

nah, its just UI thats not done

the system itself is fine

[outer raven]

everything is slower, commands take ages to populate and glitch out when you're writing them and it's no longer as easy as simply enabling or disabling a command for a role, you can't even do that through the API now so you can't automate most systems without an oauth token

[tacit crypt]

1. Haven't seen it
2. They appear instantly
3. Disabling a command for a role is literally going to the cmd in the ui, adding the role and toggling it to off
4. That's an ANNOYANCE but not a groundbreaker and I doubt it'll change any time soon too

[outer raven]

You can easily notice how when you type / the menu goes black and only gets populated a few seconds later, similar to how autocomplete works too and this didn’t use to happen before v2
Yes you can still disable commands for roles but it’s way harder because it has to be done manually and becomes quite annoying when you have over 40 commands so it’s easier to just enable the command for all roles and do perm checks on the bot iself

[inland lotus]

the disabling commands for roles is better imo, gives the owner/admins control over who can use certain commands instead of having to rely on the bot

[copper laurel]

Way too often now I try to /ban someone and it defaults to Discord's own slash command because I forget to wait for Yuu's to load

[honest barn]

the first thing you mentioned is because of the slash command backend rewrite, it was separate from perms v2 but they both landed almost at the same time

the ui not reflecting perms v2 is a known issue and they are working on it iirc, i made a github issue about it and it got the synced label and assigned to someone

[raven juniper]

How much of this is actually related to d.js 🤔

[signal sedge]

can confirm this with 400+ shards / 439k servers

[leaden obsidian]

patched: https://github.com/discordjs/discord.js/pull/8082
this might help

[quiet viper]

Are backports on v13 branch even tested?
Their should also be a separate dev release for v13...

[opaque vessel]

Did you find an issue?

[quiet viper]

Kinda sounded rude, apologies, meaning the identify issue. When Core parts are affected, they somehow should be tested on production...

[void rivet]

you can actually install the v13 branch from github, it's not a monorepo

[opaque vessel]

You can run npm install discordjs/discord.js#v13 to install it

[wild flax]

Most sharding affected things are not easy to test

Which should be obvious

[signal sedge]

i can put this in prod if u like, to test
got it in production, 448 shards, 440k servers

[leaden obsidian]

I had that tested with two huge bots

[leaden obsidian]

All of the pr's by me Voxelli [github:legendhimslef] are actually being tested thoroughly in production with two bots [35k 43k guilds | 35 shards/43 ] shards for few days.
I only push codes when testing is done so yeah..

[leaden obsidian]

have a check for new identifies calls and reconnects with 4009.

[wild flax]

I’m saying mistakes can happen and testing sharding is the most difficult task generally

Because you do need someone willing to test and you might need a big number of shards, not always but sometimes

Sharding is rarely something you can test on a tiny server by yourself

[leaden obsidian]

Yeah, I was just trying to make it clear that I take stuff seriously and push it after being tested properly

[wild flax]

Like everything else in the lib

[leaden obsidian]

I am always ready with my bot [38/43 shards bot] to test new codes so you can ping me if there is ever a need.

[signal sedge]

ill let ya know if itll crash or not

[leaden obsidian]

okay

[upper lance]

there are certain message types that dapi will throw an error 'Cannot execute action on a system message' if attempted to delete them (for example: RECIPIENT_ADD, RECIPIENT_REMOVE), yet Message#deletable doesnt seem to have a check for it. Is this intentional by design?

[ruby terrace]

we could test which ones do it currently, but that can change at any time without notice

[tacit crypt]

The problem with system message deletions is that it's inconsistent at which ones you can delete

[quiet viper]

Does the roll out of auto mod issues with v13?

[unique axle]

try it and see, and report bugs if you find them

[stray delta]

why are none of the audioplayerstatus events typed https://github.com/discordjs/discord.js/blob/main/packages/voice/src/audio/AudioPlayer.ts#L160

[copper garden]

I believe the same is true for VoiceConnection

[wild flax]

I only added the ones that had documentation before I adapted the docgen

So they were missing before

Most likely just an oversight

And I wasn’t going to add them just to fix the docgen in the same pr

[stray delta]

ok

also voice in general has a ton of eslint-disable overrides, for everything that's documented can that/ should that be changed?

[wild flax]

Preferably

But it will be a big undertaking I assume

The codebase isn’t a huge mess, but fixing those overrides can be a bit tedious

[real jetty]

This channel is for important discussion about developing discord.js, please go to #archive-offtopic , moreover this server is for discord.js not for steam bot builders

[sleek kelp]

Will content moderation support be added to discord.js? (New feature)

[loud jay]

#7938 in discordjs/discord.js by Jiralite created <t:1652824011:R> (review required)
feat: AutoMod
📥 npm i Jiralite/discord.js#feat/auto-moderation

[vernal rose]

^

[sleek kelp]

thanks

[opaque vessel]

In the future, the answer will always be yes

[visual hornet]

^ unless it's not available to bots

[signal sedge]

your patch seems to work 🙌

448 shards / 441k servers

[leaden obsidian]

🎉 Seems fine on my side as well

[real jetty]

any way to fetch all the friend ids?

[visual hornet]

if there were it'd require oauth2 and even with that i don't think there is

but definitely not in djs

[unique axle]

relationships.read even needs discord approval

[real jetty]

it's possible on python

[unique axle]

then you are running a selfbot, which is against discord terms of service

you are not allowed to automate non-bot accounts

[real jetty]

Fair nuff

[oak quail]

you can get friends with rpc

[real jetty]

source?

[oak quail]

https://discord.com/developers/docs/game-sdk/relationships

[real jetty]

interesting

[vernal rose]

I'm not able to commit bcz of this error. Does anyone know why it's happening? I've committed by adding --no-verify for now

[tacit crypt]

reinstall all deps and try again?

[upper moss]

is there a reason for VoiceChannel not having nsfw property because api returns it while djs doesn't i wanted to ask here before i make an issue on gh

[copper garden]

It was prob overlooked when tiv was added to d.js

Feel free to open the issue and I (or someone else) will make a PR for it

[stray delta]

damnit how did i miss that

[copper garden]

@upper moss

[upper moss]

i opened an issue

[pallid ridge]

export interface ChannelData {
  name?: string;
  type?: Pick<typeof ChannelTypes, 'GUILD_TEXT' | 'GUILD_NEWS'>;
  position?: number;
  topic?: string;
  nsfw?: boolean;
  bitrate?: number;
  userLimit?: number;
  parent?: CategoryChannelResolvable | null;
  rateLimitPerUser?: number;
  lockPermissions?: boolean;
  permissionOverwrites?: readonly OverwriteResolvable[] | Collection<Snowflake, OverwriteResolvable>;
  defaultAutoArchiveDuration?: ThreadAutoArchiveDuration | 'MAX';
  rtcRegion?: string | null;
  videoQualityMode?: VideoQualityMode | null;
}

does anyone know what type resolves to?

asking because it doesnt matter if i try to edit with { type: 'GUILD_TEXT' } or with { type: ChannelTypes.GUILD_TEXT } theres always a ts error about types not matching

[opaque vessel]

That type is incorrect

[ember steeple]

What djs version your using

[pallid ridge]

13.8.0

[pallid ridge]

sadness

type should be ChannelTypes.GUILD_TEXT | ChannelTypes.GUILD_NEWS right?

[visual hornet]

it is that in main~~, yes~~

[opaque vessel]

No

It should be 'GUILD_TEXT' | 'GUILD_NEWS | ChannelTypes.GUILD_TEXT | ChannelTypes.GUILD_NEWS

Basically, https://github.com/discordjs/discord.js/pull/8089 needs to be backported

Make an issue @pallid ridge if you want, then perhaps someone will add it for the next 13.x

[pallid ridge]

it should definitely be only the enum values, considering there is no check (at least as of now) and DAPI accepts type: integer

[pallid ridge]

i might make a pr

[opaque vessel]

No it should be both. If there isn't, that'd be a bug

https://discord.js.org/#/docs/discord.js/13.8.0/typedef/ChannelData
It's documented to take a string too, that needs to have a number after it

[pallid ridge]

i get an DAPI error by trying 'GUILD_TEXT'

[copper garden]

That’s resolved to num by d.js

[opaque vessel]

The string isn't sent across to Discord - it's resolved

[pallid ridge]

thats what i tought but it isn't in 13.8.0

it throws

[opaque vessel]

Hence

If there isn't, that'd be a bug

Resolving should be like this
https://github.com/discordjs/discord.js/blob/13.8.0/src/managers/GuildChannelManager.js#L146

That doesn't exist in the edit method for some reason, so... yea

If it's a number, leave it as it is, else, it's a string, so convert it to a number. And then the default type is a text channel

Then it's sent to the API

[pallid ridge]

ill make a pr later

[mighty bough]

why?

[copper garden]

Bc it’s a bug?

[mighty bough]

oh wait I missed a few messages

[copper garden]

v13 should still support string for channel.type

[alpine bough]

hey @tacit crypt (think its better to talk here? about discord-api-types#502)
even tho the docs says it, i tested myself and it doesn't work, you can test in this url: https://cdn.discordapp.com/banners/277496071897481216/a_114df53592ae20557666470b5e741966.gif?size=

cc @outer raven (you were also in the discussion)

[tacit crypt]

well iirc they don't support resizing gifts

[outer raven]

Was that change reverted or did it never land

I know for a fact Discord supports more than just powers of two and ive seen prs to add that on djs

[alpine bough]

but i still can't get the image with static images 👀
tested with vladdy's banner (only with power of two, of course)

[outer raven]

https://github.com/discordjs/discord.js/pull/6844 this is what I was talking about, guess it never landed on discord’s side but was merged on djs

[opaque vessel]

It was asked to be reverted in both linked pull requests, but that never happened

[outer raven]

Reverted? When

[opaque vessel]

On both those linked pull requests on what you just linked

[outer raven]

Those aren’t linked but alright

https://github.com/discord/discord-api-docs/issues/4031#issuecomment-963456127 apparently discord doesn’t like these

Did anyone ever revert these tho

Oh it wasn’t “reverted” just was never added to rest and thats what djs uses now

Alright guess I was behind on the news then

[tacit crypt]

They "work"/worked, that is true, but they're not recommended

[alpine bough]

so I will leave it with number type and use the docs to say it only accepts numbers power of two between 16 and 4096, thanks guys :)

[outer raven]

Pls make the type specific

[warped crater]

I don't see Vlad changing their stance anywhere

[outer raven]

@swift zealot no need to close your pr

Just change the target branch to v13

[swift zealot]

Lol, my apologies. I've never had to do that before lol

I would have reopened it but I deleted the branch without thinking.
It's been a long day. 😁

[honest barn]

iirc you can restore branch in the pr page

same button of delete branch

[copper garden]

Did you still want to make the PR?

[outer raven]

As long as you didn’t delete the fork you can restore the branch

[swift zealot]

I opened another one

[swift zealot]

I wasn't thinking at all to be honest

[wild flax]

@vernal rose are you sure your root hoisting also makes it possible to run the commands inside the packages too

without having to run them on the root

or use the workspace focus cli from yarn

I know for sure you can't make the changes to the /website directory

Since we use npm on vercel to install stuff from that folder

because yarn doesn't work there correctly

[vernal rose]

eslint, prettier are installed inside of the package too so you can run the command from there. For release, yarn workspace or turbo can work from root. If u want I can add the cliff-jumper inside of all the packages again but those eslint plugin and config can be used in root

[wild flax]

yeah its mainly the binaries I need

since for releases I execute most stuff inside the packages folders

and not on root

but youll have to fully revert the changes to the website

[vernal rose]

done btw ci is failing but ig it's not related to my changes

[wild flax]

its not

thx

[vernal rose]

https://github.com/discordjs/discord.js/blob/65d1879/packages/builders/src/messages/formatters.ts#L54 Why do these formatter functions use the generic type C extends string and not directly string as a parameter?

[warped crater]

look at the return type.

its so underscore('abc') returns '__abc__' rather than string

it's just a stricter type

[vernal rose]

got it thanks

[mighty bough]

is djs ever going to remove support to just do channel.send(string), so you need to do channel.send({ content: string })?

[opaque vessel]

I think it's a very commonly used way of sending a message in a channel and it's the only single helper overload so... possibly not? But idk

[stray shell]

For my opnion, it can stay as it is.

[inland lotus]

I dont see a reason for removing it

[honest barn]

same

[wild flax]

It won't be removed.

[real jetty]

Why did you do this update that needs to specify if it's content or embed??

I also don't understand, could you explain?

[visual hornet]

that's what discord requires

When creating a message, apps must provide a value for at least one of content, embeds, sticker_ids, or files[n].

[copper laurel]

I think they're referring to why we don't allow .send(embed) and it was because overloads like this were unintuitive and break easily, particularly when they then had to send another object for message options.

The content string is friendly enough for both users and maintainers to keep

[nova kestrel]

can i ask, why does https://discord.js.org/#/docs/discord.js/main/class/TextChannel?scrollTo=awaitMessages return a Collection? how are you supposed to index a collection of data where you cant know the keys. wouldn't it make more sense to use an array?

[unique axle]

the idea is that you collect things you want to process, iteration is a valid construct for that, what would indexing help there?

at the end of the day collections are used whenever we can associate a unique key with an instance in a "collection" of structures

[visual hornet]

if you want to index it, you can just spread the iterator, or you can iterate to process the elements in order

A Map object iterates its elements in insertion order

[unique axle]

in 9/10 cases where people want an array in here they probably don't need one

[outer raven]

And a map is easily convertible to an array whereas the opposite isn’t true

[solemn oyster]

It is true, using the Map's constructor, just requires a few more characters

[outer raven]

You can’t just slap any array in the map constructor, you have to map it

[warped crater]

new Map(arr.map((e) => [e.id, e]));

[winter flume]

is there any updates or planned things going on with https://github.com/discordjs/discord.js/pull/7204

[solemn oyster]

There's a new RFC for it, and I'll implement it in its due time

[winter flume]

oo, havent heard of that, can you link it please? sorry for taking ur time

or is this it?
https://github.com/discordjs/discord.js/issues/8084

[solemn oyster]

Yes, it is

[winter flume]

okay, thanks

[magic zodiac]

Any news on this? And is this something that will be implemented correctly in the discord.js library?

[white hedge]

I think it's still in development

[ornate topaz]

There is no reason for it to not be implemented

[unique axle]

Moved to tagged post in #992669226403909652