#archive-library-discussion

25085 messages · Page 1 of 26

frozen bridge

1 sec

Hmm it seems to be working now

If I get an offline guild ill try again

tacit crypt

owo 👍

copper laurel

Sorry, why was I pinged here? Is this relevant to me? I don't understand the sharding at all lol

frozen bridge

Nope not anymore

@tacit crypt Yep it seems to work now, it just takes like a minute longer than the other shards. What could be causing this? (Nothing specifically singles this shard out in the code)

tacit crypt

Because we wait for all guilds to come in. However, due to unavailable guilds, we wait 15 seconds. Aka

Say you have like 1000 guilds, and 5 are unavailable. We set a timer for 15s to mark the shard as ready regardless if all guilds came. We refresh that timer every time a guild comes. Once all but the last unavailable guilds came, the timeout takes over.

clever crypt

I keep having problems with one unavailable guild - 7100 members.

Sometimes it doesn't come through until 60 seconds after coming ready, sometimes it's perfectly fine.

fallen arrow

and this 15s timer is present in v12 but not v11, correct?

the solution i came up with is to manually run client.ws.connection.triggerReady(), not sure if its the best workaround

tacit crypt

I keep having problems with one unavailable guild - 7100 members.

Sometimes it doesn't come through until 60 seconds after coming ready, sometimes it's perfectly fine.
@clever crypt blame discord

warped crater

^ literally nothing you can do about it

after Discord's ready event they begin sending you guilds in the form of GUILD_CREATE packets

all d.js does is process them

glass hamlet

Thanks @fallen arrow , that workaround is working partially for me. Gonna have to work with it for now

lofty birch

So am I correct in thinking that the ready event is emitted when the bot connects, and the shard ready event is emitted when all of the guilds have been sent?

fallen arrow

should be the opposite afaik

lofty birch

Ah ok

real jetty

https://discord.js.org/#/docs/main/stable/class/User?scrollTo=toString

When concatenated with a string, this automatically returns the user's mention instead of the User object.
That's not true, when doing someString + user, the valueOf method is used, resulting in the userID.
https://github.com/discordjs/discord.js/blob/stable/src/structures/Base.js#L37-L39
Doing somestring ${user} or user.toString() does work as expected, but still, I think the word "concatenated" isn't the right word for it.

old kelp

I'm having a problem understanding the version 11.6.3 and 12.00

like what are they both

and as I know, master is the version 11.6.3, right?

frozen bridge

@wild flax wyd ya reopen?

wild flax

I commented.

frozen bridge

o

yea just saw

One of the devs above thought that there was nothing we could do about it?

nope I misread

fallen arrow

the only thing that could be done about it is to give it the same timer that v12 uses

real jetty

return { guild };
What is the point in having the above over this:
return guild;

deft holly
real jetty

Yea that is a line in the library

deft holly

that's a question about the library code, but the answer would be it returns an object (shorthand for { guild: guild }), as to why, depends on context

real jetty 
message.channel.bulkDelete(2, true)```
works but return this error

(node:2068) UnhandledPromiseRejectionWarning: DiscordAPIError: 405: Method Not Allowed

 
  name: 'DiscordAPIError',
  message: '405: Method Not Allowed',
  path: '/api/v7/channels/%3C',
  code: 0,
  method: 'POST' }```

Whats weird is from where %3C came from

raven juniper

Without knowing the context, that sounds like it's in a DM

slate nacelle
  • %3C is an encoded <
  • This method does not even hit that endpoint (POST /channels/:id)
    (It impossibly could result in that error)
  • Bug reports should go to our issue tracker instead
    (This does not include enough info though, see point 2)
clever crypt
vernal atlas

doesnt seem to throw an error

but then again doing v9999 doesnt throw an error either

GWrjkKappaLUL

ornate topaz

some people say v7 is "out" for multiple years now, but discord can't justify releasing it

tacit crypt

v7 of rest is like v6 of rest but with better errors

vivid field

Probably a rather nooby question, but why doesn't TextBasedChannel extend a regular Channel?

warped crater

its an "interface"

and it's being implemented into whatever channels are "text based"

tough geode

/\, it's never constructed, whatever it's implemented into in the lib extends Channel

warped crater

in short, it's a class but its not used the "normal" way

real jetty

guild.channels.create(name, options) and guild.roles.create({ data, reason }), I'd say it's better if GuildChannelManager#create would only accept one argument

opaque vessel

Huh? It already does, the options are optional and the type defaults to a text channel

real jetty

No I mean like guild.channels.create({ name: 'somevoice', type: 'voice', permissionOverwrites })

I'd say it's more consistent with other methods

raven juniper

The object is for optional parameters, the name is not optional for channels, it is for roles (apparently)

You see the same format in emojis.create(), first parameters are required, and then an object for optional ones

real jetty

Ahh so that's the logic behind it

ornate topaz

regarding roles, discord defaults to new role name, additionally, it's name every role you create in app had at one point, since you can rename it after you create it

thorny copper

I tried to update my bot to v12. It's horrible how Typescript's support has become worse than v11

Some examples:

clever crypt

Manager#cache is a collection, which is an extended Map.
Typings for that would be for (const [id, channel] of server.channels.cache).
If you wish to loop over just the channels suffix the .cache access with .values().

thorny copper
clever crypt

This is more of a support question that a complaint/suggestion/nit about the package.

thorny copper

with .values()

I did find a solution tho

(server.channels.cache.array() as GuildChannel[])

clever crypt

I have no problem with this code

for (const channel of <guild>.channels.cache.values()) {
    console.log(channel.permissionOverwrites);
}
``` *edited for your use case
thorny copper

I don't think there is, but TS grabs it as a "any" type

clever crypt

More or less a problem with your code editor

thorny copper

Another fantasy

And this one is really from DJS

fetch method doesn't take any arg, right?

clever crypt

Correct

thorny copper
umbral aspen

If you're calling fetch on the message, then yeah.

clever crypt

What is message?

thorny copper

client.on("message", (message) =>

umbral aspen
thorny copper

@umbral aspen Actually I complaint more than I ask for help :x

real jetty

For the collection loop, it should work fine on es6, how does your tsconfig look?

umbral aspen

You seem to be asking questions that belong in the variety of subjects discussed / asked (about) in support center.

thorny copper

Sorry

spice lava

We have GuildMember#bannable would there be a place for a general method like GuildMember.canban(GuildMember) for example. Or is this too high level same as addBlankField was removed

Edit: or would comparing roles positions by highest roles of each member be the preferred method without a custom implementation

rigid trail

i really do not see a use for this

why dont you just check .bannable on the memberThonk

the last thing the lib should do is make wrappers for already kind of iffy permission getters blobsweats

spice lava

As that would only count for the bot, as said this would be quite high level

rigid trail

you want to see if a member can ban another? lol

again, dont see a use for it

its too specific of a method to be justified to be added, especially when it has no direct correlation with things the bot is doing

spice lava

That's why I asked. Alright!

sly pollen

Does djs use cluster module for sharding or no?

And does it scale to the number of cores available?

opal mauve

the node cluster module isn't particularly useful for sharding

d.js uses normal child processes

sly pollen

any reason why you guys wanted to go with normal child processes?

one thing i noticed about internal sharding is worker threads

would a build of several process that have several worker threads(shards) be a bad idea?

it's like a mix of internal sharding and process sharding except that you can get the most out of these processes?

opal mauve

we went with child processes because we didn't need the functionality of the cluster module

sly pollen

ah i see, but what about a mix between process sharding and threads sharding?

opal mauve

unsure what advantage that would bring

sly pollen

Instead of having 10 child processes with their own independent instances and their own memory being shards
We get to have 3 processes with 4 worker threads for each. These worker threads being shards (and every 4 worker threads do share the same memory)
instead of 10 child processes being shards, we get 12 workers being shards and only 3 processes

thats what i meant

undone ravine

@sly pollen workers don't share memory with the main thread

copper laurel

Does anyone know why the message event shares typings with messageDelete | messageReactionRemoveAll?

public on(
  event: 'message' | 'messageDelete' | 'messageReactionRemoveAll',
  listener: (message: Message | PartialMessage) => void,
): this;

When would client.on("message") emit a PartialMessage?

I can't think of a reason, so I feel like it should have its own typings

real jetty

yh it should just be typed as Message. it never will be a partial within the message event, the author and content fields will always be present there so Message#partial will always be false

frozen bridge

Haiya! I'm wondering if this is a bug or not... in djs 12.0.2, setting the position of a category to 0 puts it at the bottom of the channels, while setting it to 1 puts it under the channel in position 0

im using guild.channels.create

slate nacelle
frozen bridge

Then why is setting the position to 0 having the category created at the bottom of the channel list?

guild.channels.create("Covid-19", {"type": "category", permissionOverwrites: [{id: guild.id, allow: "VIEW_CHANNEL", deny: "CONNECT"}], "position": 0})

rigid trail

this is not at all the place for that question

copper laurel

This is not a support channel

rigid trail

you mean client#voiceStateUpdate?

it includes a voice state which has guild info..

not the right channel for this

please use a support channel

clever crypt

?gotosupport

rich iglooBOT
rigid trail

on stable its a VoiceState for both params and on v11 its a guildmember so im not quite sure what you are suggesting

anyways its kind of offtopic since at this point its a code issue, not a library issue

copper laurel

reaction.count isn't showing in docs on 12.0.2 for some reason

Possibly because // eslint-disable-next-line eqeqeq has been added between the JSDoc and the property?

slate nacelle
uneven dawn

I'm not sure the best practice on this, but instead of having a generic type like GuildChannel that's defined to extend Channel , shouldn't there be a GuildTextChannel that extends TextChannel etc.?

This way you don't have to cast everything that comes as GuildChannel to the text/voice/category/news/store equivalents

rigid trail

so:

GuildTextChannel ---- TextChannel ---- GuildChannel ---- Channel```? what about DmChannels, those simply extend Channel and implement TextBasedChannel, similar to TextChannel which extends GuildChannel and implements TextBasedChannel

you will still have to cast, some methods can return any channel, say grabbing a channel from the GuildChannelManager, it can be text/voice/category, etc, so i fail to see how that solves anything, it seems to just add more clutter to inheritance

copper laurel

Channel typings will definitely be improved in v13 with proper typescript

snow crypt

I think messages could implement a guild typeguard

wild flax

Like the non-working channel typeguard?

snow crypt

I really don't know, but something to tell TS that if message.guild is present, message.channel is a TextChannel

plucky jay

I don't think a typeguard like that is possible with TS

But maybe a GuildMessage or something?

snow crypt

was about to say

wild flax

That falls under what borger said right at the top there

snow crypt 
type GuildMessage = Message & {
  guild: Guild;
  channel: TextChannel;
  member: GuildMember;
};

type DMMessage = Message & {
  guild: null;
  channel: DMChannel; // can be partial(?)
  member: null;
};
``` and rest

some methods can return any channel

@wild flax why would that fail for message?

wild flax

oh

snow crypt

so would that work?

also, the channel typeguard works?

slate nacelle
plucky jay

@snow crypt But if you use message.guild instead, of message.channel.type === 'text', it won't work

snow crypt 
type GuildMessage = Discord.Message & {
  guild: Discord.Guild;
  channel: Discord.TextChannel;
  member: Discord.GuildMember;
};

type DMMessage = Discord.Message & {
  guild: null;
  channel: Discord.DMChannel; // can be partial(?)
  member: null;
};

type AnyMessage = DMMessage | GuildMessage;

// @ts-ignore
const m : AnyMessage = get();
if (m.guild) {
  m.channel.permissionsFor
}

this works

tough geode
umbral aspen

I think it should be nullable since a category doesn't necessarily need to have any children channels. In other words, a category can be empty.
This perhaps should be updated to it not being marked as nullable, or updating it so it is nullable and that it returns a collection with entries present in it or null.

tough geode

categories can be empty, but .children is an empty collection for empty categories, not null, therefore it's misleading in my opinion.

thorny cosmos

Yes, 1s3k3b is right, the jsdocs for .children is kind of wrong, since collections extend maps, they can give an empty collection object if no key value pair exists, here is what I just evaled on an empty category
Also the typings on Collection states that Collection#filter() returns a Collection, not ?Collection, so it makes sense for why should it not return ?Collection<Snowflake, GuildChannel>

snow crypt

speaking of CategoryChannel, the setParent method is documented (because of GuildChannel), but it shouldn't be there at all

tough geode

well, it's inherited, but it has a warning

snow crypt

it doesn't have

same thing for lockPermission

unique axle

CategoryChannel#setParent should be there because the API technically allows it, despite throwing an error at this moment in time
Hence why instead the warning is introduced

snow crypt

and what would it do?

unique axle

as i just said, at this moment in time you can not tier categories like a file system, however the endpoint is there, so we decided to support it

snow crypt

but it does practically nothing?

unique axle

throwing an error at this moment in time
would not describe that as "nothing" per se

snow crypt

i'm talking discord

like, you can set a topic to a voice channel with djs, but it really does nothing if you look at it practically

unique axle

i fail to understand what you mean, the API throws an error, the request is rejected

snow crypt

the api throws an error when trying to set a parent?

does the api throw or is it just the lib?

slate nacelle

Depends on the error class you catch:
DiscordAPIError -> Discord threw it
DiscordjsError -> discord.js threw it

unique axle

as said, API error, to be more precise:

DiscordAPIError: Invalid Form Body
parent_id: Categories cannot have subcategories

snow crypt

well isn't this going with the head in the wall?

making a request that is going to fail is very strange to me

wild flax

its not worth it to specifically handle that use case or somehow remove it from the documentation despite its inheritance

snow crypt

but the library is there to interact with discord

could also split it to have a base GuildChannel, and a ParentedGuildChannel to have setParent on it, then have voice and text inherit from it, and categories would inherit from the base GuildChannel with no setParent

ornate topaz

but the library is there to interact with discord
Well, it's a wrapper for Discord's API, so theoretically, if CategoryChannel#setParent is documented in API, there is no reason to not have it. It might reject today, but what if tomorrow discord will release subcategories?
It's a wrapper for whole API, not wrapper for some of its functions

copper laurel

It exists because the API doesn't actually have different endpoints for different channel types the way Discord.js does. There isnt even a "set parent" API endpoint. Its literally just Modify Channel, specifying a parent_id
https://discordapp.com/developers/docs/resources/channel#modify-channel

setParent() is already just a helper function around an edit call really. The most logical place to share this inheritence is GuildChannel otherwise we'd be duplicating code across Text/Voice/News/Store channels

digital hawk

it doesnt play well with custom events and my event loader

i think having a [event: string]: any[] at the end of ClientEvents could potentially fix it

copper laurel

Makes sense to me - I think we've effectively locked it down too far

slate nacelle

You can augment the interface adding your own events there:

declare module 'discord.js' {
    interface ClientEvents {
        foo: [Map<string, any[]>];
    }
}

(Or that catch-all clause, too.)

snow crypt

I think it should be event: string | symbol in the all-catch

now how do i make a pr again

slate nacelle
snow crypt

so I guess we're not adding it back?

slate nacelle

I'd be in favor to not do that.

snow crypt

I'll do a pr with that note

wild flax

This doesn't make a lot of sense

why would you not extend the interface?

Why would you want to just allow any symbol or string?

snow crypt

as written in the pull, i'm just waiting for feedback

wild flax

You got feedback from 2 devs

snow crypt

why not more ¯_(ツ)_/¯

vivid field

Probably more of an api question, but is there a reason why guildMemberRemove gives you a member object whereas guildBanAdd gives you a user object?

rigid trail

hackbans

you can ban a user by id which is not in the guild (see: Guild#members#ban())

snow crypt

I would not be surprised if member.ban calls member.guild.members.ban

aaand... it does

rigid trail

why would it not

digital hawk

@slate nacelle I went ahead and just made my own interface in my bot which extends ClientEvents but I guess adding it in a d.ts works too

snow crypt

so do i close the pr?

yep

tender surge

Wish intellisense would still work if you allowed anything but yea if you allow anything now you either don't get autocompletion or you can't get the typings that are returned from each event

Also if you extend now you can easily type what's returned from your custom event instead of asserting

snow crypt

Would v11 break if moved to node-fetch?

warped crater

otherwise it would have been done already

tacit crypt

Would it break? No.
Would it be breaking? Yes

undone ravine

It wouldn't be breaking

tacit crypt

breaking from a semver point, no?

rigid trail

if nothing changes on the public API then i dont see how it would be semver major

undone ravine

No, unless there are points where raw return values are given to a user from snekfetch/node-fetch

Changing dependencies is not a breaking change

slate nacelle
snow crypt

if nothing changes on the public API then i dont see how it would be semver major
that's why i'm asking

rigid trail

i mean, i believe there is little to be gained from switching to node fetch but a significant amount to lose if done improperly, also, v11 isnt really in development as much as v12, as long as snekfetch works i dont see a need

real jetty

Would there be any way of adding in where an API call failed in the code? As in, more detailed stack traces

So instead of it coming from the library it would come from a method called from code the user had written

rigid trail

you mean unhandled promise rejections? not really no, as async code is run in parallel to the stack elsewhere, therefore stack traces are hard to make and would be huge

exotic flicker

v11-dev had a way to show accurate stack traces, but afaik node always had this missery with async stack traces

real jetty

then what changed between v11-dev and now that required that code to be changed?

well, ok probably a lot in all fairness but

slate nacelle
exotic flicker
tacit crypt

My implementation in that PR you linked @slate nacelle would only work on v8 sadly (which would be fine if we didn't have browser builds); it's to be changed

slate nacelle

RIP

So basically like appells comment said.

tacit crypt

Well, yes but actually no

tacit crypt 
TypeError: timeout.refresh is not a function
    at GABClient.handler (C:\Users\GAwesomeBot\Development\node_modules\discord.js\src\stores\GuildMemberStore.js:210:17)
    at GABClient.emit (events.js:323:22)
    at GABClient.EventEmitter.emit (domain.js:482:12)
    at Object.module.exports [as GUILD_MEMBERS_CHUNK] (C:\Users\GAwesomeBot\Development\node_modules\discord.js\src\client\websocket\handlers\GUILD_MEMBERS_CHUNK.js:18:10)
    at WebSocketManager.handlePacket (C:\Users\GAwesomeBot\Development\node_modules\discord.js\src\client\websocket\WebSocketManager.js:391:31)
    at WebSocketShard.onPacket (C:\Users\GAwesomeBot\Development\node_modules\discord.js\src\client\websocket\WebSocketShard.js:437:22)
    at WebSocketShard.onMessage (C:\Users\GAwesomeBot\Development\node_modules\discord.js\src\client\websocket\WebSocketShard.js:295:10)
    at WebSocket.onMessage (C:\Users\GAwesomeBot\Development\node_modules\ws\lib\event-target.js:120:16)
    at WebSocket.emit (events.js:311:20)
    at WebSocket.EventEmitter.emit (domain.js:482:12)``` If anyone wants to have a look, I'm a bit busy ![sad](https://cdn.discordapp.com/emojis/585885410257928194.webp?size=128 "sad")
rigid trail

GuildMemberStore 🤔

tacit crypt

yes, i'm not on latest cause we're rewriting soon

rigid trail

what node version are u running? cause timeout.refresh was added in v10

tacit crypt

nodejs 12.something

OH

ik the issue nvm

frozen bridge

Does djs use the Server Members Intent when using guild.members.cache.get() etc ?

slate nacelle

No, that's just cache, it does not interact with anything outside of your ram.

frozen bridge

ah ok thx

lofty birch

Just want to point out that the api seems to now show public_flags on a user object, you may want to look into that as this seems new

slate nacelle
tacit crypt

OWO

fucking

FINALLY

clever crypt
keen cosmos

Doesn't the data come in with a regular fetch? instead of needing a separate utility function couldn't users just use User#fetch

thorny cosmos

For User#fetch(), you would need the user object to call fetch() on them, and assuming you don't have any user object, in that case what will you do?

rigid trail

fetch from the users manager

thorny cosmos

Of course there is a method User#fetch, but it is used on Partial User Objects. Assuming you don't have that also, then how would you use? Hence you need UserManager#fetch(), i.e., a separate function exists for it @keen cosmos

copper laurel

I dont think that was the point being made

Are flags not included in a User payload - do they have a separate endpoint that requires User#fetchFlags() instead of just User#fetch()?

copper laurel

Tested - not part of the data you get about users when you identify but it is the same fetch endpoint

keen cosmos

yeah, I meant that the data comes in from the same fetch endpoint

@thorny cosmos also you're not restricted to using fetch() on partial options

thorny cosmos

yes I meant that it can be used on any valid User object, it is mostly used for partial user objects but Ok

ornate topaz

mostly used does not in any way limit it to that functionality or use case

guild.fetch() also exists, but did you ever had a need to fetch a guild? tmk you would use it only if you would at any point need maximumPresences or maximumMembers

real jetty

@keen cosmos if the User isn't partial then User#fetch() will just return the cached user, so it would never end up patching the user and updating the flags

vivid field

is there a reason why bulkDelete didn't move to the MessageManager?

ornate topaz

it was never under MessageStore

snow crypt

i think the question is more like why isn't it on messagemanager?

vivid field

exactly, with "moving" i meant v11 -> v12 and not old v12 -> new v12

rigid trail

i just didnt think about moving it when implementing managers, i think its fine and its not a big deal but i do see why you would expect it to be on the manager, unfortunately the switch cannot be made as it is semver major

i kept all methods the same from dataStores to managers with the exception of renaming MessageStore#remove to MessageManager#delete for clarity

@vivid field

loud moat

So v13 soon

rigid trail

i wouldnt exactly say soon lol, its a full rewrite and we dont even have a gateway yet, id expect the basic things like rest/gateway/ some of the core to be done by the end of 2020

undone ravine

the method could still be moved and leave the old one in place as a shortcut to it and deprecated

rigid trail

i find this useless personally

undone ravine

if the method would be more appropriate in the new location, it is absolutely not useless

ornate topaz

at that point it would be more of a change just for the sake of a change

undone ravine

no, it'd be a change for the sake of logical consistency

is there any functional difference? no, of course not

but if that is where that method should be, then that is where it should be

no reason to hold it back in an improper place because "meh, it doesn't change anything"

rigid trail

meh i just think there is no need

undone ravine

you yourself have already essentially admitted that it makes sense to be on the manager

therefore there is a need

rigid trail

it does, i still dont think the change should be made

undone ravine

you're making that decision from a purely emotional standpoint with no logic behind it

rigid trail

for all we know bulkDelete could be renamed/moved somewhere else in djs-next, and managers could not exist either, i think deprecating it is not really the right move

undone ravine

deprecation doesn't guarantee removal

it is not a commitment

ornate topaz

but if it's deprecated, devs should start to look into new way, which literally does not exist now

undone ravine

the new way is the correct location for the method

which would exist at the time of deprecation

raven juniper

commando is a framework for d.js it's not part of the library

rigid trail

you might want to read #3485 to get an idea of why things changed, its mostly to separate the API and cache methods. im not quite sure what you mean added to the client class, would you mind elaborating on that?

there are no new classes by the way, they only replaced the data store classes

while yes, they do break code significantly and many users may not see the need, which is unfortunate, the changes greatly benefitted the maintainability of the library for the future

and where would the api methods go? that would be the same as datastores but with a different name

the point of managers was to separate the cache and api, you cant quite do that without breaking users code

but what you are describing are data stores

wild flax

though maybe actually extending the class into type-specific subclasses (guildcollection, channelcollection, etc) would have been a better move to avoid breaking existing code
this is essentially what was happening with stores and why we moved away from it

rigid trail

this would still have all of the downsides of datastores

rigid trail

add is an internal method to add to the cache and remove is an artifact with a pr to remove it from typings

yes

the GuildMemberRoleManager is a pseudomanager, its add/set methods call the api

no problem

slate nacelle

Would this work?

Looks good, on a first glance.

sure

topaz mango

Don't think it's a breaking change.

rigid trail

This is a breaking change tho real_eyes

at least thats what it looks like to me, im not sure if private things like the data resolver count

snow crypt

it is like changing the rest manager

you're not supposed to touch it

hold up, wouldn't it break things that call if it they are not also changed?

because in resolveBase64 it still checks for buffer

rigid trail

it seems to me that this isnt a clean change and that it could silently affect other things that call it, and that more tests need to be written

rigid trail

Wouldnt that just nullify the point of the pr monkaHMM

opal mauve

technically, APIMessage doesn't document files as anything other than "Object", so I don't think this would qualify as breaking.

honestly a bit of an oversight in documentation, but i think it would serve our purposes here if we wanted to make this change

lofty birch

I do think a separate method for uploading local files as streams would be helpful though, I do quite a bit of sending images and my ram usage jumps up when doing so

warped crater

Doesn't this entirely contradict past changes, however

with time all of the send* (e.g. sendEmbed, sendFile) methods were removed in favor of the universal send

snow crypt

@drowsy niche you can still make separate DataResolver methods

like, a different resolving for local / remote that will then be called accordingly

snow crypt

Regarding patterns in MessageMentions, can't IDs be 16-character long?

ornate topaz

considering they are being somewhat increased, and that Discord was released in may, no snowflake from after may can be 16 characters long

snow crypt

so it will be 17,19 for now, and 17,20 after there can't be no more 19digit ids?

ornate topaz

yes

we're already at 699296380694429736

so theoretically

wild flax

What of all of this do you actually send to discord?

keen cosmos

@drowsy niche I messed around with your test code and it seems like the files property of the json response from httpbin is being reset when sending a stream, maybe that's the issue?

tribal slate

setSelfDeaf literally does not work

Not sure if I'm doing something wrong or if its because of the library itself

It shouldn't return anything

wispy harbor

(actually it should)

tribal slate

Yeah but like

yikers

rigid trail

the return type is documented so im not sure what the problem is

tribal slate

Its supposed to self deafen the bot

But its not doing that, and just returning false

rigid trail

well, thats not something for this channel

tribal slate

I thought this was a problem with the library

Which is why I posted here

Is it a problem with the docs? I'm really not sure

snow crypt

not sure what should I do now tho, the form-data repo is pretty dead
@drowsy niche create @discordjs/form-data?

tacit crypt

@drowsy niche ```ts
declare const body: import('node-fetch').Body;

body.body```

Per their docs, this is totally valid

Since res.body is a Body class, it has a body property (stupid, I know)

Do you think that might fix it? (so we don't have the issue where form-data is..borked)

In this case, body.body is a NodeJS Readable Stream, instead of a WHATWG ReadableStream

Wait the hell?

Am I seeing this wrong

Oh I totally did see this wrong, fricking docs

Well this might explain why it doesn't work without that form-data PR

tacit crypt

oh, gotcha

keen cosmos

@drowsy niche so the issue is that form-data doesn't like anything that's not a regular Readable stream, right?

wild flax

@drowsy niche if you want we can probably keep a fork and keep it up to date with upstream

wild flax

well, I'd rather have a fork with the PR merged (in our fork) than rely on someone else fork, if you know what I mean

yes, but we have to fork form-data first is what im saying

have a fork that is under our control, in case the original PR author deletes his or whatever

probably

anything is better than relying on some 3rd party fork here.

Or installing a commit from a PR

wild flax

published under @discordjs/form-data

3.0.1

youll have to make it a non-draft

👍

fallen arrow

Are partial guildChannels supported? This throws errors in the ChannelManager if the channel is not cached but the guild is, i was wondering if it would make sense to provide a partial channel or to simply return if either of them are not available instead: ```js
class InviteCreateAction extends Action {
handle(data) {
const client = this.client;
const channel = client.channels.cache.get(data.channel_id);
const guild = client.guilds.cache.get(data.guild_id);
if (!channel && !guild) return false;

const inviteData = Object.assign(data, { channel, guild });
const invite = new Invite(client, inviteData);
warped crater

this doesn't seem quite right

normally all guilds should be cached when they are received via the GUILD_CREATE packet, which provides all channels

there should never be a case where a channel is not cached

same with roles & guilds

fallen arrow

yes i am aware of that, the only use case for this is when the developer uncaches channels to save memory, which is more common than one would think

hence why the question if it would make sense to support such use cases since we already have partials in many other scenarios, or if this is out of the scope of the library

warped crater

as stated in other places & conversations related to cache, going by

uncaches channels to save memory, which is more common than one would think
would cause a lot of changes and checks all over the place for no particular reason

The client options provide various ways of keeping cache smaller for things that are not needed by the core library.

A pretty good summary of it can be seen here: https://github.com/discordjs/discord.js/pull/3995#issuecomment-604441660

Channels are data discord.js absolutely depends on internally at the moment, not just in the situation that you pointed out just now

On top of that, I honestly doubt this is "more common than one would think", given that channels are the least of your problems when thinking about cache.

The only real place you can save actual valuable memory in is the messages cache & potentially the members.

wild flax

We currently only really use or support partials whenever discord gives us partials. And channels dont fall under that category

fallen arrow

alright thanks

frozen bridge
wild flax

@tacit crypt

do we not trigger ready even if not all guilds are ready?

Im pretty sure we do, or do we only do that on internal sharding?

tacit crypt

we do, but the timeout waits 15 seconds before doing that

wild flax

ok but what if you use the sharding manager

tacit crypt

..same?

wild flax

doesnt look like it

lol

tacit crypt

The default sharding manager timeout is probably too small by default

I mean the cycle is:

Bot gets Discord READY, we set a 15s timeout
For each GUILD_CREATE, we refresh the timeout
If there's still unavailable guilds, the 15s timeout will trigger, marking the client as READY

Sooo

TL;DR: increase your sharding manager timeout and it should be fine

lofty birch

Using a sharding manager I get the error it took to long to ready sometimes

tacit crypt

..As I said

Increase the timeout

lofty birch

According to what you said it should just mark as ready after the timeout with the remaining guilds being unavailable

tacit crypt

Yes, but the default timeout is too short in the manager

Speaking of, @lofty birch do you have any of the optional deps installed? (zlib-sync, bufferutil & utf-8-validate)?

lofty birch

I don't believe I do

tacit crypt

Can you try installing those and seeing if that helps?

Otherwise, try increasing the timeout on the shardingmanager to say, a minute

(manager.spawn(undefined, undefined, 60000)

lofty birch

Will do in a bit

frozen bridge

Will User#Flags ever be supported in v11?

copper laurel

No, v11 will not receive new features

snow crypt

I am asking as it gives incorrect results, and I can't find the source for it.

ornate topaz

probably from nowhere, as acronym is generated by client from usually first letters

snow crypt

so the acronym-ing is done somewhere in the client js?

ornate topaz

by client i meant the discord app

wild flax

Yeah its not an API thing

snow crypt

by client i meant the discord app
that's what i meant

like, in the js of the app

@opaque robin that's not how you deprecate

And you don't resolve the promise

opaque robin

@snow crypt tbh I searched the server for util.deprecate and afaik from what I've seen, it returns the function with the deprecation warning.
But if you say I'm incorrect, I'll take that

snow crypt

Currently the method returns a function

opaque robin

Oh, so I should be calling the function it returns

slate nacelle
snow crypt

was about to say, do it at the bottom of the file with the prototype

opaque robin

Ah

Thanks space,

that makes more sense

snow crypt

yeah, thanks, space 😞

opaque robin

I should still be using const util = require('util') instead of directly requiring in the prototype I presume.

snow crypt

or destructure deprecate from it

opaque robin

Alright 👍

@snow crypt Wouldn't the async await mean it wouldn't be returning a promise anymore

snow crypt

nope, just the opposite

opaque robin

ah right, mb

@vernal atlas What would be the more appropriate tag to use for that?

I think <info> would be appropriate, not too sure.

snow crypt

No, just an actual description of the typedef

opaque robin 
  /**
   * An object containing information about a guild's vanity url.
   * @typedef {Object} VanityData
   * @property {?string} code Vanity URL invite code, not the full url
   * @property {?number} uses How many times this invite has been used, must be fetched at least once
   */
snow crypt

or just vanity, remove url

or data

vernal atlas

not sure what would be better (as to info or warn tag)

snow crypt

i think just vanity is enough

if someone would want to correct it later it's an ez pr

opaque robin

Might as well get everything done in the one PR tbh

so @typedef {Object} Vanity

remove URL in Vanity URL invite code

and that should be good yeah?

snow crypt

by client i meant the discord app
do you think ```js
t.getAcronym = function(e) {
return null != e ? e.replace(/'s /g, " ").replace(/\w+/g, (function(e) {
return e[0]
})).replace(/\s/g, "") : ""
}

I think it is

so yea, it should be name.replace(/'s /g, " ").replace(/\w+/g, e => e[0]).replace(/\s/g, "")

snow crypt

pr'd it

snow crypt

What prevents #2910 from being merged?

deft holly

I'd like to know about ^ as well, left a comment two weeks ago and haven't gotten a response :P

snow crypt

@clever crypt I found that piece of code with the raw website, didn't need to actually download it

looked for "acronym", found uses of "getAcronym", searched its definition and got the actual one

copper laurel

User#flags doesn't seem to be documented, not sure if it's missing or the docgen for 12.2.0 didn't work properly or something

I'm mobile so not checking or PRing myself

snow crypt

on master it's there

oh, you're correct

a PR to document it was merged after 12.2.0

copper laurel

Ahh it's after, all good

In mobile and didn't check

vapid echo

hey, any idea how long it takes for v12 bug fixes to get ported to v11? please let me know if this is wrong channel for this

i'm specifically looking for this bugfix: fix up WebSocketShard errors. it was released with v12.2.0 a few days back

lofty birch

was announced in discord dev server also

ornate root

@vivid field but client.channels gives you a ChannelManager

and you can use .fetch on it

vivid field

oh wait, i thought they used Guild#channels

also unrelated to this channel

ornate root

it was about djs

copper laurel

@vapid echo v11 is no longer maintained and will not receive further non-critical fixes. v12 is the stable branch which will receive maintenance patches and releases

vapid echo

Oh. I still see v11 releases though. Are you saying v11.6.4 (released 15 days ago) was the last one? @copper laurel

rigid trail

if there are significant bugs which can be fixed pretty easily then a quick patch to v11 may be done, but feature updates are out the window

vapid echo

Right, I am looking for a bugfix. Like I mentioned above, specifically this one: fix up WebSocketShard errors. it was released with v12.2.0 a few days back

Just wondering if it will make it to v11

copper laurel

Can you please reference the PR you're referring to

vapid echo

Sure

rigid trail

iirc that was a pretty big change, and the websocket from v11 to v12 has changed a lot, so fixes on v12 can completely break v11

copper laurel

Its highly unlikely because the websocket was signficantly changed in the v12 release

So these changes wouldnt even apply to v11

rigid trail

yeah its pretty significant

vapid echo

Oh

Okay, we can explore the possibility of moving to v12 then

proven heron

I feel like displayAvatarURL’s dynamic key should be true by default. It seems like it would be more beneficial as more people will probably be after the gif instead of the webp

wild flax

Sadly thats a breaking change and wont happen

proven heron

Explain breaking change. Almost everything you change will break pre-existing code?

wild flax

Changing a default to be something else falls under MAJOR

fickle flare

Has anybody reported any issues with this promise hanging?

It doesn't reject, it doesn't resolve... just dies 😫

tough geode

it adds listeners which either resolve or reject the Promise

real jetty

I was looking for a library to write a Bot in and when looking at the discord.js Github, i've found this: https://github.com/discordjs/discord.js-next, what should anyone expect from it? Will any bot written in the current Discord.js work in next or would i have to write the my Bot again?

wild flax

The next version, no, yes

real jetty

I know it seems to be in a pretty early stage to say anything but you have any ETA planned? I wonder how long i could expect my bot to work using the current version.

Or you plan to support the current version in some sort of LTS?

spice lava

So I found a typings issues. With the following code: ts msg.channel.delete().catch() where channel is TextChannel | DMChannel | NewsChannel fails with ```
TS2349: This expression is not callable.
Each member of the union type '(<TResult = never>(onrejected?: (reason: any) => TResult | PromiseLike<TResult>) => Promise<DMChannel | TResult>) | (<TResult = never>(onrejected?: (reason: any) => TResult | PromiseLike<...>) => Promise<...>) | (<TResult = never>(onrejected?: (reason: any) => TResult | PromiseLike<...>) => Promise<...>)' has signatures, but none of those signatures are compatible with each other.


Seems to be an issue introduced with v12 as the Channel typings changed from `public delete(): Promise<Channel>;` to `public delete(reason?: string): Promise<this>;`

Granted this would be an easy fix if you cast a type like `(msg.channel as TextChannel).delete().catch()` but I thought that this issue shouldn't appear in the first place. On the other hand I am not sure on if this should even be fixed as typings in general would be fucked if you just return `Promise<Channel>` there as this wouldnt be very detailed. 

Introducing types on the top level classes like `TextChannel` would introduce the same issue. So I would like to know some comments on this one as I would say all approaches are not perfect because there are actually cases where `channel` could be both, `DMChannel` and `TextChannel`
vernal atlas

interesting

there was something similar to this with the channel union types right?

spice lava

The issue is the same with channel.fetch().catch() btw, exact same reason as above

slate nacelle

This is the same issue as the union types, I mean it is an union type after all.

spice lava

So this is a known issue/problem?

slate nacelle

Not in this context, but I guess?
I don't think we can do much about this except using Channel instead of the union and let you assert / instanceof concrete types.

spice lava

That's what I thought. Is there already a PR for it? (will look myself but maybe you know more)

slate nacelle

I don't think so.

spice lava

time to get into 2+ 2- PRs again

tacit crypt

It doesn't reject, it doesn't resolve... just dies 😫
@fickle flare thats..impossible, theres always at least ONE event that runs

fickle flare

What can I do to help diagnose the problem?

or track the source

I'm not using standard Node, but until v11 it was working flawlessly

tacit crypt

Wait, what

fickle flare

Yes, Its running from inside FiveM's compilation of Node

I know there was some history and people here didn't like it, but they actually solved the "window" global parameter pollution and it was working as it should

.... until I tried to update to v12 yesterday 😢

vernal atlas

the data.embed_enabled here is deprecated, in favour of data.widget_enabled, im going to do a PR, assuming it would it be better to deprecate Guild#embedEnabled, in favour of Guild#widgetEnabled, is deprecating a property as simple as just adding the @deprecated tag?

copper laurel

You use util.deprecate iirc, @deprecate only JSDocs it

tacit crypt

I'm pretty sure that's only for functions

snow crypt

no

also props

Permissions#_member on v11

opaque vessel

Is this a bug in the client? Whenever I deleted an uncached message but listening to it as partial, the .system property is always true, but that's not correct?

real jetty

Suggestion to add field inline limiter, so you can use two values each line if you want to

That's quite easy to implement, but really not a feature for D.JS imo

Especially since .addBlankField has also been removed

real jetty

smugshh

ornate topaz

addBlankField was just a shortcut for addField('\u200b', '\u200b'), that's why it was removed. You can still do it on your own, adding that as 3rd inline field will "fill" the 3rd inline space

However, that will render badly on devices that do not have ability to render any form of inline fields inline. Additionally, embed rendering is purely up to discord - as example can be not-that-recent embed update that allowed to have 3 inline fields and a thumbnail.

vernal atlas

so i was actually looking around trying to figure out why user#flags can be undefined, found this, kinda odd? how the API sends it but its not picked up?

fiery geyser
snow crypt

There is still User#fetchFlags

vernal atlas

ah, assumed that it was just being lost somewhere

vernal atlas

Message#suppressEmbeds seems to be broken when using the allowedMentions client option
(suppressEmbeds calls Message#edit, which uses APIMessage.resolveData and adds in the allowedMentions default option)

would the best way be to just call the endpoint directly in suppressEmbeds rather than calling this.edit?

i feel like theres a better way but maybe thats just because its 2:30am and i haven't slept GWrjkKappaLUL

copper laurel

broken in that it will unintentionally also edit the allowedMentions?

tacit crypt

Reminder: message edits do not ping the user/role(s)

snow crypt

would ids be bigints in djs@next?

wild flax

possibly, not much is set in stone yet for djs 13

vernal atlas

broken as in the API returns an error (if said message is authored by another user)

(i thought i mentioned that but must've slipped my mind lul) @copper laurel

copper laurel

Ahh right, makes sense

As for BigInt - why? I don't see any value in them being handled as integers, strings works perfectly well.

wild flax

tbf most sensible languages handle them as a numbers

there isnt any particular reason why we couldnt

tacit crypt

Except we have the constant conversion between BigInt<->String for REST

timid pewter

Not sure if I should make a new issue for this so I am just gonna try asking here first.

https://github.com/discordjs/discord.js/pull/4087#issuecomment-619242608

I didn't get a response from any of the lib devs on this besides a reaction which doesn't help clarify to me what you guys plan on doing for this? Should TS developers expect breaking changes without warning in the future on what should be a stable branch?

surreal geode

No, updating typings is not a breaking change

timid pewter

if it breaks projects it is a breaking change, and this broke projects aka breaking change

If DJS doesn't want to properly support TS devs then thats different, but any TS dev using TS properly the way it was intended broke from this PR

All im asking is to just give a proper bump to the semver, im fine with the change ill make the changes to my code but dont implement a change that can break projects in a minor bump plz

npm i on the vps and projects breaks RIP!

surreal geode

You don't bump major because you want to, you bump it because it should be bumped. Typings are non-code changes

timid pewter

When a PR breaks a project it should be bumped

the question is whether or not DJS is wanting to properly support TS developers

If DJS wants to properly support TS, then it should enforce proper warnings of breaking changes that DO break TS projects. If it doesnt then thats the devs choice and right to choose and myself to live with

But come one folks, this is a pretty simple ask to not introducing breaking changes for TS devs in a non-major bump 🙏

warped crater

This is not how things work

surreal geode

This is not a breaking change. If you're extending the functionality of D.js, that's on you

warped crater

You don't bump the major version because X gets messed up by it

timid pewter

a major version is bumped when an incompatible api change is made

🎉

warped crater

correct, yet the API wasn't changed.

timid pewter

this is incompatible with the previous commit aka breaking

warped crater

just typings behaivour

timid pewter

yes it was

warped crater

this does not fall under semver major

surreal geode

@timid pewter How was this a breaking change

warped crater

no parameters were moved/removed, no methods were removed

timid pewter

The API was clearly changed, it prevents a lot of behavior

it prevents emitting events that arent listed in those types

anyone that was using that behavior which was supported by DJS broke

ornate topaz

Api didn't change. It was typings file that changed, it's not exactly part of library source code

warped crater

this, typings changes alone will never fall under anything that isnt semver patch

timid pewter

the typings are what provide the api to ts

surreal geode

It doesn't prevent anything. tsc now tells you types don't match

timid pewter

aka the api did change for ts devs

It doesn't prevent anything. tsc now tells you types don't match
No it prevents it. Bots wont start

warped crater

once again, this is not how semver works, also see what Daro said

timid pewter

TBH daro i was just hoping for a answer from a lib dev and then ill be on my way

ornate topaz

You can launch compiled code anyway, so nothing broke

timid pewter

I don't think you guys understand how working on a TS project works and how massively this PR effected end users

strange igloo

Hey, I'm implementing support for chunk_count, chunk_index and nonce properties in GUILD_MEMBERS_CHUNK on discord.js. In the event emit, should I better put count and index into an object or leave them as two separate parameters?
Like... (members, guild, { count, index }, nonce) or (members, guild, count, index, nonce) ?

slate nacelle

I think one single object would be good, in case they add more props.

wild flax

^

id also be on board with that

generally more in support of objects in all cases almost

strange igloo

One single object containing the three properties so?

wild flax

yup

strange igloo

Fine 👌

snow crypt

as for the bigints, i just wanted to know if they'll be used as they exist now, not insisting they should / must be used, but just showing the possibility

rigid trail

for snowflakes? there is no real reason to

the library has functions for extracting data out of snowflakes without using a bigint, and dapi gives snowflakes as strings

snow crypt

@rigid trail read above (like, really)

that conversion everytime seems unnecessary when thinking about it, but wouldn't it actually fit it better?

rigid trail

i agree with monbrey in saying its a useless conversion, most users dont have to do any integer things on ids, and if they do its an easy construction of a bigint

snow crypt

this is true

i also see no need to do math on ids

but the data type exists now, why not use it?

rigid trail

just because something exists doesnt mean its a good idea to use it

strange igloo

BigInt may also confuse begineers (it's already complicated sometimes as strings so I don't imagine...)

rigid trail

all the math you have to do on snowflakes theres a deconstruct method for it

there really is not much math u can do on snowflakes

snow crypt

(should there even be in the first place?)

rigid trail

what

snow crypt

forget it

rigid trail

the deconstruct is used internally too

snow crypt

timestamps, right?

rigid trail

making it a bigint is quite frankly, pretty useless for most if not all users, and detrimental, as it will be a pretty gigantic change

also inconsistent with dapi as snowflakes are strings when sent, not integers

snow crypt

aren't they strings to support languages that dont have support for 64b ints?

which now, js isn't

rigid trail

yes, but the support isnt as seamless as other languages like python, it really serves no purpose yielding a bigint, instead of a string which can easily be converted to a bigint if somebody needs it, which again, 99% of users wont need bigint snowflakes

snow crypt

actually, yeah probably

rigid trail

so this change would be:

  • Gigantic (most bots rely on the id property)
  • Pretty useless
  • Mostly just an annoyance
    Thats my take on it
snow crypt

well yeah, useless - probably

anyway, v13 would be a gigantic change on its own, so bigint snowflakes shouldn't be the thing we're afraid is going to break alot

rigid trail

just because other breaking changes will happen doesnt mean we should break things just because

realistically, what use will this bring, for most users, absolutely nothing lol, it will just be annoying

and unlike something like managers, it doesnt really have a purpose for the library itself either

snow crypt

again, just a possibility ¯\_(ツ)_/¯

lofty birch

There's absolutely no point to use bigints here, it's like making a change for the point of making a change which is really rather stupid

ornate topaz

aren't they strings to support languages that dont have support for 64b ints?
which now, js isn't
Note that BigInt wasn't "merged" into native number

rigid trail

number is still a primitive, and it still has the same size, bigint is a specialty object if you need to deal with large numbers

alpine pier

I mean people accidentally use numbers for ids already and it's causing them errors everywhere... and while you could argue that that's a beginner level problem, you can't deny that it will just bring more errors when people are trying to handle them like number, forgetting that yes, bigints are sth different

copper laurel

The fact that the language has BigInts does not make them a good or well supported option and it will do nothing to address people who use IDs as numbers. There is no use case I can think of for making the switch, and as Vlad pointed out, they need to be sent as strings to the API anyway

tacit crypt

I mean can we use BigInts? Totally! Should we? nah

alpine pier

Monbrey that's not what I meant. Messing up Bigints and numbers is even easier than Strings and numbers. And using bigints is also needlessly complicated judging by this mdn doc. So the few places where you'd want to have ids as numbers (which I can't think of rn) wouldn't benefit from it in the slightest anyways

copper laurel

Yeah I know, I was agreeing with you, or I meant to be. BigInts are not a useful implementation for us to be using

real jetty
vernal atlas

because the promises array is defined in the for loop?

exotic flicker

if you look at it, there are delays getting pushed into the promises array to delay the next loop run

real jetty

I get that. But this way the shards would spawn serially. I'm just wondering if it would be better if they spawn async?

Or am I missing something?

slate nacelle

There is a 1/5 rate limit for identifying, this avoid failing attempts at such.

real jetty

Got it. Thanks!

tawny warren

i wanted to know if the owner of a guild is always cached or not, because intents are giving me an headache with this

raven juniper

no, also a question for support channels not here @tawny warren

guild owners are guildmembers same as any other member and are subject to cache, use guild.ownerID instead

umbral aspen

Wouldn't it be logical for the GuildDelete action to use a typing method in it's condition (for example, ClientUser#typingIn()) to return a value to determine whether or not the client user is typing in the provided channel to not call TextChannel#stopTyping redundantly? Or am I missing the point here?

real jetty
dusk dagger
tacit crypt

Not everyone keeps everything cached and there's no issues having a fetch method just in case

dusk dagger

What do you mean by "not everyone keeps everything cached"? Is the cache opt-out? And so, would you recommend using fetch() over cache.get()? That was my understanding that is was the preferred approach but wanted to be sure.

tacit crypt

No, the cache isn't "opt-out" but some people might manually clear the cache

dusk dagger

Alright. But either way, the best practice would be to use fetch, right?

tough geode

not unless you modify cache. cache should always be up-to-date, as you said earlier, too.

dusk dagger

I know I'm exaggerating, but is there any way that the cache would somehow miss roles? Packet loss, problem with the Discord API, or whatever? A very rare occurrence, but still possible?

copper laurel

not really no

dusk dagger

So fetch is only there as a short-hand and if we manually remove entries from the cache, then. Got it, thank y'all

rigid trail

its also there for api coverage

just like guild manager and channel manager's fetch, its not much use to most people but some people may use it and the library should allow users to be able to use the whole api

umbral aspen

Ah, I didn't notice that. Thanks for informing me, @real jetty. \👍

snow crypt

what is the reason for dynamic in image options being false by default?

copper laurel

breaking changes most likely

snow crypt

thought of that, but why wouldn't it be true by default in the first place?

orchid stirrup

When was discord.js made?

outer night

This isn't a question exactly appropriate for this channel, but the first commit of discord.js was Aug 9, 2015

If you have more questions about the history of discord.js please ask in #archive-offtopic

ornate topaz

@snow crypt well, because it would be breaking. before dynamic you would always get an image in format you wanted ({ format: 'png' }). Since png is not gif, you get png.
To get a gif when person has it, and a png when person doesn't have it, you would have to check if avatar hash starts with a_ and pass format appropiatelly. That's exactly what dynamic does.
if it would be true by default, you would have exactly 0 idea why the hell you pass { format: 'png' } and get a gif, but only for few people.

snow crypt

didn't know dynamic didn't exist when the initial switch to functions was done, makes sense

drifting knot

discord.js-next/pull/24 is just updating a lockfile and adding 2 empty typescript files

surreal geode

It's a WIP PR. It's to track changes by that contributor

ornate topaz

Draft PRs exist, and this one isn't marked as one. is your #25 also wip for tracking, or is it somewhat ready?

rigid trail

there isnt even much you can do with the pr when there is no rest, no client, and no gateway lol

copper laurel

I should also point out that any PRs which are nothing more than a copy-pasting or port of existing code with some type annotation slapped on are unlikely to be accepted

surreal geode

@ornate topaz It's for tracking. @copper laurel I know it might not be accepted

ornate topaz

@surreal geode If it's for tracking, why is it not marked as draft? Draft PRs are unmergable until marked as ready

surreal geode

Oops sorry. It's marked as draft now

topaz mango

Should docstrings for Collection mention that sort and sorted are stable starting with Node 12?

snow crypt

Shouldn't there be a clone method for MessageEmbeds?

also freeze

more like permissions handle it

that would also prevent actual embeds from actual message be changed

topaz mango

You can already do new MessageEmbed(embedToClone)

lofty birch
topaz mango

Also, worker threads are not experimental anymore since Node 12.x

snow crypt

@topaz mango i know, but you can also do new Permissions(permissionsToClone), but as they can be frozen, the methods check for it and operate on clone if frozen

shouldn't this be done with embeds too?

also, it's non-breaking to update

topaz mango

What's the use case?

snow crypt

same as for permissions

making Message#embeds array elements to be frozen

see as GuildChannel#permissionsFor returns a Readonly<Permissions>, because both memberPermissions and rolePermissions (internal) call .freeze() on the permission before returning

slate nacelle

Making Message#embeds contain frozen elements is breaking.
As much as I'd like them to be frozen.

snow crypt

@slate nacelle how is it?

the interface would be the same

but MessageEmbed methods would check if it is frozen, and if it is - return a modified clone

again, like bitfields do

slate nacelle

They'd no longer return this but a new embed, changing it's behaviour in a non backwards compatible way.

topaz mango

Context for the question: I want to either clarify (if Node below 12 is supported) or remove the mention of sort being not necessarily stable.
Because in Node 12+ it should be stable.

snow crypt

@slate nacelle oof

well

can we have a branch for breaking changes on v12?

raven juniper

That's v13, aka next

snow crypt

but next is gonna be ts

and unit tested

and more

i mean a branch parallel to master, but that accepts breaking changes

rigid trail

but semantically that would be v13, which is djs next

topaz mango

So no further breaking changes are expected to the current codebase? Even if Discord does something unexpected to the API that needs them?

rigid trail

it is highly unlikely discord will make unexpected breaking changes to the api and require people to bump to the new api version

but no, v12 will not have breaking changes

topaz mango

By definition, yes. My question is "can there be a v13 before d.js-next gets ready".

rigid trail

im no dev but for that to happen djs-next would have to be made v14, @slate nacelle would that be acceptable in the unlikely event discord required breaking changes

slate nacelle

No clue, we'll see it if it comes.

snow crypt

@rigid trail can't it just be pre-v13-dev or something?

rigid trail

wtf its still v13

semantically its v13 and djs next would be v14

snow crypt

still feels like it should exist

copper laurel

If there is a need for a breaking change, then PR it to master and a v13 will have to be released

The one being discussed here however is really not worth a semver major bump on its own

humble wyvern

I saw, by doing a mistake in my code, that GuildMember.hasPermission(permission) doesn't throw any error when the permission isn't in the good format (for example, a typo in the permission flags).
The execution just stop silently.
I wonder if it's useful to open a PR to fix that or if it's just done on purpose? I hope it's the good channel for, if not, really sorry (don't hesitate to @ me)

lofty birch

doesn't occur for me

(owner and admins will always return true unless you specify to discount that)

humble wyvern

My precise mistake was :

message.guild.me.hasPermission("VIEW_AUDIT_LOG,MANAGE_WEBHOOKS", {checkAdmin : true})```
In guild where the bot didn't get admin permission, the execution just silently stopped without any message error (don't ask my why I did add it this way...)
lofty birch
humble wyvern

It's most probably an edge case

Strange

topaz mango

Probably you're eating exceptions somehow without displaying

humble wyvern

I log all unhandledRejection, but I will take a better look. Happy to see it's not due to d.js, and my bad k3llyOK

Thanks and sorry Sweat

surreal geode

I don't think that's how bitfields work

Pass in an array ['VIEW_AUDIT_LOG', 'MANAGE_WEBHOOKS'] instead

frozen bridge

Are Discord API endpoint changes going to be added to v11?

unique axle

Oct 7th: intents are required - will not be happening for v11
Nov 7th: domain changes are required - doesn't really matter as v11 is already not usable anymore

drifting knot

in djs 12 Manager#fetch is typed as Promise<Thing>, where Thing could be a user/channel/whatever. this is assuming that the fetch operation always succeeds and finds something. is this by design or a mistake?

rigid trail

its not assuming that, the promise could reject

drifting knot

does the promise reject when the snowflake isn't found

looking at source code, no

god i can't wait until djs next is released and i can bathe in first class ts support

opal mauve

not sure what specific manager you're referring to, but at least the channel manager seems to have the appropriate logic

copper laurel

Yeah not seeing the issue, most will include a call like this: const data = await this.client.api.users(id).get()
That handles and throws DiscordAPIErrors, so the fetch call, which is just an async function, would reject

snow crypt

Shouldn't channel type group be removed?
bots can't be added to group dms, so kinda seems like a weird choice to keep it

lofty birch

They could be added to group dms before iirc, so some still may be there

slate nacelle

Bots can fetch invites to group dms, which yields you such a channel.

snow crypt

oh, ok

snow crypt

@slate nacelle continuing the embed discussion, what if we added .clone() that just returns a new this.constructor(this)

or add freezing, but not freeze current non-frozen stuff

copper laurel

.clone() would be redundant, just construct it normally. The whole thing is currently non-frozen so you can't add freezing to it

snow crypt
snow crypt

@slate nacelle why do you check if the max listeners are not zero?

slate nacelle

Because 0 is used as "no limit", incrementing would set the limit to 1, decrementing it would throw.

snow crypt

and what about #2910?

real jetty

Would a pr that set the default id of fetch to 0 be useful ? I say that because when you do not provide anything it returns a 404 instead of 'uknown user'

rigid trail

it would be a breaking change

real jetty

Why ? 🤔

rigid trail

it changes the response

real jetty

yes I see 🤔

snow crypt

@opaque robin could you add what space requested in #4103? I really wanna see it merged

also, the d.js error is not imported

loud moat

Why doesn't it throw an argument error if you call fetch without passing an user object instead of doing a bad request?

copper laurel

This seems more like a support question, but you'd really need to be more specific about which fetch endpoint at least, there are a lot

rigid trail

that would be breaking btw, so that could not be changed either ways

loud moat

I was replying to the thing above

obsidian copper

Causing major problems with one of my shards right now, sending 3 messages per command

copper laurel

There's an open PR aiming to fix it

obsidian copper

Alright ^ ty

opaque robin

@snow crypt k I’ve just been busy with other stuff

tawny warren

i have a suggestion for a future version: a user/guildmember hybrid object without an user property

my reasoning: intents can get messy and sometimes member.user can return undefined and everything goes downhill

copper laurel

There's a few issues with that. First of all, the User and GuildMember objects/endpoints are completely different in the Discord API - they aren't a hybrid and as an API wrapper, it wouldn't be a correct implementation.
Second, while in theory a GuildMember object could extend User and include those properties, its not a good design pattern. It means we'd have to update every GuildMember hybrid object whenever a shared User property changes, instead of just the single User object which is referenced by member.user

In a broader sense about your concern with intents - I agree. The way discord.js is currently built does rely a lot on its internal caches for a lot of things, and those need specific intents in order to be filled and for that functionality to work. Making any changes to that behaviour would be huge, and almost definitely breaking. It'll be considered as part of the discord.js-next / v13 rewrite

snow crypt

@slate nacelle how is it cached?

tawny warren

isn't it there a way to iterate through getters/setters and peoperties and attach them to an object so the references are kept? or i just understand the core of references wrong?

snow crypt

you could use what is called delegation

so when you access member.tag it will actually be member.user.tag

?npm delegates

rich iglooBOT
snow crypt

but there's really no reason for that

drifting knot

i was going to write up some TS enums with pretty comments for gateway opcodes, where would those files belong in the ideal djs@next repo?

snow crypt

@drifting knot i guess it will be the types package

drifting knot

thought so

will open PR in a day or so

digital hawk

npm v7 looks like it will install peerdeps automatically

and I know d.js has peerdeps which might conflict like sodium and libsodium

snow crypt

sounds critical

maybe opening an issue would raise more attention

exotic flicker

there are some solutions in the file, I guess we would need to do some of those

snow crypt

are private props in WebSocketShard intentionally not shown in the docs?

exotic flicker

what props are you referring to?

snow crypt

anything defined with Object.defineProperty

slate nacelle

Probably not

snow crypt

pr incoming blobreach

tacit crypt

All of those are private props you don't need access to

I guess they're missing an @name although then again; you won't need those variables ever

vernal atlas

@snow crypt i think both would be the better option

the fix i suggested also fixes another issue i mentioned here a couple days ago

snow crypt

which one?

vernal atlas

to where calling suppressEmbeds throws an API Error if you have the allowedMentions client option enabled, and said message is authored by another user

tacit crypt

If the content isn't present

👀

vernal atlas

well, i tested passing undefined, but that removed the mentions

instead of keeping them

tacit crypt

That sounds like an API bug

vernal atlas

could be

tacit crypt

aka test it and report tbh

vernal atlas

ah, no i was mistaken before, both null and undefined do the same

thorny copper

I don't know if it's already been asked, but it'd be awesome to have a property User#nitroType which returns either 0, 1 or 2, as API returns, or <null>, NITRO_CLASSIC or NITRO

unique axle

nitroType requires an authenticated request (through oauth2, with the identify scope). As we do not provide any utility for oauth2 requests having such a field would not bring much if any benefit
All the information a API request from a bot for a user returns:

{
  id: '83886770768314368',
  username: 'Souji',
  avatar: 'c97d04911a8bc6f059900e913649fd1b',
  discriminator: '0001',
  public_flags: 640
}

ref(oauth2): https://discord.com/developers/docs/topics/oauth2

thorny copper

GET /users/{user.id} doesn't require oath. Otherwise, how could you return User#locale?

copper laurel

That endpoint doesn't, but when requested by a bot token, it does not return information such as locale and nitroType. Retrieving that data does require full OAuth, as Souji said

thorny copper

Then how do you return User#locale?

unique axle

the full return from that endpoint is in my initial response.
we also can not provide the locale, despite it being documented it will always be null, there used to be a dummy value for bots which was provided, however this is no longer true
the property still existing in the library is an oversight

thorny copper

Sad :c

Thanks

Can we hope that, one day, we can have support for oauth2 requests?

lofty birch

That requires a web server, which is not the purpose of djs.

unique axle

unlikely, discord.js is a wrapper for the Discord bot API
the purpose of oauth2 is to grant a token to do requests as the user, which is no longer part of the bot API
the request also requires an endpoint for the redirect

thorny copper

ok, thanks

digital hawk

maybe opening an issue would raise more attention
@snow crypt i'll open an issue when npm v7 is close to release as rn the latest seems to be 6.14.5

snow crypt

@digital hawk open it now so we can fix it ahead of time

digital hawk

ok

strange igloo

Hey, quick question regarding one of the library dependencies
The choice of node-fetch for > 12.x has any particular reason beside snekfetch being deprecated?

Okay, thanks 👌

lofty birch

Either way one that works some of the time would be better than none at all

real jetty

A fix really isn't that hard, it just seems like they made a mistake while implementing

I can PR one, I just wanted to know the reason why it got removed before I open one

tacit crypt

There will be proper rest stack traces once I get to actually re-doing my REST PR

space pls

real jetty

Ahh great! Then I won't open a PR

wild flax

It's nice that you can, but please don't be overconfident and think we didn't have internal discussions and trials before reverting it.

It wasn't "just" a silly mistake. Also theres performance implications with async stacktraces on top.

lofty birch

could be nice to have an option to use async stacktraces then, so it's off by default, but can be enabled

wild flax

No such thing without a working implementation

ornate topaz

why have a feature that doesn't work all the time? you would explicitly enable async traces, just to get that [object Object] when you least expect it

tacit crypt

Altering the stack trace isn't the solution

And it only works in v8 and not in any browsers that don't run v8b(like Mozilla or Safari)

The solution is implementing something that doesn't mess with the stack

tender field

In which case there can be multiple activities to a presence ? (=> Why is it an array (GuildMember.presence.activities) ?)

lofty birch

Custom Status + Other presence

unique axle

many more cases actually, discord just sends all activities, no matter which are displayed in the client GUI
spotify, games, code editors, custom status, etc.
this used to not be the case, but was added as feature (by discord) around the time when v12 neared end of development

tender field

oh ok thanks... ^^

maybe that should be written in the docs, because it is not really clear when this can happen ^^

tacit crypt

Simplest example would be rich presence and spotify

real jetty

has something been done about this, bots can ping roles now

i'm in a bit of a panic since this is going to lead to some serious abuse

disabledmentions doesnt seem to have anything to stop role pings right now

other then not formatting them at all

or maybe i'm just stupid

ornate topaz
real jetty

Shouldn't that mean it's off by default?

I updated discord.js quite recently so something seems off

ornate topaz

yes, by default it's not set

just like disableMentions is

real jetty

So should I just set allowedMentions to 'none' in the client

Docs said it's the default value but maybe I'm just reading it wrong

I tested and other bots seem to be able to ping as well

Oh - I figured it out. Sorry to bother aquaDerp

real jetty

Hi there, I was wondering about support for the new js runtime, deno. It hasn't hit its 1.0 release yet, so i understand if development hasn't started yet, but I think it would be interesting to see a d.js module for deno

If not, i'd be happy to help when deno gets released. good learning opportunity for me :P

vernal atlas

or at least, done in a way that emits the event

vernal atlas

g#4121

rich iglooBOT
real jetty

@vernal atlas methods that cause an event to be emitted called the handler itself as a fallback (for cases when the ws wasn't connected or w/e), the handler then has some logic that checks if its alr been handled but that seems to be missing on MessageReactionAdd. there was a discussion a while ago about always assuming the ws event would come thru and not call the handler itself but instead handle the response within the method itself to avoid double emissions (which was done on Message#delete() / TextBasedChannel#bulkDelete() a couple of months ago iirc) so #4285's approach seems fine except it needs to call MessageReaction#_add

vernal atlas

KidThumbsUp

opaque vessel

Hi hi! Would I be right in stating this thrown TypeError is improper?
https://github.com/discordjs/discord.js/blob/master/src/managers/GuildMemberRoleManager.js#L93

It has a grammatical error: TypeError [INVALID_TYPE]: Supplied roles is not an Role, Snowflake or Array or Collection of Roles or Snowflakes..

The other TypeError just above on line 85 seems fine though! In comparison, the latter TypeError includes all possiblities of the accepted types, but the former TypeError doesn't include them all which I'm not sure is intentional 😅

snow crypt

I have no idea why it would say an role and not a role

opaque vessel

The boolean adds the "n" here >:

snow crypt

thonk

ok another pr incoming

are there any other places where this happens?

opaque vessel

I'm not sure sorry 😅 I just came across this one

topaz mango

@snow crypt There are multiple cases where it's erroneously before "User"

snow crypt

@topaz mango you mean "an user" and not "a user"

topaz mango

Yes

snow crypt

where

topaz mango

2x GuildChannel.js, 1x PermissionOverwrites.js

And 2x in GuildMemberRoleManager.js as mentioned

Checked all other instances of 'INVALID_TYPE'

snow crypt

thanks!

updated

real jetty

hey another weird question, is there any planned support for guild video? or can bots not use that feature?

it would make sense if bots cant use it lol

I remember seeing a while back though that someone was working on VP9 support for d.js. Not sure if that's still happening

snow crypt

would djs@next have oauth built-in?

ornate topaz
snow crypt

👌

maybe we could have a separate library (similar to how discord-rpc is handled) for oauth?

ornate topaz
snow crypt
ornate topaz

i don't remember discord's oauth changing much since then

also, it's a module for passport-oauth2, which is a module for Passport, which is not a small project anyway, and actually made around auth

copper laurel

it hasnt, its also just a tiny number of endpoints

snow crypt

but js' interface has

ornate topaz

ok?

doesn't mean we have to fork and rewrite everything every year

snow crypt

Is there a way to type bitfield flags better than having public static FLAGS: Record<BitFieldString, number>; in every bitfield class?

if it was not static maybe we could have public static FLAGS: Record<S, number>; on the base bitfield class, but i'm not sure typescript would allow that

vernal atlas

like this? yeah thats not a thing

snow crypt

👍

noble magnet

Will discord.js be compatible with deno ?

copper laurel

We don't know. We haven't tried. If it isnt compatible at this stage we have no plans for it

strange igloo

Having a deno-compatible library would require discord.js to get rid entierly of the "CommonJS" module format (require/module.exports) so I'd say that it's dead already for v12
However, I think v13 would be deno-ready with some tweaks (there could be a community fork ??)
But anyway it's not recommended to run production apps with Deno yet as it is still young
This also assumes all dependencies used by discord.js would be deno-ready too

warped crater

v13 is being built on Typescript either way

so Deno support should be much less of a hustle there

copper laurel

The current answer is still very much "no plans, hasnt been discussed"

lofty birch
outer night

yeah we were aware, a patch will be released

deep heart

I am currently on discord.js version 11.6.4, does version 12 have any must have improvements in speed or something for me to try refactoring ?

exotic flicker
  1. not a topic for this channel
  2. there are improvments, but d.js 11 will break anyway as soon as discord enforces intents
deep heart

so i am forced to refactor it, fluck !

ornate topaz

also there are features which v11 simply doesn't have

fallen arrow

is there a reason for not implementing GET guilds/:id/channels?

real jetty

All channels (except for DM, which is user.createDM()) are always cached, so there is no need to fetch them

But client.channels.fetch(id) is a method on V12

fallen arrow

yes, but for the sake of api coverage

real jetty

That could be said about more stuff, kicking a member with ID directly and editing an uncached message with channel and message ID for example

fallen arrow

fair enough

vernal atlas

~~you could always use the (private) client.api for making requests to endpoints not covered

eg: client.api.channels(id).get(), or client.api.guilds(id).members(id).delete(); (kicks a member)~~

mb, read below

unique axle

do note however that you should not use (or suggest) the use of private apis for production applications as they are not part of the guarantees semver provides.
even a patch level update to the library may heavily change behaviour of or even move or fully remove private properties and methods without documenting the change in any changelogs

simple veldt

Hello
Is someone working on the templates? I see there is a PR for discordpy

copper laurel

No, bots do not have access to that endpoint

tacit crypt

Bots can only fetch templates via /guilds/templates/:id

unique axle

the PR in question (probably https://github.com/Rapptz/discord.py/pull/2652) does just that, for us that'd be accept a "template" field in guild creation options, fetching the template data and posting it with the guild creation (maybe allowing overwrites through other options so you can adapt and build on top of the template)

calm garnet

What does discord.js use for caching?

rigid trail

collections (extended maps) managed by managers

calm garnet

Hmm, alright.

Same for previous versions? v11, etc?

rigid trail

no, v11 and earlier didnt have managers

calm garnet

What did they use?

rigid trail

just collections

calm garnet

Ah, alright.

broken oak
loud moat
unique axle

As per usual discord.js merges upstream changes once their documentation is finalized and merged
That's a misconception on your or that other persons end. This endpoint is not supposed to solve a global lookup, but make a guild member lookup work without requiring intents as per nights reply

strange igloo
warped crater

mdn, object.defineProperty

rich iglooBOT
warped crater

you'll see this used very often, it can allow for special behaivour, like making the property actually readonly writable: false (Which even results in an error if you try assigning in strict mode! otherwise just wont let you mutate), perhaps ennumerable, or just about anything

It is generally a good practice.

strange igloo

Yes I know but in that case we just set its value to 0 and set it writable (aren't this.props things writable already... ?)

warped crater

Please see the mdn page, this does have a positive effect as with the passed options connectedAt is configurable: false & enumerable: false implicitly

probably few other defaults im forgetting about

otherwise its probably just for consistency in the said constructor, d.js likes doing things the same way across the board (which is great)

strange igloo

Oops my bad I didn't see the default values
I understand now

Thanks 😅

warped crater

blobcatthumbsup

tacit crypt

TL;DR: Almost anything that is set via defineProperty is done that way to be non-enumerable

vernal atlas

why doesnt allowedMentions use UserResolvables?

slate nacelle

It wasn't reliably possible to reference an isntance of UserManager (I think for WebhookClient).
Maybe it would be possible to refactor those (*Manager) to offer a static method to resolve to ID.

vernal atlas

ah right

what about accepting user / guildmember objects?

slate nacelle

The same reason, I'd rather not duplicate resolving logic (further).

vernal atlas

oki

lofty birch
raven juniper

Afaik the API does not provide that sort of data. You can parse it yourself by looking at the file extension

cunning flint

hm okay, then it would be like Message#cleanContent method for example. It's not an information provided by API, but a method used to make things easier for developers.

But I understand your choice ^^

ornate topaz

file extenstion in no way represents actual file type, yyou can take an .mp3 file, rename it to .pdf, but it doesn't magically make it a pdf.
Only way library could do that would be looking on extension, which from this reason could be inaccurate and misleading.

snow crypt

@wild flax removing the change from my pr to avoid the conflict would just be removing it from package.json, right?

wild flax

yes

well

just dont change the package.json is what i mean

snow crypt

okay

done

snow crypt

can we maybe expose the regexp in DataResolver#resolveInviteCode somehow?

such as Invite.PATTERN similar to MessageMentions'

viscid wasp

Do you think we'd ever get a Deno version of Discord.js?

unique axle

ctrl + f -> in:#library-discussion deno

snow crypt

my question got buried :(, can anyone give an opinion?

simple veldt

Hello
I'm using Discord.js with a jsdoc project, and I was getting the following error:

I added raw: [any]; to the ClientEvents interface, and it worked. Can I open a pull request to fix this or is that normal?

unique axle

raw is an internal, unsupported and undocumented API and should not be included in typings

simple veldt

All right
So it means we can't use this event using typescript... (or jsdoc in my case)?

unique axle
simple veldt

I'm using this event in a package published on npm, and it's hard to tell people to pass a partials array when instantiating their Client class + if they are using the messageReactionAdd event somewhere, to check if the received param is not a partial object... it's a regret that it is not documented because it was still quite useful to me but I understand, thank you for your answer 👍

unique axle

making third party packages that heavily rely on private and unsupported apis might not have been a good idea to begin with, they're not part of semver promises and might even be removed in path releases

simple veldt

Yep
telling people to enable partials for the messageReactionAdd and messageReactionRemove event would probably be a better solution

real jetty

https://github.com/discordjs/discord.js/pull/4162

what is the reason for the negative feedback on this PR? I personally like the idea, as it would make using custom events much simpler. Of course extending the interface is pretty simple but an inconvenience and as appellation said IDE auto complete should still work even after merging this

snow crypt
wild flax

I don’t understand the question. The reasons why are commented on the PR?

crimson harbor

tl;dr: It has little to do with IDE autocompletion, they just want to discourage people from emitting custom events at all.
But since the PR is still open, you can leave your comments there and it might convince some more of the devs.

copper laurel

That's a bold assumption which is mostly conjecture. Its not a discouragement - it just forces people to strictly type their custom events by extending the ClientEvents interface themselves, rather than add an openly weak typing to the interface.

halcyon field

Discord current fetch message method isnt practical, there should be another option (like the limit: x) that allows you to only fetch messages from a specific user.
the issue with using the method as it is nowt is that you're limited by the messages fetched, that includes messages sent by another user so the messages the max messages fetched sent by the user you want is actually inferior to the max amount of messages fetched, on the other hand (mabye) having a specific option would allow us to have a limitation of fetched messages, yes, but all those messages are by the user you want them from.. no unnecessary messages, so there is no loss in max fetched - correct return

ornate topaz

as far as i know, API does not give a way to fetch this way

merry python

yes, this is an api limitation which discord.js on its own can not solve

you'll have to request that feature from discord itself

halcyon field

I see, thanks for the advice

opaque copper
vernal atlas
undone ravine

Look at the master branch

vernal atlas

im looking at the master branch?

undone ravine

Ok, yes it should

vernal atlas

but, why is it like that?

undone ravine

Because it used to be like that

vernal atlas

so the typings just havent been updated when the class itself was?