#archive-library-discussion

1 messages · Page 19 of 1

tacit crypt
#

Thats not even the issue (well, it is, but not the issue I'm poking at)

opaque vessel
#

If the return type won't accept big integers then there's no point doing it in the first place then

visual hornet
#

oh whoops

opaque vessel
#

Heck what

tacit crypt
#

Do you see me calling Number twice? meguFace

opaque vessel
#

Oh no

#

Oh great

#

Oh perfect

#

We back

visual hornet
#

also as a side note, im not sure if i set something incorrectly in my dev env, but uh,

#

i haven't modified this or anything, just cloned the repo
eslint is complaining that this should be under node-fetch, but nothing about it shows up with npm test

tacit crypt
#

doesn't hurt to run an npm ci, restart the eslint server and also re-run the test script

opaque vessel
visual hornet
#

aight ill try looking into that, thanks

opaque vessel
#

As long as npm test works fine then all should be good I guess

visual hornet
#

yeah i understand that, just want to make sure eslint is working fine in the ide since the changes im planning are more than just swapping a and b like i initially planned lol

opaque vessel
visual hornet
#

i got to this, but it feels kinda clunky, im not sure if this could be improved in some way?

Number(a instanceof GuildChannel ? BigInt(a.id) - BigInt(b.id) : BigInt(b.id) - BigInt(a.id))
opaque vessel
#

Suppose you should use variables to make it less clunky? Shrugs

visual hornet
#

as an iife? or just make it a block and return the result?

opaque vessel
#

Yeah it looks like a block would be more readable

#

Like so?

const aId = BigInt(a.id);
const bId = BigInt(b.id);
return Number(a instanceof GuildChannel ? aId - bId : bId - aId);
visual hornet
#

aight

#
return collection.sorted((a, b) => {
  const aId = BigInt(a.id);
  const bId = BigInt(b.id);
  return a.rawPosition - b.rawPosition || Number(a instanceof GuildChannel ? aId - bId : bId - aId);
});

so this is what i've got now, anything else to be desired here?

opaque vessel
#

@dawn merlin your question you just asked isn't for me, that's for Discord

dawn merlin
#

ok, I just wanted to verify that this currently how discord is sending events

opaque vessel
#

I don't really know how ddevs and that all works (not in there), but you should probably ask in there. If you don't want to, I can get an answer for you during working hours

dawn merlin
#

i'll just make an issue ticket on the dapi-docs github, someone from ddevs will probably answer

golden mortar
#

here's what attachments is ```js
attachments: [ { id: '0', description: undefined } ],

visual hornet
#

aren't you supposed to use files to send them initially
and attachments is mainly for editing?

golden mortar
#

no clue, these were just added as the result of a rebase

#

removing those lines makes everything work fine once again

visual hornet
#

still have no idea what attachments are really for :/

golden mortar
#

neither do I but i'm wondering if that's a bug, extraneous code that can be removed, or if i need to implement a fix on my pr

ruby terrace
#

the naming scheme is kinda weird, files is the array that is processed into the attachments array, the attachments array in MessagePayload is the thing actually processed into formdata.
There is also the attachments key in Messages, which is JSON data and completely separate.

golden mortar
#

so any reason sending the attachments array would cause a 400 status from discord's side?

#

i have no idea how to fix the issue i'm having minus just removing that section of code linked above

#

the exact error:

DiscordAPIError: Invalid Form Body
attachments[0]: Attachment data not found

code 50035

ruby terrace
#
- if (file?.file) body.append(file.key ?? `files[${index}]`, file.file, file.name);
+ if (file?.file) body.append(file.key ?? file.name ?? `files[${index}]`, file.file, file.name);

You made this change to the formdata appending, which I believe causes that error. Take a look at the new attachment uploading stuff in the api docs, seems that was missed in the rebase

golden mortar
#

that fixed it! but that brings up a second question:

the issue is that file.name wasn't und/null so the name would default to that.. but if file.key was a valid name, wouldn't it throw an error there as well?

ruby terrace
#

the key is used for stickers only, because the formData key needs to be "file" for that

#

the stickers endpoint uses formdata but is more json styled

golden mortar
#

interesting 🙂 thanks for the insight & the help

ruby terrace
#

np, its all kinda confusing, I wouldn't know about that stickers stuff if I hadn't just implemented that in /rest

visual hornet
#

(unrelated to the current discussion)
i think im doing something wrong with testing
i only added a require and changed discordSort, but when testing im getting Util.setPosition and Util.idToBinary not being functions, logging Util gives an empty object
i tried requiring the index through a filepath, and also by npm pack then npm i, and they're yielding the same results

copper laurel
#

requiring the index where?

visual hornet
#

in testing code, i just did require('../../discord.js/src/index.js')

#

well actually it was esm that i already had from earlier

copper laurel
#

circular requiring index is generally very very bad, any chance thats happening?

visual hornet
#

oh it wasn't inside djs

#

i had a test file inside a different project in the same directory

flint zephyr
#

Is there any package that can perform automated tests for bots using slash commands?

#

pls ping if answering

visual hornet
#

this isn't really a question for this channel, you can just write tests yourself

burnt cradle
#

@tacit crypt has there been any discussion/decision on the issue of replacing ow in builders? Sorry for the bump but esm support being broken feels kinda high priority

tacit crypt
#

ow, my validation...

fiery shore
#

Discord.js seems to lack some API fields according to the Discord API Documentation here:
https://discord.com/developers/docs/interactions/application-commands#application-command-object-application-command-option-structure
The attributes min_value and max_value is not present in the type ApplicationCommandOptionChoice and also not set in transformOption().
See:
https://discord.js.org/#/docs/main/stable/typedef/ApplicationCommandOptionData
https://github.com/discordjs/discord.js/blob/stable/src/structures/ApplicationCommand.js#L330

#

I see that an PR is being merged 4 days ago. Let me use the github master version then

opaque vessel
#

It's just not in stable

real jetty
#

Because of the way dynamic works, shouldn't gif be excluded from the format type here as it'll already use gif when possible if you specify the dynamic flag?

dawn merlin
#

Possibly, but iirc providing both isn’t technically incorrect

opaque vessel
#

What if you don't know if the user has an animated avatar icon? Providing your desired format there is a fallback

#

Feels like the default for dynamic should be true

outer raven
#

the defaults for images should be changed a bit imo

#

but yeah it's a bit risky to provide a gif format

copper laurel
#

Im pretty sure the defaults we have now exist for a good reason, this discussion comes up every so often

opaque vessel
#

It feels a bit odd imo to specify a dynamic property to get the actual avatar icon that is being used by the user in the right format... wouldn't it be more desirable to replace that with a static property where you decide whether you want to receive their URL in a non-animated format?

So { static: false, format: "jpg" } would get the .gif and fallback to .jpg if it's not animated
{ static: true, format: "jpg" } would get the .jpg always

I'm not sure where this can falter tbh

copper laurel
#

And whats the default, static: false?

#

I just dont really see what benefit this has over setting a format, and a property which will override that for animated avatars

opaque vessel
#

Yep yep, static: false is the default. If anything, this seems more like a helper property by discord.js shrugs

#

If you think about it, fetching the avatar's hash will return it in a format starting with a_ if it's animated. discord.js converts every image received to static by default, though that's not necessarily what should be happening? It should be returned as-is, and the user can specify if they want to enforce the image to be static

copper laurel
#

Not exactly? The default format is webp

opaque vessel
#

The animated file format Discord uses is .gif

#

At least in the client

copper laurel
opaque vessel
#

Yeah but currently, you have to specify if you want it to be dynamic

copper laurel
#

Yes I know

opaque vessel
#

Sorry didn't see the code block with the huge thing being collapsed x_X but yes!

#

Tbh at that point the property becomes useless, if you want a static image, just supply "png" or "jpg" or something

copper laurel
#

uhh.... no? Because it will default to gif?

opaque vessel
#

Can you elaborate

copper laurel
#

Supplying "png" would be for deciding the format if it is not animated

#

Unless you also provided static: true

#

Or the reverse with dynamic: supply "png" to always get a png, or supply "dynamic: true" to get a gif if its animated

opaque vessel
#

What I'm saying is that if we flip the logic to ensure all the URLs made are dynamic by default, you wouldn't need the static property. Since all animated avatars on Discord are of a .gif format, then the other formats .webp, .png, .jpg and .jpeg are all for static images so... they would never attach themselves onto animated avatars

#

Supplying one of them implies you want them to be static

copper laurel
#

No it doesnt

#

That's breaking the existing functionality of being able to specify the static image format while also resolving an animated one if applicable

#

Currently:
() - webp
({ dynamic: true }) - gif > webp
({ dynamic: true, format: "png" }) - gif > png
({ format: "png" }) - always png

With your proposed static: false default:
() - gif > webp
({ static: true }) - webp
({ format: "png" }) - gif > png
({ static: true, format: "png" }) - always png

If you remove static/dynamic entirely, you lose that gif > png use case

#

The fallback scenario is gone

opaque vessel
#

I got you yeah just at the last moment, thank you for being concise there haha

copper laurel
#

Otherwise the change is literally just swapping the logic on the first two outputs

opaque vessel
#

Yeah exactly, I'm pretty sure everyone everywhere is favouring always using dynamic: true, so... we should probably change that

copper laurel
#

Not true, I dont

opaque vessel
#

Well, mostly, at least, but the logic I follow is if the user object logs the avatar's hash as "a_..." and you run .avatarURL(), one new user would likely think they're going to receive the animated avatar

#

Uh anyway... I guess that's a change for version 14?

copper laurel
#

Would definitely be breaking yes

opaque vessel
#

Cool, alright, thank you for this lil' conversation (':

outer raven
#

On that note, I believe there’s no good reason to use webp as the default is there? Discord doesn’t have a default, the client used png and webp doesn’t even support transparency

outer raven
#

It does not

#

If you try to set something’s icon or avatar to a webp image it loses the transparency, I’ve tried it

dawn merlin
#

Well the format does dunno why it doesn’t work for discord

outer raven
#

¯_(ツ)_/¯ but supplying png for that works as intended

#

So maybe that default could also be changed for v14?

#

Actually now that I look into it, webp is supposed to provide quality images with less size but it’s made mostly for browsers, and djs doesn’t work on a browser, so maybe that was forgotten when that was removed ¯_(ツ)_/¯

outer raven
#

Using discord.js’s methods

#

So for example guild.setIcon(client.user.avatarURL())

dawn merlin
#

the client gui doesn't even allow you to upload webp

tacit crypt
#

If discord cannot process webp's that's an issue on their end not ours

#

Also the client uses webp whenever possible

#

If a platform doesn't support it, then it defaults to png

wild flax
#

You cropped it with discords internal crop tool, which gets rid of any transparency

#

As for our methods, the problem exists most likely with their image microservice

outer raven
copper laurel
outer raven
#

Because the client is based on web so it needs smaller images, but if webp doesn’t work properly with djs I don’t think we should use it right?

tacit crypt
#

You do realize that it's not discord.js's fault that Discord's media whatever the hell it's called breaks webp transparency, right?

#

And also, we already default to jpegs for uploads

#

if you send discord a webp image thats on you

#

I don't see why we should change internals for this

#

Maybe we have a bug that we send the image wrong to discord when using an URL

outer raven
#

My point is that if you don’t specify a format, discord.js sends webp which then breaks the image. I understand this may not be the library’s fault, but it’s something that can be fixed by changing the default, and then if the user decides to specify webp it’s their own fault

wild flax
#

in this case it is the libs fault because of what vlad said

#

we just assume its a certain extension

#

which could potentially mean gifs break too, except if we check only for gifs

outer raven
#

But where’s the code that’s defaulting to jpeg?

remote wasp
#

@outer raven the regex you gave for INVITES_PATTERN doesn't work for events, need some help with Client#fetchInvite

outer raven
#

which PR? I don't remember touching that one 😅

outer raven
#

I remember that now

#

not sure if you agree but I feel like it would make sense for an event not to match with the invites pattern

#

so that regex does work for events only (not sure if the https should be matched or not)

remote wasp
#

Client#fetchInvite uses that pattern to resolve the invite code, so we need something that matches event's link too

outer raven
#

clicking an event link does make you join the server, so I guess you can leave the invites pattern unchanged, but that method could be interesting if there is an endpoint for that (not sure, haven't really looked at the documentation properly)

#

actually, since you wanna capture the event ID and not the invite id, lemme update that comment

lofty birch
outer raven
#

oh really?

#

what are those snowflakes

lofty birch
#

android client share does at least, and I'm not entirely sure

#

one of them is obviously the event ID

#

oh guild ID and event ID

outer raven
#

yeah that makes sense

#

but that doesn't render

#

oh but it does work

lofty birch
#

yeah it's weird

#

you only get it from Android afaik

outer raven
#

on iOS I get missing permissions Thonk

remote wasp
#

Now, the issue is that how to add a way to let users pass an event id to Client#fetchInvite without a breaking change, because it only takes invite resolvable as argument

outer raven
#

well make it a second arg

#

but it's really annoying that you cannot resolve an event from an invite, maybe we could add the method and warn users that it would make 2 api calls?

#

that's gonna be controversial though since every other method in djs uses 1 unless given certain options

outer raven
lofty birch
#

that's weird

#

anyways, I just wanted to point it out because I've seen that form a few times

outer raven
#

honestly not sure what to do with it

tacit crypt
remote wasp
#

yup, that's what I decided too. Had to go with ClientFetchInviteOptions because FetchInviteOptions is taken. Could change that to FetchGuildInviteOptions in v14 👀

visual hornet
pure flare
wild flax
#

Yes, Ill be handling that in a few days time

#

Thank you for figuring that chain of deps out and making it to the source to get it fixed 🙏

pure flare
#

Ok cool, and then @discordjs/opus will also need to be updated downstream. Thanks.

#

Lol i've been chasing it all the way down from the top.

#

also prism-media will need to start referencing whatever updated version of @discordjs/opus that integrates the fix but i'll bug them about it once that happens

oak quail
analog oyster
#

that was not the point. the point is that the link that is copied on android is different than the one on the other platforms

lethal frost
#

Has there been chat about creating a general .send() method on interactions that will send a message no matter if a reply was already sent (by calling .followUp()) or deferred (by calling .editReply())?

analog oyster
outer raven
#

Apparently I was the only one who disliked that but the issue was closed, so I'm not sure what that means
Usually djs doesn't like utility methods that have other workarounds iirc, but it's a matter of opening a PR and seeing the feedback ig

opaque vessel
#

Personally also don't want it tbh

#

Monbrey's comment in there is what I like

dawn merlin
#

Yeah it's an abstraction that is misleading

copper laurel
#

Crawl never really agreed to it, looks like it was summarised by my comment

#

None of the reactions on the initial post are from maintainers

outer raven
#

Crawl did disagree to my comment, along with 6 other people

#

not sure why

#

but yeah I assumed it wasn't something ppl wanted

golden mortar
#

Usually djs doesn't like utility methods that have other workarounds iirc, but it's a matter of opening a PR and seeing the feedback ig
I've got a question regarding this since it's true to my knowledge: why does the lib include Formatters? It simply exports some functions from builders but they're not used in the code whatsoever. Plus it adds 12 11 dependencies to the main lib

opaque vessel
#

Hi @dawn merlin - thank you for letting me know about deprecated usage of ThreadMemberManager#fetch() <:

Looking at it closely, how come the second parameter is an object and not the first? If one wanted to fetch all members in a thread but not cache them, the method would have to be called as fetch(undefined, { cache: false }). Why not fetch({ cache: false })? I may have missed something x:

dawn merlin
opaque vessel
#

Sorry, I don't follow. Before this commit, there was no Snowflake type?

dawn merlin
#

oh sorry it was a boolean before

opaque vessel
#

Ya! Exactly haha

#

So imo, I thought it would be better if a boolean was passed, it would be internally converted to { member: undefined, cache: boolean, force: false }

dawn merlin
#

yeah I think that's what it's doing

The member to fetch. If undefined, all members

  • in the thread are fetched, and will be cached based on options.cache. If boolean, this serves
  • the purpose of options.cache.
#

So ig maybe a deprecation warning isn't needed

opaque vessel
#

You're willing to keep the boolean property?

#

That does look like it'll also solve the issue

#

So I guess, either make a change to keep the boolean property, or convert the first parameter into an object shrugs

dawn merlin
#

oh I'm caching on, you're saying have one property that's boolean|object?

#

catching*

opaque vessel
#

Ya ya

#

Or just object alone at that point maybe, up to you

dawn merlin
#

well for v14 just an object but to prevent breaking changes im pretty sure it needs to be a union

opaque vessel
#

Ya

dawn merlin
#

honestly if you don't mind it can probably be an addendum to your PR, but if you'd rather not I can make a PR

opaque vessel
#

Would you pretty please mind making one <3

dawn merlin
#

for sure (as in I wouldn't mind)

opaque vessel
#

(:

dawn merlin
#

is there a way to destructure and have a named parameter on a function? ie:

function foo(options { a, b })
visual hornet
#

for the same parameter? i don't think so
but you could just destructure out afterwards since you'd need to check for the boolean first

dawn merlin
#

yeahhhh, I also have to deal with default values as well but I think thats the only way

visual hornet
#

i think the default value should be fine, since it would only trigger if neither the object nor the boolean were given

dawn merlin
#

oh wait I just realized you can get the first argument via arguments[0]

visual hornet
#

this will be changed with a breaking change in v14, right

dawn merlin
#

yeah

wild flax
#

It’s a metric that is rather bad to go by. You obviously shouldn’t add all kinds of junk, but at some point it gets rather silly

golden mortar
#

I agree in some cases but adding 11 deps just so people can import formatters from discord.js and not builders is rather strange imo

#

especially since in v13 dev a bunch of old methods that weren't used in the codebase got removed as well

#

just wondering what benefit having Formatters in the lib gives over importing djs builders instead?

vernal atlas
analog oyster
#

in that case options will not have the a and b fields

#

the best you can get is ```ts
function foo(options) {
const { a, b } = options;
}

vernal atlas
#

i mean yes but thats just kind of silly IMO, at least for making a function in djs

dawn merlin
#

@copper laurel ban

copper laurel
#

what

dawn merlin
#

There was a nitro scam someone deleted it

dawn merlin
#

@opaque vessel looks like I need to improve those type guards 😅

opaque vessel
#

Is this regarding issue #7001? o,o

dawn merlin
#

Yeah

opaque vessel
#

Sweeping the channel manager isn't actually supported so... dunno if you want to do that shrugs

dawn merlin
#

Hmm it isn’t? I thought sweeping any cache was valid

#

Ik extending caches isn’t supported

opaque vessel
dawn merlin
#

oh yeah I'm just being dumb, I literally said extending isn't supported, but thats the only way to change the sweep settings anyways.

#

I could've sworn it throws if you do that, so im not sure how the person in 7001 got around that

#

oh it just emits a warning...

loud jayBOT
visual hornet
#

could i request for someone to check if putting those changes in breaks Util in the same way mine did?

loud jayBOT
worthy coral
#

For CommandInteractionOptionResolver#getChannel, where does the Option.channel come from? Discord does not list this as a valid property from Application Command Interaction Data Option.
From what I can see, minimal transforming is done, but I've only looked at the AutocompleteInteraction#transformOption

worthy coral
copper laurel
#

Im not sure what you think the problem is here?

worthy coral
#

I got really confused because the signature didn't have a resolved param, but it will still being passed anyways. Type safety is the issue

copper laurel
#

The autocomplete interaction doesn't, so it is useless here

#

But autocomplete is only for string types anyway

#

Its a JS library there is no type safety lmao

#

This is the full one

worthy coral
#

Trying to fix that amandabox

copper laurel
#

So yeah, it probably shouldnt pass resolved in the autocomplete interaction

worthy coral
#

That was my problem because my brain is melting trying to make things type safe

#

sorry for confusion

rustic boughBOT
#

Documentation suggestion for @dusk loom:
<:_:874569322742308864> Interaction#type
The interaction's type

outer raven
#

you mean this?

#

but that does exactly the same as the typeguards, except without type safety. If that's not it then I'm not sure what you're looking for

#

determining if it's a select menu, button, command or context menu requires 2 checks, which are done by the typeguards, so why not just use those?

#

the only alternative to the typeguards is doing the checks they run yourself, which is less clean imo. There are all sorts of typeguards both for specific interaction types and more generalist ones so idk why you can't just use those

#

and by that I mean isApplicationCommand and isCommand for example

copper laurel
#

Yeah I really don't understand this question. It's the "how do I do <thing> without doing <correct existing way to do thing>"

#

What's wrong with the methods

tender surge
#
- public on<K extends keyof ClientEvents>(event: K, listener: (...args: ClientEvents[K]) => Awaitable<void>): this;
+ public on<K extends keyof ClientEvents>(event: K, listener: (...args: ClientEvents[K]) => Awaitable<unknown>): this;
```Do you think this would be possible?
real jetty
dawn merlin
tender surge
outer raven
#

Yeah in the end it doesn’t really matter what the listener returns, so I’d say any would be fine too

tender surge
#
export function createEvent<T extends keyof ClientEvents>(
  cb: (
    ...args: [...args: ClientEvents[T], prisma: PrismaClient]
  ) => Awaitable<void>
) {
  return cb
}

export default createEvent<"messageCreate">(async (message, prisma) => {
  if (x) {
    return message.channel.send(...) // Promise<Message> not assignable to void
  }
})
```If you do change to unknown in your handler, you can't dynamically pass it to client.on
burnt cradle
#

just return on the line after the send

outer raven
#

Yeah but that makes the code unnecessarily more bulky when it doesn’t make a difference if you return a message

tender surge
#

any is fine too

vernal atlas
#

return void await x
return void x

real jetty
vernal atlas
#

yeah, i was just suggesting an alternative soloution to their problem, at least until if/when its changed

dawn merlin
#

if you make the return type a promise of unknown it's misleading because it implies that return value is used somewhere else which it isn't

tender surge
#

What about any? Or a type alias that represents something with the value of any

#

It just adds extra noise atm, especially with

padding-line-between-statements:
  [error, { blankLine: "always", prev: "*", next: "return" }]
```I get it's my issue but the return type doesn't matter
dawn merlin
dawn merlin
tender surge
#

eslint rule to always add a new line before a return statement (separation of concerns preference)

dawn merlin
#

ig disable it then? lol

opaque vessel
#

What about passing a type parameter to specify the return type, or will that not work

dawn merlin
#

it would but I don't really see what justifies it?

opaque vessel
#

Shenanigans

tender surge
#

I think it would be nice to support as many JS patterns as possible, generic return type would be fine too

outer raven
#

I just don’t get the issue with having it return any

tender surge
#

For semantic reasons, but generic return type fixes that

outer raven
#

What would that generic type look like

tender surge
#

public on<TReturn = void, K extends keyof ClientEvents>(event: K, listener: (...args: ClientEvents[K]) => Awaitable<TReturn>): this;

outer raven
#

TReturn should probably come first so you can specify it easily

tender surge
#

True, edited

outer raven
#

Why not default it to any?

dawn merlin
#

My issue is that it enables code to be written with unclear intentions, it's unclear if the return value is consumed by the client or not. Also from a documentation standpoint when the return type is Promise<unknown> or Promise<any> it seems like you need to return something, and may confuse people.

zenith oracle
#

IMO, it's just confusing to add a return type of any/unknown as users may think that a value should be returned or that it can be used somewhere

dawn merlin
#

^

tender surge
#

I mean isn't Awaitable confusing for the exact same reason?

#

I read it as oh I can await this and it might return something

dawn merlin
#

No awaitable just means it can be await'd that doesn't imply anything is returning a value

tender surge
#

Could endlessly discuss those being different, anyway just something I faced today, I'll stick to ts-ignore

dawn merlin
#

or just put return on another line

outer raven
dawn merlin
#

It's confusing because any could be a value

outer raven
outer raven
dawn merlin
#

the return value doesn't matter because it's never used, when I see a return type of any I honestly assume something needs to be returned

tender surge
#

You can't tho..

zenith oracle
# zenith oracle IMO, it's just confusing to add a return type of any/unknown as users may think ...

I don't see a reason why it should be any/unknown too.
I mean, yeah, in a command handler having a return type of any would be more comfortable but also lead to unexpected issues, like we may return a string because we think that it'll be sent as a reply for example, so it's always a good practice to put your return statements outside any expression.
Also iirc the return type of that function in the built-in EventEmitter is void...

outer raven
dawn merlin
#

Doesn't matter it's still not as clear as void

#

void is always going to be more explicit and less of a gray area

tender surge
zenith oracle
#

Iirc it was changed to Awaitable because of an eslint rule that didn't allow the use of an async function in that case.
It's however really different from any/unknown

dawn merlin
#

it doesn't matter it's a callback, Promise<void> | void are void once resolved

tender surge
#

eslint didn't allow the use of async functions
ts doesn't allow me to return methods early while it's still technically valid, just like you're able to await

#

I honestly see both cases as supporting JS patterns, I do get where you're coming from

dawn merlin
outer raven
tender surge
#

Just a bit upsetting as most ts features that are being added are to be able to type JS patterns

#

Yea I know I can work around it

dawn merlin
#

honestly imo returning a value for a method that's supposed to return void isn't a great pattern anyways

tender surge
#

đŸ€·â€â™‚ïž

wild flax
#

its technically not correct, yes

#

since whatever you return, if its fails, is unhandled

#

so what we do is fine and correct

real jetty
#

Correct me if im wrong about this behavior but shouldn't this always be a guildmember because of the typeguard?

burnt cradle
#

try inCachedGuild instead of inGuild

real jetty
#

Yeah that did it, forgot about that one 😅

opaque vessel
#

inGuild() there refers to just a guild, whether it be cached or not yeah

real jetty
#

Is there a set in stone idea for what djs-modules/ws would be responsible for? Is it a general powerful websocket module that's capable at handling any url type, or one that's specific to discord only and can do all of the stuff that the current djs one can do?

outer raven
#

Are there any plans to move util functions to their own package like a @discordjs/util of sorts? Some of these functions are quite useful and people don't always need the full library to work with them

wild flax
#

like?

outer raven
#

That’s the one that sparked this idea, could look into the others too

solemn oyster
#

SnowflakeUtil is likely superseded by @sapphire/snowflake, which @discordjs/rest uses

wild flax
#

Yeah snowflake Util isn’t super useful honestly

crisp forum
#

is there a reason Shard#eval can't have a context passed into it? (like why wasnt that implemented)

outer raven
slate nacelle
crisp forum
#

ig so but i added it into the src of the pkg should i pr it?

slate nacelle
#

Gladly

outer raven
#

Can we get a way to specify the type of the components in an action row, through something like new MessageActionRow<"SELECT_MENU">() like was done for collectors?

#

cc @dawn merlin 👀

dawn merlin
outer raven
#

you might be able to mix component types in the future though, so that type could support multiple component types

dawn merlin
#

Because the array of rows isn’t guaranteed to have the same component types

outer raven
#

I'm talking about individual rows through

#

so in that case I wouldn't if I just created the action row with the type like we do with collectors

dawn merlin
#

But if you access the the row by index how it know the type? Because the array of rows is a less specific type

outer raven
#

idk about you but I never access a message's rows, I just store the row in a variable and modify it later on

#

and that's the use case I'm talking about, since you can't get more specific when accessing a message's components array (and perhaps you shouldn't)

visual hornet
#

what if the first component you add to a messageactionrow changes the class or something

dawn merlin
visual hornet
#

oh wait no that wouldn't work

outer raven
#

like this

#

and the idea was to do this

dawn merlin
#

So addcomps would only take select menu components?

visual hornet
#

could you maybe add a typeguard based on the type like how you do it with Interaction

outer raven
dawn merlin
#

Ok I see

visual hornet
#

...yeah.

i shouldn't be here

dawn merlin
dawn merlin
outer raven
dawn merlin
#

those both seem to work, I'm assuming by reset you mean setting the components to [] and splice should only take components of the correct type

outer raven
dawn merlin
outer raven
dawn merlin
#

oh wait I'm dumb, yeah it's doable

#

This works as expected

// @ts-expect-error
selectMenuRow.components = [new MessageButton()];
outer raven
#

ready for the PR? I'd be glad to test it

void rivet
#

wait can you send stickers with interaction.reply?
i didn't find it on the api docs but the typings for the method tells you you can since it extends BaseMessageOptions

outer raven
void rivet
#

you do it 🙃

outer raven
loud jayBOT
#

pr_open #7012 in discordjs/discord.js by ImRodry opened <t:1637436949:R> (review required)
types(WebhookMessageOptions): disallow stickers
đŸ“„ npm i ImRodry/discord.js#types-webhook-stickers

outer raven
#

@void rivet ^^

void rivet
#

👍

outer raven
#

In what scenarios can Invite#uses not be null? I already fetched an invite and I didn't get that data

slate nacelle
#

I'd assume when obtained through Client#fetchInvite.

outer raven
#

that's what I did though and didn't get the uses, same thing when looking at the raw data from the API

#

the uses property appears in an "invite metadata object" in the discord docs that is supposed to be extra info that may be present, but they don't mention when that can be present

vivid field
outer raven
#

oh so we only get that data when fetching the invite on the guild? PEWHmmmmZoom

#

I think the Invite class could use some improvements on its documentation to specify these quirks

vivid field
#

the docs are open source ¯_(ツ)_/¯

outer raven
#

I'll give it a shot with a PR, let's see how that goes

vernal adder
#

Audit log documentation needs some updating as well, seeing that the description of <GuildAuditLogsEntry> is literally just "Audit logs entry."

dawn merlin
outer raven
#

you could add the typeguard as well to make it work when you receive it too ig

dawn merlin
#

Hmm

real jetty
#

Why are API objects not exapanded upon? For instance i don't see why we couldn't provide support for APIMessage#edit() (you could get an api message when you followup an interaction)

#

I don't see the purpose of just dumping the api obj on them when we're supposed to be wrapping around said api object

dawn merlin
# real jetty Why are API objects not exapanded upon? For instance i don't see why we couldn't...

Api objects are usually returned when you’re client isn’t a bot in the guild. The api* objects are just the raw data returned from the api. The reason we don’t wrap them in a class is because the cache cannot be properly updated because it doesn’t receive guild events. In fact in the case of the message, you can’t edit a message purely based on the message recieved it needs to be done via the interaction (since the bot isn’t present in the guild)

outer raven
#

But yeah if it’s an interaction you should be using the interaction methods instead

peak mauve
#

discord.js\src\util\Util.js:413

if (typeof data !== 'string') throw new error(errorMessage);```

Couldn't the data be tried to convert to a string first?

#

interaction.reply(client.ws.ping) will crash the process because it is a number

outer raven
peak mauve
#

oh yeah I remember this working in previous versions

visual hornet
#

Are we still doing consistency with the api with types?
message type 20 is listed as CHAT_INPUT_COMMAND in the api docs, but it's APPLICATION_COMMAND in djs, which i guess could be somewhat confusing since CONTEXT_MENU_COMMAND is a seperate type, type 23

outer raven
#

something for v14

visual hornet
#

didn't see any issue/pr for it
i guess this would need some type updates, which i don't know how to do, so... unless someone's free to do it, i'll make an issue in a bit

outer raven
#

all you gotta do is change the value in constants

#

and then change the typings accordingly

#

but it's a semver major so ¯_(ツ)_/¯

visual hornet
#

eh it could be left for later

outer raven
#

constants line 428

#

I could make the PR rn

visual hornet
#

go ahead

outer raven
copper laurel
#

client.users.cache.size has only ever been cached users

#

Never ever has this property been populated with all users in all your bots guilds

#

Fetching all members is absolutely not recommended at all

#

Please go back to support, this is not a library discussion issue

outer magnet
#

@copper laurel

copper laurel
#

ty

arctic pebble
#

Hello

#

About the presence update

#

I think game activity presence should be separated

wild flax
#

No idea what you are asking

arctic pebble
#

to know if there is a game u a member is playing

#

coz when i use presenceupdate

#

while playing a game then i have set a custom status or some other activity like listening to spotfy, it will give my undefined or the latest activity for that

void rivet
arctic pebble
#

I have this bot that gives role when a member is playing then remove the role when he is not, then when he have set a custom status then removed it, it will remove the playing role coz, i get an undefined precense activity

#

but he is still playing

#

So the playing role shouldn't get removed to him

void rivet
#

so what do you suggest we do?

arctic pebble
#

i don't know if the issue is from the presence update or my code

void rivet
#

i guess your code
members can have multiple activities, right? your code probably wasn't made to deal with that

arctic pebble
#

but would it be possible to retain the array no. from the oldpresence to newpresence

ornate topaz
#

you do know that you can just see what an activity is, and then check any other one that is present? it doesn't end on [0] or [1]

#

you have multiple tools in javascript to do that

void rivet
#

you can find it by it's type, which for you would be playing

arctic pebble
ornate topaz
#

then don't do that.

arctic pebble
void rivet
#

yeah it's not really an issue with the library, it is your code
how you dealt with presenceUpdate

arctic pebble
#

I just compre new from old

#

Thanks @void rivet I now have an idea

sonic condor
#

Why does MessageEmbed has .video property if you can not embed a video?

unique axle
#

received embeds can have them, you can just not send them from bots

#

hence why there is access to it but no means to set it

smoky dawn
#

Is there a specific reason to why the Client constructor doesn't default to no intents?
Like, this just seems like unnecessary:

const client = new Client({
    intents: []
})

I'd much rather just do this:

const client = new Client()
tacit crypt
#

Because intents are mandatory

smoky dawn
#

So basically because people NEED to know they aren't enabling any intents?

tacit crypt
#

Because people NEED to provide intents to connect*
EDIT: They need to specify that they either want no intents or some intents so users know about them

smoky dawn
#

You don't need any intents to run the bot, though?

tacit crypt
#

I don't know if Discord lets you connect if you specify intents 0, but our lib does require at least GUILDS intent to work most of the time (iirc with interactions that's less the case)

opaque vessel
#

The fine line here is omitting the intents and providing no intents. You should explicitly specify your intents and discord.js shouldn't shortcut it

tacit crypt
#

TIL (and it makes sense I suppose)

#

for the sake of explicity, we make intents mandatory

smoky dawn
#

Alright, thanks guys.
This is probably better for the majority, as they wouldn't understand why is working, before realizing they were missing intents.

#

Glad to clear up, that it was done for a reason.

limpid oxide
#

isnt it supposed to be true by the default?

tacit crypt
#

More of a #djs-help-v14 question but since you're providing allowedMentions in your client thats what we use when it's missing from your reply calls

outer raven
tacit crypt
#

thats more of an API question but no, it shouldn't, because if you specify allowed_mentions at all Discord just disables it by default

outer raven
#

Ah I see

slate nacelle
#

That's some weird behavior on Discord's end.

outer raven
#

Probs an API bug then

tacit crypt
#

Tho maybe I'm wrong, citation needed

#

But I'm fairly certain thats how it is

slate nacelle
#

I think if you do not send allowed_mentions, all mentions are parsed (and replied user is true), but if you specify it, replied user defaults to false.

tacit crypt
#

I wouldn't say its an API bug but an annoyance personally

outer raven
#

but probably not worth the bug report

tender field
outer raven
tender field
#

sure sure do it when you have time! no worries

#

thanks for your help (in dms)

oak quail
outer raven
oak quail
#

well it was discussed with multiple staff back then

outer raven
#

Ah alright

#

Questionable but sure

median hazel
#

i dont know if this is the right place to ask but do we know if we will be able to insert any of the current message components into the new modal feature coming?

visual hornet
#

modal feature..?

oak quail
median hazel
oak quail
#

api-questions would be the best for now

limpid oxide
wild flax
#

nope

vivid field
#

if you pass no allowedMentions then the default is true

#

only if you do pass them you overwrite that default

limpid oxide
#

ah i see

oak quail
#

its actually marked as default false in discord's docs (which was confirmed in the discussion with staff), because it is in the object

#

it doesnt exist at all if the object doesn't exist

#

and d.js doesnt seem to modify it so... shouldnt it be the same as Discord and say false?

slate nacelle
#

allowed mentions itself is optional too and that missing defaults too "all mentions"

#

At least that's my explanation

outer raven
#

Should default to Discord’s default but they should enable repliedUser since that’s the default on the client

oak quail
#

the client doesnt send allowed mentions by default

outer raven
#

That’s what I’m saying

copper laurel
#

Its really not as complicated as this discussion would suggest
allowed_mentions not provided - all mentions are enabled, including replied_user
allowed_mentions is provided - only those mentions listed are enabled, which mean replied_user only if provided

#

Theres no reason to think of it as some separate default, its just an allowed_mentions property

#

Discussing the fact that the desktop client has a toggle in a default state is irrelevant, this is the bot API, not a desktop client

copper laurel
#

This seems more like support than a discussion for this channel

outer raven
sage frigate
copper laurel
#

At least, not in djs

outer raven
#

Thought this worked before but yeah you're right. That's quite annoying but I can see it's not something looking to be improved on

copper laurel
#

I dunno, I think the design is fine. parse is mutually exclusive to the arrays. You can:

  • parse all users and/or roles and/or everyone
  • array of users and parse all roles
  • array of roles and parse all users
  • array of roles/users

And add replied_user to any of the above

outer raven
#

yeah but if you don't specify any of those values, they should use the default that is used when the object isn't passed at all

#

so allowedMentions with a roles array and nothing else, repliedUser would be true for example

#

because I think that's what the average user would assume would happen

#

and the current behavior is also inconsistent with the docs, which say repliedUser defaults to true

copper laurel
#

Eh, I disagree that they would or should assume it, thats their fault for making assumptions

#

I do agree on the docs though, its just annoying to accurate represent both

wild flax
#

You overwrite the default, so the default doesn't apply anymore

#

I don't understand how that concept is so hard to grasp

copper laurel
#

I dont think it should be marked as defaulting to true though, since doesnt that imply the code sets it to true if not provided?

outer raven
wild flax
#

Yes you do

copper laurel
#

You're making the same mistake I originally called out

wild flax
#

We don't merge with our defaults

copper laurel
#

Stop thinking it has a separate default to allowed_mentions

#

It does not

wild flax
#

If you pass ANYTHING into allowedMentions it will overwrite our default

copper laurel
#

If you change allowed_mentions you have overriden the default

#

There are no sublevels

wild flax
#

lets say you do:

allowedMentions: { parse: ['users'] } }

now that means our default which includes repliedUser will be overwritten with JUST what is above

#

so if you wanted repliedUser to still be true, you have to manually include it

copper laurel
#

So having said that, shouldnt the docs specify the default as none rather than true, because we do NOT default that property if not provided

wild flax
#

we do default it, just not merge it

#

its a different discussion

copper laurel
#

I cant find where we do

outer raven
#

but it would be really easy to apply these defaults by deconstructing the object. I was trying to test it but idk where this is parsed if it is at all

copper laurel
#

But we dont want to because Discord doesnt

outer raven
#

we can do things that Discord doesn't tho

copper laurel
#

I cant find anywhere that we actually set a default for allowedMentions or repliedUser

outer raven
#

yeah me neither

copper laurel
outer raven
#

aight ig ¯_(ツ)_/¯

wild flax
#

Ah, its on the message options for it

#

Well the problem with that is that it probably used to be the behaviour when that PR was made

#

and it was documented as a discord default

#

Which is something we indeed usually don't do

copper laurel
#

Probably yeah

#

Where as now, at no point do we apply a function default parameter for that, so it should probably have the default removed from the JSdoc too

#

Because I do read that as implying that if repliedUser is not supplied in allowedMentions, discord.js sets it to true

#

(and we dont)

outer raven
copper laurel
#

Well in case I havent been clear, I do not think we should have a different default behaviour to Discord

outer raven
#

I believe it wouldn't be the first time we fix little quirks of the discord API to make them more logical

#

of course this "logical" is very subjective, but I think it's what the users would assume the default behavior to be

#

default being not passing the parameter, regardless of the object being passed

#

because whether you pass allowedMentions or not, the properties you don't specify are set to undefined, which should always be replaced by a default value

wild flax
#

Its a bit scary defaulting to discords defaults

#

Since they could change, and preferably we want to too, but thatd require a new major

outer raven
# wild flax Its a bit scary defaulting to discords defaults

well in this case we'd be defaulting to a default that isn't always used and if it does change we can handle that in a semver major, without the behavior simply changing without any version bumps (although this is unusual, discord usually doesn't ship a lot of breaking changes without version bumps)

#

so if we set defaults on the library's side, we can change those defaults without relying on what Discord does, and follow semver properly

solemn oyster
#

@visual hornet have you tried moving the require to below module.exports?

#

At the very bottom

visual hornet
#

which require? the GuildChannel one i added in Util?

solemn oyster
#

Yeah

visual hornet
#

yeah that.. solved it...
what changed here?

solemn oyster
#

CommonJS considers a module "loaded" when at least one export or when module.exports is defined, so by moving the import to the bottom, you're requiring that file from a loaded module, so when it's required back, it works as intended

visual hornet
#

hm i see it's also used in TextBasedChannel with a comment, I'll copy that comment and commit that
thanks

cursive cradle
#

Is there any reason why UserManager#send doesn't exist so you can send a message to a user without fetching them first?

#

I noticed MessageManager#delete where you can delete a message without fetching it so I feel like UserManager#send would also be rly useful

solemn oyster
#

Can probably be done

analog oyster
#

how will you get the dm channel?

opaque vessel
#

That's not relevant, when one is created it'll return the existing item

analog oyster
#

let me rephrase: how will you achieve that in a single request

opaque vessel
#

Don't believe you can

cursive cradle
#

Oh, I didn't realize that :( nvm

analog oyster
#

I guess the current User#send method already does 2 requests if the dm channel isn't cached

opaque vessel
#

Yea that's right, so you'll essentially be doing nothing under-the-hood, just refactoring

#

Anyway on that topic, I suppose you can move .createDM() and .deleteDM() there

cursive cradle
outer raven
#

there are a lot of methods that could be moved to managers honestly

#

just like the message manager has

#

I tried to do some of those at some point but there were just too many

#

so that'd be a good way to start

cursive cradle
#

I feel like there aren't too many methods that couldn't be moved to managers

outer raven
#

Just out of curiosity, what’s blocking the GuildScheduledEvent PR and the release of 13.4?

dawn merlin
outer raven
#

I really hope that’s not the case cuz I think a lot of people, including me, could use it on a dev release at least :/

#

But it’s the first time I ask about this PR

dawn merlin
#

I don’t make the rules shrug

outer raven
#

Yeah ik, just saying it would be nice

solemn oyster
dawn merlin
#

@outer raven are you looking for to do a PR?

outer raven
dawn merlin
outer raven
outer raven
#

I have no clue how that works tbf

#

What I was thinking was the PR to add methods to managers

dawn merlin
dawn merlin
burnt cradle
#

You might want to wait on any major builders prs until after the validation lib gets changed so you won't have to rewrite ur pr halfway thru

dawn merlin
#

This is tru

burnt cradle
#

Also adding the new components would be bigger than you think cuz there's currently no component infrastructure so you'd have to write it completely from scratch

outer raven
# dawn merlin Which methods?

A lot of methods that are currently handled by classes and not in managers, similarly to the guildmember and message managers. I don’t know which can be moved which is why I gotta look into it better, but there were some ideas above about dms for example

solemn oyster
#

rn there's a critical bugfix PR pending for review, among a few more

outer raven
#

I saw the dapi types pr was merged which I thought was the only blocker

solemn oyster
#

Yes, Rodry. Check the list of pull requests, and you'll see

outer raven
solemn oyster
#

It's not related to scheduled events

tacit crypt
outer raven
tacit crypt
#

Let's see..

CI not passing
Reviews still pending
Decisions still to be made

#

So the PR is still WIP?

outer raven
#

CI isn't passing because -types wasn't released simply, but I thought everything else was good since no other changes were requested?

dawn merlin
#

Don’t these blocks contradict each other?

ornate topaz
#

no

unique axle
#

if you go camel it overrides snake, that's all that second one says, right?

ornate topaz
#

first one says that you can use snake_case, the second that if you pass camelCase, it overrides snake_case

dawn merlin
#

Ah I see

outer raven
#

@dawn merlin since you’re gonna remove MessageActionRow in v14 I suggested removing the external link from that file and keeping it on the new one instead

#

Think you got confused there

#

So that when that pr does come it’s as simple as deleting the file without worrying about missing links

dawn merlin
#

ok

dawn merlin
#

@outer raven can you explain what the event status type checking would look like?

outer raven
outer raven
#

Would it be possible to create a Message#awaitEmbeds method that waits for URL embeds to resolve and returns them? Could be useful in the messageCreate event since these don't have embeds when they are sent but they appear a few seconds later

tacit crypt
#

I mean you'd need to:

  • check the flags, in the event that embeds are suppressed
  • parse the content to see possible urls that aren't escaped and assume they'll embed
  • take into account that you may never get embeds to begin with
    I can see a use case for wanting this don't get me wrong, but there's gotta be a lot of factors considered when/if implementing it :D
#

I guess point 2 and 3 can be substituted into a timeout

outer raven
#

and yeah you'd need to check for regexes and then listen for the messageUpdate event

tacit crypt
#

Are you sure you cannot create a message with the flag pre-set? And I'm talking bot made not client made

outer raven
#

let me test that

tacit crypt
outer raven
#

what about the intent? You'd need to have it to even receive the message to begin with right?

tacit crypt
#

Well yeah except for messages pinging the bot/dming the bot

outer raven
#

yeah so you'd always have access to the content if you're doing this

outer raven
#

tried to post a message with this and the flag didn't go through so yeah I don't think you can suppress embeds when you create a message

#

I'm gonna look into how collectors are done and see if I can replicate that but I'm not sure if I can pull it off

ruby terrace
outer raven
ruby terrace
#

you do get everything in those cases

outer raven
#

well then in other cases you don't get the message at all do you

ruby terrace
#

yes you do

#

its the message content intent, not the message intent

outer raven
#

ah I see...

#

so we'd have to check for client intents too

ruby terrace
#

I'm not sure if message content intent is going to be like current intents, it might only be a flag, we don't know yet

outer raven
ruby terrace
#

that's not what I'm saying, the "intent" (because its starting as privileged), may not be toggleable via the identify payload

outer raven
#

I think they would've mentioned it by now if that was the case

ruby terrace
#

there's nothing documented about it at all, wdym

outer raven
ruby terrace
#

the flags are public, no new intents have bee documented

#

and the flags aren't documented either

oak quail
#

its prob intent 1 << 15

#

iirc they said itll be in identify

ruby terrace
#

I haven't seen that, but if they said that then yes, you'd need to check that rodry

oak quail
#

if u meant the application flags

#

my pr got merged 26d ago

ruby terrace
#

oh, yeah...I forgot that was already merged ~~used to things like that taking 4 months to get merged mmlol ~~

oak quail
#

lol

outer raven
ruby terrace
#

Like I already said, those are completely separate

#

you want message events? use those, you want the content in those messages? use the new one too

oak quail
#

yeah, those control the events

outer raven
#

oh I see

oak quail
#

message_content controls the object fields

#

without msg content, you'll still know messages are being sent and everything

#

just not the content

#

like those memes people made

outer raven
#

so bots that don't need to be whitelisted will need to add that new intent anyway?

oak quail
oak quail
outer raven
ruby terrace
#

and yes, that'll be a breaking change

outer raven
tender field
#

out of curiosity, why is Guild#toJSON() are most toJSON methods typed as unknown?

outer raven
tacit crypt
#

My answer is no, idk about the others thoughts

outer raven
tacit crypt
#

And what do we do in the event Discord adds 4 more eventMetadata fields, and it happens that some collide? meguFace

astral cliff
#

Possible bug in the typings of discord.js?

I am checking for <Interaction>.isGuild() in the if statement yet it gives me this warning

Note: I am using typescript in case it's not obvious
https://i.jarco.dev/YktuhMja.png

outer raven
loud jayBOT
#

pr_open #6998 in discordjs/discord.js by suneettipirneni opened <t:1637171468:R> (approved)
Fix: Interaction channel type should be GuildTextBasedChannels when in guild
đŸ“„ npm i suneettipirneni/discord.js#fix/interaction-channel-type

astral cliff
#

Ah, my bad forgot i should've checked the pull requests / issues

dawn merlin
#

Lol, it hasn’t been merged yet no worries

tacit crypt
outer raven
#

well idk if I should ping them or what but I'd really be interested in this being reverted
Also are the performance hits really that noticeable?

tacit crypt
#

It's..not.. the performance part is just what the meme says

outer raven
#

oh I didn't know that was a meme kek

opaque vessel
#

What do people think about a method that narrows properties of a message if it is from a webhook? member would be null and webhookId would be not null, in this case

dawn merlin
opaque vessel
#

I have functionality that needs to differentiate between bots and webhooks (ignore bots, allow webhooks) so the only check for that is if (message.webhookId !== null) {...}. The narrowing is more just a "why not", not really sure if that's a valid use case shrugs

grand eagle
#

Is there currently anything in the Discord API for events?

loud jayBOT
#

pr_open #6493 in discordjs/discord.js by iShibi opened <t:1629573546:R> (changes requested)
feat: add support for GuildScheduledEvent
đŸ“„ npm i iShibi/discord.js#feat-guild-event

outer raven
#

@grand eagle ^^

grand eagle
outer raven
grand eagle
#

ah okay, sounds good. Just meant that I hope they mention when the PR is closed and integrated

outer raven
cyan cargo
#

Hi are there any way to cross server / hosting sharding?

unique axle
#

you will need to write your own sharding manager or see if someone has already done so.
this channel is for coordination regarding developing discord.js itself, not for developing with discord.js

outer raven
#

@dawn merlin as of the latest dev build (after the *Data PR was merged) passing a ChatInputApplicationCommandData type to ApplicationCommand#equals and #create throws this error

#

could you look into it? I believe this is because the method isn't expecting string types

smoky dawn
#

iirc, you can edit message attachments using the discord bot API. But using D.js I can’t edit the message attachments, only append, on my ephemeral interaction reply. Is this something to do with it being a ephemeral interaction reply, and not a normal message or does D.js simply not support editing message attachments?

outer raven
smoky dawn
#

Oh. I see, thanks.

outer raven
#

either it gets reverted or we add some inconsistencies in places where the types don't match, which sounds more of a pain to me

#

or we add types using &, which also doesn't sound very maintainable, but I'm looking to know what you guys think

dawn merlin
outer raven
dawn merlin
#

The plan is to remove string types in the future and only allow numbers

outer raven
#

why would that be a good idea

#

and when was that suggested

dawn merlin
#

In my ticket

outer raven
#

which?

dawn merlin
#

The original one talking about using camel cased dapi types

outer raven
#

can you /github it

loud jayBOT
outer raven
#

thanks

#

yeah it seems like I missed that part, but I really don't think that's a good idea, and the types shouldn't break until/if that is ever implemented

dawn merlin
#

But I can summarize by this:

  1. Having multiple data types to represent one property is not a good approach at all
  2. The data should be as close as possible to the api payload, making the naming conventions completely separate from the djs implementation.
dawn merlin
outer raven
#

the purpose of a library is to make it easier to interact with the API, and I don't think slapping numbers in types is readable or easy to understand and get used to, and having to import an enum to access its properties seems much less handy than simply writing the string which is very easily converted on the library's side

outer raven
dawn merlin
outer raven
#

in fact I don't understand why these were marked as deprecated if nothing was noted on the docs

dawn merlin
outer raven
rough roost
#

why does djs delay events until all shards are ready? i have 7 shards, each always has some unavailable guilds, meaning it will wait at least 15 seconds before becoming ready. shards are also spawned sequentially with a 5 second delay, which creates a total delay of like 2 minutes for me

loud jayBOT
rough roost
#

yeah but it's not really dealing with the core problem

iron escarp
#

When is Djs gonna support max_concurrency? I'm kinda getting sick of having to dig into the code to add support for it myself every update SadCat

tacit crypt
iron escarp
#

How far is the progress on @discordjs/ws then? I requested support for it ages ago and it supposedly was on the todo list already back then

iron escarp
unique axle
#

if you can't wait for it feel free to PR

loud jayBOT
outer raven
#

I suggested this method should reject in case no embeds are added in X seconds but that may not be a good idea do I’d like to know if the managers think it should always resolve or if it should reject when there are no more embeds to add like I suggested

#

I’m fine with both since I understand the argument for both which is why I’d like to hear more opinions

dawn merlin
#

To clarify: should awaitEmbeds reject the promise when it can't find/or resolve embeds or should it instead just return an empty array of embeds?

outer raven
#

(Or an array with the already existing embeds for that matter)

visual hornet
#

well, is there even any guarantee that the embeds would load in x seconds/ms?
i think there should be an option for how long to wait for (as a maximum i guess, if that could be checked) to reject if no embeds are found (or resolve with an empty array)

dawn merlin
outer raven
tender field
burnt cradle
#

@copper laurel did you say you dropped your builders buttons pr?

copper laurel
#

Kinda. I wanted to redesign it and haven't had time. Not sure it even needs to be in builders tbh

tacit crypt
#

Components could go into builders, sure

outer raven
#

Djs has a builder for them tho what’s the point

copper laurel
#

Migrating and consolidating builders in one place I guess

outer raven
copper laurel
#

But that's the whole point of builders

wild flax
#

lol

copper laurel
#

They don't need to be in djs at all

outer raven
#

They’re integrated nicely with the library and work just fine unlike builders which often bring up issues like snake case and having to do .toJSON() all the time

outer raven
copper laurel
#

I mean... yes, I've expressed frustrations with incompatibility between the modules and core djs before too, but that's irrelevant to the overall design of builder classes being separated

#

Because "current ones" is nothing more than a legacy after the decision was made for them to be separated really

#

The snake_case compatibility issue is planned to be addressed, and "having to do toJSON()" is a weak argument honestly, make a necessary function call

outer raven
#

It looks like no one cares about builders rn tho

outer raven
copper laurel
#

Conceptually I'd like it if djs could accept the builder class object, I agree

outer raven
# wild flax ?

it has some PRs that have been open for a while with almost no attention despite the comments of people asking for it

#

I don't use builders nor do I plan to do so but from looking at the github feed this is the impression I get

wild flax
outer raven
#

¯_(ツ)_/¯

wild flax
#

Please make sense if you try to say something

#

A blocking PR was merged yesterday, which pretty much blocked all the others

#

And they need rebases now because of that

#

Theres only 3 open, 1 has requested changes, 2 needs a rebase, 1 reviews and another draft

outer raven
#

there even was a second PR by that same guy to add autocomplete that was closed for some reason, then they opened that one

wild flax
#

Which makes no sense to merge it because it would need a rebase either way and people couldn't use it without the ow replacement

outer raven
#

well nvm ig

pure flare
outer raven
#

Just out of curiosity, what versioning system does discord-api-types follow?

solemn oyster
#

semver

tacit crypt
#

Technically semver, practically it looks like Zerover

outer raven
solemn oyster
#

Whenever Discord as a company dies and stops releasing new updates

#

aka not in decades

outer raven
#

oh really

#

so it is zerover mmLol

#

alright thanks

solemn oyster
#

Problem with bumping 1.x, is that it'd require us to bump new majors every time Discord decides to break something

outer raven
#

I thought they only broke stuff on api version bumps (or when a feature is experimental ofc)

ruby terrace
#

things may not break actually but we're going on documentation that sometimes isn't accurate, so the types can change in a breaking way based on a mistake there

outer raven
#

Yeah makes sense

#

I mean you can always call those patches if it’s only the types that break but the values are the same

ruby terrace
#

that works for djs, and technically since discord hasn't changed their values it is a patch I suppose

visual hornet
#

could the default for position in GuildChannel#clone be changed to this.rawPosition instead? that would make a more accurate default regarding the position but it still wouldn't be perfect i guess

#

it would be sending the same position discord gave back to discord instead of sending the position calculated by djs

slate nacelle
#

Sounds reasonable

visual hornet
#

i feel like there should be some kind of note to this in the docs, but im not quite sure how to word/structure that part

#

i guess i'll submit a pr and mention that?
welp forgot to mention it because i was trying to get the fork to work properly but nvm now i guess

tender field
#

Hello, for the GuildScheduledEvent PR, wouldn't it make sense to add a SubscriberManager? because i don't see any, which means if we want to know if a member is subscribed we have to make a request (or keep a cache of our own).
I think it would make sense because you could have cache, and move fetchSubscribers() to subscribers#fetch() (and even userCount to subscribers#count?). The cache could be updated through the GuildScheduleEventUserAdd/Remove actions

opaque vessel
#

I believe the idea is to create at least a good base right now, because the events you listed are actually documented as experimental and not officially supported... so would rather wait to see if it sticks around before making a manager for them?

tender field
#

ah I see, but the PR won't be merged if the two events are still experimental, will it?

opaque vessel
#

I think it will be because only base support is added and nothing more

tender field
#

gotcha

outer raven
#

I think the initial implementation should be the best possible and the idea of a subscriber manager is nice because the events will stay almost certainly

#

might change of course but they will exist

tacit crypt
#

it can easily be made a sem minor

#

deprecate fetchSubscribers and make it call subscribers#fetch

#

voila

outer raven
#

eh ig but more deprecations

#

at this point we could use a deprecation manager lol

tacit crypt
outer raven
#

I don't see why they wouldn't?

outer raven
tacit crypt
#

It's experimental

outer raven
tacit crypt
#

And it can just fetch a list

#

instead of caching them

#

And this is turning off topic fast

outer raven
#

¯_(ツ)_/¯

oak quail
#

Those two dispatches you're referring to were introduced relatively late in this feature's development. When the docs say "experimental" here, it more means that this is a "beta feature" since we're actively monitoring to make sure these dispatches are performant at scale. If we notice issues, we may rework when these dispatches are sent and what data they contain. That all said, we haven't seen any signs that we're going to have trouble with them, so if I had to make a guess I'd say they'll stay as they are right now. But we're not giving the complete green light yet just in case.

visual hornet
#

also why doesn't endReason seem to acknowledge the time and idle end reasons

weak kraken
#

is the SessionId property of VoiceState supposed to be unique to the connection->disconnection event? That is to say, everytime you connect to a voice channel a new SessionId is generated? I am not seeing that currently (#archive-djs-help-v13 message)

#

I'm just going to cheat in the meantime and use channelId to detect online/offline states

#

but this seems to be an error with the sessionId not being deconstructed during the disconnect state update

outer raven
tacit crypt
tacit crypt
outer raven
tacit crypt
#

I don't see the point

#

usually if there's messages they're text based

weak kraken
#

so then the correct way to detect "connect" and "disconnect" events to a voice channel would be channelId changes being null or not

#

feels like a weird means to detect those changes tbh

outer raven
outer raven
#

aight ill keep the messages check

#

for voice, should I keep the bitrate check or use the types?

tacit crypt
#

Probably bitrate?

outer raven
oak quail
#

@outer raven also stage channels will not have text (at launch, at least)

#

and forum channels

outer raven
#

Ah right

#

Forum?

solemn oyster
#

Yeah, datamined stuff, you'll see when it's ready

#

It's just like a text channel, with threads, but no messages (in theory at least, I haven't seen it)

real jetty
#

why are the .toJSON() methods not documented?
like Message#toJSON() and such

outer raven
#

Why are there no methods to edit individual properties of an ApplicationCommand like there are for every other structure? Does Discord not allow editing 1 property only?

tacit crypt
#

Probably an oversight?

outer raven
#

I'll test to see if they work and add if they do

#

if it's a patch endpoint it should support that

#

yeah it does indeed work, will PR

#

Is it possible to edit the type of an application command? Apparently this is documented but I tried and it doesn't seem to work

#

probably another PR should remove that documentation because the API seems to just ignore type conversions and Discord doesn't document them

outer raven
#

Yeah I won’t PR because of the types since we’d need to make new interfaces and idk how to do that with the current type guards

outer raven
#

@remote wasp the guildScheduledEventDelete event doesn't seem to get fired when an event is over and goes away from the events list, how is this meant to fire?

remote wasp
#

when you delete the event

oak quail
#

when an event ends it doesn't get deleted

#

it just gets set to completed

opaque vessel
#

It seems as of b6b4570, stuff is typed as never when the passed type to the API call is imported from discord-api-types:

import { AuditLogEvent } from "discord-api-types/v9";

const audit = await <Guild>.fetchAuditLogs({
  type: AuditLogEvent.MemberUpdate
});

const entry = audit.entries.first()!;
const test = entry.action; // Never
const test2 = entry.actionType; // Never
const test3 = entry.extra; // Never
const test4 = entry.target; // Never
const test5 = entry.targetType; // Never

Is this acceptable? This is fine via the passed type of <GuildAuditLogs>.Actions.MEMBER_UPDATE imported from discord.js, though

tacit crypt
#

Probably a typescript moment where it doesn't recognize the numbers because they're from different enums

#

Try casting the type as const..otherwise, You might have to use the d.js constants object

solemn oyster
#

I was aware of the issues in jsdoc, since they were making yarn test fail locally, thank you @opaque vessel

#

And there are two issues, the one that's making CI fail, and the fact I can't document getter-setter pairs

#

But yeah, thank you for letting me know about that PR, I was about to check 😅

hollow pelican
#

I want to create a pull request and while npm test I get this err. how can I fix it?
Edit: Got it

lusty bolt
#

hi hi, if you wouldnt mind divulging a bit of internal knowledge here, what's the difference between the idToBinary function in the Util class versus just parseInt(id).toString(2)?

solemn oyster
#

That util has been removed from the main branch (and 13.4.0). Also, it's actually BigInt(id).toString(2), but it's useless.

visual hornet
solemn oyster
#

Snowflakes can't be converted to numbers, since they have a precision of 16 digits (and snowflakes typically have 18).

lusty bolt
#

i see now

lusty bolt
visual hornet
#

number the primitive type / Number the wrapper

lusty bolt
#

wait that second reason doesnt make sense, snowflakes are already a numerical value Thonk

lusty bolt
#

but even then it's still useless? how so? you don't get a timestamp from the first 22 bits of the snowflake?

outer raven
#

that's why the function was removed?

lusty bolt
#

interesting! i'll take a look

#

thanks <3

lusty bolt
#

also curious as to why the lib uses 0 as the process ID when generating snowflakes and not the actual.. process ID Thonk but i guess it doesnt matter that much does it

copper garden
#

Pretty sure only the date portion of the snowflake is taken into consideration for paginated endpoints

lusty bolt
#

see this is like the third time i’m hearing about paginated endpoints but i have no idea what that means

#

ah wait never mind i might have an idea

#

never mind this is outside the scope of the library lol

solemn oyster
solemn oyster
sullen idol
#

For Permissions, the only way you can tell if a permission is set to default in discord is if both values are false in the allow and deny. Why not set the values to null if its default? So we won't have to go through allat hassle đŸ˜Ș

solemn oyster
#

Because it's more computationally effective, and also because that's what Discord sends us

opaque vessel
#

Anyone else feel this is a bit off where the warning precedes the type? Would have thought it would be on the same line or after it, like it is with others such as ThreadAutoArchiveDuration or BufferResolvable etc.

solemn oyster
#

You're right, wanna tie with Rodry placing the warning below?

solemn oyster
#

@outer raven I'd say, feel free to PR equals to builders

outer raven
solemn oyster
#

Not sure what the other contribs think about it, but I have no problems with that myself, might be useful to have them in slash command builders (and in turn, also the rest of embeds), cc: @wild flax @tacit crypt

tacit crypt
#

Having built a method that reports all differences between two api datas (so, builder returns), equals is NOT nice to implement

outer raven
#

well equals just returns a boolean, not the differences

solemn oyster
#

Yeah, so better have them where they're at, than implementing them everywhere else we use them at

#

And that

wild flax
#

modules?

outer raven
#

#equals isn't used by the lib itself (although it could) but it's pretty useful in my code at least and having to make and maintain a function to do that myself is annoying

#

could it fit in Util? (something like embedEquals)

wild flax
#

I don't think so, at least not in the main lib

#

we have nothing to do with raw data

outer raven
#

equals is not about raw data

solemn oyster
#

So... you're suggesting to have @discordjs/comparers or something?

outer raven
#

me?

solemn oyster
wild flax
#

yeah something like this

#

idk what do to about the type-guards either

opaque vessel
dawn merlin
outer raven
dawn merlin
#

Wdym

outer raven
dawn merlin
#

You import them?

outer raven
#

and some typeguards are useful even in js like the interaction ones

dawn merlin
outer raven
dawn merlin
#

What?

#

There’s no casting

copper laurel
#

I think the questions are getting confused here

#

So rather than Interaction.isCommand(): this is CommandInteraction
Is it possible to do Typeguards.isInteractionCommand(interaction: unknown): interaction is CommandInteraction or something like that?

#

idk how it works but that seems to be whats being implied

#

Because just getting a boolean true back doesnt help

outer raven
#

yeah that was my question

#

and even if that's possibly it still seems unnecessarily complex

#

I think we should just move all messageembed methods to builders, including equals

analog oyster
#

although that particular function is not included in the pr

zenith oracle
#

I mean, that seems a method that should be included in the class, I don't see what's the advantage of having it in a different package

analog oyster
#

that's true, the package is kind of confusing and doesn't include much so it's hard to figure out what it's actually supposed to be doing/how you're supposed to use it

dawn merlin
dawn merlin
#

Comparing json objects rather than having something be put on a class also seems to have a lot of utility, take /rest and Dapi-types as an example

outer raven
#

thing is the equals method compares embed instances too and, personally, that's what I use it for in my code

dawn merlin
#

Ig my question is does builders output a instance version of embeds? (IE one that isn’t a buildable state)

outer raven
opaque vessel
#

Ah I see thank you

opaque vessel
opaque vessel
#

I'll change it then :eyes:

junior pumice
#

is there already a PR for guild banners?

opaque vessel
#

Yea

visual hornet
opaque vessel
#

I believe they mean animated banners

junior pumice
opaque vessel
#

What you're saying and what you mean are two different things :P but no

junior pumice
#

yeah sorry

#

didnt know what to call it

opaque vessel
#

No one has made a pull request about it to Discord's documentation yet either

outer raven
#

The API doesn’t have that field either

wild flax
#

It’s an experiment

outer raven
wild flax
#

That doesn’t mean anything

outer raven
#

Well it’s more than an experiment at this point

torpid mesa
outer raven
#

Ah ok

torpid mesa
dawn merlin
#

Yeah I’m on stable and my client has it lol

wild flax
outer raven
#

Well it’s not exclusive to the experiments tab that’s what I meant

wild flax
#

Yeah almost no experiment is

#

There’s always a tiny rollout almost

#

Server profiles has been in a tiny rollout for ages before they decided it’s not an experiment anymore

tacit crypt
#

Server banners and bios are barely starting to rollout

outer raven
#

Everyone seems to have access to them now

#

But yeah it’s not on the api so nothing we can do

tender field
#

For #7091 (removal of deleted getters), instead of iterating theough every entry to set the deleted field to true on a XXDelete event, can’t you just check if the parent was deleted in the getter? i.e.:

Message: In the ChannelDelete event, where it checks whether or not a channel has messages, then iterates through all of them to mark them as deleted.
Then can’t you make Message#deleted return deletedMessage.has(this) || this.channel.deleted or smthg? So you don’t have to update it

tame marlin
#

will this come out soon?