#archive-library-discussion

1 messages · Page 13 of 1

solemn oyster
#

We do

#

In some classes we do something like```js
if (data.foo) {
this.foo = data.foo;
} else if (this.foo === null) {
this.foo = false;
}

iirc, `User#bot` is one of those cases
#

That could be refactored tojs } else { this.foo ??= false; }

copper laurel
#

I know we could use it of course

#

But theres no immediately urge to

solemn oyster
#

The recent change to support custom user agent parameters could also use it

empty viper
copper laurel
#

why

outer raven
covert flint
#

it is

outer raven
covert flint
real jetty
#

Any reason why repliedUser is not on ReplyMessageOptions and is instead super'd from BaseMessageOptions allowedMentions? Can you reply to a user without message#reply?

ornate topaz
#

doesn't current setup of it being placed in MessageMentionOptions allow it to have different default value passed via ClientOptions?

real jetty
solemn oyster
copper laurel
empty viper
copper laurel
#

Because like I said

#

Why do we need it

vagrant holly
outer raven
#

Apparently the Collection link was removed from the docs, which file should it go in?

#

gonna PR and throw it in the Client file cuz i don't see a better place for it atm

outer raven
#

Is there any reason why ClientUser#setActivity still accepts 2 parameters instead of just 1 object?

#

Since v13 already changed that for sending messages, I think it would make sense to do so here too

quiet viper
#

There should be a function for hydrating objects from broadcastEval or anywhere else to a guild object, so you can access the methods and getters

solemn oyster
quiet viper
# solemn oyster So... using v8's serder?

what are you meaning lol?
lemme elaborate:

const guildobject = {id: guildid, name: guildname...}

const guild = client.guilds.hydrate(guildobject)
guild.leave()
///Functions, which can now be accessed
```Turn a plain object in a Discordjs Structure
solemn oyster
#

v8's serder is able to serialize and deserialize complex types

strange igloo
#

Would guildobject be a Guild#toJSON or a raw Discord guild object

solemn oyster
#

Curious, we can't use it for v12's collections

unknown.png
outer raven
solemn oyster
glass cypress
#

when is v13 gonna drop

unique axle
#

when ever crawl feels like it + 1 day every time someone asks, +1 week whenever someone asks in devcorner channels

long arch
#

Should defer be changed to deferReply? I remember a conversation about that here the other day but a maintainer didn’t give an answer for it so I’m not sure if it’s a yes or a no

Conversation started from here #archive-library-discussion message

copper laurel
#

We kinda dont care

long arch
#

So like you guys wouldn’t mind if a PR is made for it to be changed to deferReply?

#

Cause like I don’t want to open a PR for it and then have it be rejected or whatever

copper laurel
#

I mean people will probably debate it, but you're welcome to make the PR

outer raven
#

Why is the Emoji CDN endpoint the only one that defaults to png instead of webp?

#

the docs don't document that

real jetty
#

I still don't get how the djs manages the requests Hmm Especially the APIRouter file

wild flax
#

A big mystery

rough glacier
#

currently <Message>.content is marked as nullable in the docs but it returns '' when no content is specified. Should it return null or be marked as a string ?

outer raven
#

Yeah the API sends '' too, should probably be updated

slate nacelle
#

That's for partial messages.

obtuse hazel
#

Then every property should be considered as nullable, excepted the id, in each structure which might be partial, which is not the case

slate nacelle
#

The docs seem to take those into account, except for cleanContent.

outer raven
#

@solemn oyster since you already approved https://github.com/discordjs/discord.js/pull/6278 lemme ask you this
We noticed on the upstream PR that Discord actually defaults the autoArchiveDuration to 24h and not the channel's setting. Should we try to set it to the channel's defaultAutoArchiveDuration when it exists?

solemn oyster
#

That's why we don't land stuff before they land in dapi-docs

outer raven
#

yeah ik

#

the fix is really easy, should I push?

solemn oyster
#

@wild flax @tacit crypt @slate nacelle wdyt?

tacit crypt
#

02shrug whatever crawl says

solemn oyster
#

I personally think we should not define the default, but let Discord default it

#

To not deviate from the behaviour from Discord

outer raven
#

but then if discord defaults to 24h it might be counter-intuitive if people are expecting to see the setting they chose

rough glacier
#

would a "MAX" option in autoArchiveDuration based on guilds boost count be too much of a runtime check?

winged dust
#

when replying to an intent with nothing (interaction.reply()), a better error would be nice. This one isn't very descriptive: UnhandledPromiseRejectionWarning: TypeError: Cannot read property 'fetchReply' of undefined

#

I spent a lot of time with this stupid mistake in my code 😅

ruby terrace
#

options is documented as required

strange igloo
#

If you really want a strict language that tells you when you're not using methods correctly, you should probably switch to TypeScript Thonk (or at least get its server running on your code)

winged dust
#

yes yes, I know, I'm just saying that in case someone doesn't give any arguments by accident, a better error would be nice

strange igloo
#

While that could be possible, validating any possible input would take a large part of the code and create useless checks at runtime

winged dust
strange igloo
#

OP's idea is equivalent to a warn, you say it's wrong but don't halt it (so basically you'd still get the thrown error later in the code)
The second one would probably be the "best" one (but with throw new Error instead, and no console.error at all) - but as I said the code related to input validation would likely take like a third of the whole code, then
The last one that wraps everything into a try/catch is terrible

copper laurel
clever summit
#

@copper laurel seems like https://github.com/discordjs/discord.js/pull/6262 broke guild text channels. From my testing _patch gets never called because immediatePatch is set to false throughout the constructor chain. calling this._patch(data) at the end of the BaseGuildTextChannel seems to work, though idk if that breaks something different

copper laurel
#

Yeah okay these never patch

#

I think I would need to add a constructor back to TextChannel which just calls super with false and then patch

#

And then patching starts its own super chain?

#

(and NewsChannel probably)

ruby terrace
#

it should _patch at the end of the BaseGuildTextChannel constructor

copper laurel
#

I guess it could there too

ruby terrace
#

at least until there's a constructor in its subclasses

copper laurel
#

Should I just put constructors back there I mean

ruby terrace
#

What would possibly go in them

copper laurel
#

this._patch(data) 😄

ruby terrace
#

lol, up to you where you put it

copper laurel
#

Nobody uses text channels anyway

copper laurel
#

@outer raven | number is a valid type for those - when you create a guild you can also create roles, set overwrites etc all at creating

#

You reference the roles by a referential index

outer raven
copper laurel
#

Yep

#

Say you create a guild, and you also tell it to create 5 channels, you can reference those 5 channels by number for overwrites, and roles etc

outer raven
#

ahhh I see

#

alright my bad, will revert

copper laurel
#

All good, its a specific niche case that rarely gets used

#

But I imagine before Guild Templates were a thing template bots probably used this sort of stuff often

outer raven
#

I don't see why a bot would own a guild tho but yeah if it's there we gotta document it lol

unique axle
#

that is largely irrelevant, it's supported api spec
(also me, hi, i use that)

outer raven
#

lol aight

strange igloo
vernal atlas
#

probably not a bad idea

tender field
wild flax
#

used to be the fastest

tender field
#

hmm weird i'm pretty sure it's the slowest

#

at least in all my cross-platform workflows, it's always the slowest

wild flax
#

it might be by now

supple current
#

what r the possible text of <MessageAttachment>.contentType

oak quail
#

it's returned by the API, djs just passes it through

supple current
#

oh ok thx ill look into it

outer raven
hasty kindle
#

Is there any chance of an embedded audio file, similar to videos, images, YouTube, etc.?

slate nacelle
#

I don't think implementing that is within our power.

thorny tree
#

why 😭

unknown.png
slate nacelle
#

Because it just was an alias to the resolve method of the member manager.
No idea why that isn't used in the second line there.

thorny tree
#

yes but it was really useful and very short way to test if the bot has certain permission

slate nacelle
#

Guild#me is still there, isn't it?

thorny tree
#

oh thanks 😄

outer raven
#

@tacit crypt btw

unknown.png
tacit crypt
#

Huh? They changed the name? Is that en-us?

tacit crypt
#

@outer raven

rough glacier
#

@tacit crypt should i use a temp value and assign something like maxArchiveDuration ?? data.autoArchiveDuration since they all get reassigned?

tacit crypt
#

perhaps? could do it like the file above the one i reviewed

outer raven
#

they changed this months ago tho

#

same on en-uk btw

rough glacier
round thorn
#

Is there a reason why URL isn’t capitalized when used on its own but is capitalized with other words hmm

Example:
MessageAttachment.url
MessageAttachment.proxyURL

I can make a PR to fix this inconsistency unless it’s like that for a specific reason

outer raven
#

because why would you have .URL

tiny swan
#

Maybe .proxyUrl

round thorn
#

^

#

Idm which but it should be the same tbh

clever crypt
#

what djs currently uses is correct and follows camelCase standards

#

if the name of a function/property is an acronym, it should be lowercase (MyClass.url, MyClass.http). the rules are different for constants

#

but it also depends on the length of the acronym. so like openURL looks descent and openHTTPConnection looks odd

#

v13 changed Guild.ownerID to ownerId and interaction.channelID to channelId because:

This is a more-correct casing for the camelCase used by discord.js as Id is an abbreviation of Identifier, not an acronym.

URL is an acronym

round thorn
#

I don't think the library reflects this atm

unknown.png
round thorn
solemn oyster
#

@clever crypt we'll eventually replace them to Url

outer raven
#

wait you will?

#

why tho

copper laurel
#

Because of all the reasons already listed above

uneven rain
#

so if a user was uncached when the bot was started, and they sent a message thus triggering the message event, would that cache them?

copper laurel
#

yeah

real jetty
#

You would need to have the intent(s) to trigger the event though, I think

stray delta
#

..yes?

honest barn
#

wait why is the minimum node version 16.6 now

#

are any of its features used in the code

solemn oyster
#

Not at the moment, but we will

#

Normally, we'd make the minimum 16.0.0, but 16.6.0 is a security release, so anything lower than that is discouraged.

#

16.6.0 brings Array#at in comparison to 16.0.0, which brings logical assignment operators (||=, &&=, ??=)

analog plover
#

Since to Node.js added an AbortController (quite a long time ago), why not use it in the library instead of the abort-controller module?

solemn oyster
#

OH YEAH

#

@wild flax can we have this change before release?

stray delta
real jetty
#

I was wondering why I was able to install a module nodejs already has(abort controller), now realized its not the same...

ruby terrace
tacit crypt
real jetty
stray delta
#

the latter

outer raven
#

Why is node v16 gonna be required? Afaik there's nothing that uses node 16 in djs right?

hallow ocean
#

according to Monbrey:
But we're setting it to 16 so we can use its features later

outer raven
#

nah you can install it but you get a warning

#

I really don't think you should be recommending a version of node that is not LTS

#

I mean sure it will be in 2 months but it isn't yet

copper laurel
#

Yeah but we also dont care

#

We dont want to have to release v14 in two months in order to use new Node features

#

When we can just make this version a v16 version

outer raven
#

why would you release v14 just to use the new node features

#

like someone said the other day they're nice to have but you don't need them that urgently

copper laurel
#

But we can also set v16 now

#

And not need a semver major if we want anything

#

I don't see why it's an issue

outer raven
#

v14 would've been a semver major anyway and when that comes out node 16 will be LTS

#

I think it would've been better to wait tbh

wild flax
#

We agreed internally having a 2 month transition period where it is still "current" before it transitions into "LTS" is ok 👍

outer raven
#

aight

void rivet
#

(repost)
For inviteCreate

     const client = this.client;
    const channel = client.channels.cache.get(data.channel_id);
    const guild = client.guilds.cache.get(data.guild_id);
    if (!channel) return false;

    const inviteData = Object.assign(data, { channel, guild });
    const invite = guild.invites.add(inviteData);
``` and for inviteDelete
```js
    const client = this.client;
    const channel = client.channels.cache.get(data.channel_id);
    const guild = client.guilds.cache.get(data.guild_id);
    if (!channel) return false;

    const inviteData = Object.assign(data, { channel, guild });
    const invite = new Invite(client, inviteData);
    guild.invites.cache.delete(invite.code);

it checks for the channel but not the guild, so if I only disable the GuildManager cache, the guild should return undefined
and since there's no check, for both this and inviteDelete, it'll cause an error
is this expected?

copper laurel
#

You REALLY should not disable the guild manager cache, and we added warnings and removed it from types so you dont

#

Like if there's any cache you shouldn't disable it's that one

void rivet
#

Wasn't aware of that
came across this issue because a user disabled every cache they could

#

so I take it this falls in the functionality break category and there's no need to add any further checks?

raven cloak
#

Thanks to all the contributors who helped ❤️

vagrant holly
#

Can a PR be made to remove the message event now that v13 is out? mmm

opaque vessel
#

I wonder if there's a chance now to rename the master branch to main? Not sure if that would mess anything existing up

digital hawk
#

see so my thing is. I'm okay with it being node 16 but it's just that many use v14 lts because it's lts

vagrant holly
digital hawk
#

yes v16 goes into lts in like 2 months

copper laurel
#

So if you want it to keep work if we do a minor release like v13.1, use node 16

copper laurel
void rivet
#

okay thanks 👍🏻

vivid field
digital hawk
#

from what I've seen, v13 doesn't even work on node 14

#

cuz abort controller yeah

vagrant holly
digital hawk
copper laurel
vivid field
#

oh true, it's --experimental-abortcontroller

copper laurel
#

Anyway, only talk here if discussing lib development please

vagrant holly
wild flax
#

Why not?

vagrant holly
#

Wasn't sure if y'all had a planned deprecation period

tacit crypt
#

its not like v14 is coming out tomorrow

round thorn
#

damn there goes that hope 😔

quiet viper
#

Will the existing PR's merged in v13?

#

and how will it be with new Features?

solemn oyster
#

New features will land as semver minor (13.1.0)

quiet viper
#

👍

tacit crypt
#

Unless they're breaking in which case why v14

drifting knot
#

should structures with a .toArray() method also have a Symbol.iterator that calls it

drifting knot
#

huh i guess bitfield is the only thing with a toarray method and it already has an iterator

#

nvm

wild flax
#

@oak quail can u rebase your PR (banners)

warped crater
vagrant holly
#

Will open another to keep things clean

warped crater
wild flax
#

less conflicts too potentially

#

lol

vagrant holly
#

Slightly meta, is there a reason Gh sponsors points to Amish, and not y'all who actually maintain the lib daily?

wild flax
#

because we get robbed

vagrant holly
wild flax
#

I have no idea honestly

#

github also only allows 4 people

#

which kinda sucks

vagrant holly
#

4 works

wild flax
#

we have like 5 though lol

vagrant holly
#

who am i missing

wild flax
#

hydra, me, space, vlad, kyra

vagrant holly
#

space doesnt have gh sponsors

unique axle
#

no love for the support crew

wild flax
#

guild subs soon

#

well just charge people here

#

lol

vagrant holly
#

What's hydra's username

wild flax
#

hydrabolt

#

amishshah

vagrant holly
#

oh same person

#

yeah so 4 works cause space doesnt have sponsors

wild flax
#

should add my ko-fi link in there too

vagrant holly
#

smh

wild flax
#

man I wish they would accept OF

#

oh they do with custom!!

vagrant holly
#

You can do custom links

#

Yeah

wild flax
vagrant holly
#

Gonna get some spicy pics of djs source on OF, soon™️

wild flax
#

naked inner workings of our code

cobalt comet
#

Can I hold d.js' hand?

icy bronze
#

yo, I don't know where to ask because #djs-help-v14 is flooded by v13 update but i'm having an issue when I require Message structure in the Webhook structure (forked repo to edit myself some stuff), it seems to invalidate the holds and cause it to be an empty object (very weird), is there any reason behind that?

unique axle
#

we do not provide support for forks to persist old features
potatodetective oh, this is not about Structures, i see

icy bronze
#

not exactly old feature

#

just a quick edit on the webhook structure where I build Message instead of returning APIMessage

#

but when I require it on top of the file, I don't get why but it invalidate my Message hold in MessageManager

#

I never used Structures to extend ehe

#

i'll provide more context if you don't mind

#

Webhook file, simply require Message

2021-08-07_4242.png
#

what I edited, build Message instead of returning APIMessage

2021-08-07_4243.png
#

the issue I get

2021-08-07_4244.png
#

and I have verified, when I bring back the file to the lib state, I don't have any holds issue

#

I also tried console loggin Message in different files.
Webhook file returns the class
MessageManager file returns an empty object

#

so node warnings are giving me more context
Warning: Accessing non-existent property 'Symbol(nodejs.util.inspect.custom)' of module exports inside circular dependency

copper laurel
#

Circular dependency is why

tacit crypt
#

Move the import to the bottom of the file or in the function

icy bronze
#

yeah got it but how could I do in my use case 🤔

#

alright I was trying in the function, still not done yet but i'll update

icy bronze
#

welp, here is my workaround, seems to be working

2021-08-07_4246.png
#

ty for helping everyone

#

by the way, it may be confusing the reason of doing that but its because I use the lib without the gateway for my interaction project (that runs with webhooks) and it lacks of support for uses like that.
so I am doing workarounds that aren't much reliable but works

#

building the Message here allows me to create interaction collector for example without having the channel in the cache

#

pretty useful when you don't want to fetch the channel each time

bitter peak
#

As the announcement says, it will be patched soon

loud jayBOT
real jetty
#

Why was Guild#owner removed?

rustic boughBOT
strange igloo
#

Because the member object associated to the guild owner was not guaranteed to be cached - as a replacement, that method ensures you will get its member no matter what

stray delta
#

sounds like the opposite reasoning why fetchApplication was removed lol

strange igloo
#

The application is unique, only used for the client, so I guess it can behave differently

tacit crypt
#

which never changes

slate nacelle
#

It effectively just moved to Application#fetch, as you couldn't use it before logging in anyway.

fallow crater
#

Will any of the packages in discordjs/discord.js-modules be implemented into discord.js? Or should these modules only be used for interacting with the Discord API without a bot?

tender field
#

This is a rewrite of discord.js, so the main package will work the same as the current one, and i don’t think they’ll be implemented in the current djs because their goals is to replace the current one entirely, not implement them in the current one

copper laurel
#

Not entirely true - there's no reason parts of it like rest or ws couldnt be introduced piece-by-piece into discord.js eventually

tender field
#

Yes of course they could, but i mean they are mainly being built for /core right? Not to replace current djs pieces (event though if they are ready before /core, yes you don’t have any reason to not implement them)

copper laurel
#

It makes more sense to implement the modules if we want to continue enhancing them, otherwise you end up in the situation we're in now - djs v13 got enhancements that modules doesnt have, because its twice as much work

#

Better to enhance in one place

tender field
#

Yeah right

real jetty
#

why are ya still recommending erlpack to be installed? it doesn't work with node 16 at all

#

theres a pr for it, but due to the lack of activity in the erlpack repo i doubt its getting merged

solemn oyster
obtuse fox
#

is detect invisible user possible?

wild flax
#

no

solemn oyster
#

It's invisible for a reason

honest barn
real jetty
#

Why doesnt GuildMemberRoleManager have a method fetch()?

#

What if I wanted to contact API directly to check if a user has a specific role Hmm

unique axle
#

there is no guild member roles endpoint, is there

real jetty
#

Oh

real jetty
unique axle
#

the member data includes a list of role id's. we resolve them based on the roles we get from the initial guild payloads + update events

real jetty
#

hm ok

unique axle
#

you can fetch all guild roles, but not the ones of a specific member, including the actual role information
the association member -> role always works via the id in the member and the data in the role payload

real jetty
#

Ok

bitter peak
#

btw @wild flax the version number pr should be good now

terse magnet
#

Why APIMessage has been deleted? To prevent developers from using additional libraries?

slate nacelle
#

It has been renamed to MessagePayload.

terse magnet
#

Thanks

icy bronze
#

Hey, trying to import discord.js using ESM gives me this.
I have fixed it replacing by "import": "./src/index.js" but it shouldn't be the way

2021-08-07_4250.png
wild flax
#

I am using ESM, so that can't be

#

Its probably because you run from github

#

The esm only gets generated on publish

icy bronze
#

I don't run from github thats weird

clever crypt
#

@tacit crypt @solemn oyster should i refactor all the iconURLs in the Emebd or to iconUrl?

tacit crypt
#

no.

solemn oyster
#

no

tacit crypt
#

URL stays as URL

clever crypt
tacit crypt
#

kyra is fake news-ing

clever crypt
#

calling the cancel culture police

wild flax
clever crypt
#

okay

clever crypt
#

builders discussion

loud blade
#

Is there any update about the issue where if you use zlib-sync, you would have increasing gc pauses over the time you use it?

real jetty
#

Can't Typing#inGuild() made into a property instead?

#

using a getter

solemn oyster
#

Nope

#

We can't make TS casts with getters, it needs to be a method

oak quail
#

how will d.js handle resolved interaction string mentions 🤔

#

might be useful to just expose resolved

fallow crater
#

maybe they can also be implemented into the CommandInteractionOptionResolver

tacit crypt
#

We actually talked about this (me and @ruby terrace) when we were in VC in Ian's server.. but uh i don't think we got to an "answer".. probably gonna have a Mentions of sort..who knows

#

It's definitely to be done

wild flax
#

Probably like on messages

#

A .mentions or smth

#

It’s dumb

#

It should never have been done this way

tacit crypt
#

🤣

#

True

quiet viper
#

but, when you use the CHANNEL or ROLE Type, you will get the object in the option?

haughty flame
#

why wouldn't there Permission on ApplicationCommandData
so we can just do

      Name: name,
      Description: description,
      Options: options
      Permission: Permission
#

so we wouldnt have to fetch the commands and adding command.permissions.add({ permissions }); manually

unique axle
#

you can't supply permissions during creation

#

those are two separate api calls and shouldn't be mushed together in the library

haughty flame
#

should i ask for this call on discord api server ?

#

or there must be seperate api calls for a reason ?

unique axle
#

technically yes, but they already said they're going to revamp the permission approach, so i doubt that'll do anything

haughty flame
#

Cool, i guess not gonna add a moderation command for now,
my SlashHandler will look like a mess if i do that manually

oak quail
haughty flame
#

what if they add a permission like MANAGE_GUILD only to use the command ?

unique axle
#

@real jetty permissions are still per guild. you patch permissions in the guild scope, not on global, even for global command permissions

#

@haughty flame "what if"'s don't really use much here, you can suggest approaches in discord developers or on their github, we can just implement what's there

brisk remnant
#

Are the TypeScript definitions automatically generated?
I've tried all day to see if I can bundle them up (for the monaco editor) but I haven't suceeded.

covert flint
#

no, they're manual

frank turret
#

tho if you still want me to use Number.isNaN that’s fine, I’m sure regular isNaN is broken in more ways than I accounted for

icy bronze
#

Hey @ruby terrace @solemn oyster @tacit crypt
I am contacting you because since v13, I am having a big issue with memory usage. My bot was already using v13 before the release but using an old commit before some breaking changes.
I have updated it to v13 the same day of the release and since that, my memory never stop climbing, I tried configuring cache but it doesn't get any better.
I'll send some graphs for you

Here is past month, we can see the ram climbing normally (5-6 days to reach the limit but never uses swap or at least doesn't make other process crash)
At the end you can see past 3 days where the ram usage just climbing way faster and never stops, it causes some process to crash like database)

2021-08-09_4256.png
#

Also more closer look to past 2 days usage

2021-08-09_4255.png
#

I have tried multiple cache configurations, here is my current one

2021-08-09_4257.png
tacit crypt
#

Btw, its defaultMakeCacheSettings

#

Thats an offtopic

#

and you have another typo at the Permission one

icy bronze
#

crawl sent me there

#

will fix the typo

tacit crypt
#

its not defaultmake

#

its defaultMake

#

as for ram usage.. do you have any heapdumps you can inspect (do NOT send them, as they can contain your bot token/auth details)?

icy bronze
#

I have tried to heapdump on a shard but it literally killed it lol

tacit crypt
#

right..that

#

What are your intents?

icy bronze
#

13999

#

sorry I don't have a list

#

mmh weird when I select all my intents I don't get the same number

#

it may have changed with new intents

#

but basically this

2021-08-09_4258.png
tacit crypt
#

I see you're not sweeping members, is that intentional?

icy bronze
#

I wasn't before v13 too

#

but I could, I have no reason not to

#

my current config is just some testing I made fast this morning because I didn't have much time

#

but it can be improved I guess

tacit crypt
#

and you don't happen to have v12 graphs, right?

icy bronze
#

v12 you mean?

tacit crypt
#

Yes, my kb skipped a v

icy bronze
#

(after thinking about it I should have created a thread sorry)

#

I switched to v13 the day it was a thing

#

as I said I was on a previous commit before some breaking changes (like send(string, options) one)

#

but I always been on master branch

tacit crypt
#

Then a graph from then

burnt thunder
#

Is there a way you can check if a user has Discord Nitro?

tacit crypt
tacit crypt
icy bronze
#

I have a shard that itself use 8GB of ram, Im making a heapdump and will investiguate

#

the dump only ends being a 600mb file HmmHmm

tacit crypt
icy bronze
#

alright did it with node one

#

still 600mb but eh, ig its normal

vagrant holly
#

fwiw im running pretty much the same intents as you and seeing ~250mb ram per shard @ 1k guilds/shard

#

the only major intent i see you have that i dont is voice states

icy bronze
#

I don't have music just a radio thing

#

and ye im seing ~1500mb per shard

#

and some are going wild I don't know why

vagrant holly
#

I would start tracking the size of different collections to understand what's growing

icy bronze
#

with the dump I noticed one of command taking a lot, i'll find a fix

#

other than that 😐

#

I don't see anything revelant

#

like, TextChannels has 13% retained size

#

perm overwrite manager too

#

does setting a sweepInterval without a sweepFilter works?

vagrant holly
#

No, how on earth will it know what timestamp to use to sweep by?

icy bronze
#

well how do I sweep users or guild members then mmmh

vagrant holly
#

Up to you

quiet viper
icy bronze
vagrant holly
#

My recommendation is very much to start tracking the collection size for assorted collections as well as overall mem usage, so you have a better picture of what's causing issues

#

It made the source of my mem issues w/ the v13 update very obvious

unknown.png
icy bronze
#

damn why I never thought about that before

#

thanks for the tip i'll monitor cache sizes

spice sierra
#

Hello sorry for bothering, you still have the opcode 5 I know it has been removed now but what was it used for when it was available ? (I'm being a bit curious I asked in the developer server but didn't get a reliable answer apparently it's for users)

icy bronze
#

@vagrant holly guild channels are automatically in channels cache too right ?

ruby terrace
# icy bronze I have removed thread caching and it didn't get any better

You didn't remove thread caching, that typo in ..defaultMakeCache made it not sweep archived threads from the guild and client caches, and yes, threads are in the client and guild caches too, so you'll have to write a custom Collection to enforce no thread caching (you'll get a process warning for doing so btw)

icy bronze
icy bronze
vagrant holly
wild flax
#

That is really fully making sure nothing gets cached lol

vagrant holly
#

nod Using a LimitedCollection with a limit of 0 is just inefficient, 'cause it does a lot of ops to just go "welp shit im full"

icy bronze
#

ty lmao

vagrant holly
#

I should also note that lastMessageTimestamp is not a standard prop of User/GuildMember, I inject it in a listener

icy bronze
ruby terrace
vagrant holly
#

Oh neato, will switch back to it then

ruby terrace
icy bronze
#

my larger cache is

#

permissionsoverwrite

#

thanks

#

120 fucking millions

vagrant holly
#

that seems

#

risky

icy bronze
#

skillz

outer night
#

can you guys take this into a thread?

icy bronze
#

nah jk but shouldn't I set a maxsize or sum

vagrant holly
#

Koyamies caching hell

real jetty
#

I had a question regarding copyright for async queue, I'm talking about the v12 file instead of the sapphire/async queue package. I want to add the async queue file to one of my projects, I included the copyright comments that say its the property fo Kyranet and Discord.js

Is there anything else I need to do regarding copyright stuff?

tacit crypt
#

Why.. aren't you using the module from npm?

#

But usually if you just copied the d.js file it should be fine, iirc it had a license headee

real jetty
tacit crypt
#

You know that adding extra dependencies isn't a bad thing right?

#

Nonetheless, if you don't want to install the dep, make sure your local file has the license header

real jetty
tacit crypt
#

Yes

real jetty
# tacit crypt Yes

Also what about the APIRouter, RequestHandler part? Do I need to add djs license header for that too? And sorry this will be the last question I promise

tacit crypt
#

Yes, yes you do. I don't exactly know which part of it is needed, but you would need to provide the license header. Or use @discordjs/rest

solemn oyster
#

Having certain deps within your project, instead of having them as regular dependencies can harm the maintainability of your project. For starters, do you even know how async-queue's code works? Or djs/rest?

We're also adding more and more dependencies (carefully) to discord.js and related projects to improve the maintenance, like we installed ow for /builders

real jetty
solemn oyster
#

We plan on switching to djs/rest to some point, so yeah

real jetty
#

oh ok, thanks a lot, I'll check it out

copper laurel
#

If you copy the code, you lose any link to the original developers maintenance and updates

#

It just becomes the orphaned code that you're less able to maintain yourself

cosmic pagoda
#

When having custom cache manager and maxSize equal to 0 keepOverLimit function is ignored and it never adds anything into the cache. But if maxSize is > 0 then the keepOverLimit works just fine. I tested it with BaseGuildEmojiManager and ReactionManager

ReactionManager: {
        maxSize: 0,
        keepOverLimit: (reaction, key, collection) => reaction.emoji.id === config.IDs.upvote || reaction.emoji.id === config.IDs.downvote //even if this method returns true, cache is always empty
    },```
Feel free to open issue on github with this (if its not intended behaviour) as I can't open issues
fallen arrow
#

keepOverLimit doesnt actually go over limit, it prevents removal when adding new items. for example if your limit is 5, and you want to add something new, the oldest item by order of insertion will be removed to make space for the new one. keepOverLimit will prevent specific items from being removed, so the next in line is removed instead, but the limit never goes over 5

cosmic pagoda
#

then it doesnt work because when I was testing it with maxSize just 1 and keepOverLimit which would permit 2 more items in the cache the total cache size was 3 and not 1 as it would have worked like you just explained

fallen arrow
#

then i misinterpreted the code

cosmic pagoda
#

so 1st item was some random collected emote and the other 2 kept over limit were the one I permitted in this cache upvote and downvote emote (total 3)

cosmic pagoda
fallen arrow
#

but yes, like you said, maxSize =0 does a hard return in the function, so it never checks for any of that

cosmic pagoda
#

so when having maxSize it should check the keepoverlimit func

cosmic pagoda
#

but can you link me where the keepoverlimit is called? i cant find it anywhere

fallen arrow
#

util/LimitedCollection.js

cosmic pagoda
#

ah I was in different commit

#

got it

#

in my eyes it should take in account for the keepoverlimit before returning maxSize: 0 so the keepoverlimit can be used to cache only very specific objects

#

not like the 1 unrelated is gonna make a difference but still

oak quail
#

yeah it should, if it doesn't then I consider that a bug

vagrant holly
#

This is gonna make the convo yesterday about limitedcollection maxsize = 0 being efficient redudant/incorrect

#

cause suddenly ops are gonna be performed before it goes "welp shit im full"

wild flax
#

Yeah you have to set it to 1 if you want to use keepOverLimit

vernal atlas
#

freshly installed dev 13.1.0-dev.t1628337792.68c0591

#

hm interesting vscode seems to just have just been having trouble, very strange lol, fixed when i ctrl clicked

bitter peak
solemn oyster
#

It reads from package.json

wild flax
#

Dunno, doesn't look like it

#

oh it did

#

but its not setting it as latest @dev for some reason

#

oh no

#

its all good

#

you are just on an outdated release @vernal atlas

vernal atlas
#

oh interesting

stray delta
#

when #6172 gets merged will we need to specify the type for slash commands? I know it's an option but more or less asking about djs's side

minor ether
#

Anyone else thing the Boolean option should be Yes No instead of True False? Seems a bit more use friendly and makes more sense in most scenarios

image0.png
#

Or is this a discord api thing

cloud kraken
#

We don't control that lol, just use choices

copper laurel
copper laurel
oak quail
copper laurel
#

Unless the API starts requiring it wouldnt that just be incorrect though

short crescent
#

Add discord context menu api

copper laurel
real jetty
#

is user.bannerURL gonna be available in 13.1.0?

stray delta
#

that pr isn't going to be merged until the pr for the api documentation is merged

icy bronze
#

it was afaik

stray delta
honest barn
#

yeah its not merged yet

icy bronze
#

ic

pale seal
#

Partial Messages for typescript

vagrant holly
#

Thoughts on throwing an error in LimitedCollection if a sweepInterval is provided w/o a sweepFilter -- seems to be something that's caught multiple people out, and seems like a sensible option error to throw?

ruby terrace
#

hmm, I'm not exactly opposed to that, but there was a reason I didn't do that, I just can't remember it

oak quail
#

isnt there a default sweepFilter that checks createdTimestamp?

ruby terrace
#

there is not, there was when it was SweptCollection, but since the merge there isn't

oak quail
#

oh

oak quail
neat bolt
#

0 is meant as a noop cache

#

the difference between 0 and 1 isnt a big deal

wild flax
stray delta
#

should context menus have builders? the guide uses them, so it would be more consistent
any ideas? souji said maybe deprecate slash command builders because the name is too specific. should I pr?

wild flax
#

It should already be possible

#

the only thing that needs changing is allowing no description be set

#

and the naming needs changing

#

since it allows uppercase and spaces

oak quail
#

does changing BaseGuildEmojiManager's caching do anything if client.emojis isnt accessed? since it's just created in the getter

#

also shouldnt GuildEmojiManager be in the Caches interface?

ruby terrace
#

BaseGuildEmojiManager is a DataManager, it doesn’t have a cache (technically). probably got them backwards

wild flax
#

@vernal atlas what? cc review

vernal atlas
#

well assuming this.guild?. is handling the rare case the guild isn't present, it should be checked before adding to the collection, if not then it should just be removed and assumed present

wild flax
#

Idgi

vernal atlas
#

what does that mean

wild flax
#

We still add to the collection though

#

Just the raw

#

You say it seems silly to add undefined, but we never do

vernal atlas
#

OHH

wild flax
#

We either resolve, or add raw

vernal atlas
#

i misread where the ?? member was

#

yeah no im just blind

wild flax
#

lol

vernal atlas
#

facepalm moment

opaque vessel
#

~~Hi hi guys, does anyone know why the typings for a WidgetMember allow for undefined, but the JSDocs says they're nullable? Is this some sort of oversight? >:

For example: If a widget member is not in voice, deaf will be undefined. The typings match up with this, but the documentation says ?boolean, but I was checking against null and was being mislead here. How come we don't default these properties to null and instead allow them to be undefined?

I would look into the pull request for more information, but I get an internal server error from viewing it >:~~

void rivet
proper token
#

Hello - I notice the lib doesn't require a style for a MessageButton, and defaults it to null, but the API docs say that style is a required parameter... Is this mismatch intentional? I don't have any code running on d.js 13 yet, but it seems like this would be an API error waiting to happen.
References:
https://discord.com/developers/docs/interactions/message-components#button-object
https://discord.js.org/#/docs/main/stable/class/MessageButton?scrollTo=style
https://github.com/discordjs/discord.js/blob/stable/src/structures/MessageButton.js#L49

vivid field
#

You can still set it after constructing using setStyle()

proper token
#

I'm aware; just concerned that the d.js lib treats it as optional when the API docs say it's required.

#

Especially since the lib doesn't supply it a default value under the hood

unique axle
#

it's the same level of optional as embeds need to have a description or field, but the constructor still doesn't require any input at all
that's how these structures have generally worked, you make an instance and then set the specific attributes

#

do not see any reason for concern here

copper laurel
#

It's optional because as a structure, you might not have set a style on it yet. Once you do, it will be defined. If you don't, you get an API error

tired kindle
#

Context: <#archive-djs-help-v13 message>
Isn't it a better idea for the library users to define the behavior themselves rather falling back to another behavior?

copper laurel
#

define the behaviour how exactly? I'm not entirely sure what you mean by that

#

Like a client option?

#

throwIfNoGuild (bad name but)

tired kindle
#

I'm not longer familiar with Djs or Discord API anymore but I would find very hard to diagnose such issue. I would be unsure whether I'm receiving a D.js object or the raw data from the API. It's bit ambiguous and hard to test of the same function does return different structures when you call the same function with the same arguments but the library initialization parameters differs

#

Something like a... "inconsistency?"

copper laurel
#

I sort of agree, but theres a very specific reasons for that inconsistency, which is required to support the way slash commands work

#

If you have a bot user in the guild, and you provide the GUILDS intent which is essentially required to use discord.js as a bot user, it will always be a Message

#

If you dont have a bot user in the guild, its just the applications.commands scope, you get raw API objects

#

The unexpected inconsistency really only comes up when people havent fully understood intents and left out GUILDS

tired valve
#

You can do an instanceof check if you are unsure what you're receiving

copper laurel
#

You can also construct an InteractionCollector with raw objects, you just cant use Message instance methods

tired kindle
#

I see, thus I believe it might not be a bad idea to have specific methods for each behavior rather sharing them as it would be able to report (elevate error) if there's no bot user

#

Making the reporting more clear

wild flax
#

There is no methods on raw objects

tired kindle
#

That's the issue

wild flax
#

Yes, so check what you get

tired kindle
#

How would you ensure it's a D.js object (with methods and so) or raw data from the API? It would look very ugly

copper laurel
#

instanceof

vivid field
#

I thought of just constructing a new Message() regardless when I first implemented interactions, but the channel and guild were in the way

#

but now that they're getters I think it should be fine

copper laurel
#

Possibly

#

Would be good to isolate raw out to client.ws events

wild flax
#

is breaking though

tired kindle
#

v14?

vivid field
#

right

#

I'll keep that noted though

ruby terrace
#

yeah, personal goal for v14 is to completely separate out stuff like that, making djs far less cache dependent

copper laurel
vivid field
#

yeah I think

#

so instead of ?? data it would become ?? new Message(data)

copper laurel
#

So why do DM messages still need the partial to emit

#

Surely we can remove that now?

vivid field
#

wait actually no

ruby terrace
#

cause messages are created on the manager for the channel, we could totally remove that though and just emit with a message object lacking channel

copper laurel
#

i mean yeah, but we could emit one that wasnt if channel wasnt found

#

Exactly like webhook currently does?

vivid field
#

Message#channel is a getter now but it's not marked as nullable

copper laurel
#

Why tf not

ruby terrace
#

wtf

vivid field
#

so that would be breaking too

copper laurel
#

Arent getters kinda implied always nullable gdi

vivid field
#

¯_(ツ)_/¯

wild flax
#

Its because our whole lib currently doesnt really work without GUILDS

copper laurel
#

I thought it was going to be nullable because people can fuck up the cache, or is that why we also did the whole "stop breaking unsupported cache modifications"

wild flax
#

so theres no reason to mark it as nullable

copper laurel
#

Okay fair enough

ruby terrace
#

and messing with channel caches isn't supported atm

vivid field
#

welp in that case this is a dream for v14 then

tawdry egret
#

any idea why default emojis will not show up on selects-menu on mobile, but will show fine on desktop?

#

very likely, it's the same bot code behind both interfaces. just a minor nuisance for me that some people will have emotes and some won't

copper laurel
#

Yeah definitely not library related, just a rendering issue

wheat basin
#

were there any thoughts about passing custom class type as a replacement to Structures ? ex. ```js
class ExtendedMesage extends Message {
constructor(client, data) {
super(client, data);
...
}
get property() { ... }
}
const client = new Client({
structures: { Message: ExtendedMessage }
});
client.on('messageCreate', x => { /* x instanceof ExtendedMessage */ });

typescript support might be literally impossible but i kinda fw the idea
copper laurel
#

Thats just the same thing with the same problems

unique axle
# copper laurel Why tf not

because that would've been a fucking disaster
we depend on it so much that that'd have made half the library in its current state nullable

#

we talked about that in #archive-internal-lib-discussions and while i'm still not really a fan of it, crawl has rightly so decided to consider a non-nullable getter here

neat bolt
copper laurel
#

Yeah I forgot the original issue it was resolving was just the change in type of channel

wheat basin
#

i see alright

icy bronze
#

but its tricky, some functions or properties may not work, its for my use only.

#

but doing that allows me to have a djs client that doesn't connect to the gateway but receive interactions via webhooks and build them like djs do. then I can use them to defer, reply etc! its just that I have no guilds, no channels in cache

#

so it was rendering an APIMessage (that could be a Message)

#

so I made a workaround for that

opaque vessel
wild flax
#

When it’s not a community I guess?

opaque vessel
#

I just created a guild and it defaulted to en-us

#

:thinking:

wild flax
#

Huh

strange igloo
#

Looks like it defaults to en-US in non-community guilds yeah

opaque vessel
#

Well it works as documented, apparently

#

Oh never mind

Marked Guild#preferredLocale as nullable since a Guild may not have community enabled
Well this reason went untested I guess

#

@outer raven haiiiii, are you able to confirm the above :eyes: did you test it?

wild flax
#

They may have changed that

void rivet
slate nacelle
#

I don't think we implement that endpoint.
What's the use case for the after parameter, out of curiosity?

strange igloo
#

probably for pagination since the response is restricted to 1k members Thonk

slate nacelle
#

Then the gateway variant, that we implement, would be more efficient.
They also mentioned a single member.

void rivet
# slate nacelle I don't think we implement that endpoint. What's the use case for the `after` pa...

So I want to get a random member, now all the members aren't cached
I don't want to fetch every single member
let's say I'm using a giveaway command and I also need to exclude members that are new accounts, like one week or so, so my plan was, generate a random timestamp from discord's starting timestamp to last week, generate a snowflake, use that on after with limit set to 1, that way I'll only fetch a single member
that's the use case for me

outer raven
opaque vessel
#

Odd, it's not marked as nullable here. Maybe it changed?

Screenshot_2021-08-12_at_12.58.54.png
outer raven
#

Perhaps, I could swear it was nullable when i made that pr

icy bronze
#

thats what I do but its difficult to have a good random member way without cache

opaque vessel
icy bronze
#

I could suggest to discord to add an option or sum

void rivet
strange igloo
#

The endpoint should probably be implemented for API coverage, but how Thonk
Having yet another overload to GuildMemberManager#fetch is probably not wanted, so that would be in another method

Or completely break current logic by renaming fetch in request (to match with the Request Guild Members gateway command) and keep fetch for the REST endpoint

void rivet
icy bronze
void rivet
icy bronze
#

o

#

I see now

void rivet
obtuse hazel
icy bronze
#

then yeah mine doesn't fits

strange igloo
#

That would make the method use either WS or REST depending on a property, which I'm not against but I have no idea if everyone will agree

icy bronze
#

its called list guild members. GuildMemberManager.list()

#

👍

#

wait isn't the enpoind the same

void rivet
#

no, the one implemented uses request guild members

icy bronze
#

oh yeah right

void rivet
obtuse hazel
#

D.js doesn't support the rest endpoint but only the websocket request, which is not the same

outer raven
void rivet
#

Yeah I guess so far they haven't seen any need for it
but since the api does allow it, why not implement it?

obtuse hazel
#

It would allow fetching members without a websocket connection

#

It's worth for some use cases

void rivet
#

Okay so I guess the proposal right now is that this should be added as <GuildMemberManager>.list?

icy bronze
#

thats how I see it

strange igloo
#

Woud be the best, I think, to stay semver minor

void rivet
#

Yeah that seems like a better approach than overloading the existing fetch method

vivid field
#

if you want to do that, use @discordjs/rest

#

but additional api support doesn't hurt

opaque vessel
void rivet
#

Also the <GuildMemberManager>.fetch, if you choose to fetch multiple members, why is it that you don't have the ability to make it not cache the result the way you have with a singular member fetch?

icy bronze
void rivet
#

So should I work on the <GuildMemberManager>.list method?

copper laurel
#

No

rustic boughBOT
copper laurel
#

Uses the REST endpoints

void rivet
copper laurel
#

The actual list endpoint isn't very useful on it's own, we use the gateway for fetching them all

void rivet
#

I needed it for it's after param
and since the api allows it, why not?

copper laurel
#

Eh, I guess so

void rivet
#

So was that a yes? :D

copper laurel
#

Yeah why not

dawn merlin
lusty bolt
#

yo, real quick question just out of curiosity, why does v13 now require node 16.6?

warped crater
#

native abort controller

lusty bolt
#

ah i see. cool

real jetty
opaque vessel
real jetty
#

Hm alright.

empty viper
slate nacelle
empty viper
#

Oh I see, neat !

wild flax
#

@void rivet if discord has a default, we shouldnt set one

#

the search one might be an oversight

void rivet
wild flax
#

we cant do that sadly

#

since it would be semver major

#

but we can make sure to not repeat the mistake

#

and make sure your PR doesnt set one

#

👀

void rivet
#

Okay 👍🏻

#

I'll test it first just to be sure

#

Should it mention that the api defaults to 1?

wild flax
#

Nah

#

The defaults we list are lib defaults, never api defaults

void rivet
#

Guild prune does the same thing I guess, sets the default of days to 7, which is also the api default

wild flax
#

ok you know what

#

that might be better for a v14 change then

#

lets just roll with a default then

void rivet
#

So now I revert back to setting a default value?

wild flax
#

😆

#

I'm sorry haha

#

I didnt think it was that big of an issue in the whole lib

#

Looks like well have to fix a lot on that front

void rivet
#

Yeah np, I'm just new to github, so don't know most of the stuff, like if I can revert a commit on a pr

wild flax
#

You can just make a new commit readding it

#

since we squash commits anyway

#

so in the end it will be 1 commit regardless

void rivet
wild flax
#

nah we can leave that

void rivet
#

okay made a typo along the line, now it should be okay, thanks again

#

I'll also look for more like this where it sets the default value despite the API already having one

void rivet
pale seal
#

I noticed that the repo uses eslint + tslint. Is there a reason why both are still user as tslint is deprecated since eslint can do all the work now?

vivid field
#

@typescript-eslint doesn't lint declaration files from what I heard

pale seal
#

Hmm, not enough an expert for that xD

shut wave
#

Not necessarily an issue but why is type optional in:

export interface BaseMessageComponentOptions {
  type?: MessageComponentType | MessageComponentTypes;
}

Did a big ol' refactor, bot starts just fine then boom:

TypeError [INVALID_TYPE]: Supplied data.type is not a valid MessageComponentType.  
    at Function.create (/BLEH/node_modules/discord.js/src/structures/BaseMessageComponent.js:86:17)

I left off type: 'ACTION_ROW' because the types didn't tell me I needed it...

Curious as to what case the MessageActionRowOptions would work without said type because of

export interface MessageActionRowOptions extends BaseMessageComponentOptions {
  components: MessageActionRowComponentResolvable[];
}
copper laurel
#

Because when you use the builder classes, new MessageActionRow() etc, it internally sets type

#

And thats really what those options are for

#

But if youre not using the class and just writing an object, its required

#

Otherwise youd be writing new MessageActionRow({ type: 'ACTION_ROW', components: [...] })

shut wave
#

Ah so MessageActionRowOptions should probably be export interface MessageActionRowOptions extends Required<BaseMessageComponentOptions> {?

#

Assuming that MessageActionRowOptions is the 'write it yourself without the class' variation (based on components?: (MessageActionRow | MessageActionRowOptions)[]; from MessageOptions)

copper laurel
#

no, MessageActionRowOptions is the parameter for the MessageActionRow constructor where it isnt required

#

arguably it should probably be components?: (MessageActionRow | Required<MessageActionRowOptions>)[] to make the parameters required when passing the object

#

and that would allow it to remain not-required in the interface for the constructor

shut wave
#

👍 Makes sense - The impl could detect the 'object' style and run it through the new MessageActionRow automatically as well?

copper laurel
#

Nah it really shouldnt

#

Whats the benefit of that?

#

Well actually, it does do that

#

But it can only do that if you set the type

#

If you dont, it cant possibly know that it should be run through that specific constructor

shut wave
#

So in MessageOptions['components'] you can pass things with a different type than ACTION_ROW currently?

#

Otherwise it should probably be doing something like rows.map((row) => row instanceof MessageActionRow ? row : new MessageActionRow(row))

shut wave
outer raven
wild flax
#

Thats literally what I was saying

outer raven
#

No but I remember you saying we should use the api’s defaults and never hard code them

#

And that’s done on some occasions

wild flax
#

yes

outer raven
#

Not many tho

wild flax
#

yes

#

and we can't change it in v13

outer raven
#

Really?

#

But the behavior is the same

wild flax
#

Think about it for a bit

outer raven
#

Well if you have the same default value as the api and remove that default from the lib its the same

copper laurel
wild flax
outer raven
#

But you don’t release a new version when discord changes a default

#
  • i doubt they’d be changing the default days to prune inactive members which is what I’m talking about
wild flax
#

likeliness doesnt matter

#

and yes we dont

#

thats the problem

#

it would then be undefined behaviour

outer raven
#

But if nothing else in the lib does this then why does this method do?

wild flax
#

theres more

#

And a lot of those things are remnants

#

it just so happens that this was the way we did it in the past

#

and since the last major no one noticed or bothered

outer raven
#

Ah I see

#

So it can be changed

#

Can u tell me what are the other ones?

wild flax
#

No, it can’t be changed until v14

outer raven
#

Yeah ik

wild flax
#

search is also one of them iirc

outer raven
#

But it can be changed thats what im saying

outer raven
void rivet
shut wave
copper laurel
#

You can't just set the type of the component?

outer raven
#

And that’s exactly what I’m saying shouldn’t happen

wild flax
shut wave
# wild flax releasing a major version just because you made a dumb design decision in the fu...

I mean, you could quite easily support something new without making it a breaking change - i.e. if no type is passed then assume its a MessageActionRow but if a type is passed then do what it currently does with the Base class.

It's far more dumb to make an API decision based on something that 'might' happen...

Also, you're aware feature flags exist? Let people opt in to 'breaking' behaviour rather than forcing major updates in 'big bang' style

wild flax
#

I'm glad you don't design this lib

#

Because passing a type requires you to then use completely different syntax, completely alienating the interface

copper laurel
#

That's exactly why we removed the nested array syntax, which I liked but made way more sense to drop

shut wave
# wild flax Because passing a type requires you to then use completely different syntax, com...

I mean, the array syntax made complete sense to me because the current API onky supports Message action rows. If discord update their API to add a major new feature I wouldn't be surprised to see an update in Discord.js - but you can very easily support multiple variations without having to make breaking changes and/or adding feature flags to let people opt in in advance to allow for easier migrations.

Honestly after comments like this I'm glad I haven't tried to contribute. I asked a question and made suggestions on how you might improve your API from the perspective of someone using it. You literally called me dumb - thanks for alienating another experienced developer 👍 You do you I guess.

I'll stick to overriding your types and wrapping your broken API and types to make my life easier rather than suggesting improvements in the future.

wild flax
#

I called it a dumb design decision, because we made it ourselves and the whole premise of locking ourselves into a corner dumb.

#

Stop being so offended over something that wasn't even directed at you.

#

And you are welcome I guess.

shut wave
#

'Im glad you don't design this lib' hard not to take offense from that ngl. But you're right - I'll be the bigger man and clarify what I was trying to suggest.

Basically what you're doing is making your lives easier (i.e. developing d.js) and as a result making everyone else write more code.

In this particular case, it would have been very easy to retain the nested arrays API then use type checking to determine whether 'whatever new thing' discord might add in the future should do.

If that code is too complex or adds a performance overhead or is overly complex, you instead hide it behind a feature flag on the Client constructor to opt in to the behaviour to let people change things gradually rather than forcing a huge rewrite with every one of your major releases.

Obviously that's too late so we'll have to live with it but maybe at least consider the people using your APIs in the future. Discord.js has so far been one of the worst libraries I've used for upgrades because it's all or nothing. V13 is the exception of course because you basically seem to have rewritten the entire thing so I expected a rewrite but you could definitely work on making it easier to upgrade/migrate in the future.

Ignoring all the migration stuff, you should at the very least be changing the types to prevent people hitting a runtime issue by omitting the type: 'ACTION_ROW' - after all, that's what Typescript is really for

wild flax
#

Yeah, and we decided against doing that.

#

Theres nothing wrong with that, as much as there might not be anything wrong with your suggestion in eyes of other people or yourself.

#

You now throwing insults around because I disagree with you is simply some nice /r/niceguys material

#

So if you have nothing constructive to say anymore, keep it out of this channel and take it to #archive-offtopic

ornate topaz
#

Doesn't having different sets of features determined by a param in client options kind of make it so that lib devs have to maintain both ways? With added bonus that the usage isn't uniform anymore because it depends on an arbitrary switch?

shut wave
ornate topaz
#

wait, but, if you're talking about interactions, they didn't exist at all in v12, so there is nothing really to maintain backwards compat for

shut wave
#

Yes - and I addressed that with 'V13 is the exception ...'

#

I was pointing out for future changes as there's nothing that could be done to the current API without a breaking change 😉

ornate topaz
#

and in terms of v13 alone, that would mean that we would have to design things fast and care about how to implement new things when they come out, instead of having a relatively clean way of adding new features later on without the need to change any usage at all

wild flax
#

So what is your point? The what you call "feature flags", or also just referred to as deprecation of features, is something we have been doing all the time

#

It just so happened that interactions never existed and we went with a bit more verbose syntax.

#

Go listen to the message event, youll get a nice warning. It's also deprecated in the docs. Its no different to the new messageCreate event. Thats something we've been doing actively since like version 8 of this library.

shut wave
#

feature flag = opt in to new behaviour for existing option
deprecation = existing option/behaviour going away with warning

Same principal though

I understand what you've done with the verbose syntax and why you've made those decisions. The point does still stand R.E. the runtime issue because of the type

wild flax
#

I see no issue open about it?

#

Nor a reproduction case

#

We can't know or see bugs if no one tells us

shut wave
#

channel.send({ components: [{ components: [aButtonComponent] }] }) = throws an error at runtime

I asked about it here because I wasn't sure if it was a bug or if I was being stupid #archive-library-discussion message

wild flax
#

This lib isn't written in TS either, so typings being more buggy than not is a lot harder to fix and spot since we don't run through TSC

copper laurel
#

If Discord introduces some other type of row, sure its technically not breaking, but its a bad user experience to sometimes have to specify type and other times not

shut wave
copper laurel
#

We were right in the first place - passing objects directly should be Require<MessageActionRowOptions> to enforce the type param, since its required

#

Thats the real solution here to it not asking for type when it should

shut wave
# copper laurel If Discord introduces some other type of row, sure its technically not breaking,...

Not necessarily - As long as the type information (and documentation for non-TS users) defines what the components expects to be passed it doesn't really matter if it supports n different types.

If the 'default' were ACTION_ROW for instance that would make sense as you either have ACTION_ROW or you specify the type. As said, I'm fine with the Require change - as long as the types stop me getting runtime errors we're golden 😛

copper laurel
#

Its not up to us to decide ACTION_ROW deserved a default over anything Discord might provide in future either

#

I get what youre saying technically speaking for types, its more about UX and expectations

shut wave
#

Yeah, I get that - Fundamentally the issue here is just a disconnect between what the lib expects and the types. Easily fixed, ima go back to my bot now 😂👍

copper laurel
#

Yeah I think its more accurately fixed by making it required in object params for send

real jetty
#

Not sure if I should ask about discord-api-types here but when would APIUser.bot be not provided? TS says its an optional param

slate nacelle
#

I think it's only provided for bots.

real jetty
#

ah alright

quiet viper
#

Does this new announcement of unique custom ids mean, that we have to generate evertime different ids? On each message?

slate nacelle
#

I assume it's per message.
So you can reuse the same id on different messages.

quiet viper
#

Ah, so I cant have 2 Buttons with the same CustomIds

#

Okay, never do this...😅 thx

hollow crest
#

Does discordjs have a way to create user commands (actions you can take from a menu when right clicking on a user)?

Screenshot_20210813-223951_Firefox_Beta.jpg
slate nacelle
#

Yes

hollow crest
#

Could you possibly reference the relevant location in the guide docs? I haven't been able to find it.

slate nacelle
hollow crest
#

Thank you space. I was trying to find it in discordjs.guide

outer night
#

There's some more relevant info in #archive-context-menus pins, if you have any more follow up questions pls post them there instead catThumbsUp

#

And we'll hopefully get a guide page up for it soon

slate nacelle
#

Oh, I should have just linked to there. msclap

hollow crest
tired valve
stray delta
#

nvm misread

hoary ether
#

Global commands have inherent read-repair functionality. That means that if you make an update to a global command, and a user tries to use that command before it has updated for them, Discord will do an internal version check and reject the command, and trigger a reload for that command.
https://discord.com/developers/docs/interactions/application-commands#making-a-global-command

Does that mean it's possible to artificially "force reload" a global command without having to wait the 1 hour fan-out?

oak quail
#

well itll only update in the current guild

hoary ether
#

right

#

so i guess that means: from the perspective of a user who's using a global slash command, i'll never run into a scenario where i'd have to wait for the "new" version of a slash command to fan out for my guild

wild flax
#

not really but it might fail a few times

#

until its updates

#

its not guaranteed to be fast-tracked after the first failure

hoary ether
#

i wonder how discord handles the error message in the event that the global command hasnt updated yet

#

oh, maybe this is one of those "interaction application command failed" screenshots that i've seen in #archive-interactions ?

oak quail
#

yes

real jetty
#

When I do 2 commands with the same name and different type for example slash & context menu user and use the PUT method it doesn't work and throws the error Application command types are immutable. It's an API-Side bug, right?

unique axle
#

yes

real jetty
#

So for now, I guess I have to solve this by using the POST method.

unique axle
#

yes

real jetty
#

Well thank you, because I'm adding support context menus to my package so at least I know I can't solve a better rate limit yet

rough roost
copper garden
rough roost
strange igloo
#

What does "official" mean here? Thonk The only "official" HTTP module in node is the native http

brisk remnant
#

What might actually be worth moving to is phin - it has the exact same API as node-fetch, just a way smaller size.

unknown.png
copper garden
#

So what? It saves 131 kB

#

That would not be noticeable as a backend dependency

solemn oyster
#

We don't care about bundle sizes, node-fetch is a defacto-standard and very used package

dawn basalt
#

Suggestion: Helper getter TextChannel#messagable similiar to TextChannel#viewable or TextChannel#managable

    if (this.client.user.id === this.guild.ownerId) return true;
    const permissions = this.permissionsFor(this.client.user);
    if (!permissions) return false;
    return permissions.has(Permissions.FLAGS.SEND_MESSAGES, false);
  • Not limited to TextChannel though. A better name could also be used instead.
empty viper
#

sendable ?

strange igloo
# 
get sendable() {
  if (!this.guild || this.client.user.id === this.guild.ownerId) return true;
  const permissions = this.permissionsFor(this.client.user);
  return permissions?.has(Permissions.FLAGS.SEND_MESSAGES, false) ?? false;
}

With a !this.guild typeguard that could fall into TextBasedChannel to be spread into all text channels (guild/non-guild)
But we still use permissions where we shouldn't, I mean it would work but it looks terribly unsatisfying to my eyes

#

That said, it won't even be right as I make it say true for DM channels, but we can't know before having tried whether or not we can send messages in DMs

So that would only be a prop for guild channels that are text-based, but there are no classes that represent them
Which would mean that would have to be duplicated in Text/News/etcChannel
Or just return null for dms, idk

opaque vessel
#

I'm dropping this here because of the recent node-fetch talk: node-fetch is moving to become an ESM module only in version 3 (already happening in 3.0.0-beta.10) which I believe will enforce that on us if we ever upgrade to version 3. :eyes: note note

solemn oyster
#

Then we'll stay v2, no biggie

real jetty
#

Remove self bot ability

hoary ether
#

apparently there's no .deferReply() method?

vernal adder
#

Is just a bug

#

It exists

#

You can see it on the other interaction types

hoary ether
#

which doc is more reliable then? i'm assuming main points to the main branch in the repo, correct?

ornate topaz
#

main and stable are branch names

#

main was master earlier

#

so main will be "newer" than stable, but also won't reflect your state if you just use stable version from npm

hoary ether
#

if i installed with npm i discord.js then that points to stable version right? so that means it's supposed to be 13.1.0 right now

ornate topaz
#

yes

hoary ether
#

isn't the documentation auto generated from the codebase? how can this inconsistency happen unless it was manually updated?

ornate topaz
#

it is

#

but source code is not auto generated, but written by humans

#

might be related

hoary ether
#

ah i see

#

so the actual method was changed to deferReply but the comment was not, so the docs wasnt generated properly

ornate topaz
#

docs were generated from source code, properly

#

it's just that the source code was missing something

#

there are few places where everything has to be set, not exactly hard to miss one

vernal adder
#

usually doesn't happened, and gets fixed quickly

hoary ether
#

at this point ive encountered enough inconsistency in the docs that i'm starting to feel more inclined to reference the actual package inside node_modules/ xD

#

thanks for the quick replies tho

bitter peak
#

typings are usually more likely to be correct than the docs, but if you notice inconsistencies then you should open a PR or issue

ornate topaz
#

typings are done manually

#

and it's js lib

#

that might be misleading thing to say

bitter peak
#

Well, they're still more likely to be updated than the jsdoc. Obviously it's not a guarantee still

ornate topaz
#

not really, but whatever

copper laurel
#

This particular change happened because I moved those documentation stubs to BaseCommandInteraction, but at that same time a PR to rename it landed. Because I was moving the lines it didn't get correctly reflected in my rebases

dawn merlin
#

I was wondering if it was possible to represent the complex union types from typescript definitions in the jsdoc. I feel like it would improve some ambiguity.

copper laurel
#

Not really no

#

jsdoc is to document JS, not TS

elder reef
#

Not sure where to post this, but it seems like it belongs in here since it has to do with what discord.js exports

There's this note in /typings/enums: ts // These are enums that are used in the typings file but do not exist as actual exported values. To prevent them from // showing up in an editor, they are imported from here instead of exporting them there directly.
Yet vscode says I can still import it. I assume that's not intentional? I'm using typescript, but I think I shouldn't import this anyways since it seems like an internal thing that could change frequently.ts import { ApplicationCommandTypes } from "discord.js/typings/enums";

dawn merlin
#

It’ll cause a runtime error if you import enums like that

#

You need to use the exported Constants object

elder reef
#

Ah ok

sharp wigeon
#

hey uh so not sure what's going on here. I know this isn't a help channel but looks like an internal error

3.png
#

I assume import { URLSearchParams } from 'url'; this would fix it

wild flax
#

did you install @types/node

sharp wigeon
#

hmm ill try that

outer raven
#

we used to have 1 interface for slash command options, who thought this would be a good idea?

unknown.png
#

I have 1 function to transform all options from all of my commands into a different thing and I can't possibly know which one of those interfaces they correspond to

#

can we bring back the old interface and get rid of those?

#

seems like it was caused by #6247, did anyone test this properly? 🤔

dawn basalt
strong heath
# 
npm ERR! node-pre-gyp http GET https://github.com/discordjs/opus/releases/download/v0.5.3/opus-v0.5.3-node-v93-napi-v3-win32-ia32-unknown-unknown.tar.gz
npm ERR! node-pre-gyp ERR! install response status 404 Not Found on https://github.com/discordjs/opus/releases/download/v0.5.3/opus-v0.5.3-node-v93-napi-v3-win32-ia32-unknown-unknown.tar.gz
npm ERR! node-pre-gyp WARN Pre-built binaries not installable for @discordjs/opus@0.5.3 and node@16.6.1 (node-v93 ABI, unknown) (falling back to source compile with node-gyp)
npm ERR! node-pre-gyp WARN Hit error response status 404 Not Found on https://github.com/discordjs/opus/releases/download/v0.5.3/opus-v0.5.3-node-v93-napi-v3-win32-ia32-unknown-unknown.tar.gz```
sly forge
# outer raven I have 1 function to transform all options from all of my commands into a differ...

checking the type actually exposes its properties. idk if this is helpful or not but I made a similar function

private _transformOptions(
    options?: ApplicationCommandOptionData[],
  ): ApplicationCommandOptionData[] {
    if (!options || !Array.isArray(options)) return [];
    return options.map(option => ({
      type: option.type,
      name: option.name,
      description: option.description,
      required:
        option.type === 'SUB_COMMAND' || option.type === 'SUB_COMMAND_GROUP'
          ? option.required
          : option.required ?? false,
      choices:
        option.type === 'STRING' || option.type === 'NUMBER' || option.type === 'INTEGER'
          ? option.choices
          : undefined,
      options:
        (option.type === 'SUB_COMMAND' || option.type === 'SUB_COMMAND_GROUP') && option.options
          ? this._transformOptions(option.options)
          : undefined,
    })) as ApplicationCommandOptionData[];
  }
outer raven
tacit crypt
tacit crypt
#

Tho I see there's some other issues with it soo

outer raven
icy bronze
#

@wild flax about my import error with ESM, it's because I use my fork but I don't build it when installing. I don't get what is the build script of the lib, prepare doesn't seem to be the one and I am still having the error after doing install in the folder

#

if you know how I can fix

#

my postinstall script for now is "postinstall": "cd ./node_modules/discord.js && mkdir -p .git && npm install"

tacit crypt
#

you should make it be npx gen-esm-wrapper src/index.js src/index.mjs iirc

#

basically like what the prepare script it

icy bronze
#

so prepublishOnly script then?

wild flax
#

yes

#

but no need to run the tests

#

and you need to do npx anyway

#

since you prolly dont have our dev-deps installed

icy bronze
#

I think ye

#

so gen-esm-wrapper src/index.js src/index.mjs is enough?

#

ok nvm I read it wrong lol

#

thanks i'll try it out

#

yay worked HYPE

urban mist
#

Hi, I'm re-posting this from #archive-interactions because someone suggested I asked this here, hope it's not an issue...

Question about subcommands: as of now, Discord allows you to create a subcommand and a subcommand group at the same depth level, like this:

command
|_subcommand_group
| |_subcommand
| |_subcommand
|_subcommand
|_subcommand

This is not explicitly allowed in the docs, but if you try registering a command like this it'll work, and you just receive the used command options in the interactionCreate event

Is this behavior actually allowed or is it something that works even if it's not supposed to? If it's allowed, why does the @discordjs/builders library prohibit this kind of nesting (at least through the typings)?

slate nacelle
#

I'd assume Discord allowing that is a bug and not intended.

wild flax
#

Yeah that doesn’t seem like it is intended

urban mist
#

Got it, thanks guys

strange igloo
dawn basalt
loud jayBOT
#

pr_open #6444 in discordjs/discord.js by WiseDevHelper opened <t:1629023866:R> (review required)
feat(BaseGuildTextChannel): Add BaseGuildTextChannel#sendable getter.
📥 npm i WiseDevHelper/discord.js#feat/channel-sendable

strange igloo
raven juniper
outer raven
#

I remember a discussion with @wild flax where he said he preferred tabs over spaces, isn't it about time the whole lib is refactored to use tabs?

wild flax
#

No

outer raven
#

why not I mean almost everything else djs related uses tabs at this point

wild flax
#

Because its a disastrous diff

lofty birch
#

Spaces are much worse for accessibility

outer raven
wild flax
#

Eventually

dawn merlin
#

After seeing reactions to the permission helpers PR’s. I was wondering if instead of tacking these helpers onto the classes themselves, new ones would be moved to a static permissions utility class instead. I.e. ChannelUtil.isPrivate(channel)?

oak quail
#

builders not supporting that is an issue

outer raven
#

Why is the ClientPresence class not documented nor present in the typings?

slate nacelle
#

Because it's an implementation detail, it should probably be private in the docs too.

outer raven
#

thing is it's not even private, it doesn't have JSDoc comments and it's not declared in the typings. Same for Client#presence

zenith oracle
#

^^

outer raven
# zenith oracle ^^

well yeah it's fine for it to be private, but it's not fine for it to be undocumented

zenith oracle
#

Well, i see it in the docs, wdym?

outer raven
copper laurel
#

It only has one method that arguably should be internal too, set

#

Its missing {@extends Presence}

#

Which is where the actual methods should be

faint current
#

@solemn oyster easy:

Make code clear, doing proxies and functions referring to other functions is one of the worst things you can possibly do. It's easy to get large memory footprint if near every object points to few other circular references making it's not only tough to parse but also easy place for memory leaks.

Another thing that is really annoying is how big D.js actually is. I would love to see something like from https://github.com/detritusjs/client where you have multiple packages so you download only what you need. D.js in v13 finally removed voice support from main path but it still support a buch of crap.

Next thing is memory management. I have no idea who had idea of storing everything in Collections. They are cool to use - true, but they leave huge memory footprint at scale.

#

D.js code looks like you would totally not care about performance at all, just make it work and leave standalone.

solemn oyster
#

where you have multiple packages so you download only what you need
That's already in the works

faint current
solemn oyster
#

That's our first step, we'll soon work on @discordjs/ws as well, once we finish the new tests and the cache wait opt-out

wild flax
#

Man you are the whole circus and every clown in it

faint current
#

Cause I care about performance while using Node?

wild flax
#

Your constructive criticism comes from "launch some benchmarks" and "all big bots use eris"

#

Which are bot invalid statements right there

#

Barely any HUGE bot uses JS in the first place lol

faint current
#

And what d.js shown then?

faint current
wild flax
#

We are this popular and this hugely used because the majority of bots are not HUGE bots, and that is simply what we focus on the most 99% of the time

copper laurel
#

I'm still not seeing any constructive suggestions for improvements, which is what you were redirected to this channel for. Continuing to make criticisms seemingly just for the sake of shitting on djs will not be tolerated here

faint current
#

Tatsu, Atlas, Dyno & Rythm are using Eris. Dank Memer is slowly being rewritten on Eris.

#

Idk about other

#

Mudae & Karuta used D.js

faint current
#

Biggest D.js pain is that it's pretty in cost of efficiency