#archive-library-discussion

1 messages · Page 20 of 1

vernal adder
#

It's not released yet, but yes, we will support it.

solemn oyster
#

Even if you could do that, many other drawbacks still stand.

In reality, we'll most likely get rid of partials in favour of near-stateless data, and this will make those getters suffer even more.

tender field
heady sable
#

Suggestion: explicitly require setTimeout/setInterval/setImmediate from node:timers wherever .unref() is used
Reason: browsers dont understand unref, so using djs13 in something like, electron renderer prcess, throws error

ornate topaz
#

D.js should not be used in render process

heady sable
ornate topaz
#

Cause it's not rendering anything?

heady sable
#

Well, I need it in the renderer process

#

setting up IPC for everything is a lot of work

ornate topaz
#

Then just get the data from the main process

heady sable
#

there are a shit ton of restrictions on what can and cant be sent-
you need to .toJSON everything before sending
that messes up with a lot of properties-

ornate topaz
#

Then don't send entire d.js structures but only the data you need

heady sable
#

I need entire djs structures-

ornate topaz
#

Do you?

heady sable
#

Mhm

haughty flame
#

probably use REST instead ?

ornate topaz
#

What do you do

heady sable
ornate topaz
#

...and hiw exactly does that require full structures instead of just data?

haughty flame
#

or just make an api of the bot and transfer data from that api ?

heady sable
ornate topaz
#

That's a roundabout way of achieving same thing, moon

#

You see

#

D.js should not be used in renderer, because as you have noticed, it's different environment

heady sable
haughty flame
#

there was actually djs webpacks, not anymore

ornate topaz
#

If you absolutely decline the proper use, feel free to make your own fork of d.js

#

And probably expect more stuff to not work in the renderer process

heady sable
heady sable
ornate topaz
#

"everything"

heady sable
ornate topaz
#

I gave you the reason why it most likely won't

haughty flame
heady sable
#

Alright then, I'll publish it as a separate package and use it for my project 👀

heady sable
ornate topaz
#

Yiu don't have to ping me with every message

heady sable
#

but as you said, I'll make my own fork and work on it 👀

heady sable
ornate topaz
#

Then don't reply either, i am capable of understanding that you were talking to me

heady sable
#

kk

dawn merlin
wild flax
#

It doesn't matter regardless

#

Using d.js in the render process is unsupported and youll likely encounter other issues

#

Set up proper IPC

heady sable
heady sable
tender surge
#

Was going through some of my todo's and found

// TODO: remove once native check is implemented
function isGuildTextChannel(
  channel: TextBasedChannels
): channel is TextChannel {
  return channel.type === "GUILD_TEXT"
}
```Was there any plan to add a native check? I'd like to follow that issue but I couldn't find it
loud jayBOT
visual hornet
#

i believe this is what you're referring to?

tender surge
#

Thanks! I didn't think of checking for the word typeguard

visual hornet
#

There was also a convo about it in this channel, but search is down
You could probably search for "isStrictText" when it comes back up, i remember that was mentioned, that probably hasn't been used for much of anything else

opaque vessel
outer raven
#

That discussion also seems to suggest that /pull/num works for issues, so maybe use that everywhere instead?

wild flax
#

Idk yet that seems like a bug

#

And not a conscious decision?

vernal atlas
#

!777 oops, accidentally typed this and just noticed lmfao

fiery herald
#

he just didn't update it on GitHub?

unknown.png unknown.png
frozen patrol
#

What is the best handler for a discord.js bot? Like which many js bots use? Glob/builders?

real jetty
#

this is moreso a question for #archive-offtopic as this channel if for conversations about the librairy itself

outer raven
#

Is there any preference for the use of toString() over ${var} on the library?

copper laurel
#

I would think toString() when being called on classes that have that method, ${} if actually string-building is fine

outer raven
#

it seems like doing ${var} is faster though, and toString is actually only used in a handful of places

copper laurel
#

By that I mean return this.thing.toString() is probably preferable to return ${this.thing}

outer raven
#

This is the test I ran btw

unknown.png
solemn oyster
#

That looks like a monstrously flawed benchmark.

Try a class with that, there are some optimisations going on in there, because both have the exact same semantics.

outer raven
#

oh yeah with a class they're both equally fast

#

well nvm that I guess

real jetty
#

Some servers have access to the timeout on Discord. Is there a draft PR to use it with bots?

loud jayBOT
tender field
#

this?

real jetty
# tender field this?

No, this PR adds the property to know if the user is timeout or not but not all the functions to timeout a user from the bots :/

#

My bad

#

I didn't see the end of the modification, thanks 👍

tender field
#

np

raven juniper
#

The feature is still not released from discord and is not available through the API yet

real jetty
visual hornet
#

the bot doesn't know the guild has access to the feature. as far as the bot is concerned, it may as well not exist.

real jetty
#

If the only problem is whether the server has access to the functionality or not, then it is not a problem ( Servers are not selected randomly ) 😉 The only thing I needed was to know if the bot could use this feature (thanks to the PR) if it was in a server having access to this feature. Now that I have the PR I could test

visual hornet
#

The feature is still not released from discord and is not available through the API yet

dawn merlin
#

@opaque vessel for your PR I was requesting the interface for GuildMemberEditData be updated for the new field

opaque vessel
#

Isn't this right?

export interface GuildMemberEditData {
  nick?: string | null;
  roles?: Collection<Snowflake, Role> | readonly RoleResolvable[];
  mute?: boolean;
  deaf?: boolean;
  channel?: GuildVoiceChannelResolvable | null;
  communicationDisabledUntil?: Date | number | null;
}
dawn merlin
#

oh I missed the diff in ur PR, ignore me

opaque vessel
#

Haha, no worries! (:

real jetty
# visual hornet > The feature is still not released from discord and is not available through th...

It's released... As I said some servers have access to this feature (screenshot made by me few seconds ago), when I say something I have a reliable source behind it (I hate to assert something without proof) 😅
Never-mind, this channel isn't made to discuss if a feature is released or not. If other people are interested in the answer to my question here is an answer with tests :
Bots can use this feature in servers that have access to it (I'll let you discover how to know if they have access but it's pretty easy)

unknown.png
unique axle
#

not merged on DAPI docs -> not released, for all we care

#

this is still in a pre-release phase and could potentially still change in usage and API documentation, hence it won't be merged yet, until the API is set, confirmed to be set and merged on API docs.

hasty bluff
real jetty
#

Yes, I understand 🙂 but that didn't answer my original question which was whether there was a PR going on and whether a bot in a guild with access to this feature could use it

real jetty
hasty bluff
#

Yes there is

#

They are waiting for discord docs to be updated first

verbal solar
#

Is v12 gonna be deleted any time? Or is it gonna stay?

wild flax
#

it will just stop working eventually

#

¯_(ツ)_/¯

fiery herald
wild flax
#

I don't quite get what you are asking

#

like yeah I didn't make a release, because nothing noteworthy happened there anyway

fiery herald
#

you've replied me even if you didn't get the question ._.

oak quail
#

all servers with the PARTNERED feature have access

#

as well as certain others

unique axle
#

this does not need to be discussed any further here

#

as long as it isn't merged on DAPI docs it's not going into the library

sullen idol
#

Add the allow and deny objects to the permissions property for creating a role 😪

unique axle
#

that's unfortunately not how role permissions work.
guild level permissions can only be granted or not granted
the only input for role creation that makes sense is the granted ones, which is exactly what it takes at the moment

fiery herald
#

which version of Discord API is discord.js v12 using?

unique axle
fiery herald
wild flax
#

v7 technically doesn't exist

#

so whenever v6 goes down, so does v7

outer raven
#

why is it that in almost all structures with timestamps the *Timestamp property is obtained by doing new Date(...).getTime() and the *At getter is just new Date(...)? Wouldn't it be more efficient to make *At a property and *Timestamp a getter that returns <At>.getTime()?

vernal atlas
#

probably yeah

#

although actually

#

*Timestamp (and or *At, its been a while so i forgot) is sometimes assigned in initial construction

vivid field
#

it would probably be more efficient to use Date.parse(x) instead of new Date(x).getTime() unless that gets optimized

visual hornet
#

isn't the *Timestamp sent from discord though? why would that need to be a getter?

vivid field
#

discord sends an iso8601 date string, not a timestamp number, so discord.js converts it

visual hornet
#

ah, i misread rodry's message as them both being getters, my bad

#

wouldn't *At be modifyable if it wasn't a getter though?

outer raven
visual hornet
#

*At properties are Dates, and you could modify them with the setX methods

#

wait, none of the objects are frozen, are they
so every thing else is modifyable?

outer raven
visual hornet
#

i mean if all the other properties of the object are modifyable then the date being modifyable doesn't really matter

#

i was referring to if *At was the property and *Timestamp was the getter

outer raven
#

the only way you can modify them is through the edit method ?

visual hornet
#

reassignment...?
like modifying the object directly

outer raven
#

but... why?

visual hornet
#

Just to the end user, if the object gets modified directly such that the data is incorrect
I was thinking about that, but i realized that all the other properties are modifyable as well so it doesn't really matter

outer raven
vivid field
#

I'm already working on it dogeHaHa

#

don't see a reason not to change it

outer raven
solemn oyster
#

So they take a lot of space in memory

outer raven
#

ahh that makes sense

#

well then ig the only thing to do here is use Date.parse instead which is a great idea and I didn't even know about the method

vivid field
#

same tbh, I looked it up just because of this discussion

haughty flame
#

#djs-help-v14 message

I've been testing with some events for my bot, and it seems like whenever I kick it from a server, it tends to trigger both guildDelete and guildMemberRemove events instead of just the guildDelete event

is this supposed to happened ?

proven blaze
#

I believe so? Its not a bug so to speak as a member is being removed

visual hornet
#

if it does happen it would be an api bug/issue/behavior, not a djs one
like the phantom guildDelete

proven blaze
#

fair enough

outer raven
#

@vivid field I did some tests and using the ternary operator seems to be faster than using && for when dates are possibly null, should probably change that too in your PR maybe?

vivid field
#

are you sure? it's almost identical for me, even a tiny bit slower

#

oh after a few runs it turns out to be faster, but only by 0.8% max

#

not sure if that's worth removing simplification of code

wild flax
#

It’s not

outer raven
quiet viper
#

There are lot of other things to make the libary faster such as converting the caching system...

dawn merlin
outer raven
#

hm?

quiet viper
# dawn merlin ?

Saving whole nested Structures vs saving raw data.
I was intending to solve bigger "problems" rather then complaining on small things.

outer raven
#

what are u on about

dawn merlin
#

^

quiet viper
# dawn merlin ^

Just forget it lol.
I am talking about other factors, which are more relevant for a "faster speed".

dawn merlin
#

I mean we have an issue ticket for storing raw data it’s planned to be added

quiet viper
#

tomorrow I will tell more, currently falling asleep. I made a list...

dawn merlin
visual hornet
#

About the workflow of releasing versions, is my understanding correct that each version will be released when the relevant milestone is completed?
ie 13.4 when the 13.4 milestone gets completed, etc

copper laurel
#

In theory

#

But the milestones themselves are subject to change too

real jetty
#

I mean if there was a critical security patch then I hope the maintainers will release the next version pretty quickly, without the milestone necessarily being met

copper laurel
#

Has that ever happened....?

real jetty
#

I don't think so, but it definitely could in the future

copper laurel
#

I just don't see how it's relevant to the question about our milestones. Of course we can make other releases as needed

dawn merlin
copper laurel
#

Security patches are not roadmapped milestones in the first place

#

Same for discovered bugs and regressions, yeah

solemn oyster
#

We'll just make another milestone and move everything that was planned and didn't merge to it, @real jetty

real jetty
#

So if there was a security patch release, only the patch would be released, and not the other bug fixes, is that correct?

solemn oyster
#

We do that a lot, in fact we did that recently for 13.3 > 13.4

#

We'd just release whatever is on main

#

And the version depends on the semver from the commits, if we just landed bugfixes, dep updates, or docs changes, we'd just release a new patch

undone ravine
#

This is definitely not the correct place to ask this question

hallow ocean
woeful rain
# 
public reply: (options: string | MessagePayload | InteractionReplyOptions) => Promise<Message | APIMessage | void>;

// reply func
const reply = async (options) => {
  if (!await interaction.fetchReply()) return await interaction.reply(options);
  else return await interaction.editReply(options);
},

I fixed it by adding the GuildCacheMessage<CacheType> type which according to discord.js typings returns editReply. Isn't there a bug in the docs then?
https://github.com/discordjs/discord.js/blob/main/src/structures/interfaces/InteractionResponses.js#L130

Types: https://github.com/discordjs/discord.js/blob/a0fe0acbf1c0134d88d9fc519506cf33116288cc/typings/index.d.ts#L1580 | https://github.com/discordjs/discord.js/blob/a0fe0acbf1c0134d88d9fc519506cf33116288cc/typings/index.d.ts#L348

unknown.png
opaque vessel
#

I fixed it by adding the GuildCacheMessage<CacheType> type
I'm a bit confused by this, don't those links you provide already include them?

woeful rain
#

I have

// ˇ Without error
public reply: (options: string | MessagePayload | InteractionReplyOptions) => Promise<Message | APIMessage | GuildCacheMessage<CacheType> | void>;
// ˇ With error
public reply: (options: string | MessagePayload | InteractionReplyOptions) => Promise<Message | APIMessage | void>;

public static createWithInteraction(interaction: CommandInteraction | ContextMenuInteraction, command: Command): CommandContext {
  return new this(interaction.client as GClient, {
    ...(super.createBaseWithInteraction(interaction)),
    interaction: interaction,
    command: command,
    commandName: command.name,
    arguments: new ArgumentResolver(interaction.options.data),
    reply: async (options) => {
        if (!await interaction.fetchReply()) return await interaction.reply(options);
        else return await interaction.editReply(options);
    },
    editReply: interaction.editReply.bind(interaction),
    deleteReply: interaction.deleteReply.bind(interaction),
    followUp: interaction.followUp.bind(interaction),
    deferReply: interaction.deferReply.bind(interaction),
  });
}

When I had everything but GuildCacheMessage<CacheType> in the type, it threw the error shown in the screenshot. So do you guys happen to have some error in the typings there? Because in the documentation there is Promise<Message|APIMessage>

File: https://sourceb.in/R4iFs4v1xH
Full code: https://github.com/Garlic-Team/GCommands/tree/next

opaque vessel
#

It's... never a good idea to supply such a huge block of code or your entire codebase to reproduce an issue, you should create a bare minimum reproduction sample

woeful rain
#

I don't really know how to fully explain it. I simply have a reply function, and there I have used the reply and editReply functions. When reply isn't there yet, it gives reply, when it is, it already edits. I have typings that the function returns Promise<Message | APIMessage void>;. But, when I just have this in the typings, it throws me an error which is shown in the screenshot. When I clear editReply in the function, it works. However, when I want the editReply to stay there, I look more and find that I have to add GuildCacheMessage<CacheType> there as well. However, the docs don't state that editReply can return a GuildCacheMessage<CacheType> type.

unknown.png
opaque vessel
#

The issue isn't that type... that makes no sense, GuildCacheMessage<CacheType> is Message | APIMessage. Looking at your error, it states that APIMessage imported from @discordjs/builders isn't compatible with that of APIMessage from discord-api-types/v9. So... there you go. This just means there's a change in the exported type, and you're comparing cross-versions that are not compatible

#

If you scroll down in the error you screenshotted, that is the reason why

woeful rain
#

I import from discord-api-types/v9

opaque vessel
#

|:

#

Maybe @discordjs/builders's discord-api-types dependency should be bumped @tacit crypt

tacit crypt
#

Feel free to PR it if it wasn't already

analog oyster
#

You guys should setup dependabot or renovate or whatever else to bump the dependencies automatically

dawn merlin
analog oyster
#

Pretty sure you can configure the bots to not update the dependencies if it's a major version difference

outer raven
golden mortar
#

With my pr switching d.js to undici, it seems it's getting held back by whatwg streams + blob being experimental and I don't really understand why this would be a deciding factor? I just wanted to ask here to see the reason

tacit crypt
#

@remote wasp Any thoughts on the 3 other comments on the events PR? eyess

sullen idol
#

Why does guild.bans.create() possibly return a snowflake? Cant you try to resolve the guildMember and if that fails, return the GuildBan which has the user object?

copper garden
sullen idol
copper garden
#

Also the GuildBan can’t exist until it’s created

#

That would require another api call

sullen idol
#

I gotchu

outer raven
copper garden
#

Would ppl actually use it tho?

outer raven
#

I think so because returning a Snowflake is the least useful information you can get from creating a ban

copper garden
#

Could make it a partial user

outer raven
#

I think the GuildBan would be the best way to go tbh

ornate topaz
#

But isn't Snowflake the absolutely only thing you need to fetch a user? if you really need to have the user object that for some reason wasn't given, you can use it to fetch. + This way you have clear way of controlling if you want to cache the user upon fetching, where the ban option would have to have its own sub-option to allow that control

#

And while true, you don't have a full GuildBan from that ban in that case, what exactly (apart from User) do you not have at the moment of creating the ban, given how it's your bot that created the ban?

solemn oyster
#

To be honest, if you banned a user, you should at very least have the User or the GuildMember beforehand, unless you're banning on sight without any validation whatsoever. And since you'd normally do, d.js returning User, GuildMember, or their partials, is completely useless

tacit crypt
#

From what I see tho, managers return the least amount of data needed, while structures return more, and I personally like that

sullen idol
opaque vessel
#

If you pass a snowflake that isn't a user id then yes... nothing to build there, just invalid

sullen idol
#

Well yeah I was thinking about catching the rejected and have users enter an ID. If its invalid then itll send a message letting them know, with the resolved tho I can see who got banned instead of having to fetch. Also, my ban command bans users who arent even in contact with the bot so instead of me having to fetch the api, this would be helpful

outer raven
sullen idol
#

^

sullen idol
#

Btw when is server banner being added? Like GuildMember#bannerURL n stuff

ornate topaz
outer raven
outer raven
sullen idol
ornate topaz
#

wdym Thonk
we don't release stuff that is not documented in the api docs

sullen idol
#

Ik but ian ask for tht, I asked when, thnx for the info tho all cool

analog oyster
#

When it gets out on the api and documented on the docs

sullen idol
#

"When do u go to the store?" "When I go to the store"

#

Ofc it needs to get documented

ornate topaz
#

we are unable to give you a date you could use in your calendar, simply because it is not in our control. the answer you got is as close as possible

sullen idol
#

Thanks

solemn oyster
#

Without any validation whatsoever?

ornate topaz
#

doesn't API handle passing invalid id anyway?

#

you save a request trying to fetch the id just to ban it and never use it again

zenith oracle
# solemn oyster Without any validation whatsoever?

I mean, many bots have something like a ban command where you can supply the ID of the user (for example if you want to ban a user who is not in the server) and returning something like "Username was banned" is common. So, we can assert on our side that the ID is actually a valid snowflake but we don't want to fetch it from the API to see if it's a real user ID because we don't want to do 2 API calls and we don't need to... When we ban the user the API checks it for us and returns an error in case.

solemn oyster
#

But in order to display username (as well as create a moderation log, which also many bots do), you need to fetch the user glare

opaque vessel
#

Would people be opposed to adding a fetchUser option in BanOptions, which fetches the user object after successfully banning? Akin to how interaction replies have a fetchReply option since the response is nothing

#

Could always assure the return type is User then, even if uncached

solemn oyster
#

I knew it'd come up to this, it's basically a big can of worms

#

We just allowed the fetchReply thing to go thru because it was very highly requested and a lot of people wanted it, but in turn, it has also increased the development cost of that method, and brought this very proposal Jira is proposing

tacit crypt
#

I still don't get why we should fetch/create a user object if you pass in an id..when you can do that yourself if you want

solemn oyster
#

Hence why I'm saying we should change that to return the manager, Vlad

#

Like many other manager methods do

tacit crypt
#

Returning the manager is useless too, what will you do then?

#

We don't return the managers for delete calls for instance

zenith oracle
# solemn oyster But in order to display username (as well as create a moderation log, which also...

Yeah, fair enough, but since returning a Snowflake is totally useless (as I surely already have it if I ban a user) shouldn't djs return the cached user, or a partial one if none is cached? Because now we need to do something like this:

const id = interaction.options.getString("id", true);
await interaction.guild.ban(id);
const user = await interaction.users.fetch(id);
interaction.reply(`${user.username} was banned`);
tacit crypt
#

You could use a user type in that example

#

Since that'll resolve for ids too

opaque vessel
#

Other methods return the manager? :thinking:

tacit crypt
solemn oyster
#

Discord doesn't return anything? We shouldn't try to make up something. What if Discord decides to return something that isn't compatible with what we're returning? We'd need a semver-major to change that. While that wouldn't happen if we return void, because changing something to a promise that resolves to a void (always ignored), to one that resolves to non-void (may be ignored), is technically not breaking.

opaque vessel
solemn oyster
#

For all we know, Discord could change that endpoint to return a ban object, or a partial guildmember, and not a user

tacit crypt
#

or could do nothing

solemn oyster
#

The fact the possibility exists, and we're making up stuff that Discord doesn't give us, is troublesome

#

And we're also trying to move away from requiring cache so much, plus, any extra operation in the managers will slowdown the operation of the structures that call them and do return this;

opaque vessel
#

I'd say return void and call it a day tbh lol.

These days people use slash commands... if you pass an id, it'll resolve to the user object and congratulations, you have that already. Nothing else you need to do (and you even get the guild member object if they're in the guild)

solemn oyster
#

The people who don't fetch the member/user before banning are people who aren't aware anyone could pass an ID to it and literally ban *anyone*, even those with higher roles than them

quiet viper
#

Its completely senseless providing data back, when Discord does not give them.

"Just because the Users are to lazy" is not a valid reason.

• The User has to be fetched before banning the Person, in order to validate if the User exists and if the Permissions are below the executor user

solemn oyster
#

The user doesn't have to be fetched before banning, guild.bans.add doesn't rely on cache, but it has to be fetched for permissions

#

This is exactly why Discord returns nothing, it's beyond useless. If you're banning somebody, you should always have the user or the guildmember beforehand, because you're supposed to check permissions to not get a 401 back, or banning users regardless of the hierarchy or any protection (e.g. mod role protection) the bot should have

quiet viper
solemn oyster
#

It uses resolveId, which returns the ID as-is when you pass a string

tacit crypt
#

Meister meant that on the bot dev side the user must be fetched

#

Not on the lib side

quiet viper
#

^

tacit crypt
#

Anyways the points were made preeetty clear from what I see

  • you ought to fetch the member/user yourself to check for permissions and hierarchy
  • we shouldn't return data for things you can fetch yourself because of lazyness
#

Of course, the last point has the asterisk of interactions fetchReply or w/e (but I'd argue that one is fine due to the nature of the interactions api, and is a common enough requirement that makes sense to add)

outer raven
#

So do we agree to return void on manager methods where discord returns nothing? So that we can remove the mess of return types that is guild.bans.add?

sullen idol
tacit crypt
#

So do it

#

Fetch the member, if it doesn't return a member you can freely ban, else check hierarchy, ban if possible

sullen idol
#

Why not have it return a User or GuildBan instead? That way we just have to resolve and boom we good

solemn oyster
#

Have you even read any of the messages?

tacit crypt
#

We've already discussed why we shouldn't fetch after the ban, with the clearest reasoning being that Discord doesn't return anything right now, and should they choose to, it'll require a breaking change and a major version

sullen idol
#

Alr

tacit crypt
#

Alongside that:

  1. Calling fetch will check caches first, which, if you don't sweep said caches, means super fast returns
  2. An API call to fetch a single member or user is super fast too, and isn't as ratelimited as chunking members, you don't need the GUILD_MEMBERS intent, etc, and gets cached once fetched
sullen idol
#

I gotchu

sullen idol
#

How is GuildMember#User nullable?

raven juniper
#

partial probably

sullen idol
#

Gotchu

copper laurel
#

Theres been a lot of talk here - if theres an issue with the ban method returning inconsistent values then arguably you should reduce it to the maximum one that can be guaranteed

#

Which would be for it to always, only return a Snowflake

#

Then the developer is free to use that to fetch any additional data they wish - either a User object, or a GuildBan object

outer raven
copper laurel
#

Can snowflake not be guaranteed?

outer raven
#

it can, but why would it return a snowflake if discord doesn't

#

that's the least useful piece of information

#

and it's something you certainly already have

#

returning void is just so much more consistent

solemn oyster
outer raven
shell vector
#

With the V13 update, did the library change anything with the privileged intents? On v12 I was having issues trying to get my bot to show the actual full user count of my bot. It would only show the cached user count. However, after getting privileged intents, I am able to start my bot and it shows immediately my actual full user count (80K) users. But when I switch to my V13 branch, I’m having once again the same issue. It is only showing the cached users as my bot user count. So did these privileged intents get changed? And if so is there a way I can fix this? I want my bot to start and immediately show the actual # of users my bot has, not the cached user count. I have the same exact intents and partials etc. the client is setup exactly the same. So with the v13 library I’m not sure what changed this. Can anyone input on this?

unique axle
#

your premise is already wrong.
if you rely on client#users or guild#members (accumulated) you have never received the "actual" user count. to do so you'd need to fetch all members of all guilds at ready (which we heavily recommend not doing because of the massive memory overhead, time and availability reliance). a good estimate (though it includes duplicates) is to accumulate guild#memberCount instead, over all guilds in client.guilds.cache.

with version 13 discord.js does not send all possible events in the identify payload anymore, meaning you will have to specify each intent you want to receive in the client options (https://discordjs.guide/additional-info/changes-in-v13.html#intents)

shell vector
#

So this is the same code I am using on v12 and v13, but on v13 like I said it won’t show the 80K users

const intents = [Intents.FLAGS.GUILDS, Intents.FLAGS.GUILD_BANS, Intents.FLAGS.GUILD_EMOJIS_AND_STICKERS, Intents.FLAGS.GUILD_INVITES,
Intents.FLAGS.GUILD_MEMBERS, Intents.FLAGS.GUILD_MESSAGES, Intents.FLAGS.GUILD_MESSAGE_REACTIONS, Intents.FLAGS.GUILD_VOICE_STATES];
const client = new Client({ intents: intents, partials: ['GUILD_MEMBER', 'REACTION', 'CHANNEL', 'MESSAGE'] });```
unique axle
#

you don't receive all guild members on large guilds on ready, never did, no matter the intents

shell vector
#

I had to apply for user presence and once I got that approved I was able to show the full user count. Before this it was only showing the cached users

unique axle
#

that's a misconception. even with the intent you rely on cache and user data that hasn't arrived yet will not be included

#

it's just that you get more data due to GUILD_MEMBER_ADD and GUILD_MEMBER_UPDATE events with the GUILD_MEMBERS intent
as for presences: yes, that is necessary to get the initial members (again, not all members) on ready with the initial guild data

shell vector
#

I’m just confused because I was using those exact intents and I was only able to show cached users. I applied for user presence intents and now I am able to show full user count on startup. So that intent i was approved of fixed my issue. If I disable the user presence intent, I go back to only being able to see cached users

unique axle
#

it is not the full user count, as much as you want it to be, you are always only seeing cached users, because that is simply how the library works
we cache data as it arrives through various websocket events or requests you make

#

intents just mean that you get more events, more data, faster cache fill (or data to cache at all, depending on the type of data)

shell vector
#

Well then my question is, how with the user presence intent I can see 80K users on startup but without it I can only see 20 users then it grows slowly? Those 80k users weren’t cached.

unique axle
#

Those 80k users weren’t cached.
well, yes, they were.
the presence intent controls if you get guild member data for guilds on start-up (on large guilds: online/idle/dnd only)
the user data for any members we receive through that are cached.

shell vector
#

Okay, so if they were cached then how come with v13 they aren’t being cached? I’m sorry if I’m being ignorant. But I spent so long fixing this for v12 and then updated to v13 and now that fix isn’t working.

copper garden
#

Try limiting intents on v12 and you’ll produce the same results

shell vector
#

So do I need to add more intents to have this outcome I want?

shell vector
copper garden
#

The only reason you get more users with the presence intent is bc the presence update event comes with the user object, which d.js caches

shell vector
#

So with the difference from v12-v13 why is this not caching all members?

copper garden
#

v13 is forced to use intents

#

v12 is using an older api version, where it got added as an optional property for backwards compatibility

shell vector
#

Okay, so I just won’t be able to show all users on startup with v13? I’ll have to just update via cache?

copper garden
#

Presence intent will only cache non-offline users

#

I believe you still need the guild members intent to initially receive all members if the guild is not large

shell vector
#

I do have the guild members intent

copper garden
#

50 members is the large threshold by default

#

You can increase it up to 250 members

shell vector
#

Okay, well thank you both @copper garden @unique axle I appreciate all the clarification and advice. Thank you, I do appreciate it. I’ll start trying to figure out how I can change it. I appreciate your time ❤️

visual hornet
#

you could just sum up Guild#memberCount with only the GUILDS and GUILD_MEMBERS intents as mentioned before.

shell vector
#

Yeah that’s not recommended though as souji suggested and I agree, that’s not the best way of going about it

unique axle
#

wait, other way around, i recommend that

#

it includes duplicates but it's much less straining on your caches

visual hornet
#

the fetch on ready was the one not recommended?

shell vector
#

Oh, I got that mixed up my b

visual hornet
#

there's just not really a great way to go about it while also getting perfect results though, those 3 solutions each only tick one of those boxes

shell vector
#

Yeah unfortunately. Well thank you all again. I’ll try the suggestions you have given me. Thanks again!

shell vector
copper garden
#

Need the nullish coalescing in case of unavailable guilds

shell vector
#

Okay

visual hornet
shell vector
#

got it working! Thank you all client.guilds.cache.map(guild => guild.memberCount).reduce((a, b) => b + a, 0)

visual hornet
#

that iterates on the cache twice btw

shell vector
#

you have a more convenient way you can provide?

visual hornet
shell vector
sullen idol
#

Am I on the old docs? Lol i jus click the redirect

visual hornet
#

That's how the collection docs are now, and also #archive-site-discussion for developing the docs btw, this channel is more for the functionality of the lib

sullen idol
#

Ohh alr

visual hornet
#

seems like your djs and/or djs/collection versions are outdated then

#

and can you just stick to a single channel

sullen idol
#

Gotchu, imma see

sullen idol
dawn merlin
real jetty
#

I'm on v13.4-dev and its just not there peko

sullen idol
visual hornet
#

oh huh i do recall using it though in old code. well that's odd, my bad then

outer raven
#

Reverse was merged 20 minutes after the last release so u gotta wait for a new one

#

Hopefully when the other pr is merged

visual hornet
#

that is somewhat comical

real jetty
#

Why is this enforcing the void return type for callbacks?

unknown.png
#

Does djs even do anything with the callback after its called?

dawn merlin
real jetty
#

Guess that's fair, makes everyones code a bit messier though.

outer raven
opaque vessel
sullen idol
#

Theres an error wit djs returning a collection of members when fetching only 1 btw

copper laurel
#

how so

#

Please be more descriptive

errant brook
#

hello if i wanna add a new type of option to command option types what all do i need to check

sullen idol
#

I just check more into it, if the value passed is undefined it returns the whole collection instead of a rejected promise, dont think thts supposed to happen righ?

copper laurel
#

Of course it is

#

members.fetch() and members.fetch(undefined) are identical in Javascript

#

You couldnt have the first work if the second didnt

sullen idol
#

Thats interesting, it didn't do that before so I thought it was an error

#

the more yk I guess

copper laurel
#

I promise you it always did haha

sullen idol
#

Yh I probably was trippin or sumn lol

copper laurel
#

If you were to pass something that isnt undefined, but also isnt a valid ID, that would error

sullen idol
#

Alright, Lemme try

#

Is there anyway I can get undefined returned? To make the code shorter

copper laurel
#

Wasnt meant to be a reply to you sorry

sullen idol
#

I gotchu

errant brook
copper laurel
#

Depends how different it is to other option type

errant brook
copper laurel
#

No, I mean the discord.js typings

errant brook
#

where do i find those?

copper laurel
#

Though possibly api-types too if we pull those from there

errant brook
#

i added it in api-types

copper laurel
errant brook
#

all i need to do now is add in djs tuypings and constants like you said

#

thanks!

errant brook
outer raven
#

That’s not what they meant…

errant brook
#

???

worn bobcat
#

Hehe

errant brook
#

lol it's my pr i know what im making the pr for XD

errant brook
outer raven
#

I can but keep in mind I'm not a maintainer

errant brook
errant brook
#

why did MessageAttachment#_patch not patch filename ?

#

i know that but why was it not in MessageAttachment#_patch tho

#

like all other properties are being patched in MessageAttachment#_patch then why not name

visual hornet
#

Because it's seperated out from the data object as the second parameter in the constructor, as megatank mentioned
it's for convenience when making your own attachments to send, why wrap it in an object when you have no other data to provide

copper laurel
#

why would the name of an attachment ever change

solemn oyster
#

I doubt we patch nested objects, if only, we re-create them

errant brook
zenith oracle
errant brook
#

ill do that

tame marlin
#

does it trigger userUpdate event when changing profile banner?

opaque vessel
tame marlin
#

and does GuildMemberUpdate get triggered when changing in-guild profile avatar/about me/banner

opaque vessel
#

No. This is more of a question you would ask in discord.js's support channels, not here (or test yourself)

real jetty
dawn merlin
real jetty
#

I think it should be moved to Util though because its a useful utility if you're already using the ApplicationCommandData type for creating your slashie objects. I personally use it for deploying without having to be logged in to discord.

dawn merlin
#

But it’s transformed internally anyways

real jetty
dawn merlin
#

Yeah that’s my point lol, it’s run for you anyways when you pass an object in

tropic hull
#

Why use webhooks instead of embed for answer at slash commands?
We can't use custom emote in webhooks

copper laurel
#

I dont quite know what you're asking here but
A) Webhooks can have embeds in them, they are not mutually exclusive
B) Webhooks can also have custom emotes in them, as long as the @everyone role has USE_EXTERNAL_EMOJI permissions
C) Discord designed slash command responses as webhooks, not us

tropic hull
#

It's not practical to have to give permission to everyone

opaque vessel
#

Webhooks aren't in your guild - has nothing to do with your bot

opaque vessel
tropic hull
tropic hull
visual hornet
#

Your bot answers through the webhook which isn't exactly attached to any member so you can't give it perms directly, it just takes the default (ie @everyone) perms

tropic hull
#

Interesting

copper laurel
#

Your bot user doesn't need to be in the guild at all for slash commands to be provided, hence, response are webhooks

outer raven
#

Why are we allowed to modify a guild's features on Guild#edit? Does the endpoint actually support adding/removing any features?

dawn merlin
outer raven
#

yeah I know it's there but does it actually work?

opaque vessel
#

For ones that obviously won't, yes... you can for example remove the community aspect of a server

outer raven
#

oh I thought bots couldn't do that

#

alright

#

and is there a way to obtain all available features? It doesn't seem to be exported in constants

#

@opaque vessel could you say something about the currently unresolved reviews on the timeouts pr pls cookieCat

opaque vessel
#

Well for the first one, looks like two members of discord.js decided against for renaming the helper method, so that's a resolution

export type TimeoutDateResolvable is pretty harmless, but no core maintainer has said anything yet

I have nothing to say about "Why does this method not support TimeoutDateResolvable?", ckohen already said my reasonings too

So... I have nothing to say to any of them

outer raven
#

Well for the first one, looks like two members of discord.js decided against for renaming the helper method, so that's a resolution
I genuinely don't understand why, and people only reacted, no one actually said anything. I replied to your comment and I genuinely think it makes sense, so I'd like to understand your POV on why you think that name makes sense here but not on other situations

I have nothing to say about "Why does this method not support TimeoutDateResolvable?", ckohen already said my reasonings too
I mean it doesn't hurt to support it does it

junior pumice
#

is there already a PR for the timeout feature?

quiet viper
junior pumice
#

is there or not

tired valve
#

Keep the channel on topic

junior pumice
#

wdym its channel topic

#

PRs are literally a part of developing discord.js

quiet viper
#

#archive-sharding message
Is this a bug of the action handler? Seems to cause a crash of the Process. Should they create a issue?

opaque vessel
#

They just need to update to stable

sullen idol
#

Can you add like an errors option to MessageComponentCollectorOptions, so the end event will only trigger by time or whatever we specified?

copper laurel
#

Should already be there, not sure why its not documented

#

Should be in the base CollectorOptions

#

Oh nvm, I know why

#

Errors are only relevant to the promisified versions

#

Collectors dont have error events, they just end with a reason

sullen idol
#

Right right, thats why we use .catch() ain it?

copper laurel
#

Well not on a collector no

sullen idol
#

Hmm, I mean like .awaitMessages and .awaitReactions, are the errors not rejected promises?

copper laurel
#

Well that doesnt use MessageComponentCollectorOptions, it uses AwaitMessageComponentOptions

#

And that already only errors on time

sullen idol
#

So, we won't be able to have it end by time only for MessageComponentCollectors?

copper laurel
#

It only ever collects one component, or runs out of time

#

Thats the only conditions it can end

ornate topaz
#

You don't need error to be able to specify time

sullen idol
#

I gotchu

copper laurel
#

component - resolved
time - rejected

sullen idol
copper laurel
#

It was designed that way (single collection only) because Discord requires you to immediately respond to the interaction

chrome plover
#

Not sure if this is the right place, but any idea if it will be possible to place multiple users on timeout at once? like for example:

await guilds.disableCommunicationsFor(Array[Targets], {options}):

Options being duration in ms and a reason for audit log.

sullen idol
copper laurel
#

Unlike reactions/messages where you can apply extra error conditions like ending on a max number etc

sullen idol
#

..

copper laurel
#

The API isnt designed that way, much like you cant multi kick or ban

chrome plover
#

true, thanks for the quick reply.

copper laurel
sullen idol
untold sedge
#

hope your pr for timeout get merged to the library 🙂

dawn merlin
outer raven
#

@dawn merlin a few days ago you PR'd this change and now I'm not getting types on my created channels when not specifying a type (defaults to text) and I'm getting the store channel deprecation, could you look into it?

unknown.png
#

it always falls back to the last overload

dawn merlin
#

There’s a type test for this and it seems to be passing

outer raven
#

oh and intellisense only gives me GUILD_STORE as a possible type

unknown.png
dawn merlin
outer raven
#

I am yeah

#

and that was not accounted for in the tests

#

if I specify the type it does work, but I get no intellisense

loud jayBOT
#

pr_open #7132 in discordjs/discord.js by suneettipirneni opened <t:1640041398:R> (review required)
types(CategoryChannel): createChannel should default to a text channel
📥 npm i suneettipirneni/discord.js#types/default-category-channel-type

outer raven
#

@dawn merlin shouldn't there be more?

unknown.png
dawn merlin
#

no, these are the valid options:

export type CategoryChannelTypes = ExcludeEnum<
  typeof ChannelTypes,
  | 'DM'
  | 'GROUP_DM'
  | 'UNKNOWN'
  | 'GUILD_PUBLIC_THREAD'
  | 'GUILD_NEWS_THREAD'
  | 'GUILD_PRIVATE_THREAD'
  | 'GUILD_CATEGORY'
>;
outer raven
#

right you can't make threads

#

alright then that works like a charm, thanks!

#

I mean, shouldn't GUILD_STORE be suggested?

dawn merlin
#

It's hard bc it's an overload that comes after it, it still works, but it's deprecated

outer raven
#

oh right yeah and if you remove the exclude it doesn't get marked as deprecated

#

alright then I guess that doesn't hurt anyway

dawn merlin
#

@outer raven what do you want me to test?

outer raven
#

the checks pass, but just to make sure they dont break in the future

dawn merlin
#

done

solemn oyster
#

@woeful rain there's no disableCommunicationUntil method

woeful rain
#

my bad

spice junco
#

is this in djs v13.4.0 beta yet?

unknown.png
#

ping me if u got answer

copper laurel
#

there is no beta

#

Its not merged into -dev yet

outer raven
spice junco
copper laurel
#

not yet

spice junco
#

ah

#

will it be in djs 13.4.0?

#

the official release

copper laurel
#

yeah it should be

spice junco
#

alright

#

thanks man

lofty birch
#

will the timeouts PR override the user's permissions getter to remove the permissions that it's taken from them (send messages, connect to vc's etc.) or does that have to be implemented on our side

opaque vessel
#

Not sure if that's something that should be done. They technically still have those permissions, they're just timed out. Maybe you should check if they're timed out before doing whatever it is you need to do with them in that state

lofty birch
#

it feels more like a convenience thing - I'm happy to do it on my own getter but I think it could be nice to have within the lib as during the timeout, they can't in fact do those things

outer raven
#

and maybe you could also add a moderatable getter just like kickable and bannable?

#

also VoiceChannel#joinable should take timeouts into account too

#

I can leave a review on the PR with all the info if u need

opaque vessel
#

Their permission bitfield remains the same from the API if someone is timed out. I'm not really sure discord.js should modify that?

#

A quick look at other libraries reveals they don't factor this in either

opaque vessel
#

Ah wait you mean the helpers not the actual modifying the bitfield. Read the wrong initially... guess I could do those

outer raven
opaque vessel
#

So BaseVoiceChannel#joinable I added the check in
GuildChannel#manageable too - this accounts for the .deletable property also
VoiceChannel#speakable has the check too (stage channels don't have one)
Message#deletable has the check too

It seems there is no helper check for reacting on a message or sending a message, so I did nothing there

You can still edit a message and pin a message when timed out, so did not alter those properties (no idea why)

Did I miss anything?

lofty birch
opaque vessel
#

I read wrong, disregard that

lofty birch
#

Ah yeah, no I definitely didn't mean actually modifying the bitfield, that would be bad

visual hornet
#

oh wait i brainfarted on that last part those checks wouldn't be necessary if bots couldn't be timed out mb
so yeah sendable

lofty birch
opaque vessel
#

Well I've tested it and found it to be the case - have you?

lofty birch
#

Huh, you're correct. must've confused losing channel perms with that

visual hornet
#

same for channel and message deletions, both of your own and others' messages

opaque vessel
opaque vessel
visual hornet
#

im testing with admin perms and highest role

opaque vessel
#

Timeouts have no effect on administrators

visual hornet
#

can't send messages (nor reply) with it so i don't think that's fully true
although as an admin i still can do the other 2 actions listed here

unknown.png
opaque vessel
#

You can't send messages when timed out with administrator?

visual hornet
#

not through the ui, no

opaque vessel
#

This is strictly the bot API, doesn't matter what the UI does

visual hornet
#

guess that's a negligible inconsistency then

#

if the api allows sending, anyways. (and it does)

lofty birch
opaque vessel
#

Huh what's the bug? Not being able to send messages when timed out as admin?

lofty birch
#

yes

#

you can do so, the client just doesn't show it

rough roost
#

it seems you also can't pin messages when timed out

opaque vessel
opaque vessel
opaque vessel
opaque vessel
rough roost
#

all the permissions it has. it can't publish/pin messages when timed out

create_instant_invite, kick_members, ban_members, manage_channels, manage_guild, add_reactions, view_audit_log, read_messages, send_messages, send_tts_messages, manage_messages, embed_links, attach_files, read_message_history, external_emojis, change_nickname, manage_nicknames, manage_roles, manage_webhooks, manage_emojis, use_slash_commands, request_to_speak, manage_threads, create_public_threads, create_private_threads, external_stickers, send_messages_in_threads
opaque vessel
#

Ty just verified that

#

Why are there so many helpers

visual hornet
# 
permissions.has(Permissions.FLAGS.ADMINISTRATOR, false)

is the second param you put here really necessary? or is it just more of a standard internally?
not really significant but just noticed and was curious

#

GuildMember#bannable : no changes needed, accessible in API
GuildMember#kickable : no changes needed, accessible in API
GuildMember#managable : no changes needed, accessible in API
Invite#deletable : no changes needed, accessible in API
Role#editable : no changes needed, accessible in API
ThreadChannel#editable : 50001 Missing Access
ThreadChannel#joinable : no changes needed, accessible in API
ThreadChannel#managable : 50001 Missing Access
ThreadChannel#sendable : 50001 Missing Access
ThreadChannel#unarchivable: 160005 Thread is locked
ThreadMember#managable : 50001 Missing Access

opaque vessel
#

There's more? Oml

visual hornet
#

yeah im just going through the typings file lol. pretty handy.

opaque vessel
#

I'm kind of scared that some of the above things (verified myself btw) are still usable... like, what if they're oversights and will be patched in some future API deploy and this library has them hardcoded

visual hornet
#

i'd.... hope that would fall into a semver patch.

opaque vessel
#

It probably wouldn't be a priority to release either

#

Hai hai @solemn oyster, do you think the library should account for the client user being timed out for the permission helper checks above?

#

Or would you say that's something for the developer to account for?

visual hornet
opaque vessel
#

I just did that cause it's done everywhere else internally... not like that extra parameter does anything though in that specific case

visual hornet
solemn oyster
solemn oyster
opaque vessel
#

I suppose, alright, ty (:

visual hornet
#

checkAdmin false -> BitField#has(ADMIN)
checkAdmin true -> (true && BitField#has(ADMIN)) || BitField#has(ADMIN)

ruby terrace
#

the admin permission can be set in a channel overwrite, it has absolutely no effect on actual permissions, so you must ignore it, server wide admin is already split out

outer raven
visual hornet
wild flax
#

@opaque vessel you still haven't checked your "add necessary checks to permission helpers" is this done already though?

opaque vessel
#

Thread channels has some left, like sendable

wild flax
#

alright, thats the last thing thatd be blocking the merge then

#

so whenever you get to it, or need some help

opaque vessel
#

Should now all be done (:

wild flax
#

@outer raven i dont get what you are asking in your latest comment

#

it already returns true if you have admin, regardless if you were muted

#

🤔

outer raven
#

are you talking about speakable?

wild flax
#

yeah i mean

#

some people might not check joinable

#

¯_(ツ)_/¯

#

you could be dragged into it you know

#

so youd only have to check speakable

outer raven
#

But given that you joined the channel, you're allowed to speak in it if you're timed out, but you're not allowed to join any channel to begin with unless you're admin

outer raven
wild flax
#

¯_(ツ)_/¯

#

I don't think it matters much

outer raven
#

I just think that helper shouldn't be touched, along with most others

#

the only ones that should be changed are joinable and sendable, everything else is not affected by timeouts

wild flax
#

imo itd be kinda dumb to have joinable return false

#

but speakable true

#

lol

outer raven
#

but that's how Discord designed it

#

you can't join, but if for some reason you do, you're allowed to speak

wild flax
#

like theres a lot of edge cases for admin anyway

outer raven
#

I think that's the only one isn't it?

wild flax
#

but semantically itd be confusing

outer raven
#

being able to speak when timed out could be (and imo should be) considered a bug on Discord's end, but if they allow it for now, we should too and only change later if they do change this

wild flax
#

i dont think so

outer raven
#

well then it's your call

#

what about manageable though?

wild flax
#

im not a huge fan of implementing discord shenanigans

outer raven
#

and deletable on messages

wild flax
#

id rather have some coherent system

#

while you technically (even though you cant join) speak

#

it doesn't make sense since you cant join

#

so I can safely say you can't speak for the helper method

#

it just makes things less confusing

outer raven
#

I mean yeah I don't see a scenario where someone would time a bot out if it has admin

#

but for big bots that might be something they gotta take into account

wild flax
#

or an admin another admin

#

¯_(ツ)_/¯

outer raven
wild flax
#

what about it

outer raven
#

why was that changed in the timeouts pr?

wild flax
#

why do you ask me

outer raven
#

idk you seemed to agree with it

wild flax
#

id rather want to know why you dont

#

instead of playing this back and forth game here lmao

outer raven
#

actually I got confused because you can edit a single property on a thread (default auto archive duration) but not anything else on any other channel so I guess that's another bug, ignore

#

however you can always join threads regardless of timeouts and perms

wild flax
#

cc @opaque vessel

#

this is something we can talk about

#

:D

outer raven
#

yeah sorry for my confusion earlier, joinable seems to be the only helper that doesn't need to be touched

#

Also could you please add a moderatable check that works similarly to kickable and bannable but with the new perm? cookieCat

visual hornet
#

did you test with the api on this

outer raven
visual hornet
#

ah my bad i skimmed over and missed the last few messages

opaque vessel
opaque vessel
outer raven
outer raven
opaque vessel
#

Yeah there's a big difference between the client and the API side. The client won't let you do it though (visibly it will, but the request also errors out)

outer raven
opaque vessel
#

How would this getter work? Just check if the guild member is timed out? Lil' confused on that one

outer raven
opaque vessel
#

Ah right a check to see if you can timeout a user

#

Interestingly it looks like a bot can still timeout a user if they're currently timed out (lol)

outer raven
opaque vessel
#

Nah

#

People may alter their user cache to remove all users (it can be set to 0)

#

That includes the client user

outer raven
#

is that supported?

opaque vessel
#

Apparently yeah

outer raven
#

then that ?? false should be applied elsewhere too

opaque vessel
#

It's also in other permission getters:

const permissions = this.permissionsFor(this.client.user);
if (!permissions) return false

'Cause the only way that is defined is if you're cached in the guild

opaque vessel
#

Anyway, that should all be done now [:

outer raven
opaque vessel
#

[:

outer raven
#

0 so it returns false?

#

actually probably -1

slate nacelle
#

It's already throwing an error

outer raven
#

oh bruh

#

blind facepalm

#

I don't need to touch these examples do I

unknown.png
opaque vessel
#

I say examples are fine

opaque vessel
outer raven
#

I'm gonna apply that same logic to these

solemn oyster
#

If you modify the getters to throw a defined error, you'll make it semver-major, since the error will change

outer raven
#

I've done this same exact thing before and it was semver patch

solemn oyster
#

You're changing it from a TypeError to an Error, so yeah...

#

You're changing the behaviour in there

outer raven
#

how can I make this patch then

solemn oyster
#

Also please re-use guild.me, no need to run the getter twice

#

You can't, gotta wait for v14

#

It'll come out soon, so don't stress much on it

outer raven
outer raven
solemn oyster
#

Over the 50% of the open PRs are semver-major

zenith oracle
solemn oyster
#

7 of which were created within a month of 13.0.0's release

#

We shouldn't leave them sitting for any longer, we're aware of that, and we're working towards a v14 quite soon

outer raven
#

oh alright 👀

outer raven
opaque vessel
#

Anyway, that should finally be it for the timeouts pull request [:

outer raven
#

and events seems to be done too so v13.4 soon™️? 👀

solemn oyster
#

Yup, hopefully before the Christmas break

outer raven
#

aye

solemn oyster
#

So you don't have to use base types (which aren't really strict typed)

outer raven
#

didn't I just do that?

outer raven
#

@dawn merlin when I reviewed your PR this was returning a TextChannel promise like it should, why'd you change that?

unknown.png
#

that PR didn't fix anything it seems

#

oh wait this was because of the rebase

#

im gonna try to fix it

#

this method should never return that type union anyway

dawn merlin
#

I think this was from the make channel types stricter PR

#

CC @solemn oyster

outer raven
#

I don't fully understand that PR but shouldn't TextChannel stay as TextChannel?

dawn merlin
#

Not necessarily, dm and group DM’s don’t count

outer raven
#

what?

solemn oyster
outer raven
#

gonna PR

dawn merlin
outer raven
#

that's not what I said

#

a TextChannel isn't a dm channel

heavy heron
#

Hi there any idea when the new timeout feature will come to djs?

copper laurel
#

when its ready

#

soon ™️

outer raven
heavy heron
heavy heron
outer raven
copper laurel
outer raven
heavy heron
#

But how do i access discord.js@dev?

#

What is it even?

outer raven
#

you install it with npm

heavy heron
#

Oh ok

outer raven
#

npm i discord.js@dev

copper laurel
#

I probably shouldn't meme in here, never mind lol

dawn merlin
#

Rodry taking everything literally smh

outer raven
#

i genuinely didn't get it

copper laurel
#

Sorry haha

outer raven
#

Any reason why these structures are required here instead of at the top of the file?

unknown.png
#

BaseMessageComponent#create btw but this is done elsewhere too

tacit crypt
#

Circular imports

outer raven
#

hm?

tacit crypt
#

Every component imports BaseMessageComponent. BaseMessageComponent imports every component

#

The import is thereby circular

copper laurel
#

By having the import scoped to the case block, it avoids the circular import since MessageButton imports BaseMessageComponent

tacit crypt
#

Of course, the other solution would be moving them at the bottom, but it's not the prettiest view

outer raven
#

oh so if they were at the top it would error?

copper laurel
#

Yeah you get weird constructor errors at runtime iirc

outer raven
#

ah alright

opal sapphire
outer raven
#

Would it make sense to add the MessageEmbed getters from discord.js (like hexColor and createdAt) to builders?

visual hornet
#

couldn't you just import djs to reexport its MessageEmbed at that point

loud jayBOT
outer raven
#

@visual hornet ^^

visual hornet
#

oh. well then yeah i guess
although im a bit confused on the naming of createdAt tbh, but other than that i guess yeah if you want to keep those properties

outer raven
#

yeah it seems like it's just the timestamp and not when the embed was created
and I don't think knowing when the embed was created is useful, but maybe a unix timestamp instead of an ISO string would so that could be made into a getter

real jetty
#

is the new timeout feature already added to the library?

outer raven
real jetty
#

ty man

pine python
#

this might be a naive question but why do the require statements for node libraries use require("node:events") rather than require("events")? My jest unit tests freak out because it can't resolve the require statements in the discord.js source code that start with node:xxxx,

rough roost
wild flax
#

Jest has support for this

pine python
#

yeah i just found the release where they added support for it as you sent that, thanks for the help guys

outer raven
tacit crypt
#

The only difference will be that if your nickname is everyone, it will ping. Nothing else. Roles will use their names, users will use their usernames, members will use display names

outer raven
#

What?

#

Doesn’t clean content output the mentions with their ID?

tacit crypt
#

...no?

#

cleanContent getter calls Util.cleanContent

#

It has always called that method in fact

outer raven
#

Hmm ok

outer raven
#

Will there be no more 13.x versions?

solemn oyster
outer raven
#

When attachment options and modals come out?

solemn oyster
#

Not sure, we don't even have an internal ETA for it (while we do for v14 👀)

visual hornet
#

If v14 happens to work out before 13.5, those changes would all just get squeezed into 14.1, right?
Or would you want to wait to put them in with v14

tacit crypt
#

v14 won't happen that soon where you'd end up with the 13.5 turn into 14.1, so don't stress about that

outer raven
#

How soon do you expect it to be though? (If you wanna share that ofc)

visual hornet
tacit crypt
outer raven
#

Exactly 1 semver major release away 👌🏻

tacit crypt
worn bobcat
#

setAuthor string params are deprecated. Why not do the same on setFooter?

outer raven
visual hornet
#

setFooter doesn't have 2 optional parameters like setAuthor does
with the author, you could have a url without the icon, but to show either you'd just need text, so both of them are seperately optional
with the footer, you only have the optional icon, which is dependent on the text being there

opaque vessel
solemn oyster
pulsar phoenix
#

They should add a timeout() function for Guild#Member

unique axle
solemn oyster
trim vigil
#

Why do you get a warning in console when not providing a token upon client.login()

#

It defaults to DISCORD_TOKEN so why does it error?

opaque vessel
#

I don't do that and don't get a warning, ever. You're doing something wrong

#

Ask in the support channels

outer raven
trim vigil
#

It is and it successfully logs in, it just throws a warning

outer raven
#

what warning?

#

@trim vigil

trim vigil
#

I don't think it works anymore because I just get an error now that says a token must be provided

outer raven
trim vigil
#

I had it setup properly

#

It got removed from the docs so it probably got removed

visual hornet
#

you have to have the env var set before instantiating the client, perhaps that couldve been it?

vernal rose
solemn oyster
#

Doesn't matter, those test files are quite useless and should be replaced with unit tests

vernal rose
#

Oh ic

outer raven
#

Is there a type guard that turns all interaction reply and editReply return types into Message classes but doesn't require them to be sent in a guild?

dawn merlin
outer raven
dawn merlin
outer raven
dawn merlin
#

@burnt cradle I just realized that typescript allows this combination for autocomplete getIntegerOption().setAutocomplete(true).setName('test').addChoices([]);

#

I don't know if there's a way around that

burnt cradle
#

Yeah I don't think this propagates the restrictions it previously had on it, so setName returns a full option to ts

#

But that's why runtime checks exist anyway so ¯_(ツ)_/¯

dawn merlin
#

I’m questioning the benefits of the static typing here then, if it can easily be worked around I don’t think it’s worth the complexity

#

CC @tacit crypt

tacit crypt
#

What

#

Do you have to explicitly set the return type to this?

dawn merlin
tacit crypt
#

Wack...

ruby terrace
dawn merlin
#

Yeah but it’s unintentional from our types. And it kinda invalidates the way we set types up in builders

loud blade
#

why was, setAuthor() was depracated, while addField() remained the same.
Shoudn't be addField take EmbedFieldData as well for consistency?

opaque vessel
#

The method isn't deprecated, just how you use it is

#

addField() doesn't have optional values

loud blade
#

what I mean is in the arguments obviously, sorry for the misleading info. But what I meant is the values

opaque vessel
#

Actually in the next major version, addField() will take an object as a sole parameter

loud blade
#

addField() has inline as optional.
and another thing is, why addFields accept a single EmbedFieldData option, if addField can obviously accept that, where in addFields should only accept an array for consistency.
I mean they did change the setAuthor in 13.5.0, so I actually hoped the addField was also changed so people would just do a single refactor on a single semver minor release.

oak quail
#

addfield only has one optional param so making it an object isn't needed

#

making it an object is useful when there are multiple optional params

loud blade
#

though since addFields accepts an EmbedFieldData, I think it also makes sense to add addField to accept an EmbedFieldData

#

and depreciate the old parameters options, so its either a single argument, or an object with multiple params to make message embed consistent.

vernal adder
solemn oyster
#

Yeah, we'll switch without deprecation I guess, it's unlikely we'll have a 13.5.1 (or a 13.6.0 for that matter), as we're now working on 14.0.0.

strange cedar
#

What does the roadmap look like for 14.0.0?

dawn merlin
strange cedar
oak quail
#

and i dont see any previous discussion of this, or an issue or pr

ruby terrace
#

switch to builders

dawn merlin
#

Objects are easier to add onto, without creating long parameter lists. They also have “built-in” labels for the arguments.

oak quail
#

an embed field is literally just name, value, and inline

#

making it an object is just code clutter

#

people keep saying "d.js is making useless changes to break code and make it less usable", and honestly this change would just prove them right

dawn merlin
oak quail
#

it may be inconsistent but its logical, and a better ux

outer raven
#

if you're only adding 1 field why would you need to construct its object? It's just nicer to type without it, also ^^

oak quail
#

is the plan to have no methods that take more than one argument

#

functions can have multiple params for a reason

dawn merlin
#

But if the only thing a function does is take input and shove it into an object and append, the object should be provided the user

oak quail
#

by that logic you would just make the user write out a whole discord message object and simply send it to discord

#

the point of d.js is to make it easier than that

dawn merlin
#

And if you want to do anything more than send text, you have to provide an object anyways

vernal rose
golden mortar
ruby terrace
#

that's why the change is happening. For addField, I don't necessarily disasgree with whats been said here, but that PR needs to be made to /builders in order to keep the current function signature

#

if maintainers agree with it, then said PR will merge, otherwise it'll be closed

solemn oyster
# oak quail people keep saying "d.js is making useless changes to break code and make it les...

Hey, if we didn't do that, we wouldn't have a job to do.

Out of jokes, the addField change affects a huge deal to a lot of people, even me (who has been rejecting the change to objects for quite some time, this is going to take hours to fix in my bot T_T), but something undeniable is that making it take objects alongside the rest of methods promotes a level of consistency that allows users to intuitively use them correctly.

Having to remember which methods take multiple parameters, and which methods take an object is a bother and a mixed API, we're simply consolidating them into a single for everything, although in a quite unintended way.

wild flax
#

I also would like to go a bit further into this and ask the question how something taking multiple Params makes things “easier”

#

How is something taking multiple params compared to an object easier? By what definition?

#

What is “easy”?

#

How is it measured

oak quail
#

in this case i think the version which makes you type less is easier

#

since there isnt really other difference

#

also everyone is used to the current system already; I don't think making it more similar to the other methods really provides a benefit here

#

especially with modern editors which will tell you exactly what you need to put

vivid field
#

it would make the method totally unnecessary too because addFields already accepts a single object through rest parameters

oak quail
oak quail
#

(tbh it would probably be better to remove addFields, does anyone use it)

hasty bluff
#

I'm not sure if this is the right channel to ask.
guild#premiumProgressBarEnabled has the same value for both oldGuild and newGuild, why's that? shouldn't it return false in oldGuild and true in newGuild in case i enabled it?
(using latest djs version 13.5)

visual hornet
hasty bluff
#

it seems like a bug that's why i asked here

visual hornet
#

support channels would be more active for possible debugging to just kinda make sure it's actually a bug and not a mistake (not that that's bad, it happens, but having someone else check your work can help filter those out)

unique axle
hasty bluff
#

mhm alright, it was on my end sorry.

tacit crypt
# oak quail in this case i think the version which makes you type less is easier

Typing less doesn't automatically make it better. That's a gripe I have with a lot of our methods that do this annoying "list of required parameters with an optional object at the end for all optional fields". What is each option?? Yes, if you use vsc or intellij suite you'll see what it is, but not everyone uses that, and yes you can check the docs but if I have to check the docs every time to remember the order.. I'll pass. With an object, you know at a glance what each field is, is it a name, a file, a value, you name it. It brings consistency with everything else

zenith oracle
#

In my opinion, yeah, it's surely more consistent having it as an object... But, it may be misleading. Both name and value are required, while inline is optional so having it as an object with these 3 properties may be difficult to understand what field should be filled and what field may be leaved blank, while with parameters you know you must put them.
Actually, not really a big problem if it's changed to an object however... it was already done with the send() method and I think it would also be better if Discord a day decides to add a new field to that object, just thinking about all the big projects that will require a big rewrite of all those addField()

tacit crypt
#

Technically, a good find and replace can automate most of the migration to an object based interface eyess

dawn merlin
#

I kinda agree with the notion that addFields() is a useless method. Its existence is only to be a shortcut to addField(). Something that can easily be used with .forEach

quiet viper
outer raven
# tacit crypt Typing less doesn't automatically make it better. That's a gripe I have with a l...

If the problem is having to check the docs when writing these methods I think that using a single object for addField makes that even harder because, while you get suggestions when typing on modern IDEs (with the name and type of the parameter), the same doesn’t happen when that parameter is an object, you pretty much have to guess the names of the properties because not even vscode will give you intellisence unless you start typing one of the properties out. Also I’m pretty sure this has been mentioned here but if addField is going to take 1 object only then might as well remove it entirely because you’d be removing the only reason people have to use that over addFields

#

Does vscode work with capturing groups? I haven’t been able to do that

tacit crypt
#

I can experiment with that and see if I can come up with a regex

#

besides the point

opaque vessel
tacit crypt
outer raven
# tacit crypt 1. It was an example 2. You do get suggestions in your IDE even for object ones....

Yeah I have use Ctrl + space but that doesn’t tell you which parameters are required even, which would make life harder for people on JS. Not to mention that they may not even get types depending on how they’re importing their embed builder
How do they cover different use cases? If you change the syntax for addField it will become the exact same as addFields or setFields for that matter

tacit crypt
#

They would notttt be the same as setFields.

outer raven
#

If you use it when adding the first field it would, and syntax-wise it would be the same too

dawn merlin
dawn merlin
inland gazelle
#

Hey all, ran into an issue last night with message embeds and displaying an image. If I use an image URL from my server, discord won't show the image. But if I use the image from the example at https://discordjs.guide/popular-topics/embeds.html#embed-preview, it does. I ran across a reddit or something that said discord only allows images from certain servers??? Embed aside, I tried posting the link itself from my server and the one used in the link above, and same thing, my link will not show an image but theirs does. If I send it in a direct message, it shows just fine. I know this is less a discord js issue, but wondering if any of you have run across this??

visual hornet
#

might be better to ask this in discord devs

inland gazelle
visual hornet
#

discord devs is a different server, the invite is listed in #useful-servers

also btw this isn't actually exactly a troubleshooting channel per se (check channel topic)

inland gazelle
#

Gotcha. Thanks.

waxen dove
wild flax
#

Yeah the example is just wrong

#

the return type is correct

waxen dove
#

alright thanks

#

could i open a pr for this

visual hornet
#

if there hasn't been one already, go ahead i guess

waxen dove
#

alright

charred acorn
#

would it make sense to use rust's discord module, compile it to web assembly and use it? will that performance increase be worth it?

wild flax
#

no

lilac tulip
drowsy barn
#

I wonder how do bots communicate with websites. Trying to make a captcha system that redirects to a website any idea how I should go about it?

wild flax
#

Websockets

drowsy barn
#

Pog damn I am an idiot

#

Redis pubsub I heard is decent too

wild flax
#

Redis is server side

#

Good luck with that on a website without leaking your credentials

drowsy barn
#

yeah but what about having it run serverside for the web app and having the bot as a different node app

#

using php or something im still tryna learn web dev

outer raven
#

Would the monorepo PR be a good chance to start using tabs all across discord.js? Most if not all of the other packages already use them so since the diff is big I think that would be a good opportunity right?

ruby terrace
#

that makes retargeting all those semver majors PRs that much harder, not opposed but those PRs should be merged first and then do that if we want to IMO (merging the other PRs first may be in the plan, don't know)

golden mortar
#

i really hope prs are merged before the monorepo one so i dont have to setup everything again 😄

outer raven
ruby terrace
#

it will cause merge conflicts yes, but without changing anything else in the files git recognizes the file structure is the only thing that changed and thus a rebase will successfully complete without any user intervention (unless you touch package.json or similar)

#

that's not a minor difference

solemn oyster
outer raven
#

oh alright then, I guess there will be a better time for that one

opaque vessel
remote wasp
#

can't remove it until discord does it first

real jetty
#

Is there really a need to have two types for the same thing here?

unknown.png
#

Well, channelTypes will be the same thing at runtime

tacit crypt
real jetty
#

Why not use a second type for raw api data (probably from -types) and then use a union?

tacit crypt
#

Thats what it is!

#

I don't exactly know why your editor shows both

real jetty
#

Hmm.. very strange

forest beacon
#

Hey guys, would you use Jest to unit test TypeScript modules ? I heard it does really bad with asynchronous tasks

outer raven
vernal rose
forest beacon
#

I’m wondering if it’s worth it to work around problems from Jasmine to unit test scenarios that should be easy to test…

#

(I mean working around could be easy but to me it sure means it is not as easier as to use the things like they were built for)

solemn oyster
#

We're already using Jest for -modules, but we're not using ts-jest, it's too slow and has many issues.

#

Also, that last bit is a bit off-topic and not related to this channel's topic.

drifting knot
#

some getters (ex. Role.members) are O(n) operations which is not documented at all. should this be changed? either lib-wide or for this specific instance

unknown.png
#

adding a note like "don't do role.members.has(userId), it's way slower than member.roles.has(roleId)" or even "this is a O(n) operation" can help users understand why their code may not be performing well at scale

solemn oyster
#

Do you think users know what Big-O notation is?

#

We could add it in the docs just like Redis does, but we'd need to decide on whether we want to do that, because it'll involve a lot of maths to even process them, specially for recursive things

drifting knot
#

i wouldn't recommend adding time/space complexity to the entire library as it's a very tedious process like you said

#

i think in this specific instance it'd be good to add a note about performance

dawn merlin
#

I would just say "runs in linear time complexity"

solemn oyster
#

Yeah, and what is "linear time complexity"? How do you explain that to a user?

drifting knot
drifting knot
solemn oyster
#

Yeah, I agree. Having the Big-O notation of getters and methods is hella helpful for me

#

I don't know if it's doable at all (cc: @wild flax), but maybe we could add an "Advanced" switch just like we do for privates, to show the time complexity alongside the docs, I think that would balance keeping things clean and simple for newbie users and verbose but resourceful for advanced users

drifting knot
#

probably worth making a GH issue/discussion as an RFC for this

#

i have a few ideas on how you could document this info but don't want to clutter the channel

wild flax
#

Feel free

drifting knot
pulsar ledge
#

Is there a particular reason we don't get a guildMemberUpdate event when a timeout expires?

opaque vessel
#

That's a question for Discord

pulsar ledge
#

Alright

outer raven
quiet viper
ornate topaz
#

because it adds clutter that isn't useful for majority of users

fervent crescent
#

Hello, I want to use discord-js RPC to mute my self via a script. The example for rpc defines a clientId. What is a clientId and where do I get it?

outer raven
fervent crescent
#

I'm sorry. You are right this is the wrong channel. I thought rpc made to allow such functionality. Thank you very much.

oak quail
#

@outer raven @fervent crescent it is allowed

#

rpc isn't selfbotting

vernal rose
#

interaction.options.getMember("user", true) throws an error when the input is a user but not a member. But as there is no way to limit the input to member only (as per ik) then why getMember have the required parameter? Means what i mean is there shouldn't be any required param in getMember and it's output should be always GuildMemeber | APIInteractionDataResolvedGuildMember | null

visual hornet
#

if the user is in the guild the getMember's erroring behavior would function like getUser i guess?
if the option is optional and isn't set, required being true makes it error

vernal rose
visual hornet
#

You mean it'll return user instead?
...no, i said erroring behavior
option is required but the input was a user who isn't a member
and there's no member to return? so that makes sense
if you don't want it to error then you can just set required to false? (or omit it as that's the default)

vernal rose
visual hornet
#

...for there being no member

dawn merlin
#

@vernal rose I’m confused on what’s being asked the required parameter is only set to true if the option is required in your slash command

vernal rose
# dawn merlin <@758880890159235083> I’m confused on what’s being asked the required parameter ...

My question is related to getMember. As discord don't provide a member type in slash command so users can enter any users id in USER type means a user who isn't present in that guild. So if the option is set to required then also we can't set getMemeber's 2nd param to required because it can still be empty irrespective of the user option is set to required.

I'm not able to explain it properly as English isn't my 1st language if u didn't got it then i can show a example.

#

so what i want is that there shouldn't be a required option in getMember method and it's output should be always GuildMemeber | APIInteractionDataResolvedGuildMember | null

dawn merlin
#

hence they're members

vernal rose
#

Id*

rustic boughBOT
#

Tag suggestion for @slender idol:
• > text: single line blockquote
• >>> text: quote until the end of the message

dawn merlin
#

hmmm

#

I honestlty didn't know entering the user's direct id worked even if they weren't in the server

vernal rose
#

Yeah u can try

dawn merlin
#

I just did

#

it works

vernal rose
#

Yeah so should I make a pr to remove required from getMember?

visual hornet
#

no? it still has the use for optional arguments
and still for this use here that you've pointed out

vernal rose
#

Other methods have use case but getMember don't have

visual hornet
#

it's for typechecking

visual hornet
vernal rose
dawn merlin
#

they're no longer a guild member, and as a result it's a null response