#archive-library-discussion

25217 messages · Page 13 of 26

opaque vessel
#

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

#

:thinking:

wild flax
#

Huh

strange igloo
#

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

opaque vessel
#

Well it works as documented, apparently

#

Oh never mind

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

#

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

wild flax
#

They may have changed that

void rivet
slate nacelle
#

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

strange igloo
#

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

slate nacelle
#

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

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

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

outer raven
opaque vessel
#

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

outer raven
#

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

icy bronze
#

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

opaque vessel
icy bronze
#

I could suggest to discord to add an option or sum

void rivet
strange igloo
#

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

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

void rivet
icy bronze
void rivet
icy bronze
#

o

#

I see now

void rivet
obtuse hazel
icy bronze
#

then yeah mine doesn't fits

strange igloo
#

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

icy bronze
#

its called list guild members. GuildMemberManager.list()

#

👍

#

wait isn't the enpoind the same

void rivet
#

no, the one implemented uses request guild members

icy bronze
#

oh yeah right

void rivet
obtuse hazel
#

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

outer raven
void rivet
#

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

obtuse hazel
#

It would allow fetching members without a websocket connection

#

It's worth for some use cases

void rivet
#

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

icy bronze
#

thats how I see it

strange igloo
#

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

void rivet
#

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

vivid field
#

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

#

but additional api support doesn't hurt

opaque vessel
void rivet
#

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

icy bronze
void rivet
#

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

copper laurel
#

No

rustic boughBOT
copper laurel
#

Uses the REST endpoints

void rivet
copper laurel
#

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

void rivet
#

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

copper laurel
#

Eh, I guess so

void rivet
#

So was that a yes? :D

copper laurel
#

Yeah why not

dawn merlin
lusty bolt
#

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

warped crater
#

native abort controller

lusty bolt
#

ah i see. cool

real jetty
opaque vessel
real jetty
#

Hm alright.

empty viper
slate nacelle
empty viper
#

Oh I see, neat !

wild flax
#

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

#

the search one might be an oversight

void rivet
wild flax
#

we cant do that sadly

#

since it would be semver major

#

but we can make sure to not repeat the mistake

#

and make sure your PR doesnt set one

#

👀

void rivet
#

Okay 👍🏻

#

I'll test it first just to be sure

#

Should it mention that the api defaults to 1?

wild flax
#

Nah

#

The defaults we list are lib defaults, never api defaults

void rivet
#

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

wild flax
#

ok you know what

#

that might be better for a v14 change then

#

lets just roll with a default then

void rivet
#

So now I revert back to setting a default value?

wild flax
#

😆

#

I'm sorry haha

#

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

#

Looks like well have to fix a lot on that front

void rivet
#

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

wild flax
#

You can just make a new commit readding it

#

since we squash commits anyway

#

so in the end it will be 1 commit regardless

void rivet
wild flax
#

nah we can leave that

void rivet
#

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

#

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

void rivet
pale seal
#

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

vivid field
#

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

pale seal
#

Hmm, not enough an expert for that xD

shut wave
#

Not necessarily an issue but why is type optional in:

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

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

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

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

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

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

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

#

And thats really what those options are for

#

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

#

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

shut wave
#

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

#

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

copper laurel
#

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

#

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

#

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

shut wave
#

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

copper laurel
#

Nah it really shouldnt

#

Whats the benefit of that?

#

Well actually, it does do that

#

But it can only do that if you set the type

#

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

shut wave
#

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

#

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

shut wave
outer raven
wild flax
#

Thats literally what I was saying

outer raven
#

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

#

And that’s done on some occasions

wild flax
#

yes

outer raven
#

Not many tho

wild flax
#

yes

#

and we can't change it in v13

outer raven
#

Really?

#

But the behavior is the same

wild flax
#

Think about it for a bit

outer raven
#

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

copper laurel
wild flax
outer raven
#

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

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

likeliness doesnt matter

#

and yes we dont

#

thats the problem

#

it would then be undefined behaviour

outer raven
#

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

wild flax
#

theres more

#

And a lot of those things are remnants

#

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

#

and since the last major no one noticed or bothered

outer raven
#

Ah I see

#

So it can be changed

#

Can u tell me what are the other ones?

wild flax
#

No, it can’t be changed until v14

outer raven
#

Yeah ik

wild flax
#

search is also one of them iirc

outer raven
#

But it can be changed thats what im saying

outer raven
void rivet
shut wave
copper laurel
#

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

outer raven
#

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

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

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

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

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

wild flax
#

I'm glad you don't design this lib

#

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

copper laurel
#

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

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

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

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

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

wild flax
#

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

#

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

#

And you are welcome I guess.

shut wave
#

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

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

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

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

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

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

wild flax
#

Yeah, and we decided against doing that.

#

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

#

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

#

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

ornate topaz
#

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

shut wave
ornate topaz
#

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

shut wave
#

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

#

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

ornate topaz
#

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

wild flax
#

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

#

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

#

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

shut wave
#

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

Same principal though

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

wild flax
#

I see no issue open about it?

#

Nor a reproduction case

#

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

shut wave
#

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

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

wild flax
#

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

copper laurel
#

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

shut wave
copper laurel
#

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

#

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

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

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

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

copper laurel
#

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

#

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

shut wave
#

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

copper laurel
#

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

real jetty
#

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

slate nacelle
#

I think it's only provided for bots.

real jetty
#

ah alright

quiet viper
#

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

slate nacelle
#

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

quiet viper
#

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

#

Okay, never do this...😅 thx

hollow crest
#

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

slate nacelle
#

Yes

hollow crest
#

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

slate nacelle
hollow crest
#

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

outer night
#

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

#

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

slate nacelle
#

Oh, I should have just linked to there. msclap

hollow crest
tired valve
stray delta
#

nvm misread

hoary ether
#

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

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

oak quail
#

well itll only update in the current guild

hoary ether
#

right

#

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

wild flax
#

not really but it might fail a few times

#

until its updates

#

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

hoary ether
#

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

#

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

oak quail
#

yes

real jetty
#

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

unique axle
#

yes

real jetty
#

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

unique axle
#

yes

real jetty
#

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

rough roost
copper garden
rough roost
strange igloo
#

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

brisk remnant
#

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

copper garden
#

So what? It saves 131 kB

#

That would not be noticeable as a backend dependency

solemn oyster
#

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

dawn basalt
#

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

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

sendable ?

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

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

#

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

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

opaque vessel
#

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

solemn oyster
#

Then we'll stay v2, no biggie

real jetty
#

Remove self bot ability

hoary ether
#

apparently there's no .deferReply() method?

vernal adder
#

Is just a bug

#

It exists

#

You can see it on the other interaction types

hoary ether
#

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

ornate topaz
#

main and stable are branch names

#

main was master earlier

#

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

hoary ether
#

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

ornate topaz
#

yes

hoary ether
#

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

ornate topaz
#

it is

#

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

#

might be related

hoary ether
#

ah i see

#

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

ornate topaz
#

docs were generated from source code, properly

#

it's just that the source code was missing something

#

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

vernal adder
#

usually doesn't happened, and gets fixed quickly

hoary ether
#

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

#

thanks for the quick replies tho

bitter peak
#

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

ornate topaz
#

typings are done manually

#

and it's js lib

#

that might be misleading thing to say

bitter peak
#

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

ornate topaz
#

not really, but whatever

copper laurel
#

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

dawn merlin
#

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

copper laurel
#

Not really no

#

jsdoc is to document JS, not TS

elder reef
#

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

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

dawn merlin
#

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

#

You need to use the exported Constants object

elder reef
#

Ah ok

sharp wigeon
#

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

#

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

wild flax
#

did you install @types/node

sharp wigeon
#

hmm ill try that

outer raven
#

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

#

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

#

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

#

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

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

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

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

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

outer raven
icy bronze
#

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

#

if you know how I can fix

#

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

tacit crypt
#

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

#

basically like what the prepare script it

icy bronze
#

so prepublishOnly script then?

wild flax
#

yes

#

but no need to run the tests

#

and you need to do npx anyway

#

since you prolly dont have our dev-deps installed

icy bronze
#

I think ye

#

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

#

ok nvm I read it wrong lol

#

thanks i'll try it out

#

yay worked HYPE

urban mist
#

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

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

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

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

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

slate nacelle
#

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

wild flax
#

Yeah that doesn’t seem like it is intended

urban mist
#

Got it, thanks guys

strange igloo
dawn basalt
loud jayBOT
#

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

strange igloo
raven juniper
outer raven
#

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

wild flax
#

No

outer raven
#

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

wild flax
#

Because its a disastrous diff

lofty birch
#

Spaces are much worse for accessibility

outer raven
wild flax
#

Eventually

dawn merlin
#

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

oak quail
#

builders not supporting that is an issue

outer raven
#

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

slate nacelle
#

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

outer raven
#

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

zenith oracle
#

^^

outer raven
# zenith oracle ^^

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

zenith oracle
#

Well, i see it in the docs, wdym?

outer raven
copper laurel
#

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

#

Its missing {@extends Presence}

#

Which is where the actual methods should be

faint current
#

@solemn oyster easy:

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

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

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

#

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

solemn oyster
#

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

faint current
#

👀

solemn oyster
#

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

wild flax
#

Man you are the whole circus and every clown in it

faint current
#

Cause I care about performance while using Node?

wild flax
#

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

#

Which are bot invalid statements right there

#

Barely any HUGE bot uses JS in the first place lol

faint current
#

And what d.js shown then?

faint current
wild flax
#

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

copper laurel
#

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

faint current
#

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

#

Idk about other

#

Mudae & Karuta used D.js

faint current
#

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

copper laurel
#

Good for them. Different libraries for different purposes then I guess. discord.js is a very well documented, easy to start with bot library that is the most popular for a reason

faint current
#

I already said that D.js is good when you learn or don't know what to do but at scale, for more experienced things people switches to Eris or other its forks

#

Cause many people also works every day on forks

copper laurel
#

This is still not on topic of this channel

Serious discussions about developing discord.js

solemn oyster
#

Ok, and how do we improve that?

#

Lay out a plan

wild flax
copper laurel
#

I'm waiting to see any serious suggestions, other than modularisation which we've indicated is happening

wild flax
#

And we reached that, hence our popularity.

#

The problem with "big" bots, is sadly also 90% of the time on the developer

#

Bot devs aren't the smartest or greatest, neither do they develop bots with "scale" in mind, they just write a bunch of code and suddenly need to support 400k server usage

outer raven
wild flax
#

Neither do they update d.js very often, so in the end they use their own fork with their own modifications

icy bronze
#

is there any plan on adding InteractionOptionResolver to sub command options?

copper laurel
icy bronze
#

oh?

#

so I use it like I would with top level options?

copper laurel
#

There can only ever be one subcommand or subcommand group selected at a time, so the getThing methods are for that subcommand

#

And getSubcommand() tells you which one

icy bronze
#

damn yeah thats obvious

#

alright thx for answering

copper laurel
outer raven
#

yeah I'm adding that and I'll leave set as public, will see what the reviews say

loud jayBOT
#

pr_open #6450 in discordjs/discord.js by ImRodry opened <t:1629066437:R> (review required)
types(ClientPresence): add type declarations and docs
📥 npm i ImRodry/discord.js#types-clientpresence

strange igloo
#

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

I would like to know what would be a better alternative tbh Thonk yes hash maps internally takes more RAM compared to what it actually stores, but they are also super efficient to work with.

Using plain arrays would be suicide for bigger bots, as looking for a specific item would require a function to be ran up to n times (assuming Array#find is used - but n iterations with a for-loop leads to the same problem). I don't know exactly what would be the performance drop but there would surely be one, Map wasn't invented without any reason behind.

sent back with Souji's permission

ornate topaz
#

i don't think it was necessarily asked "why store everything in collections" but more of a "why store everything in collections".
in which case i'd assume "<some other library> that doesn't cache anything at all is automatically better, because hugest of bots, duh"

vagrant holly
#

Signed, a dev that works on Rythm

ornate topaz
#

(that might take a while, given that they were muted for 3 days)

vagrant holly
dawn basalt
#

Is there a plan on replacing TSLint with ESLint?

#

TSLint has been deprecated for a while now.

solemn oyster
#

Yes, whenever we rewrite d.js to TS

fallow crater
#

iirc there is/was an issue open about that

loud jayBOT
tired valve
#

you need the channel partial for that to work.

outer raven
ruby terrace
#

I saw (heh, edit pings don't ping), I'll get it in for the next minor

real jetty
#

How long does djs cache messages for?

oak quail
#

by default it caches up to 200 messages per channel, and they do not get sweeped

#

but you can change the limit and the sweep settings in clientoptions

hoary ether
#

do we have plans for a slash command permission builder in /builders?

real jetty
loud jayBOT
#

pr_open #19 in discordjs/builders by Fyko opened <t:1628378012:R> (changes requested)
feat(SlashCommandBuilder): create setDefaultPermission function
📥 npm i Fyko/djs-builders#feat/setDefaultPermission

hoary ether
#

that's the defaultPermission. i was referring to permission overwrite

#

the object you would pass to GuildApplicationCommandManager.permissions.set() or .add()

ruby terrace
#

not a bad idea, kinda thought that was already in there. though they aren't that complex, and I wouldn't want to do it now when we've been told permissions are going to be overhauled

hoary ether
#

oh ouh

#

discord making a lot of rapid changes with this new interaction feature

ruby terrace
#

to be fair everyone has been complaining a lot about permissions

real jetty
solemn oyster
#

Is that a serious question?

#

Do you know how many bugs we had, over and over, because mismatching types all over the library, specially when we do breaking changes?

#

Besides, most of the development team are TS users, it's almost a miracle we can maintain discord.js at all, because we find JS hard to maintain

hoary ether
#

isn't the ts rewrite repo archived now?

solemn oyster
#

No

#

Just put on hold, we're working on /modules first

hoary ether
#

last i check it was.

#

ah i see

#

im assuming all the new modules like /rest and /builders are all written in ts?

solemn oyster
#

I mean the djs rewrite [was put on hold], the /modules has been progressing... slowly

real jetty
solemn oyster
#

Yeah, we're not starting new projects in JS

#

We're writing them all in TS since the very start, due to the aforementioned reasons

real jetty
#

But it's still going to use everything in js like sapphire, or?

copper laurel
#

The modules are essentially the component parts of a djs-rewrite, which will tie them all together

solemn oyster
copper laurel
#

Sapphire is TS I'm pretty sure

solemn oyster
#

It is

real jetty
ornate topaz
#

TS is not C#, it's not entirely different language.
It's just a superset of JS that adds types and everything around that, and it transpiles back to JS

dawn merlin
#

Also in addition to the other reasons given the typings in some areas are more specific than the jsdoc.

solemn oyster
#

Oh yeah, documentation with examples and everything in IntelliSense, the best part of TS libs

real jetty
#

So it won't limit discord.js users who work in JS in any way?

hoary ether
#

it shouldnt

ornate topaz
#

If it goes back to JS, why would it

hoary ether
#

there are tons of npm modules out there written in TS, and u can import them to ur js project and use it as js just fine

ornate topaz
#

You don't run TS at all, so it's all JS anyway

real jetty
#

Ok, then it's fine that it doesn't limit users in any way, it just adds more TS stuff to users.

real jetty
solemn oyster
#

And far better typings and documentation

dawn merlin
#

Microsoft does list TS as a language tho, not a framework. I don’t think just because it transpiles to JS it can’t be considered another language. Most truly compiled languages all technically transpile to VM bytcode or asm. That doesn’t mean asm and other compiled langs are the same language.

ornate topaz
#

JS is its limiting factor, they cannot change that due to nature of TS. All JS is valid TS.

real jetty
#

So then are you going to redo @discordjs/docgen to generate as well or use a completely different generator? (docgen uses jsdocs)

dawn merlin
#

JVM is the limiting factor between java and kotlin. They’re still different languages.

ornate topaz
#

ok you win, what did you want to prove again? This wasn't relevant to the convo at all.

real jetty
#

okay

copper laurel
#

You're literally responding to a discussion about how the docgen needs to be rewritten for TS while asking where the documentation for the TS modules are?

copper laurel
#

Not yet no

real jetty
vivid field
#

so that it doesn't have a constructor

empty viper
#

why not using a namespace ?

bronze sigil
vivid field
#

because the docgen doesn't parse that

outer raven
#

I commented on #6456 saying it wouldn't make much sense and would be hard to implement logistically but after giving it some thought I have an idea of how it could work but since it would involve returning a different object I'm not sure whether you guys would want this or not so I'd like to put this here for discussion before opening a PR

loud jayBOT
copper laurel
#

Yeah, not a fan of it returning a different object, like I said in that

#

raw access to resolved is available now, you can check for the existence of users/roles in that

outer raven
copper laurel
#

In a sense

outer raven
#

unrelated but if we want to link a static property (like FLAGS in MessageFlags) do we write it with the # like any other property or does it need to be referenced differently?

ionic plaza
#

The parameter name for Message.edit() is content, which is inconsistent with Channel.send() and other functions for sending messages (options). I'm assuming that this is a leftover from v12. Bug?

wild flax
#

Parameter names are honestly quite useless in JS

#

No such thing as named parameters

#

Wouldn’t really categorize this as a “bug”

ionic plaza
#

Maybe not a bug, but seems a bit off

#

Especially with VSCode's new parameter thingy

#

Hardly the end of the world 🤷

outer raven
#

how do you enable that

#

a few days ago a PR was opened to fix sth like that so if you have the time you could also do that yourself (considering that new feature)

#

but tbh the bug here is with options imo, it should just say content

ornate topaz
#

"bug"? it's just a name, really, it affects 0 code whatsoever

fallow crater
outer raven
ornate topaz
#

???

#

does that option break the library?
runtime errors?

outer raven
outer raven
ornate topaz
#

then there is no bug. it's just that this is kind of the first time the name is actually used somewhere outside of the documentation, where even there it's just "options" on one line, and "options.something" on another, so you know it goes inside the object.

outer raven
#

You understood what I mean why is it such a big deal

ornate topaz
#

it might be an issue or inconvenience, not a bug

outer raven
#

😐

ionic plaza
#

If nothing else, parameter names should be consistent to avoid mistakes when developing D.JS

ornate topaz
#

idk man

fallow crater
#

It's something very minor, but if it's really needed, I can create a PR lol

oak quail
#

the thread permission getters are really broken wew

ruby terrace
#

how so

oak quail
#

editable and sendable both checked the old private thread type

#

sendable checked this.archived instead of this.archived && this.locked && !this.manageable

#

also why do all the permissions.has calls pass false to checkAdmin? shouldnt it be true?

ruby terrace
#

no, admin overwrite does nothing

ruby terrace
ruby terrace
#

none of that really matters anyways since they're getting redone

oak quail
oak quail
#

is there a djs bug?

ruby terrace
#

no

#

you also can't rename the flags without a major release

oak quail
#

ah... right i forgot about that

ruby terrace
#

let me see if I can find a good screenshot of the checkadmin thing

#

Okay, no good screenshots, let me explain. Channel overwrites can set the bit for admin but it doesn't do anything, the library already checks role perms for admin and splits it to all permissions before it gets to overwrites so all permissions are still granted when you have admin on the guild level. Setting it to false prevents returning true when the permission does not actually do anything.

oak quail
ruby terrace
#

the return value of that

oak quail
#

ah right blobfacepalm

#

so are users just expected to set it to false when checking channel permissions?

ruby terrace
#

not really, I'd consider it good practice, but its an exteremely rare edge case where someone had to intentionalyl add an overwrite with the admin permission via the API, you can't do it in client

unique axle
#

well, the issue really is not with checking channel permissions, because that's a tiny tiny use case
the issue is with checking permissions after overwrites, which should still factor in the global permissions
because the API accepts and sets overwrites for 8, even propagates them and additionally completely ignores them in the client

#

so you can end up with an 8 overwrite you can't remove without a bot, just because some bot screwed up overwrites, which however messes up all the perm calculation of other bots

wild flax
outer raven
low tide
#

I'm unsure if this is the right channel, or if it's a bug, but I get an INTERACTION_ALREADY_DEFERRED error (or something like that) whenever there's a small error in my code, such as a syntax error.

outer raven
low tide
#

I'm not deferring the same interaction twice. It only happens when I have a syntax error or similar small error.

outer raven
#

you are, you just probably don't know where, go on that channel and show your code, this channel is for developing djs

low tide
#

I don't appreciate you thinking of me as an idiot, I never get that error if I don't have any syntax errors in my code

outer raven
#

if I had to guess you have an error handler which defers interactions. Either way please don't continue this conversation here and move it to the channel I mentioned

low tide
#

No. I don't.

# 
const Discord = require("discord.js");

module.exports = {
    name: 'ping',
    async execute(client, interaction, options) {
        await interaction.deferReply({ ephemeral: true });
        consle.log('test');
        await interaction.editReply({ content: `Pong! \`${client.ws.ping}ms\``, ephemeral: true });
    },
};

Note the consle. I don't have any code that defers this interaction before I execute the command file.
And this is the error I get: https://cdn.danielcatkins.studio/WAIh4OcwVb.png

Fix the typo:
https://cdn.danielcatkins.studio/Ze9AsRc8pE.png
https://cdn.danielcatkins.studio/hHvq7fufG5.png

outer raven
low tide
#

I don't have an error handler, but thanks. I'll make a reproducible example.

outer raven
#

Disabling the emoji manager completely breaks reacting to messages with guild emojis, should this be documented?

opaque vessel
outer raven
#

if you wanna see the error stack

#

would be nice if we could see what was actually sent to Discord but that's all I got

#

also please don't disable pings when replying

opaque vessel
opaque vessel
#

Did you provide an actual guild emoji object?

outer raven
outer raven
opaque vessel
#

Crashed with just the id

outer raven
#

yeah that's the issue then

#

because it tries to get the emoji from cache

opaque vessel
#

I think that's not something to document then? It clearly worked with the full custom emoji string, so it should be possible

#

Sounds more like a bug

outer raven
#

but why is it even doing this if we only need the id to react?

opaque vessel
#

Yeah, exactly

outer raven
#

can you look into it to see if it's possible to fix? I'm not really sure and might break something tbh

opaque vessel
#

So yeah, the problem is as you said, it's trying to get the emoji from the cache. This is intended, because emojis need to be URL encoded and sent across as a name:id format per the docs. If we only know the id, well, we don't have the name and that's pretty much what the cache check is for. I guess a way to ensure this works is to force-fetch the emoji somewhere. It'll fetch from the cache if already available, so

next bobcat
#

On v13 release ownerID was converted to ownerId, however the .displayAvatarURL method did not get the camelcase treatment. was this on purpose?

opaque vessel
#

URL stands for uniform resource locator. Id stands for identifier. It's fine

next bobcat
#

interesting

#

i was wondering if something like that was the reason

outer raven
opaque vessel
#

Yeah it's just a caching problem in general. If the bot isn't aware of the custom emoji (but has access to it) and you provide only the id, it'll fail

outer raven
#

Alright I'll just keep that cache enabled then, no worries

opaque vessel
#

I mean if you know the custom emoji beforehand, you could fetch it then use that, but unsure if this is... fixable

ruby terrace
outer raven
ruby terrace
#

it...does?

outer raven
#

and that was the full stack trace

oak quail
#

hmm

#

would making invite.channel nullable be considered a breaking change

#

if it currently throws an error where it would be nullable

copper laurel
#

Technically yes

#

People would be catching that error, not checking for null

oak quail
#

so support for fetching it cant be added until v14?

#

or would it have to be, like, an option to allow it for now

opal mauve
#

you could enable the new functionality with an option that can be removed in future versions

brisk remnant
#

How many digits are in a discord snowflake?

visual hornet
#

17-18, 19 in 2022, 20 in 2090
so 17-19 is sufficient for now

quiet viper
outer raven
quiet viper
outer raven
#

I’m pretty sure it does

wild flax
#

No

#

You can even do :_:12312312333123123123123:

#

Do you not test this before you say something

runic leaf
#

Installing @discordjs/opus returns an error

#

Can someone else try it and inform if they're facing it too?

analog prawn
#

Its @discord.js/opus

#

I think

wild flax
#

No its not

#

And without knowing the error god knows whats wrong

analog prawn
#

Not sure then.

#

I remember installing it once.

#

I need to find how i installed it.

analog prawn
outer night
runic leaf
analog prawn
wild flax
#

You are being so unhelpful its incredible

runic leaf
wild flax
#

Thats it? Nothing more?

runic leaf
#

it doesn't shows the entire log

#

bugged

#

the log is huge

wild flax
#

Well, with that alone no one can help you

patent cedar
#

Did I miss something or is BaseCommandInteraction#deferReply missing in the docs?

real jetty
#

Is it really necessary for everything a djs caches to be cached?

raven juniper
#

guilds is probably the only thing that "needs" to be cached for d.js to work properly a few caches should be kept for d.js to work properly, but they should overall not be that memory intensive. that's the point of adding the option to limit caches in v13, you can limit what is kept in memory otherwise

real jetty
void rivet
#

Overriding the cache used in GuildManager, ChannelManager, GuildChannelManager, RoleManager, and PermissionOverwriteManager is unsupported and will break functionality
other than that, it's judging by your use case and what you need

bitter peak
#

@copper laurel regarding #6469 (the resolver properties) I think we've been over this before like five different times already and the consensus every time is to just expose the method. But for the hoistedOptions, I could see that being useful, but maybe as a separate PR. What do you think?

swift trellis
wild flax
#

#6469 is pointless

#

We have .data to work with the data if you want to do your own parsing

swift trellis
#

Do you know the date?

swift trellis
#

But will it stop working? Or will it simply not be supported?

#

It really says: "Doesn't look like anything to me" that's why I don't quite understand it

#

@real jetty ^^

unique axle
#

v7 was a non-public api, yet a lot of people and libraries used it, because it had some much needed improvements
the API version has moved on to 9 in the meanwhile and accordingly the older versions 6 and 7 will stop working eventually™️
so while it still works for now, that won't always be the case and a swap should be made, which we did by progressing our library towards using v9 with version 13 of discord.js

copper laurel
copper laurel
loud jayBOT
copper laurel
#

Not sure if you're in this server but to answer why:

  • No top level await, so the snippet is incorrect
  • awaiting client.login() doesnt guarantee everything is ready to go, thats what the ready event is for
  • we wouldn't want to use the ready event either, we're intentionally discouraging people from setting commands on ready
  • @discordjs/rest doesn't require logging in an entire Client instance, which populates caches and connects to the gateway and various other overheads
outer raven
# copper laurel Not sure if you're in this server but to answer why: - No top level await, so t...

that PR doesn't seem ideal to me but neither does the current suggestion
Since this is shown as the most basic way to deploy commands, most users end up blindly copying it and have absolutely 0 clue what they're doing (because this is too advanced for the average user of the help channels), then come crying to #djs-help-v14 because something doesn't work
I think that once #6414 is merged the suggested code should be updated to run on the ready event and compare local commands with discord's commands and only edit them if changes are found, which is a much more reliable way and doesn't spam the API

copper laurel
#

I disagree, theres still no reason to be doing all that processing on ready

#

The "average user of the help channels" is a bar far to low for us to realistically aim for

#

People are always just going to copy and paste

outer raven
#

but the point of having this example is so that users can have some basic code to base themselves off of when starting using slash commands. The issue with deploying on ready was the API spam from what I understood and that PR fixes this

copper laurel
#

Not really no

outer raven
copper laurel
#

Yes

outer raven
#

unfortunately so, but I think providing code snippets this complicated isn't ideal

copper laurel
#

There's genuinely nothing complicated about it, it just dares to address a concept in a different way to the core discord.js library. It's otherwise an incredibly simple code snippet.

outer raven
#

Yeah but it involves installing another package that most users aren't familiar with, isn't properly documented (to my knowledge, correct me if I'm wrong) and is mainly used internally by the library or by people who actually know what they're doing.
The code snippet may be simple, but people don't know what they're doing and why they're doing it that way, which they should when using an example

copper laurel
#

Performing a delta would require

  • fetching commands, at least one API call to global, maybe more per guild
  • O(n) processing time to do a deep equality check on them all
  • 1 or more .create() calls per command where changes were found
#

Thats still quite a bit of API usage

#

The core of the concept is manually choosing to deploy your command changes, that's why its a separate script and not something that happens on ready

#

Regardless of which library it uses

#

Better documenting the example to explain why it's done that way, sure, that addresses the concerns

outer raven
# copper laurel Performing a delta would require - fetching commands, at least one API call to ...

ok yeah you would need to fetch all global commands, however the equals function doesn't seem like it would take too much time or resources to run, even if you have 100 commands
And keep in mind in most cases you'd only need to call .edit on 1 command, which seems fine
The issue is with guilds though. The way I've done it is just calling .set on startup since it's only 1 api call and these don't need to wait to be updated, but it becomes an issue if you're using permissions which I'm still figuring out myself

outer raven
#

Also, is it really necessary to install discord-api-types? Most users aren't even on TS and it isn't listed under the optional packages

copper laurel
#

I 100% agree theres a lot of room to improve the documentation around the example, how /rest works, adding permissions down the track, but I will always disagree that automatically doing anything on ready is the right way lol

outer raven
#

Well I did this because I personally like things to be documented and having to run a command to update others didn't seem ideal, but I do realize my approach also has its flaws and does hit a lot of rate limits sometimes

copper laurel
#

I also don't run a command, my CI/CD pipeline has a stage that runs the deploy script after build, before restarting the application

#

API types defines Routes

#

Thats why its there

outer raven
#

ah I see

outer raven
copper laurel
#

Yeah

outer raven
#

Can I take a look at that or is it closed source

copper laurel
#

I wouldnt want to share it right now lmao, its an old hacky thing I havent touched for a while

#

Off topic for this channel

#

Point is, discord.js in general is moving towards the modular design, there might be other instances in future where individual parts become suitable for use

#

@discordjs/rest is arguably the right way of doing all the client.api stuff that came about prior to core support for slash commands

outer raven
#

yeah but discord.js never recommended using client.api because it was a hacky way. I know that @discordjs/rest isn't technically hacky but it's more advanced than the library itself

#

I saw some people say the other day that the library is good for beginners and I also think that's why we see many people who don't even know what an if is in #djs-help-v14, but that is also why examples like these should be as simple as possible and not require other packages that aren't even in the optional packages list and are not explained anywhere

copper laurel
outer raven
#

which uses the same example

#

ill probably wait for the equals pr to be merged and try suggesting something there, let's see what the feedback is

copper laurel
#

Of course it does, the script is the approach we want to encourage lol

#

I goes into a lot more detail about how it all works though

#

The other thing I wanted to call out, is that I don't see telling people to install @discordjs/rest is in any way different to installing @discordjs/builders, we're already introducing that modular approach in other areas.

hoary ether
#

i'd like to chime in if yall dont mind.

#

most users end up blindly copying it and have absolutely 0 clue what they're doing (because this is too advanced for the average user of the help channels)
and
but people don't know what they're doing and why they're doing it that way

not sure if Rodry and Monbrey have looked at the restaurant analogy i suggested in #archive-guide-discussion , but TLDR, the goal is to make it as clear as possible to users that the deployment of commands can and should be separated from the bot itself. I do realize that the restaurant analogy i used probably wasn't the best idea since it seems very out of place, but at the very least we can include something along the lines of the following in the guide:

In order to make Slash Commands work, we need to do two things:

  1. Register the Slash Command: In this step, we are essentially telling Discord:
    "Hey Discord, I would like you to show these commands to the user when they type / in the chat"
    This step only needs to happen once. The only other time we would need to "register" the commands again is when we want to make some changes to the commands. By registering the commands again, we are essentially telling Discord:
    "Hey Discord, I would like you to show these new commands to the user instead"

  2. Reply to the Slash Command: In this step, we decide what and how to reply to the user who used our Slash Command. This will essentially be our "bot".

We can definitely word it in a better way if needed, but i hope i got my point across.

I also realize that the current readme already suggest what i wrote above, although not as explicit:

Register a slash command against the Discord API:
<insert deploy script>

Afterwards we can create a quite simple example bot:
<insert index.js script>

copper laurel
#

Yeah, I think once Sanc's changes land and restructure/reorder a lot of the pages we can then look further into revising content further

hoary ether
#

👍

short lark
wild flax
outer raven
outer raven
wild flax
outer raven
#

Then?

wild flax
#

Nothing. I'm simply not going to accept it.

#

Registering your commands should be a separate process.

outer raven
#

Alright then if the recommended way can be automated I’ll be happy with that

wild flax
#

I don't see why it should.

#

The moment you need to do permissions, you need to manually interject anyway

outer raven
wild flax
#

What is automatic about "sepecific user & role"

hoary ether
#

The only scenario that could be automated (that I can think of) is if you want to defaultPermission:false and then whitelist the owner of the guild(s)

hoary ether
outer raven
outer raven
#

it should be explained better

wild flax
#

Not in a readme, no

wild flax
hoary ether
outer raven
outer raven
hoary ether
outer raven
#

You can make it automatic this way. Simply store the ids the user wants in a db and use them for all commands, otherwise it’s not possible to automate it in any way

hoary ether
#

I've been trying to make a boilerplate for v13 and I've ran into the same concerns with automating permissions as part of the deployment script (for global registration)

outer raven
#

The thing I was suggesting only works well for 1 guild bots

hoary ether
#

Right, exactly. The fact that you have to manually store the id of a role or a user makes it "not automated"

#

I think that was crawl's point

#

On that note, does anyone know if role id is unique across all of discord? Or can there be duplicates because of guild context?

unique axle
#

it is

hoary ether
#

Then it's technically possible for discord to allow us to do permission overwrite without specifying guild id, yeah? 🤔

unique axle
#

since the same endpoint is used for users: no

hoary ether
#

Sorry I meant in the future*
Maybe they can give us a different endpoint

unique axle
#

i don't see why they would, it needlessly complicates the procedure

hoary ether
#

you're right... the more i think about it, the more i realize how dumb my suggestion was

open flax
#

Any specific reason why <Message>.mentions.channels is a Channel type and not TextBasedChannel?

ornate topaz
open flax
#

WHAT

#

HOLY SHIT

#

I've been waiting for that

#

thanks

open flax
#

like textbased is #

ornate topaz
outer raven
ornate topaz
#

dude..

outer raven
#

oh wait u mean sth else nvm

rough roost
#

why does Webhook#send wait default to true and is not even an option

outer raven
#

someone forgot to deprecate the last v13.1 dev version

outer raven
modest lodge
#

I posted the following in djs-help but didn't get very far. Should there be a channel for discussion of discord-js-modules? I see there is an announcement but no specific place to ask related questions. Like my question (for now) is will there be (or is there) support for deleting slash commands through it? I see that support for such a thing should be possible but there are no docs or even (as far as I can see) a document explaining the goals.

rough roost
outer raven
#

feel free to make a PR then but I think that'd be a semver major change

ruby terrace
#

For some reason I thought there was a PR open to provide that option (option defaults to true, making it semver minor), but I can't find it

outer raven
#

ye as long as u keep the default behavior it should be fine actually

#

will you open it?

modest lodge
#

Any idea where I should post questions about the ability to remove a command via the DiscordJs REST library?

outer night
modest lodge
#

@outer night That was in response to my question? Is the rest library solely around for slash command support?

outer night
#

this channel is about developing the library, please redirect any questions about using the library to a support channel

modest lodge
#

It wasn't about "using it" as much as it was about "documenting it". Where would discussions about the development of that library be appropriate?

outer night
#

oh i misunderstood, thought you were just using the main library instead of using @discordjs/rest from discord.js-modules. the reason that there's isn't much documentation is because the project is still very much a WIP, so we recommend most just use the main library and only advanced users who are willing to comb through github source to go ahead with the -modules library. documentation will be added once the project is in a more mature stage

solemn oyster
#

(And we get a docsgen for TypeScript as well)

modest lodge
#

no problem... I will point out that the DiscordJs Guide https://discordjs.guide/interactions/registering-slash-commands.html#guild-commands provides from what I can see only one example for registering slash commands and it uses/recommends the rest library. I really, really understand the issues related to new features. My original post suggested that "maybe" a channel associated with the library discussion would be a good thing. That way this one isn't clutter up and the level of help might be better than that offered on the slash-commands one. People who made things work suddenly think they are experts, it gets depressing. 🙂

hoary ether
outer raven
#

@ruby terrace about your #equals PR, I'm testing it and for some reason this part of the code is returning true when comparing two options with required set to true, any clue? (_optionEquals on line 222)

#

I'm honestly a bit lost because I've logged that entire condition and it does return true, but I've also logged option.required and existing.required and they return true as well, so true !== true should be false

ruby terrace
#

are you sure that's the param check that's causing the entire thing to be true?

outer raven
#

yep, I added this log after the if and it returns true true true

#

only happens in 3 of my commands, 1 of them only has 1 option and I have no clue what the issue is tbh

ruby terrace
#

I'm dumb

#

needs parens

outer raven
#

where?

ruby terrace
#

its nullish coalescing the entire thing !== check

outer raven
#

you did add parens but in the wrong place i think

#

lemme try

#

yep that's it, the parens after existing.required should be before the !== instead

ruby terrace
#

should be (option.required ?? (optionType === 'SUB_COMMAND' || optionType === 'SUB_COMMAND_GROUP' ? undefined : false)) !== existing.required

outer raven
#

yep

ruby terrace
#

I was wondering how I missed that and then I realized I forgot about required when I tested dead

outer raven
#

also, why not do ["SUB_COMMAND", "SUB_COMMAND_GROUP"].includes(optionType)?

#

would also make it easier to add more in the future

ruby terrace
#

mm, sure

outer raven
#

all working well now

outer magnet
#

Question will MessageEmbed constructor (along with MessageButton, MessageActionRow, MessageSelectMenu) go under builders in v14?

copper laurel
#

Yeah eventually

hoary ether
#

Curious: couldn't i just make a PR to /builders for MssageEmbed, MessageButton, etc right now? or do you guys want the migration of the constructors to happen at some milestone (say, builders v1.0.0)?

loud jayBOT
copper laurel
#

There's also a button one but I want to redesign that

#

We don't just want the existing ones moved though

opaque vessel
ruby terrace
#

Uh, probably from when ephemeral messages didnt send their full data

opaque vessel
#

I've tested this out from interactions where the bot wasn't in the guild & ephemeral messages and non-ephemeral messages - it always manages to find it. I don't see how this can possibly fail, even after looking through source code

#

It would be nice if it could change from being nullable - one less (pointless) check for me in my code [:

ruby terrace
#

ephemeral messages used to not contain components

wild flax
#

or a message in general for that matter

opaque vessel
#

Ooh, wonderful, so now that they both do exist, there really is no reason for this to be nullable anymore?

ruby terrace
#

TODO item for v14 mmLol

opaque vessel
#

Hot

#

Should I make a pull request to remove its nullability?

#

I suppose I'll make an issue instead, just in case more components come along and might not appear in ephemeral messages or whatever. When version 14 comes closer to fruition, a pull request can be made then. <:

wild flax
#

@opaque vessel p sure animated defaults to undefined because Member Screening doesn’t give you an animated property

#

Neither of its false or true

#

So defaulting this to false would be misleading

opaque vessel
#

Oh I see! But still in the case of a component, what I said still holds true. Maybe just don't use the utility function in that case?

wild flax
#

Maybe

pliant crater
#

hey why do they call it an intent

#

instead of something like an RPC

#

how is it an intent if the user already did it

opaque vessel
#

I think that question would be better asked at Discord rather than here >:

vernal atlas
#

do all interaction classes have a reply method? if that is so why isn't the reply method simply in the Interaction class in the typings

#

ghost ping.. ?

copper laurel
#

Because there might be a type of interaction that doesn't one day

vernal atlas
#

perhaps its worth creating an interface for all the reply methods in the typings then, unsure what a good name would be though

copper laurel
#

That's exactly what it is

rustic boughBOT
vernal atlas
#

in the typings

quiet viper
#

are colors such as PINK no more accepted?

#

TypeError [COLOR_CONVERT]: Unable to convert color to a number.

unique axle
#

well, you do have to pick one that exists.

rustic boughBOT
unique axle
#

and pink just doesn't

quiet viper
#

okay thx

outer raven
#

@solemn oyster why the semver major on the events PR?

#

if they never worked is it really breaking functionality

vernal atlas
#

i suppose technically if you added event listeners for them

#

using the constants, you'd now get an error providing undefined as an event, and of course in typescript you would get an error compiling

outer raven
#

v13.1 caused tons of typescript errors and was minor still

#

I don’t think that really matters

#

But if people were using them apparently they shouldn’t so I thought it wouldn’t be major

solemn oyster
#

For once, because constants changed to remove properties, as Sugden said

#

And that's a breaking change

#

What we can do is add a warning that those events don't work anymore, or undocument them (while keeping the code)

#

This channel is strictly for discord.js development, not support. @dark sonnet

outer raven
solemn oyster
#

Are you in a rush about getting your PR's merged ASAP?

outer raven
#

nah I'm not but at the same time I don't rly like having prs sitting for months lol

solemn oyster
#

We do proper software development, even if it means an update needs to wait for months before being landed

outer raven
#

yeye I get it, no worries

hoary ether
oak quail
#

which is why they were documented and added to d.js

outer raven
#

they never fired according to the discord dev

oak quail
#

well thats wrong

#

and afaik they didnt say that

outer raven
#

1 sec

oak quail
#

they might have stopped sending them to bots within the past month

outer raven
#

they said they're not supposed to be sent to bots, so I assumed they never worked

#

tbh now that i think about it I think it would've been better to add deprecation warnings instead

#

will probably do that if i see too many people using these events in help channels

sage frigate
#

The docs mention a .getMessage() method on the slashCommands.options builder but nothing about that method in the guide or in the github source. Anyone know what this is about?

opaque vessel
#

It is for context menu interactions

sage frigate
#

Ah, I see. Guessing that is relatively new then, saw the message type in the docs

opaque vessel
#

Where are you seeing this btw? Got a link?

sage frigate
opaque vessel
sage frigate
#

Awesome

worthy coral
#

what zlib library does djs use

#

nvm. I overlooked zlib-sync

solemn oyster
dawn basalt
#

message.awaitMessageComponent doesn't seem to collect Select menu interactions (even if componentType is set to 'SELECT_MENU'). Is this intended?

copper laurel
#

I dont know if you're actually asking if we developed it that way in this channel, or this is misplaced support

#

But no, it does collect them last I checked

dawn basalt
copper laurel
#

Just tested, it works fine. Whatever issue you're having is not the lib

dawn merlin
#

Yeah I’m pretty sure it should be any message component interaction.

outer raven
#

yeah just change it to MessageComponentInteraction

outer raven
#

Why is there VoiceStats#requestToSpeakTimestamp but not VoiceState#requestToSpeakAt like almost every other timestamp in the lib?

rough forge
#

why did they get rid of structures in v13 ?

zenith oracle
grizzled field
#

From what it seems, ContextMenuInteraction is not exported at all in the index.js of discord, but is exported from index.d.ts. Is there a reason to it not being exported, or is it not being exported an error?

slate nacelle
#

That sounds like an error to me.

grizzled field
#

nevermind, just wasn't on github version of djs. It was fixed a while ago.

copper laurel
burnt cradle
#

@copper laurel in regards to the context menu pr, in what ways could it be unified with the slash builder? I feel like theres not much overlap

#

the name validation is different

#

I may be just being dumb but it feels weird to add a bunch of logic and stuff to the slash builder to make it compatible with context menus when separating it would likely add less overhead and be easier to maintain

copper laurel
#

eh maybe I'm thinking more closely to the API design than a builder

tacit crypt
#

As much as I agree with Mon on this, personally I'd still have them separated... Tho it means we also have to rename slash commands to chatinoutcommands

wild flax
#

lol no

burnt cradle
tacit crypt
wild flax
#

no to calling them like that

#

thats terrible lol

#

ChatInput is 1 out of 3 types, where the other 2 share the same builder, since user and message inputs can be combined

#

so keeping "SlashCommandBuilder" and "ContextCommandBuilder" seems sensible as is

burnt cradle
#

it's called ContextMenuCommandBuilder rn

wild flax
#

Yeah thats fine

tacit crypt
#

i see where you're going, don't get me wrong

wild flax
#

We don’t need to mirror the api for exposed builders though

#

What’s the point

tacit crypt
#

Fair

strange igloo
livid ridge
#

hmm

#

yes, i also opened a issue about it 😅

real jetty
#

I can make PR

livid ridge
#

also

#

why does userUpdate event gets emitted when i edit intents of my bot from developer portal

strange igloo
# real jetty I can make PR

already got changes ready to be published, but just wanted to know the global opinion since iirc the library shouldn't guard check for disabled cache issues

real jetty
strange igloo
#

because discord updates the user that's associated to your client, and emits USER_UPDATE to your bot (which does not require any intent, so you will always receive it)
now why since there is no intents prop on the client user, idk, but that's probably internal to discord here too

livid ridge
#

ok

#

also the event is not emitted when u change about me of bot lol

#

😶‍🌫️

real jetty
livid ridge
#

ok

outer raven
#

@hallow ocean you resolved my conversations without really addressing them nor responding 🤔

#

Also you forgot to update the typings

hallow ocean
#

Sorry! For the first one, I don't really think it's needed. For the second one, I don't get what you're saying so I just did the suggestion regarding adding the default value. And yes, sorry about forgetting to update the typings, I'll do it ASAP. I hope I didn't get your expectations low

#

Solved your request regarding updating the typo again

outer raven
#

At least that’s how I read it

#

And for the first one I just said that the typo was already fixed so a rebase could remove that change as it is no longer needed

hallow ocean
outer raven
#

So that nothing changes if it’s a spoiler and you do setSpoiler(true)

hallow ocean
#

All good

outer raven
#

Just commented one more thing that I forgot, otherwise LGTM :)

hallow ocean
#

Sorry again for being stubborn

outer raven
#

All good, no worries

livid ridge
visual hornet
#

aren't they always cached already?

opaque vessel
#

It's possible to sweep yourself out of the cache. I guess a real fix would be to make checks to ensure the ClientUser is always cached, and throw an error if you try to set the manager's cache limit to 0 (1 minimum)

livid ridge
strange igloo
# livid ridge Uh no? If client was cached, then that error would not emit

Well actually it is, Client#user is an actual property assigned to the user object, and not a getter to client.users.resolve(...) like GuildMember#user would be
The issue here is that the action that compare changes between old and new user tries to get the user from the cache, that's here empty
But the user itself is "cached" in client.user, no matter if the UserManager cache is enabled or not

livid ridge
#

So client.user is always cached?
What about <guild>.me?

strange igloo
#

That wouldn't be that useful
The library doesn't guarantee that Guild#me exists all the time anyway

livid ridge
#

Hmm ok

#

But it will be useful for small bots

#

Cuz small bots can keep the member cache disabled as their bot check permission to send messae / embed links etc

strange igloo
#

You should always fetch the member associated to the client user anyway, as it's not guaranteed to be cached already
If you disabled caches, then you shouldn't, but you can still have something like that

const botMember = await guild.members.fetch(client.user.id);
if (!botMember.permissions.has("BLAH_BLAH")) throw new Error("...");
outer raven
#

Should the RESTManager class be documented?

wild flax
#

why

solemn oyster
#

No

#

One of my plans for v13 is to change the entire REST manager with @discordjs/rest, I'd like that possibility to not be destroyed

burnt cradle
#

@tacit crypt which enum are you referring to? because the only one I see is ApplicationCommandType and ts wont let me build because it doesnt think its exported

tacit crypt
burnt cradle
#

well its erroring when i try to build it

tacit crypt
#

What's the error

burnt cradle
#

'"discord-api-types/v9"' has no exported member named 'ApplicationCommandType'.

tacit crypt
#

That's impossible

burnt cradle
#

clearly not

copper laurel
burnt cradle
#

0.22.0

#

hmm yeah seems context menus didnt exist in 0.22.0 think the version needs to be bumped

#

but 0.22.0 is latest release so

copper laurel
#

Yeah looks like it needs a release

tacit crypt
#

Ohhh

#

Right

outer raven
solemn oyster
#

It would

#

Making anything from djs REST public = replacing is a breaking change

muted aurora
#

Is this a issue of the typings or am I missing something?

lucid pasture
#

It is fine

muted aurora
#

I guess partial messages are missing the content but in the documentation it seems like content don't have to be present 4Shrug

lucid pasture
#

Yeah because of that reason, partial messages are missing content so it can be null

muted aurora
#

I seem to be the first to be confused by this - so nevermind then 🙈

visual hornet
#

wouldn't that be an empty string though, not null
tested for both embeds and attachments, although they are on v12 (haven't finished updating yet)

loud jayBOT
outer raven
#

Does anyone know the reason to this?

fallow crater
#

doesn't seem to be exported in src/index.js.

loud jayBOT
outer raven
#

Ah I thought the issue was with the typings, nvm

muted aurora
#

After my stupid thought earlier today, I might have a useful idea now. If users have entered a command incorrectly it can be exhausting to re-enter the command (I know command input is supposed to be done via interaction commands, for my use case it's not a command its pure user input). Have ever been considered to create a MessageEditCollector, I would actually find that quite helpful so users can easily adjust the input without having to rewrite everything 🙈

#

I'm also comfortable trying to implement this, but wanted to know opinions first before going into too much depth.

wild flax
#

Unlikely we’ll move into that direction with everything moving to slash commands

muted aurora
#

Okay, so it wouldn't be worth implementing that?

ornate topaz
#

Similar issue exists for slash commands as well, but since by design they are not messages, there is nothing to edit and you have to write again anyway

muted aurora
#

I don't think the implementation of interactions are bad, not even the privileged intent for messages, but especially for small bots that only have a few functions, it would be really helpful to have good things for handling classic messages as well 🙈

wild flax
#

Disagree.

muted aurora
#

All right, thanks for the fast responses 😅

dawn merlin
#

quick question for @discordjs/permissions-helpers do we want to extend the library classes in-place (i.e. Object.defineProperty) or should we create methods that simply take the objects like: isPrivate(channel): boolean?

copper laurel
#

For what now? Is this a new builder?

#

Definitely do not extend library classes though, thats why we removed structured

#

Utils should be functions

dawn merlin
#

For the permissions helpers Crawl suggested that we create a /permission-helpers module and put the code there

copper laurel
#

Functions

#

But should probably see what crawl thinks

wild flax
#

Yeah a always functions

severe sun
#

why is ban .ban(user, options) but unban is .unban(user, reason) ?

burnt cradle
#

because theres no other options besides reason for unban

grand eagle
#

Can someone explain how the discord slash command builder works? I think creating something similar for node-cron for cron times would be really useful.

hoary ether
grand eagle
hoary ether
#

discordjs/builders

grand eagle
hoary ether
#

Also, your question is off topic for this channel

grand eagle
#

is it? I thought this would be the best place to ask about how the library works.

#

I was also told to go here.

hoary ether
#

Serious discussion about developing discord.js

coarse ginkgo
#

Is v14 still going to be written in TS?

pastel magnet
#

v14 isn't -next.

grand eagle
unique axle
#

the typescript rewrite is not versioned yet

#

v14 will very likely not be the ts rewrite

coarse ginkgo
coarse ginkgo
grand eagle
unique axle
#

rewriting the entire library from ground up in typescript for ease of maintenance and less pesky bugs, this has no date or version yet
if we need to make breaking changes for new features we will do that, so v14 is not the ts rewrite, whatever you want to call it
modules (which will be composed and used in the rewrite) are developed under https://github.com/discordjs/discord.js-modules - we currently suggest using the rest portion to manage your application commands, for example (https://discordjs.guide/interactions/registering-slash-commands.html)

coarse ginkgo
unique axle
#

modules (which will be composed and used in the rewrite)

coarse ginkgo
#

gottcha thanks :D

fallow crater
#

iirc there are plans to implement modules into the main library?

solemn oyster
#

Yeah, eventually

grand eagle
solemn oyster
#

All volunteer

#

You're more than welcome to sponsor the project in GitHub

grand eagle
peak tree
#

For the library devs, I'm sure you have heard about discord.py shutting down and the reasons behind it. What are your thoughts on the issues raised by the head dev? I know you guys might not be able to answer because of NDAs, if that's the case (or if I'm asking in the wrong place) then sorry for bothering.

#

(please ping me with any replies)

solemn oyster
#

In my honest opinion, it was over-generalised, some of the points are childish and are clouded by past anger. Nevertheless, I think this fits better in another channel since Discord.py's endeavors don't have any effect on the development of Discord.js

peak tree
#

Okay, sorry. Thanks for the quick response!

outer raven
warped crater
#

even if it was, should be private.

#

it's just a field that you'll never need to use