#djs-in-dev-version

1 messages · Page 7 of 1

steel haven
#

Mostly because the runtime error for that would otherwise be less helpful for the invoker to understand what they did wrong

meager crag
#

So is that a "should only runtime-check function parameters"?

#

The falsehood check in equals() is a bit strange – doesn't really seem to fit any specific paradigm, and just prevents falsy values from throwing at runtime, which probably decreases debuggability if anything

steel haven
meager crag
twilit bobcat
#

And all methods expecting a function as parameter check for it being a function before trying to call it.
not all of them though, as mentioned sort doesn't do that, toSorted doesn't either

steel haven
twilit bobcat
#

ah, makes sense then

#

yeah it does

#

node 20 though, not sure what the lowest supported version for collection is

#

or well it also says it accepts undefined which isn't a Comparator

#

I don't think it's an issue though given compareFunction has a default value

steel haven
twilit bobcat
#

ah, true

#

toSorted has that same issue

agile whale
#

ig it got ignored, can't blame anything for it; there's also a reference in GuildManager but its in listeners so it passes

image.png
steel haven
agile whale
steel haven
agile whale
steel haven
#

As long as you state it‘s about the dev version/main branch it‘s okay to open an issue

#

But I‘ll probably draft a PR to fix that tonight anyway

#

Comments on commits are indeed not the right place for these kinds things though. Either here or an issue

agile whale
#

My apologies, I'll come here

twilit bobcat
#

shouldn't these follow the "A manager for the X" format? similar as other djs objects

image.png
#

the current descriptions make them sound like they're collections or maps

steel haven
#

Afaik there’s already a PR for that

#

It was even merged already

cinder wraith
#

Was it fixed/unmerged/rerebased/whatevered?

#

Iirc that's the one that got merged unintentionally early

dull mulchBOT
steel haven
#

It was

cinder wraith
#

Ah AD_BN_Thumbs

twilit bobcat
#

oh yeah looking now at main

#

it's actually a mix of both now lol

image.png
#

channels' description got reversed but the others were applied

#

(the original pr did change channels)

steel haven
#

Half of the change to channel‘s description went through though. Only the change on the first words didn’t

meager crag
# steel haven Well, an equals() method should never throw imho. It should accept any type and ...

Sorry to labour the point. It sounds from your description of what this method should be, that its semantics are along the lines of equals(collection: unknown): collection is Collection<Key, Value> (accepts any parameter and returns whether it's a Collection with equal contents), rather than equals(collection: ReadonlyCollection<Key, Value>): boolean (assumes that the parameter is already a Collection, and just checks its contents)?

#

The documentation doesn't currently suggest this, so just wanted to clarify

steel haven
meager crag
#

I'm using TS type notation there just to convey the idea

slate mango
#

@meager crag a few things regarding your Collection PR:

Thank you for the * -1, I got surprised to see that, although I’d probably include in the PR’s description that it’s to avoid accidentally promoting 0 (SMI) to a double.

I haven’t double checked with the spec, but does new Array(n) create an array with n holes (aka .length is n) (also internally tagged by V8 as HOLEY_VALUES, same as before, which is undesirable) or an array with a capacity of n (PACKED_*, very optimised and desirable)?

Regarding the slices, can’t we make it a combination of skip/drop to the start, then pick/take the amount of items until the end? It can be implemented spec-compliant like this.

meager crag
# slate mango <@718085825488748564> a few things regarding your Collection PR: Thank you for ...

I haven’t double checked with the spec, but does new Array(n) create an array with n holes (aka .length is n) (also internally tagged by V8 as HOLEY_VALUES, same as before, which is undesirable) or an array with a capacity of n (PACKED_*, very optimised and desirable)?
It creates the array as sparse, ie. with length: n but with empty items. The only way to create a PACKED array here is to use Array.from(), but that's significantly more expensive for the reasons alluded to. HOLEY arrays still do have access to many fast paths, and I wouldn't imagine (but have not tested) that any onward performance difference in consuming the array would outweigh the 10-20x longer it takes to create it, in the majority of usage cases.

Regarding the slices, can’t we make it a combination of skip/drop to the start, then pick/take the amount of items until the end? It can be implemented spec-compliant like this.
Are you referring to last()? In which case, this actually turns out to be slower.
By definition, a manually iterating process for last() has to iterate over every single element in the collection (first to skip over the unwanted values, then to grab the wanted values and append them to the output array). However, running iterable-to-array on the builtin map iterator returned by this.values() appears to be approximately twice as fast as this in V8. I ran a few tests, but it seems around 50% quicker just to perform the iterable-to-array and call .slice(), rather than hand-cranking the iterator.
If you're able to find a trick that I haven't, then I'm all ears!

meager crag
#

The only way to create a PACKED array here is to use Array.from()
Should have said "the only way to create a PACKED array of size n". It's obviously possible to create an array of length 0 and then sequentially define its elements – this was the original approach I took, but on testing, it's around twice as slow as starting with a length-n sparse array, presumably because it has to update length with every new element added.

slate mango
#

Just curious, may I ask how you benchmark your code? @meager crag

#

I find it a bit suspicious that drop+take would be much slower than making the entire thing into an array and then slice, or in the case of .last(), just dropping (hand-cranking) until this.size - amount and then spreading the rest of the interator into an array.

meager crag
slate mango
#

Oh, I don’t remember reading that one

meager crag
#

I'm just using benchmarkjs to test these over collections of size 100-10k.

meager crag
tight delta
plain roverBOT
#

tag suggestion for @tight delta:

Errors such as ECONNRESET, ConnectTimeoutError, SocketError: other side closed indicate a network issue

  • Free or shared hosting providers often come with significant limitations
  • Another indication of these issues are 'Unknown Interaction' errors.
cursive venture
#

Also not related to the dev version

tight delta
#

What should I do

knotty plover
#

nothing we can do about it

bright wren
scarlet tangle
#

Is there a way to forward a message in dev version?

sinful heath
#

No, I think that might’ve been something I missed in my PR haha

dawn phoenix
#

well, as long as the api supports it, there is always the "make the rest request" approach you can take
if you want to use a feature a lot throughout your code base, you might want to consider wrapping it in its own function and swapping the implementation of that once there is an official release

if you use client.rest you will share the rate limit handler with your client instance and should be fine
-# not applicable here, but as a general caveat: functionalities that are not documented by Discord may be removed or changed at any point in time without prior warning or respecting semver. this is why we try to not prematurely merge PRs and recommend you thread with caution.
-# also note that we are unable to help with custom implementations, unless you specify and show said implementation

sterile pilot
#

Is there a function to check if a user has forwarded a message? I want to create an anti-link system

keen bobcat
#

are you using the dev version?

sterile pilot
dull mulchBOT
keen bobcat
#

it hasn't been merged yet, you can follow the pr

plain roverBOT
sinful heath
#

I think this would be what's being looked for. If its size is greater than 0, then it represents a forwarded message

keen bobcat
#

oh there were 2 different pr's for it, mb

sterile pilot
#

Can it be used?

#

@sinful heath

sinful heath
meager crag
#

@tawdry mantle what do you think about event maps for BaseClient et al? It would peg users to @types/node versions since EventEmitter was made generic (about a year ago iirc) so would probably have to be a major version change

tawdry mantle
#

yes, not yet. Next release of main will be a major at this point. It's been in since very end of Feb. The problem right now is that we can either leave types/node where it's at and support TS <5.6 or update and I think break everything <5.6 (the iterator changes appear to cause some issues, at least when testing, it may not be a real issue in user code) Apparently the person testing didn't notice the new namespace for iterators, using that is the way

#

The only reason I want to wait is to ensure that the new changes are stable (not logically, but because they are a bit controversial) and probably your refactor PR to merge.

meager crag
#

Aye, the iterator changes are backwards-compatible with TS <5.6 but make it very difficult to override iterator-returning methods downstream (which fortunately isn't necessary if using an event map).

#

Related, those static method overrides from #10360 now break the latest @types/node, so probably need to be removed for v14 as well

#

I proposed adding instance methods to BaseClient to provide a strictly typed way of calling events.{on,once} without clashing with @types/node, but there's not much of a case for having them once those functions work as expected.

#

Might be that the simplest option is just to remove the overrides now and accept un-narrowed types for those functions until v15 (or whenever)

dull mulchBOT
tiny dock
#

guys, there's no event called "SUBSCRIPTION_UPDATE"

cinder wraith
tiny dock
cursive venture
tiny dock
#

I don't think so..

cinder wraith
#

are you talking about entitlements?

tiny dock
#

discord just talk about it in their changelog

image.png
tiny dock
sinful heath
tiny dock
plain roverBOT
idle galleon
#

We alr have it in stable

dull mulchBOT
sinful heath
#

Still being worked on ^

tiny dock
#

exemple

image.png
tiny dock
#

I'm going to watch

split crystal
#

When a shard resumes saved session, is it supposed to emit a clientReady? in my case, it only just logs that the shard resumed but it is not responsive thereafter

silent hedge
#

are you actually using the dev version

split crystal
silent hedge
#

how many shards are you running

#

and is it only internal sharding

split crystal
#

im trying out the integration of the /ws library in mainlib with worker sharding strategy and the session saving methods

silent hedge
#

right, ok. i dont remember exactly what we did with the client events

silent hedge
split crystal
#

this is not reproducible with the microservice using /ws so i guess this is a flaw on mainlib?

steel haven
#

and /ws itself has no clientReady event, so of course it's not reproducible with that

silent hedge
steel haven
#

we might indeed not do that, now that I look at the code

silent hedge
#

i feel like i looked at this before but forgot to say anything

#

or did but forgot and no one saw

steel haven
#

this might need a rewrite of parts of the login logic though, because some shards might resume while others need a fresh connect... ugh

silent hedge
#

hm? why's that an issue the shard itself decides what to do

#

don't we have a tracking problem at-worst

steel haven
#

we have a bigger issue. Guilds don't get sent on resume, so the current notion of Client#guilds has all guilds the bot is in when clientReady emits would fail us

split crystal
steel haven
#

then the clientReady would've already emitted and the client should simply remain ready, what did you expect it to do that it didn't?

split crystal
#

it did not emit though

steel haven
#

but you said the client was logged in before, at that point in time it would've emitted, right?

split crystal
#

the shard that resumed from the saved session is unresponsive for some reason

#

sorry i may have misunderstood your question

split crystal
#

i was multi-tasking sorry

#

i did not read the question properly

steel haven
#

walk me through what your code did when you started it. You call Client#login(), and it (tried to) resume at that point in time with a stored session? only for one shard or did all shards have a stored session?

split crystal
#

all

#

yes that is correct

#

i also utilise the worker sharding strategy

steel haven
#

that is indeed an issue with current dev version of mainlib, yeah. see the above discussion with DD. and it would need some thought on how we'd approach and handle that

split crystal
#

Ah

#

how unfortunate

#

Thank you for the help

silent hedge
#

we're screwed i think

rigid haven
#

was there a reason why OmitPartialGroupDMChannel<> wasn't added to the parameters of messageUpdate?

image.png
uncut kelp
#

It's already there on main, so your question is outdated

rigid haven
#

ah, okay

willow mica
steel haven
willow mica
steel haven
willow mica
steel haven
haughty ridge
#

Hey, i found that on discord, is it available on djs ?

image.png
#

That would help a lot for invite loggers, avoiding any error

cursive venture
#

bots do not have access to the members tab

sharp stump
#

I recently changed to a dev version of discord.js (15.0.0-dev.1728475516-c36728a81) due to the lack of api support for forwarded messages in the stable release. After proceeding with an upgrade of the dev version, from 15.0.0-dev.1728475516-c36728a81 to the current latest dev build 15.0.0-dev.1732017912-98153baf9 I have encountered the following type discrepancy:
Code

await interaction.deferReply({ ephemeral: true });

Error

TS2769: No overload matches this call.
  Overload 1 of 2, '(options: InteractionDeferReplyOptions & { fetchReply: true; }): Promise<Message<boolean>>', gave the following error.
    Object literal may only specify known properties, and 'ephemeral' does not exist in type 'InteractionDeferReplyOptions & { fetchReply: true; }'.
  Overload 2 of 2, '(options?: InteractionDeferReplyOptions | undefined): Promise<InteractionResponse<boolean>>', gave the following error.
    Object literal may only specify known properties, and 'ephemeral' does not exist in type 'InteractionDeferReplyOptions'.

Did I miss a change in how the ephemeral flag is passed to the defer request?

vague coyote
sharp stump
jade harness
#

is v15 gonna be the TS rewrite?

rain bramble
#

There's no specific version for TSR

knotty plover
#

It's unlikely to be v15

twilit bobcat
#

maybe vX, X → ∞

fallow iris
robust sparrow
#

and what are the differences between 14 and 15-dev ?

keen bobcat
#

I don't believe there's a comprehensive change log for dev yet

idle galleon
robust sparrow
#

mb

idle galleon
# robust sparrow mb

It’s fine. We generally don’t make the list until it’s closer to release

uncut kelp
keen abyss
#

What made you all decide to remove ephemeral completely and now you have to specify the flags instead? This seems like a strange decision since just specifying ephemeral seems way easier

#

Everything else is great though

uncut kelp
# keen abyss What made you all decide to remove ephemeral completely and now you have to spec...

Is there that much of a skill issue gap between ephemeral: true and flags: MessageFlags.Ephemeral? 🤭

Specifying ephemeral means discord.js would do MessageFlags.Ephemeral internally. They both achieved the same behaviour. You can use it right now in version 14. However, since ephemeral is just one possible flag, it may set a precedent that all possible flags should be booleans, e.g. ephemeral is here, why not suppressEmbeds too?

It also begs the question of what happens when you're using both flags and ephemeral. Which one takes priority, especially if you're dynamically/conditionally using those properties? Don't think you'd know that off the top of your head without testing it out. It's better to just have one simple way of doing it, and flags is the correct way of doing it instead of listing every option out as a boolean

keen abyss
#

I think it’s a qol thing rather than anything else, but you do give a great example of priority, I guess I can’t argue much further

#

Thanks for responding, and great work on everything

cinder wraith
keen abyss
#

StringModalSubmitInteraction

cinder wraith
silent hedge
#

in general my sentiment is that methods that make API calls should do less magic and instead we should have more tools to help build the payload where complexity is high (like our bitfield helpers in this instance)

#

no magic props that don't actually exist, no props that influence other props within the method's body, etc

cinder wraith
#

this makes no sense / is a null comparison. they target diff. properties on the underlying prop sent to the API
they are placed on the same message. sure, they don't collide with each other, but how many people here even know ephemeral is a flag to begin with? like, i don't understand why having everything be additive into the resulting message so far would suddenly make flags and ephemeral expect people... what? to not be additive now?

steel haven
#

what happens if ephemeral is set in flags but you pass ephemeral:false?

keen abyss
#

Can you not do that already though? I don’t think I’ve seen one case where anyone has had that problem

cinder wraith
#

-# regarding ^, do people know flags exists?

keen abyss
#

I’m still on the side of keeping ephemeral purely for qol, but I do understand why you removed it

silent hedge
#

ultimately this is a case where I think by metrics I consider to be objective, this change improves the code you write, even if you're "missing qol"

#

and I'd reckon everyone else that pushed for this feels the same

#

if you only care about quickly prototyping changes like this suck as they add up, yes

keen abyss
#

I’m not too sure, I do feel that we’d get a decent amount of people running here complaining.

silent hedge
#

but fundamentally discord bots are usually large and complex, so its good that we do those things

silent hedge
#

this is more correct, so it should be this way

keen abyss
#

I guess if that’s how you feel then there’s no point arguing, since you ain’t gonna budge because you don’t care about qol

silent hedge
#

sometimes we make compromises, but those in internals know I've been an advocate for removing send(content: string) too

#

I'm all in on the "lets make it right" side, there's counterbalances/people on the "lets just keep it high qol" side

#

in this case the former won out

silent hedge
#

if enough people decide we should actually keep it it'll get reverted

#

i'm just voicing my position

cinder wraith
#

then why say you don't care instead of we don't care (as in: peopel who pushed for it)

keen abyss
#

Make a poll 🤷‍♂️

silent hedge
keen abyss
#

Removing .send(“hello world”) makes hella more sense, as well for internals. Removing ephemeral, idk, to me doesn’t seem as reasonable

steel haven
#

they are both qol properties/overloads that differ from actual API representation though. I'd argue the opposite: if any of those two should be removed ephemeral should be first before send(string)

keen abyss
#

send string makes more sense, djs can just throw an error if you don’t send an object. Ephemeral, I’ll go back to my point before, I don’t believe anyone has come here before saying it doesn’t work because they sent both flags and ephemeral

knotty plover
#

The reason for that is probably because the second most used flag is usually done via a helper method in an edit

plain roverBOT
wanton crown
#

That's really interesting, my first time seeing this
what flags are there? and can you set multiple at once? TujiThink
I guess you'd just put them in an array?

steel haven
#

you could. but in the end it's a bitfield. just like permissions, intents, etc. so you can also just use bitwise or | to combine them

wanton crown
#

I see. So it would just be something like this? TujiThink
interaction.reply({ flags: [MessageFlags.Ephemeral, MessageFlags.AnotherFlag] })

fiery aurora
steel haven
wanton crown
#

I'm surprised I haven't seen anyone use this nyaShrug
I'd have switched over to that a long time ago if I knew ephemeral: true would be removed

cinder wraith
#

because there's only 3 flags at the current moment that you can set

#

Ephemeral that exists for years, SuppressEmbeds that only ever gets used as an edit to a message (personally i wrap urls with <> instead, if i send any), and SuppressNotifications for a silent message which is relatively new

fiery aurora
#

will

interaction.deferReply({ ephemeral: true });

also be changed to

interaction.deferReply({ flags: [MessageFlags.Ephemeral] });

?
Not sure how these flags function in relation to deferring, so asking to make sure.

steel haven
#

Yes of course.

fiery aurora
#

🙏

frank lance
fiery aurora
#

v15

frank lance
#

😭

#

why not just keep it the same

fiery aurora
#

because there's more flags

#

grouping them makes sense

frank lance
#

fair

austere rampart
#

Is there a general vibe of when v15 will come out? Obviously its early days but trying to get some type of idea of when I'll be able to use Deno since the ws@2.0 stuff is only going into v15, just wondering if we're looking at 6+ months or if theres some specific feature thats going to be the holdup or if its just a "whenever it feels right" type of thing waiting

knotty plover
#

The general vibe is always "when it feels right" but given that we've already started work on a v15 branch and a change guide, I wouldn't expect it to be more than 6 months.

#

But we never know 😄

robust sparrow
#

does @discordjs/voice is compatible ?

uncut kelp
#

Compatible with what?

robust sparrow
#

v15-dev

uncut kelp
#

Maybe. It's development, it can just change

#

Might be that recurring gateway voice dispatcher type error thing or whatever it is

robust sparrow
#

okk ty

ashen kernel
#

is the ready event different in the newest dev ver

keen bobcat
#

is there a particular reason you ask?

forest elm
keen bobcat
forest elm
#

its not there

ashen kernel
#

Thank you both appreciate it

keen bobcat
#

(i did say mostly mmLol )

silent hedge
uncut kelp
silent hedge
#

mmmmh

#

i cant really remember when we did this

#

i'd imagine qjuh's big PR that got rid of the compat layer for ws

#

was probably missed back then

uncut kelp
silent hedge
#

yup

uncut kelp
#

Yeah so just purely dev version. Just needs a quick documentation fix and a guide note. Thank you for clearing that up (':

silent hedge
#

its even in the list in the commit body

uncut kelp
#

I thought I could get away with just referencing the pull requests, but obviously not (':

ashen kernel
#

message.guild.roles.cache.get(r.role) can u no longer fetch role like this?

knotty plover
#

you have never been able to .get() anything without using the id

#

This has not changed in the dev version

ashen kernel
#

wait tf my code worked before and after update it broke haha
ill use .find

#

ty

neat portal
#

is guild.bans.create() gonna be removed?

rain bramble
idle galleon
neat portal
fallow iris
#

Seeing someone saying this has to be true

knotty plover
#

It's not

fallow iris
#

-# (Should be ironic)

daring matrix
uncut kelp
#

What you described as easy for you is not maintainable. That logic then follows booleans should be made for flags everywhere. Perhaps it's something you should adjust yourself to. There's always documentation too.

Also, flags is a bit field

daring matrix
#

In an interaction reply, only Ephemeral, SupressNotifications and SupressEmbeds are valid (if I am not mistaken).

Why is having that as an abstraction unmaintainable?

#

It's the same level of maintainability as specifying the types for the flags. Here's an example of the InteractionReplyOptions
Flag options are manually typed, based on which are applicable to a specific interface's flags.

export interface InteractionReplyOptions extends BaseMessageOptionsWithPoll {
  tts?: boolean;
  ephemeral?: boolean;
  fetchReply?: boolean;
  flags?: BitFieldResolvable<
    Extract<MessageFlagsString, 'Ephemeral' | 'SuppressEmbeds' | 'SuppressNotifications'>,
    MessageFlags.Ephemeral | MessageFlags.SuppressEmbeds | MessageFlags.SuppressNotifications
  >;
}
silent hedge
#

It's the same level of maintainability as specifying the types for the flags.
it's not, hope this helps

#

it's less than half the work

#

"intellisense is miss-leading me" is also not the strongest point here

daring matrix
#

Either way - I was voicing my opinion, as was welcomed earlier on.
In my opinion, Discordjs should try to abstract more, rather than actively devolve by removing abstractions that are widely used.

uncut kelp
#

You could always do this if you don't want to use MessageFlags

image.png
daring matrix
silent hedge
#

I think I've made it pretty clear that our goal is not to remove abstraction, I just believe that it should be introduced in a way where we aren't lying about the inner structures of the API. Resolving from more convenient types into the actual payloads is an okay transformation, but straight up taking in propeties to an API-call method that aren't actually on the payload, is IMO, a no-go.

daring matrix
silent hedge
#

not at all, @discordjs/core is the thin one

#

the reason is simply because we can ultimately do it without much compromise (e.g. this prop removal is imo, deeply insignificant) and in the past we've been hurt by not doing it multiple times, often in ways that couldn't be resolved without a major version

#

I also just think it encourages you to write better code (being friendlier to the ecosystem and newcomers (in terms of the API) as a whole, for instance) and also helps you in the long run

#

if our standard becomes to adhere to the API where possible, it becomes pretty unlikely for us to change those interfaces on our end over time

#

those are benefits I can name for the user end, for us internally, there's more

daring matrix
silent hedge
#

How is it vastly beneficial? How would someone new to the API even know ephemeral messages are a thing, if not from our docs/guide to begin with, that has been/will be accordingly updated to specify how you do that?

cinder wraith
#

seeing it as an explicit option for example

#

right now the only reason the word ephemeral even exists on docs for the flags is because we're either doing in-place extraction out of MessageFlags to extract the 3 settable one of out however many there are, or because for the exact same reason on old docs we are kinda obligated to say that you can only set those 3 flags in an info block.

current docs show the entire in-place type, while old docs just say MessageFlags

daring matrix
cursive venture
#

it is not on the send method though

#

regular messages cannot be ephemeral

daring matrix
cinder wraith
#

but they can have the other 2 flags

twilit bobcat
#

adding those as well would polute the type way too much imo

daring matrix
twilit bobcat
#

it's not like they'll be the last flags discord will add though

#

they aren't individual fields in the api, they're in flags, so I'd argue they know why is that and it's not that unreasonable to move it there to be more consistent with the api

cinder wraith
#

but rn we're already mingling into that a bit

twilit bobcat
#

there's also the conflicts that were mentioned, eg what would be the expected behavior if ephemeral is false but it's set in the flags

cinder wraith
#

we are extracting the 3 currently settable ones out of them all, with an in-place, unnamed extract

#

i'd argue for naming that extract and using that as the type

twilit bobcat
#

yeah it'd be better if it was named imo

daring matrix
cinder wraith
#

"bad" why

twilit bobcat
#

what if it's explicitly set as false though, not just non present

daring matrix
#

But what I think does not matter. I am just voicing my opinion

cinder wraith
#

well, wouldn't that mean that we would need to replace all bitfields with just objects with boolean props?

#

admittedly, not like you can set user flags, but those, as well as member flags and permissions, are just bitfields

#

intents are also a bitfield

#

we do abstract over the bitfield itself

#

but by allowing you to do more with it, not completely changing what it is

twilit bobcat
#

I don't see the issue with abstractions tbh, at most it's more verbose but it isn't hard to understand

cinder wraith
#

your issue here started with a bit misleading intellisense, and i'm arguing right now for a way to fix it - taking a narrowed SettableMessageFlags or however that would be called, instead of the entire MessageFlags

#

that would solve your original issue without having to use string key names of the fields (which we resolve for you in such cases)

#

additionally, note that we also allow passing arrays of bits*, you don't have to do bit operations yourself. that's for an example of how we do some abstraction

* bitresolvables, more precisely. which the string key names are

twilit bobcat
#

I'd also argue that it's better to have it in an array, since there's only two states for it, it's either set or non set

#

an optional boolean makes it three possible states, true, false or non set

#

in this case false and non set are the same thing

#

so we might as well just follow the way it's designed in the api which doesn't have that issue

cinder wraith
#

i meant "spreading out" the props out of the bitfield into the outer object

#

so like new Client({ guilds: true, guildMessages: true, messageContent: true }), like in the case of reply({ ephemeral: true })
-# (though this example is kinda bad, there's no way we wouldn't wrap those into their own intents object, at which point...)

hollow wharf
#

Hello guys, i'm here for latest update asking - we still can't not use bot to forward a message to a User or Channel correct ? The reason i prefer Forward more than crossport/publish or basically fetch and resend the content is that the Forward giving the receiver the message link for user to come directly - which is super useful for message that have button

cursive venture
hollow wharf
#

Can you share a link ? i tried Ctrl + F the "forward" keyword but can't find anything to confirm anything

#

PR stand for Post Release right ?

cursive venture
#

pull request

hollow wharf
#

So it 100% will be added or just hopefully will be added ?

cursive venture
#

it will be added

#

but it could be in the next release or in v15, not too sure

dull mulchBOT
cursive venture
#

this is said PR, but is for v15 afaik

hollow wharf
keen bobcat
#

Minor versions don't have any breaking changes, so you wouldn't need to rewrite anything until v15 is released

#

And afaik message forwarding is getting released in 14.17

rigid haven
#

It hasn't been backported yet and no pr has been made

steel haven
#

It hasn’t even been merged yet, so ofc it’s not backported yet

pine prawn
#

you should make js message.reply easy to write for not mentioning users in replies,

knotty plover
#

it is very easy to do this

#

Simply pass allowedMentions: { repliedUser: false } }

pine prawn
knotty plover
#

In the options

#

No, we tend not to and are continually shifting away from helper shortcuts that don't reflect the actual API

pine prawn
harsh path
#

if most of your bot's replies should have pings turned off you can also just put it in your client constructor

covert cipher
#

are there any actual docs for the main branch? looks like the ones on the site are outdated, e.g. they still have WebSocketManager

cinder wraith
#

which site

knotty plover
#

docs autogenerate, theres no reason they would be outdated unless that was broken, and it doesnt seem to be

covert cipher
#

ig its just an old page still existing for some reason

knotty plover
#

ahh, yeah not sure why individual pages exist

pine prawn
#

what to fetch bot banner? like

interaction.client.user.displaybannerurl```?
keen bobcat
#

You should refer to the docs, not guess

plain roverBOT
pine prawn
split crystal
silent hedge
#

the library is fundamentally built on the reliance that all guilds are cached, and with stored session info allowing a resume from a different process all-together, we cannot populate the guild cache

#

its a symptom of a problem that is incredibly difficult to address as things are

split crystal
steel haven
split crystal
silent hedge
#

very, but "fetching all guilds" is a little iffy

#

the API endpoint for it is kind of a pain

split crystal
#

You mean i would have to handle its pagination ?

silent hedge
#

that's one part of it, yeah

#

if you can find an alternate way of filling up the cache that'd also work

split crystal
#

I do not think this is feasible for us

silent hedge
#

and store guild API data in like, redis or whatever else

#

and "trick" the library into caching it back on startup

split crystal
#

i sort of expected that there would be no viable solution for this in mainlib until TSR so i made a microservice with /ws and /core and /brokers to just avoid doing this 😭

silent hedge
#

why are you still using mainlib at all then

steel haven
#

Alternatively use await client.guilds.fetch(id) everywhere you‘d usually client.guilds.cache.get

silent hedge
#

i wrote /ws and /brokers and chimed in on /core specifically to support stuff like this

#

like, that was my whole thing in becoming an active contributor here

split crystal
silent hedge
#

i see

split crystal
#

i have been experiementing with this setup for quite a while

#

and its proving useful

uncut kelp
#

I wouldn't say there is a big skill gap from switching to discord.js to @discordjs/core+ws+rest. It'll probably open their eyes a bit

silent hedge
#

well, I think if you're still learning everything it can be a bit of a shock to break out of like, the one thing you're used to

#

and start having to work with the API docs more and stuff like that

split crystal
split crystal
split crystal
silent hedge
#

just do caching yourself

#

its a bit of work at the start but you get there

#

simplest way if just JSON.parse/JSON.stringify

#

easiest step up is msgpack since json strings kinda suck for storage efficiency

split crystal
silent hedge
#

and at those stages its still trivial since those dynamically deal with whatever you throw at them anyway

split crystal
#

i never considered JSON due to perf reasons, but then again a xms difference is irrelevant in such a language

silent hedge
#

personally I'm running some completely custom stuff that originally kyra built

#

and I patched up and modified a bit

split crystal
#

okayyy that looks like some really cool low level stuff, since it is kyra who originated it... i suppose it is with maximum efficiency in mind?

silent hedge
# 
export interface CachedGuild {
    icon: string | null;
    id: string;
    name: string;
    owner_id: string;
}

export const recipe = createRecipe({
    icon: DataType.String,
    id: DataType.String,
    name: DataType.String,
    owner_id: DataType.String,
}, 200);
silent hedge
#

the idea is just storing stuff as the computer would kek

#

you define a memory layout

#

and then recipe.encode(someData) just straight up returns raw bytes that follow that layout

#

the first N bytes are icon string, the next N are the id, so on

#

for numbers there's sized types, i.e. I32

split crystal
silent hedge
#

the main overhead is for some safety the type is still embedded inside the data

#

like, if you wrote a string, the first byte tells you that a string is coming up

#

which tells the decoder the next byte is the length, N, and the next N bytes are characters

#

but you still tell it to decode a string, and if the byte type is miss-matched, you get an error thrown

#

with that recipe system I wrote (which Kyra didn't originally have)

#

that extra need for safety is kinda redundant

#

but it has its own overhead

#

either way, its not a perfect system and I'm still experimenting with it when I have time kek

#

how big is your bot

split crystal
split crystal
silent hedge
#

who knows

#

the actual real API is is very fast though

split crystal
silent hedge
#

looks something like

new Writer(200) // pre-alloc 200 bytes
  .string('some string')
  .i32(123145)
  .dump();
``` and you just get back a Buffer
#

and then decoding

const reader = new Reader(buffer);
const str = reader.string();
const i32 = reader.i32();
#

this is what I meant with the safety byte, if you called i32 first on accident, thanks to that mechanism it would error

#

otherwise you'd just read whatever was there and treat it like a number without knowing any better

split crystal
#

also, i noticed the redis broker uses redis streams, i personally have never extensively tested redis streams, so i just nabbed the interface /broker uses it and integrated kafka with it

what i mean to ask is, are redis streams reliable for a larger load?

silent hedge
#

I'm honestly not sure

#

my prod still runs rabbitmq on some older broker code I wrote years back

#

generally I've been told that it should be completely fine, redis is pretty performant

#

if you wrote different brokers on our interface though, you should consider PRing it too

split crystal
#

do the subpkgs still follow OO patterns?

silent hedge
#

mostly

#

pub/sub and call/response patterns

split crystal
#

i mightve..... sort of.... used evt instead of the aee

#

so the code doesnt follow OO in the way one would think

silent hedge
#

oh we can continue in #big-apps if you wanna now since we're way out of scope

split crystal
rose dagger
#

hello guys

#

may i ask for help here?

cursive venture
rose dagger
#

i don't really know what version i am using, i am just beginning to code/script a discord bot

cursive venture
rose dagger
pine prawn
#

whats currrent version of dev release?

steel haven
#

It changes every 12 hours. If you have a regular version number without the word dev in it it’s not a dev release

pine prawn
#

ohh

still blaze
tame smelt
#

To me it seems unnecessary since the above code returns if it does

#

Inconsistency perhaps

silent hedge
#

yeah thats an oversight from when I refactored the send logic

meager crag
#

Is there an intended behaviour where LimitedCollection is instructed to set a new value beyond the maximum size of the collection, but keepOverLimit returns true for all existing values? The current behaviour is that the new value is set anyway, growing the LC beyond its maximum size – can't tell if that's deliberate or not.

knotty plover
#

If I'm understanding your question yeah, that makes sense to me. A caching system should be getting rid of its older values and keeping new ones. keepOverLimit isn't a filter on new items, its a filter on the sweeping of existing items.

So a new item would come in, get stored, it checks what it should remove, but you've told it not to remove any existing items, so it wont

cinder wraith
#

is keepOverLimit a functionality of LimitedCollection or sweepers though

knotty plover
#

The sweepers, I'm pretty sure

#

Which is what I was trying to say, yeah

cinder wraith
#

does that mean that LimitedCollection has no means of being Limited then?

#

ever since it was made i was pretty sure that it would simply remove oldest element if adding new would make it grow beyond set limit

knotty plover
#

Okay so I might have explained this badly but

#

Code is here

cinder wraith
#

oh, so it is fucntion of LimtiedCollection

knotty plover
#

When setting a new item, it FIRST checks it's contents to see what it should keep if it's over its limit, and deletes

#

Then it will ALWAYS add the new item

#

So if you set it up to keep all existing contents, yes, it effectively breaks its size limit

dull mulchBOT
agile whale
knotty plover
#

"Necessary" is subjective, but the reasoning why it's been proposed is right there in the PR

#

Having said that, it's been open for two years with basically no discussion

agile whale
#

just asked, naming sure is opinionated; especially for something like this that people use most often, i think current names are at least intuitive enough

agile whale
candid sky
#

Hey, will resuming come in v15?
like resuming the ws connection so that I can keep my bots voice channel connection alive if my vm would reboot

cinder wraith
#

so resuming ws or resuming voice?

candid sky
#

both would be nice

cinder wraith
#

one might be a bit more tricky to do than the other

candid sky
#

Which one is tricky

steel haven
#

The main issue with resuming mainlib discord.js in a new process is that guild cache won’t get filled but many functions of djs rely on guild cache.

steel haven
#

You‘re free to PR the ability to use a custom cache in discord.js. That’s … and apparently you don’t actually want to know

modest sigil
steel haven
modest sigil
#

Ok

dreamy ether
#

Good evening all,

After anothing recurring exploit where users manipulate what a bot says in order to ping everyone

I am wondering, would a good change be to require the user to pass a “everyone ping allowed” in an interaction object?

#

if so, ill get to it! Please let me know

rigid haven
#

it's already a feature

#

ClientOptions#allowedMentions sets a default for BaseMessageOptions#allowedMentions

dreamy ether
#

is the default for the bot to allow everyone pongs by defualt?

rigid haven
#

yes, because that is the default of the discord api

dreamy ether
#

unfortunate

robust badge
#

Is undici version has been fixed on dev version?

#

I get security issue so

robust badge
#

and djs package has no security policy so I didn't know where to report this so I just came to here.

uncut kelp
#

Undici is the vulnerable package here. No, it's not updated to resolve that, but it's open-source, so you're welcome to try

robust badge
uncut kelp
#

We use 6.21.0, and it's fixed on 6.21.1, so it should be no problem updating it

robust badge
#

I make pr then*?*

uncut kelp
#

Sure

robust badge
#

done

uncut kelp
#

Did you manually edit the version? Gotta update the lockfile too now since it's out of date, and update Undici everywhere else

steel haven
#

Not to mention that that vulnerability doesn’t affect us as we never use the functionality that was vulnerable

rigid haven
#

It would also be very helpful if the version bump was backported to a 14.x release

uncut kelp
#

It will—it's not a breaking change

pine prawn
#

why npm audit fix downgrading discord.js to v14.14.1?

keen bobcat
#

were you using the dev version to begin with?

pine prawn
#

no, I'm using latest stable..

keen bobcat
#

then you're in the wrong channel, as this is for people using the dev version

pine prawn
#

is dev version get updates daily?

keen bobcat
#

releases are done every 12 hours (see the topic)

pine prawn
#

so is you have canary/alpha or beta version which get updates les frequently?
as I want to try new features first but updating library every 12h seems... Not good

steel haven
#

You don’t need to install the update every 12h

pine prawn
#

then..?

cinder wraith
#

whenever the update with a commit or pr merge of interest is released

twilit bobcat
#

do consider that dev builds aren't guaranteed to be stable, I wouldn't recommend using them in production

#

even new releases tend to have bugs that are hotfixed asap

cinder wraith
#

-# probably because nobody runs the dev builds 🥴

sweet flare
#

zlib-sync isn't installing at all on newer node. But from what I understand, you switched to node:zlib? I would recommend removing this dependency from the docs if its no longer necessary.

haughty sorrel
#

Hey @meager crag, regarding this PR, I came across this proposal (specifically the motivation part) and wanted to know what you think about it

meager crag
# haughty sorrel Hey <@718085825488748564>, regarding [this PR](<https://github.com/discordjs/dis...

Hey! The TC39 proposal regarding rescinding subclassing behaviour for builtins won't affect userland implementations (Symbol.species would be retained, and the explicit rationale put forward is to allow userland to continue to use it for that purpose). Map doesn't actually use any builtin subclassing behaviour in its own methods, and although the Map[@@species] getter would be removed, there's nothing to stop Collection from re-implementing it, and there wouldn't be any backwards compatibility issues with doing so.

#

From what I understand, that proposal is a long way from even reaching stage 2 – TC39 doesn't have precedent for reverting existing language features

haughty sorrel
meager crag
#

The issues motivating the proposal only apply to under-the-hood engine internals, particularly for array methods, as it messes with path selection and whether the constructed object is an optimisable builtin data structure or not

haughty sorrel
boreal knot
#

and we didn't switch to node:zlib, we also support node:zlib

#

we don't have perf benchmarks to compare between em

sweet flare
#

It hasn't really been updated in 8yr so I doubt it'll receive anymore updates. If you want to keep it ig I would suggest forking and fixing it, otherwise you'll be stuck with a broken dep in the foreseeable future

steel haven
sweet flare
#

I just removed it without a noticeable difference but you might've wanted to know it's not installing anymore

formal vector
uncut kelp
#

It'll be resolved in the next development version

formal vector
#

thank you!

urban abyss
#

Hey guys quick question would 16kHz PCM, uLaw work for a discord bot when developing? this is for testing purposes

#

Or like does discord purposely not work with this format

steel haven
#

Doesn’t sound related to developing the library discord.js. You can ask in #998942774994927646 assuming this is about playing sound in voice channels

urban abyss
#

I'll proceed to put a req in djs-voice channel

icy dew
#

I see that ChannelManager#createMessage() exists now, maybe it's just me, but wouldn't it make sense for it to be ChannelManager#send()? Because even for the UserManager, it's send() not createMessage(), so I thought maybe consistency-wise, it could be changed?

steel haven
#

the opposite is the case. createMessage is the method that's in line with API naming. The send() methods now are merely helper methods internally calling that createMessage() method

icy dew
steel haven
#

It's just a helper

icy dew
#

got it

steel haven
#

since in the end it's also a createMessage() call on the DMChannel with the user

icy dew
#

yeah I figured, thanks

verbal estuary
#

What new features does the dev version have? I know its a broad question, but if theres a list i can check out

keen bobcat
#

There should be an updating page on the guide repo

uncut kelp
verbal estuary
#

Thank you

#

I went to the guide and i barely see any changes. So for example on main branch on djs docs i see AllowedMentionsBuilder class so like where do i find what it does?

uncut kelp
#

It's a builder, like others, but for allowed mentions

verbal estuary
#

Actually i just realized best way to find new discord features for bots would be thru their documentation im sorry

twilit bobcat
tame smelt
desert plover
#

does anyone know when discord.js 15.0.0 will be officially released?

uncut kelp
#

No

silent hedge
#

when it's ready™️

desert plover
#

and what percentage of it is already done?

silent hedge
#

wouldn't be able to tell you

#

more work is added as we figure out it's needed

steel haven
desert plover
steel haven
#

we don't "add" stuff. we implement what the API supports. v14 and v15 both currently cover all documented API

desert plover
#

okay

verbal estuary
#

tbh if you ask me currently discord is not adding much on bot side so discord.js wont be adding much features unless discord themselves do. discord is focusing more on sdks currently, but maybe i can be proven wrong, who knows

tame smelt
#

Maybe 👀

ember lantern
#

Out of curiosity, has a caching system that uses Redis ever been considered for djs?

dull mulchBOT
ember lantern
#

Interesting

steel haven
#

Guess it isn’t been used as cache though, only as broker

#

But with /core you can make your caching system any way you like

#

Replacing the caching system in mainlib discord.js with something else is not really feasible at the moment

ember lantern
lapis cove
steel haven
lapis cove
#

thanks :D

#

maybe with #Member too, it also has displayName property

steel haven
#

Funnily enough for GuildMember that already is the case

lapis cove
#

yikes, so only User

image.png
dull mulchBOT
lapis cove
#

I created the pull request :3

haughty sorrel
#

I don't know if we want to have getters in toJSON() as it'd make sense for it to match the API, discussing internally

lapis cove
#

getters have been added to json data for a while. Isn't it would be more accurate if we use api data instead?

steel haven
#

That’s exactly what Danial was hinting at, yes.

lapis cove
#

mhm, what do you think about setting this.data and removing .toJSON()?

image.png
steel haven
#

toJSON() is not something we invented. It‘s what’s literally used by the js engine if an instance gets handled in JSON.stringify(…). So fully removing it makes things worse actually

lapis cove
#

ah... so instead of using custom function for it, returning JSON.stringify(this.data) will be good right?

#

it's already raw data with no extra members

steel haven
#

No. Just return this.data or however the actual data is stored. What we wouldn’t want is doubling all data by storing it additionally as a data property, because that would double the memory storage needed

lapis cove
steel haven
#

Huh? The current method does bad things by returning redundant data imho. And getters don’t really cause API data to get returned

lapis cove
forest elm
lapis cove
#

we can also make the data can only be accessible by naming the property as #data, so users can only access data through the getters

lapis cove
keen abyss
#

Where’s the code for djs in dev? Is it another branch?

sinful heath
#

It’d be in the main branch

keen abyss
#

Cheers

strange knoll
#

are components v2 useable in @dev version?

steel haven
strange knoll
steel haven
#

You can check out the PRs we have for them if you‘re in such a hurry

twilit bobcat
#

they should work if you use direct rest calls

strange knoll
#

i wanted to try the builders to directly see how their JSON looks instead of just relying on the types by discord-api-types

steel haven
#

Huh? But the builders will produce those exact types

strange knoll
#

i wanted to use the builders to see how the lib sent them cuz when i tried with just the types, i was getting an error about the types

now i found out the issue is that i wasn't putting the components v2 flag

pulsar jacinth
pulsar jacinth
strange knoll
verbal estuary
#

What’s components v2?

shell lynx
verbal estuary
shell lynx
#

kinda, but that is if you want to use raw api calls, d.js does not have it implemented yet to their public releases (they also probably wait until the official announcement is sent by Discord API devs)

verbal estuary
#

I see. Thank you ^^

valid fable
shell lynx
knotty plover
#

Havent we already said that too

#

Its not some secret insider knowledge

shell lynx
#

could be, I just used that example hoping they were convinced enough shrug

pulsar jacinth
cinder wraith
#

Didn't they have it for months

pulsar jacinth
weak star
#

So turns it out was today

knotty plover
#

Yeah because people were just talking random shit

fierce lantern
#

are components v2 planned to get backported to v14? yes i know the v15 pr isnt even merged but im asking because its dapi types release is a breaking one which makes me think it can't

forest elm
#

there is no v15 pr, only v14

#

i guess that should answer your question

fierce lantern
#

by v15 pr i meant the components v2 pr to main instead of the v14 branch

inner maple
#

feral <- me waiting for the d.js release

knotty plover
#

Please keep this channel on topic with actual questions. Discussion is welcome in #archive-offtopic

inner maple
#

oop sorry, forgot that channel exists 😅 thank ya for the redirect

steel haven
fierce lantern
#

ah nice

desert plover
#

is there anything new in v15 that is not in v14?

twilit bobcat
#

new in dapi?

#

or new in djs itself?

desert plover
#

it's about what's new in djs and dapi

cinder wraith
#

given how v15 exists merely as a dev branch right now without much of, if any, ETA for its release, there's no reason to gatekeep any features discord adds from the only currently stable and supported v14

#

v15 might get them separately and/or differently due to it being a major version which explicitly means breaking changes in comparison to v14, but both the dev branch and the eventual minor/patch release of v14 should get the same things

desert plover
#

okay

twilit bobcat
rustic goblet
#

Is it correct that builders v2 doesnt export ContainerBuilder? Seems like a bug to me but this is the first time for me looking into components v2 so just wanna check

uncut kelp
#

@boreal knot^

boreal knot
#

huh

#

it should, if it doesn't, submit a pr

uncut kelp
rustic goblet
dull mulchBOT
uncut kelp
#

Thank you <:

rustic goblet
#

Np!

#

Also curious, whats the reason theres methods like setPrimaryButtonAccessory

#

since you end up needing to do .setPrimaryButtonAccessory(new PrimaryButtonBuilder()) instead of .setButtonAccessory(new PrimaryButtonBuilder())

uncut kelp
rustic goblet
#

or i mean of course i can later, but i cant use a chained function with ternary

uncut kelp
#

Methods return the builder, it's not a problem:

declare const sectionBuilder: SectionBuilder;
declare const enabled: boolean;

(enabled
    ? sectionBuilder.setDangerButtonAccessory((button) => button.setLabel('Danger'))
    : sectionBuilder.setPrimaryButtonAccessory((button) => button.setLabel('Primary'))
).addTextDisplayComponents();

declare let sectionBuilder: SectionBuilder;
declare const enabled: boolean;

sectionBuilder = enabled
    ? sectionBuilder.setDangerButtonAccessory((button) => button.setLabel('Danger'))
    : sectionBuilder.setPrimaryButtonAccessory((button) => button.setLabel('Primary'));

sectionBuilder.addTextDisplayComponents(...);

@boreal knot don't suppose you think there is any "cleaner" way to do what they want?

boreal knot
#

You don't need to override the let

#

You can just call the builder...

# 
declare const builder: SectionBuilder;

if (enabled) {
    builder.setDangerBlah()
} else {
    builder.setBlah()
}
uncut kelp
#

I'm confused, that's what I just said

boreal knot
#

You don't need a ternary

#

Nor setting the builder

uncut kelp
#

Yeah okay, there you go then!

boreal knot
#

👀

rustic goblet
#

Yeah i know thats possible too ofc, but i just like having the single chained function

#

I feel like adding a setButtonAccessory would be nice but if its not something you guys are looking to add i can work around it of course

boreal knot
#

I just went off of how we do it for action rows too when it comes to setting buttons

#

Cc @silent hedge thoughts?

rustic goblet
#

Also noticed that builders doesnt re-export discord-api-types, for example the SeparatorSpacingSize used by the separator builder, you cant import that from /builders (but you can from /core). Is that intended?

tame smelt
rustic goblet
#

Ahh i see

midnight stirrup
#

just a general question, anybody know the character limit for text display component?

plain roverBOT
#

documentation suggestion for @midnight stirrup:
discord Component Reference - Text Display
read more

rain bramble
#

Well. It's not documented

#

Try it and see

midnight stirrup
#

it doesn't seem to say 😔

#

yea i'm in the process of migrating to components v2, was hoping someone would have a documented answer before i started testing
ty anyway!

steel haven
#

The upper limit of text characters is 4000 in total.

twilit bobcat
#

also this is for the in-dev version, either v15 or unreleased v14, the former doesn't even have cv2 iirc and the latter doesn't exist because there's no new commits to the v14 branch since release

#

and ddevs should be a better place to ask for api questions overall

midnight stirrup
#

aight will check it out ty

brisk path
#

Does v15 have CV2 yet?

dull mulchBOT
steel haven
#

v15 doesn’t exist yet, so no

brisk path
steel haven
#

The main branch is the dev version. Which will one day lead to a release of v15

brisk path
gleaming violet
#

getting this error for some reason TypeError: polyfillDispose is not a function

uncut kelp
#

You're outdated—we removed all instances of that

gleaming violet
#

anything i should check?

uncut kelp
#

Only discord.js? You have to do the rest too

gleaming violet
rigid haven
#

Well the question is are you using discord.js@dev or discord.js@14.19

gleaming violet
#

djs 14

# 
  "name": "dis",
  "version": "1.0.0",
  "description": "",
  "type": "module",
  "main": "src/index.js",
  "scripts": {
    "dev": "nodemon index.js"
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
  "dependencies": {
    "@aws-sdk/client-sso-oidc": "^3.686.0",
    "@aws-sdk/client-sts": "^3.686.0",
    "@citizenfx/client": "^2.0.6497-1",
    "@citizenfx/server": "^2.0.6497-1",
    "ascii-table": "^0.0.9",
    "axios": "^1.7.9",
    "discord.js": "^14.19.1",
    "dotenv": "^16.1.4"
  },
  "resolutions": {
    "discord.js": "14.11.0",
    "@discordjs/builders": "1.6.3",
    "@discordjs/collection": "1.5.1",
    "@discordjs/formatters": "0.3.1",
    "@discordjs/rest": "1.7.1",
    "@discordjs/util": "0.3.1",
    "@discordjs/ws": "0.8.3"
  },
  "overrides": {
    "@discordjs/builders": "dev",
    "@discordjs/collection": "dev",
    "@discordjs/formatters": "dev",
    "@discordjs/rest": "dev",
    "@discordjs/util": "dev"

}
}
``` this is my package.json.
rigid haven
#

Remove all the resolutions and overrides - you only need those if you're on discord.js@dev (and then run npm i again)

gleaming violet
rigid haven
gleaming violet
queen ore
#

when will the guide for components v2 be released?

uncut kelp
brisk path
#

How can I use the v14 branch in my project?

rigid haven
#

v14 is stable, just do npm i discord.js
the main branch is the beta development branch that you install by doing npm i discord.js@dev

brisk path
rigid haven
#

ah in that case you can't as far as i believe

#

i think v14.19.2 is planned to happen soon though

brisk path
#

ah

haughty ridge
#

hey, <GuildMember>.inviter is still not available on djs ?

keen bobcat
#

discord doesn't provide that data

haughty ridge
#

oh sad, thx

zinc sentinel
#

improve container builder to be setup similar to embed builder as i and maybe most ppl find it quite hard to setup containers I especially do

knotty plover
#

It is very similar to embed builders

#

Containers are simply more complex because they're more powerful

carmine acorn
#

I think we just need documentation on discord.js guide to show what they are and where they can be used and examples and etc….

tame smelt
ebon vector
#

Is MessageComponentsV2 supported in discord.js@dev?

knotty plover
#

Yes, and in stable!

ebon vector
# 
src/interactions/slashCommands/test.ts:42:17 - error TS2769: No overload matches this call.
  Overload 3 of 3, '(options: string | MessagePayload | InteractionReplyOptions): Promise<InteractionCallbackResponse<boolean> | undefined>', gave the following error.
    Type 'ContainerBuilder' is not assignable to type 'APIActionRowComponent<APIComponentInActionRow> | JSONEncodable<APIActionRowComponent<APIComponentInActionRow>> | ActionRowData<...>'.
      Property 'type' is missing in type 'ContainerBuilder' but required in type 'ActionRowData<MessageActionRowComponentBuilder | MessageActionRowComponentData>'.
  Overload 3 of 3, '(options: string | MessagePayload | InteractionReplyOptions): Promise<InteractionCallbackResponse<boolean> | undefined>', gave the following error.
    Type 'MessageFlags.IsComponentsV2' is not assignable to type 'BitFieldResolvable<"SuppressEmbeds" | "Ephemeral" | "SuppressNotifications", MessageFlags.SuppressEmbeds | MessageFlags.Ephemeral | MessageFlags.SuppressNotifications> | undefined'.

42     interaction.reply({
                   ~~~~~

  node_modules/discord.js/typings/index.d.ts:259:3
    259   type: ComponentType;
          ~~~~
    'type' is declared here.
#

I got this error, when I try to build

knotty plover
#

I was wrong, due to PR fuckery it's only in v14

ebon vector
#

Okay. Thank you.

austere grove
#

why doesn't the topic use formatted timestamps for the release times anymore? (<t:1746878400:t> | <t:1746921600:t>)

uncut kelp
#

It would require updating twice a year to be accurate for those who go through daylight savings

austere grove
#

wtf discord lol

uncut kelp
#

Actually, it's a user issue. Take this timestamp for example on 31st October 2024 00:00:
<t:1730332800:t>
If you're in BST, for example, this would display as 00:00. That would be correct!

But it doesn't look correct for right now, 12th May 2025, because it's a misuse of timestamp markdown

austere grove
#

yeah fair enough

cinder wraith
#

also pretty sure we got some questions about the date that is inevitably tied to the timestamp even if you format it to display only the time

errant idol
rain bramble
rigid haven
#

isn't it always 00:00 utc tho, and utc doesn't follow dst?

rain bramble
#

UTC is always the same
Take Eastern Standard Time and Eastern Daylight Time for example
EST is UTC-05:00, but EDT is UTC-04:00

#

They change between UTC offsets twice a year

#

If your timezone doesn't use DST, you won't see any difference in the time. But if it does, there will be 1 hour difference in here.
<t:1735689600:f>
<t:1748736000:f>

cinder wraith
#

but the release cycle doesn't shift for daylight saving

#

00:00 utc is 00:00 utc regardless if it's june or january

scarlet tangle
#

do i need to bump djs builders either to use cv2 in djs dev

twilit bobcat
#

you didn't need to install builders separately

plain roverBOT
#

discord.js includes multiple sub-packages, installing these separately can mess with internal code:

npm uninstall discord-api-types @discordjs/rest @discordjs/builders
yarn remove discord-api-types @discordjs/rest @discordjs/builders
pnpm remove discord-api-types @discordjs/rest @discordjs/builders
scarlet tangle
#

has the way to attach files changed in djs@dev?

# 
const { AttachmentBuilder } = require('discord.js');
const attachment = new AttachmentBuilder('./files/attach.png', { name: 'file.png' });
await message.channel.send({ files: [attachment] });
#

i have no clue why this code throws the following error:

TypeError: Cannot read properties of null (reading 'byteLength')
    at Object.pull (/home/ubuntu/test-bot/node_modules/undici/lib/web/fetch/body.js:63:20)
    at invokePromiseCallback (node:internal/webstreams/util:172:10)
    at Object.<anonymous> (node:internal/webstreams/util:177:23)
    at readableByteStreamControllerCallPullIfNeeded (node:internal/webstreams/readablestream:3145:24)
    at readableByteStreamControllerPullSteps (node:internal/webstreams/readablestream:3254:3)
    at [kPull] (node:internal/webstreams/readablestream:1201:5)
    at readableStreamDefaultReaderRead (node:internal/webstreams/readablestream:2269:39)
    at nextSteps (node:internal/webstreams/readablestream:493:7)
    at async writeIterable (/home/ubuntu/test-bot/node_modules/undici/lib/dispatcher/client-h1.js:1437:22)
silent hedge
#

what version of node are you on

scarlet tangle
#

v22.14.0

#

nvm; removing yarn overrides for @discordjs/rest solved the problem

silent hedge
#

huh

#

but that's not how it's supposed to go

#

you should need the override for whatever latest dev djs rest is

scarlet tangle
#

the latest version of uncidi used in djs/rest@dev is causing this ig

# 
├─┬ discord.js@15.0.0-dev.1747095234-aa533efe2
│ ├─┬ @discordjs/rest@3.0.0-dev.1744589650-5c0b71455 invalid: "^2.5.0" from node_modules/discord.js
│ │ └── undici@7.8.0 deduped
│ └── undici@7.8.0
scarlet tangle
uncut kelp
# scarlet tangle i have no clue why this code throws the following error: ```js TypeError: Cannot...

I got this error too last night @silent hedge on 15.0.0-dev.1747008876-4f5e5c7c1. Haven't looked into it yet, but here's what my overrides are:

"overrides": {
    "@discordjs/builders": "2.0.0-dev.1747008877-4f5e5c7c1",
    "@discordjs/collection": "3.0.0-dev.1747008878-4f5e5c7c1",
    "@discordjs/formatters": "1.0.0-dev.1747008873-4f5e5c7c1",
    "@discordjs/rest": "3.0.0-dev.1747008873-4f5e5c7c1",
    "@discordjs/util": "2.0.0-dev.1747008873-4f5e5c7c1",
    "@discordjs/ws": "3.0.0-dev.1747008874-4f5e5c7c1"
}

Node.js 22.13.1 btw

silent hedge
#

hmm okay

uncut kelp
#

This reproduces it for me:

(client.channels.cache.get(CHANNEL_ID) as TextChannel).send({
    files: [
        new AttachmentBuilder("https://cdn.discordapp.com/avatars/618976181026422814/1f341400799da66e593f58e2e4bdf066.webp", {
            name: "test.webp",
        }),
    ],
});

Seems related to Undici—was not able to reproduce on 6.21.3, but was able to reproduce on all 7.x

cursive venture
steel haven
#

Probably another instance of undici (or undici-types) exporting its own Buffer type differing from the one in the NodeJS version causing an instanceof Buffer check to fail

steel haven
# scarlet tangle i have no clue why this code throws the following error: ```js TypeError: Cannot...

@jolly pike when we pass FormData (the native one from NodeJS in our case) to undici.request() we face that error 👆
investigating I found that this is the case because util.isFormDataLike() is true here https://github.com/nodejs/undici/blob/2ed2a8a1393b0da3215997e9941ec3a92a93f3d0/lib/dispatcher/client-h1.js#L1021 but webidl.is.FormData is false here https://github.com/nodejs/undici/blob/2ed2a8a1393b0da3215997e9941ec3a92a93f3d0/lib/web/fetch/body.js#L120
I'd call that an undici bug, do you agree?

meager crag
#

undici 7 specifically doesn't accept cross-implementation FormData etc – importing the undici implementation should be all that's needed

steel haven
#

but isn't the one in NodeJS global the same? since fetch() comes from undici after all? this is rather confusing and/or annoying

meager crag
#

import ... from undici won't result in the same object instances as Node's built-in fetch globals, even if the npm undici version matches that used in the loaded Node version

#

so basically, you need to use the global FormData etc. if also using global fetch, or the imported one if using fetch from a node_modules undici import

meager crag
#

in theory this might be fixed with a dependency bump if and when a new version of nan is released, but just out of curiosity, what's the state of the consensus regarding zlib? obviously there's now been support for zlib-native for some time, plus zstd emerging - is the intention still to continue to support zlib-sync?

silent hedge
#

we hate it yepge

scarlet tangle
#

Is there a specific reason as to why the actual discord.js lib is the only one not written in typescript? Seems like it's overdue considering everything else has already hopped on that train

keen bobcat
#

Because if was written in js, newer projects were specifically written in TS. Rewriting the mainlib to TS is not simple or quick, and it hasn't been a priority

steel haven
#

That and the fact that mainlib is fully typed, so the benefit of it being typescript would only be for the maintainers of the library, no benefit for the users of it

scarlet tangle
# steel haven That and the fact that mainlib is fully typed, so the benefit of it being typesc...

There would still be benefits in that, no? You wouldn't have to work with typedefs/jsdoc comments, and frankly Typescript is superior when you look at it from any standpoint.

Also, it really wouldn't be just the maintainers that benefit from it. There are people who maintain custom forks of djs, and most of them have typescript codebases. Why not give the "power users" something less to worry about?

scarlet tangle
steel haven
scarlet tangle
haughty sorrel
steel haven
# scarlet tangle Fair point I guess. I don't know. To me it seems kind of odd to keep your main l...

A 1:1 port would literally benefit nobody while being a lot of work for those who do it. All the other packages you see that are already typescript are actually part of the typescript rewrite. They are all pieces of the puzzle, what you ask for is already happening. It's just not something that happens over night with a project at this scale (and contributors doing this in their free time instead of being employed to do so)

fierce lantern
#

speaking of rewrites, considering requiring esm modules is a thing now is it planned to eventually move to esm

#

dual publishing is nice but its essentially double the package size

steel haven
#

Did you even look at what djs publishes?

#

Because there is no dual

velvet jasper
#

The size that shows on npm shouldn’t matter. In cases where size matters code should be tree shaken anyways by a bundler.

#

some packages on npm will ship their whole src/ folder

steel haven
#

It just works with both esm and commonjs, so what you ask for has no advantage for anyone. But only the disadvantage of not working with cjs anymore (or then needing dual publish)

fierce lantern
fierce lantern
#

i'm not suggesting djs moves to esm now, requireing esm modules isn't stable yet after all, but i've heard they want to remove the experimental tag quite soon

steel haven
# fierce lantern i'm talking about the packages that aren't mainlib

I see, you referencing the "rewrites" made that not clear at all. There won't be any need to rewrite the other packages, it would simply be a change of settings of the tooling. And would be an option once the minimum node version we require is one where require(esm) is stable

fierce lantern
#

alright

split crystal
uncut kelp
#

We don't count them

split crystal
uncut kelp
#

Or not

#

Thank you for pointing that out

split crystal
#

@uncut kelp if possible, please ping me with a dev release because we use this in prod and rely on the validation messages

uncut kelp
split crystal
#

thank you

uncut kelp
#

<:

uncut kelp
fierce lantern
# steel haven I see, you referencing the "rewrites" made that not clear at all. There won't b...

it looks like it already supports a node version that has unflagged require(esm) 👀. it was unflagged in 22.12.0 (and stopped emitting a experimental warning in 22.13.0) and every package from the monorepo happens to require node >=22.12.0. should i open an issue, or is it better to wait until they stabilize require(esm) (which i've heard they want to do for october's node 25 release). require(esm) is currently in a release candidate status

azure tree
#

Hi guys, was wondering if there is an option in dev branch to get gradient colors from roles?

steel haven
azure tree
#

ohhhhhhhhhh

#

😢

dull mulchBOT
old glen
native bronze
#

how to use legacy content in comp v2?

image.png
dawn phoenix
#

put it outside the container as a text display - this is not related to developing the library or in-progress PRs

native bronze
steel haven
stiff kernel
#

Is there a version of the npm package which includes the enhanced role styles PR?

(I know it's on main but hopefully that's still relevant here)

uncut kelp
#

If you know it's on main, what's the question here? O_o

twilit bobcat
#

if you're asking whether there's a v14 version, no

stiff kernel
twilit bobcat
#

there's only latest (v14 branch), which is latest stable v14 and dev (main branch) which is going to be v15 eventually and has breaking changes/maybe bugs

stiff kernel
#

Okay so @dev is main branch

twilit bobcat
#

prs are usually merged to main and then backported to v14

#

yes

#

but again, if you're currently using v14 then it's going to have breaking changes in your code

stiff kernel
twilit bobcat
#

imo only use it if you want to stay on the edge™, not just for one feature

stiff kernel
twilit bobcat
#

waiting duckshrug

stiff kernel
#

seems like color is still being returned by the discord api, and not colors

uncut kelp
#

Can you elaborate on where color is being returned and not colors?

stiff kernel
#

based on their docs you'd think it return

image.png
stiff kernel
uncut kelp
#

What is your discord.js version?

stiff kernel
#

lemme get the specific

uncut kelp
#

That's a tag – not a version

stiff kernel
#

"^15.0.0-dev.1752538515-5a611be8d",

#

wouldve been installed between these two commits

image.png
uncut kelp
#

I see it on there

image.png
#

My guess is you're not actually using that version

stiff kernel
#

hmm yeah

#

oh well its also in docker maybe thats it

uncut kelp
#

I would say try a clean install (nuke node_modules) and try again I guess but haha

#

Quick question, how do you get your role there? Is that via an interaction?

#

And uh, do you have any other discord.js stuff installed or discord-api-types? If so, you shouldn't

stiff kernel
stiff kernel
uncut kelp
stiff kernel
uncut kelp
#

My other thought is that you have a dependency that uses a non-dev version of discord.js and it's not figuring out which one to use

#

But yeah either way it looks like some kind of issue in the setup here rather than discord.js

stiff kernel
#

I think so yeah

stiff kernel
# 
"dependencies": {
    "@prisma/client": "^6.11.1",
    "discord.js": "^15.0.0-dev.1752538515-5a611be8d",
    "dotenv": "^17.2.0"
  },
  "devDependencies": {
    "@types/node": "^24.0.13",
    "prisma": "^6.11.1",
    "tsx": "^4.20.3",
    "typescript": "^5.8.3"
  }
uncut kelp
#

Oh okay, maybe not then. Yeah I have no idea, that looks like it should work to me. Maybe your node_modules or your lockfile is outdated... try deleting them and reinstalling

stiff kernel
#

after making a fresh container, guessing it worked

image.png
uncut kelp
#

That's good. NewsChannel is quite an old change (was renamed to AnnouncementChannel)

stiff kernel
#

ah thanks i was looking for what it turned into

#

and perfect it works

#

just needed a fresh restart likely due to the dependencies in package-lock as you said

tall verge
#

Does anyone know how to use @discordjs/structures?

knotty plover
#

Its not even finished

#

They're basically just classes. What is it you want to try using it for?

unkempt vault
#

not exactly a question related directly to what djs does, but more of how the repository does it.

I was checking the published npm packages for various djs packages. How do the dist files have single index.js,mjs,etc files with ALL the code from that repo in one file? what are you using to do that? is it esbuild? do you have a link to the config files for this setup in the djs repo handy so I can have a look at it? (i'm trying to publish packages myself.)

silent hedge
unkempt vault
#

Thank u. I’ll check it out dogeHaHa

tall verge
#

Then what would that package be used for in this specific case?

tall verge
#

I see that certain projects are already using it as an alternative to Tsup.

silent hedge
#

i dunno? meguFace why fix something that aint broke

#

so long as tsup is maintained and meets our demands we'll never move

silent hedge
#

they can be a valuable starting place for building an abstraction, but its a lot of work to fully implement on top and its full of opinionated choices

stuck raptor
#

Does the fetchInvite function not return the number of members on the server?

uncut kelp
#

Only if you instruct it to

scarlet tangle
#

is there any doc for builders v2?

#

noticed that SlashCommandBuilder has renamed to ChatInputCommandBuilder and its methods also has updated but couldnt find any migration guide

scarlet tangle
#

and why does <EmbedBuilder>.setDescription(null).toJSON() throw an error even though embed's description is optional

silent hedge
#

because it's optional. not nullable

#

setDescription doesn't even take null in terms of types

#

use clearDescription() instead

scarlet tangle
# silent hedge use clearDescription() instead

thats kinda strange as the below code worked before the release of builders v2:

const { EmbedBuilder } = require('discord.js');
const embed = new EmbedBuilder()
  .setTitle('Hello')
  .setDescription(null);
channel.send({ embeds: [embed] });
silent hedge
#

yes, now it doesn't

#

that is by design

scarlet tangle
#

has the logic or design changed then?

silent hedge
#

yes, this is why it's a major bump

#

null is not a real value the API accepted, it was handled as a case by the lib to "clear" the value, but this was deeply inconsistent with fields that did accept null but also supported clearing

#

now clearing is always an explicit method and a lot of places that previously accepted null do not anymore

scarlet tangle
#

I see.. thank you for the assistance

steel haven
stuck raptor
uncut kelp
#

Well, that response isn't particularly helpful

#

What did you try? What version? Code sample? Are you actually instructing it to?

stuck raptor
#

What kind of instructions should I give?

#

15.0.0-dev.1753876893-c3dc58169

stuck raptor
silent hedge
#

please refer to the documentation

uncut kelp
#

Your code sample is not even correct JavaScript. Provide what you are actually doing

tiny dock
#

Hello everyone, I was wondering if there was any documentation on the development version? 🤔

uncut kelp
#

Choose main in the version selector to see it on the website

tiny dock
twilit bobcat
#

it isn't finished so there isn't one yet

#

there's a pr that was keeping track of some of the changes in the guide repo

steel haven
tiny dock
#

Thanks for your replies, I'll look at the commits 🙏

patent zephyr
#

They have documentation for 15.0.0-dev.1754006526-8f5ac55d8 (the latest dev version).

#

?

twilit bobcat
patent zephyr
patent zephyr
twilit bobcat
#

sorry, I don't understand what you mean

patent zephyr
#

How do I know what has changed, what has been added, and what has been removed?

twilit bobcat
#

you don't yet, documentation documents the current state, not changes

#

there are other ways though, read the whole conversation I linked to you

lapis cove
#

will djs switch to BigInt for Snowflake IDs?

steel haven
lapis cove
#

Oh wait I forgot about json requests also require string :P

knotty plover
#

To add to the above, there's no benefit to them being BigInts really because they arent used for calculations. Number isn't a particularly useful format for Snowflakes

#

I dont know what "speed" you're referring to there

robust badge
#

Will we see major changes on discord.js or we will keep going with v14.x?
For now, everything seems fine so far, I would like to know if there’s going to be breaking changes

uncut kelp
#

There are major changes coming yes

robust badge
# uncut kelp There are major changes coming yes
  • Is there an ETA?
  • I have checked docs but all I see are main and v14. I am not sure main means development as branch on website so yeah. Is there a website/wiki that we can follow up the changes?
dawn phoenix
#

the commit messages are the changelog

robust badge
#

Then release… alright, thanks.

uncut kelp
#

People rename their default branches to whatever, but that's not the case all the time if that's what you were asking

#

Select main in the website to see documentation is what you need to do yeah

dawn phoenix
#

the main github branch releases as discord.js@dev, yes, if that's what you mean

#

which can also get breaking changes very frequently, especially when it gets closer to a major release. so we recommend pinning your version to a commit and only updating after reviewing commits you will apply with that update
(granted most devs will not realy have a benefit from using dev in the first place)

unkempt vault
#

what styles djs docs? the docs website, not the guide. I'd appreciate a link to the repo for it :)

forest elm
unkempt vault
#

thanku

#

and to generate the docs? is it the docgen package?

forest elm
#

no, that's a legacy thing that im not even sure why its still around

forest elm
uncut kelp
forest elm
#

and why is that still around

uncut kelp
unkempt vault
#

i'll check out api-extractor thanku

steel haven
unkempt vault
#

ooooo

rain grail
#

i am using the dev branch and i cannot figure out why the SuppressNotifications flag appears to not work? am i doing something wrong? im gettin yelled at

or does it just show the channel red indicator + highlight without sending any desktop/mobile notification?

    i.reply({
      content: `<@${user.id}> linked to the role <@&${role.id}>`,
      flags: [MessageFlags.SuppressNotifications],
    });
shell lynx
rain grail
#

ok that's what i thought, so false alarm then, thanks

uncut kelp
#

If by "gettin yelled at" you mean "I am still mentioned", you wanted allowedMentions, not that flag

rain grail
#

oh... indeed, thanks 😅

uncut kelp
signal abyss
#

It isn't possible to test the select modals with discord.js is it?

dawn phoenix
#

select menus in modals are not yet publicly available

#

they're currently being tested by library and large bot developers before a public release in ab. 2 weeks

signal abyss
#

I know, I meant for testing
sorry if this is a stupid question 😅

#

I just thought maybe I can install the branch

dawn phoenix
#

no, it's API gated and only available in a test server owned by discord that's not open to the public

#

oh, you're in the test kek

signal abyss
#

Uh, I just asked advaith for the invite and he gave it to me

dawn phoenix
signal abyss
#

from my understanding it has to be built first?

#

like pnpm run build

dawn phoenix
#

alternatively you can use the raw payload as documented with Client#rest

signal abyss
#

I think it's not possible because discord.js crashes while processing the request?
Unless the is a way to tell it to ignore modal submit interactions

#

or is it like a whole different package?

uncut kelp
#

There's only a pull request for @discordjs/builders and discord-api-types right now

#

It's not really ready for testing unless you use them

#

There's nothing handled yet for discord.js (the package itself)

dawn phoenix
#

i'd recommend waiting for a public release
if you want to test it now to play around with it, you can use a separate @discordjs/rest REST instance to send raw payloads and see what it looks like

signal abyss
#

Alright, thank you, sorry for bothering you

dawn phoenix
#

your production bot won't be able to use it anywhere but that server anyways, so a small test app will likely fit that exploratory phase much better

signal abyss
#

👍🏻

knotty bison
#

just asking a curious question, can each section contain it's own thumbnail?

twilit bobcat
#

yes

#

and please keep this only for the dev djs version

knotty bison
twilit bobcat
#

I mentioned it since it's more of an api question

#

not djs specific

knotty bison
#

hmm, well... i'm trying to add the thumbnails, but it's not working, djs is ignoring it

twilit bobcat
#

show your code

knotty bison
# 
const buildPromotionsContainer = (content: string, promotions: any[]): MessageCreateOptions => {
  const container = new ContainerBuilder();
  container.addTextDisplayComponents(text => text.setContent(content))

  for (const promo of promotions) {
    const sectionBuilder = new SectionBuilder()

    const description = `Disponível até <t:${DateTime.fromISO(promo.end, {
      zone: "America/Sao_Paulo"
    }).toSeconds()}:F>\n${promo.link}`;

    // Add game title
    sectionBuilder.addTextDisplayComponents(
      new TextDisplayBuilder().setContent(`# 🎮 **${promo.title}**`),
      new TextDisplayBuilder().setContent(description)
    );

    if (promo.img) {
      sectionBuilder.setThumbnailAccessory(
        new ThumbnailBuilder().setURL(promo.img)
      );
    }

    // Add link button
    sectionBuilder.setLinkButtonAccessory(
      new LinkButtonBuilder()
        .setLabel("🌐 Abrir no Navegador")
        .setURL(promo.link)
    );

    container.addSectionComponents(sectionBuilder)
  }

  console.log(JSON.stringify(container))
  return {
    components: [container],
    flags: 1 << 15
  };
};```
knotty plover
#

You cant have both a thumbnail and a button

#

you get one accessory, so the button is replacing it

knotty bison
#

ohh

#

I didn't know about that, thx!

twilit bobcat
#

also I'd strongly recommend against using any

#

that goes against the entire purpose of using ts

#

and you can use enums instead of raw numbers

plain roverBOT
ruby sparrow
karmic spire
#

Please update this lib (discord.js) soon to receive select strings inside the modal

icy dew
dull mulchBOT
knotty plover
karmic spire
#

will there be more types of selects? type of channels, roles, users

knotty plover
#

In phase 2

karmic spire
#

and when can we use it? because now the select inside the modal does not respond

frigid reef
#

just wait till it will get announced

karmic spire
twilit bobcat
#

there's no eta as always

#

also this channel is for the dev (main, v15) version