archive-library-discussion

[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]

Not currently. But hardcoding it to a row makes no sense if ever Discord changes that

https://github.com/discordjs/discord.js/blob/stable/src/structures/MessagePayload.js#L140
https://github.com/discordjs/discord.js/blob/stable/src/structures/BaseMessageComponent.js#L60

[wild flax]

And if discord ever changes it while we would still be on v13...

[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]

GuildSearchMembersOptions?

[void rivet]

yes the limit is by default 1
it does the same for GuildMemberManager.prune, there's default values that's the same as the API's default
https://discord.js.org/#/docs/main/master/typedef/GuildPruneMembersOptions

[shut wave]

I guess that makes sense. Seems a bit strange to not do something 'just in case' discord changes it as they've not mentioned anything about changing it but - I'll just wrap message sends in my own function that does it instead as it's a buttload of boilerplate currently 🤷‍♂️

[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]

releasing a major version just because you made a dumb design decision in the future seems a lot more dumb

[shut wave]

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]

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]

It does indeed - It's a small amount of temporary overhead until the next major release where the 'old' way is removed along with the feature flags and the 'new' way is left as the only way.
It's standard practice in most large libraries

[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]

Ah, I haven't looked at the source and I incorrectly assumed it was written in TS - That would explain it

[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]

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]

Since it's an application command, for example, here: https://discord.js.org/#/docs/main/stable/class/ApplicationCommandManager?scrollTo=create
https://discord.js.org/#/docs/main/stable/typedef/ApplicationCommandType

[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

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

[slate nacelle]

Oh, I should have just linked to there.

[hollow crest]

Thank you, will do. I have one more question, I'll ask in slash commands.

[tired valve]

I'm just waiting for builders since the guide relies on those for interactions

[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]

any plans to move from node-fetch? maybe https://github.com/nodejs/undici? would the change be considered semver major?

[copper garden]

Why would that be necessary?

[rough roost]

It's official, much faster and has a nice api so why not?

[strange igloo]

What does "official" mean here? 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.

https://github.com/ethanent/phin / https://npmjs.com/package/phin

[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]

which version does the documentation show in stable? https://discord.js.org/#/docs/main/stable/class/CommandInteraction

apparently there's no .deferReply() method?

but main does show .deferReply() https://discord.js.org/#/docs/main/main/class/CommandInteraction

[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

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

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

https://github.com/discordjs/discord.js/blob/main/typings/index.d.ts#L2215-L2253

[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

https://github.com/discordjs/discord.js-modules/blob/main/packages/rest/src/lib/RequestManager.ts#L51 think the problem is here

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]

I think this property should only exist on BaseGuildTextChannel similar to how BaseGuildVoiceChannel#joinable exists.

[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]

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]

I have to transform 1 option at a time but this seems like a good approach, I'll try it out thanks

[tacit crypt]

? This is a warning that we do not have prebuilds for opus yet, which is fine, as it'll build on your system instead

[tacit crypt]

Answer is no. It's the same reason as to why -types has lots of unions. Strict typings 😃

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

[outer raven]

but then we can't use these types to make interfaces of our own easily

[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

[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]

Completly forgot this class existed lol, well yeah that's definitely its best place to fit in

[dawn basalt]

Opened the PR. Mon doesn't seem happy.

[loud jay]

#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]

Well imo I'm completely neutral of this, I mean it's a simple permission check but it can always be useful, and considering all the existing similar getters, this one has no reason to not get implemented
Either this, or get rid of all manageable/bannable/etc getters.

[raven juniper]

There's more than a simple permissions check involved in some of those getters. I was in favor of removing a lot of them, but they're useful because they cover stuff that's more than just "do I have this one permission"

[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]

ye but it will be done eventually right

[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]

this is intended; the docs just don't have an example of it

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]

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]

no methods are documented and it's not on the typings

[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

https://www.npmjs.com/package/@discordjs/rest

[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]

Yea, mudae who burns crap ton of money to host it

[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]

So its good for 99% bots? Thats good enough for me as a goal.

[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]

should I PR and add that as private?

[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]

Theres no need for it, the subcommand options are hoisted to top level

[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]

I dont know about documenting set, but extends Presence should probably be there

[outer raven]

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

[loud jay]

#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 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]

How 'bout we don't make up random facts to push your personal agenda, just saying

Signed, a dev that works on Rythm

Also there is #874411732527886336 for memory related discussions, if you are interested

[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 jay]

#5337 in discordjs/discord.js by JMTK closed <t:1627085624:R>
After v8 gateway PR, bot doesn't initially receive DMs

[tired valve]

you need the channel partial for that to work.

[outer raven]

https://github.com/discordjs/discord.js/issues/6411 can someone give this a has pr

Also the upstream PR for https://github.com/discordjs/discord.js/issues/6379 has been merged cc @ruby terrace

[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]

There's a PR open

[loud jay]

#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()

this https://discord.js.org/#/docs/main/stable/typedef/AddApplicationCommandPermissionsOptions and this https://discord.js.org/#/docs/main/stable/typedef/SetApplicationCommandPermissionsOptions

[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]

If I may ask. What would be the point of rewriting the whole thing in TS? Will it help more with typings or?

[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]

Yes, now you may think I'm some kind of idiot but I've never worked in ts before. That's why I'm asking you if it's worth rewriting at all.

[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]

With my second point, you may realise that people who use and embrace TS never work on JS unless forced to

[copper laurel]

Sapphire is TS I'm pretty sure

[solemn oyster]

It is

[real jetty]

Yes

[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]

Yes, I know that

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]

Yes, this is then built into js.

[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]

https://github.com/discordjs/discord.js/blob/main/src/util/Formatters.js#L27
why does the Formatters class extend null?

[vivid field]

so that it doesn't have a constructor

[empty viper]

why not using a namespace ?

[bronze sigil]

why not using plain object with methods?

[vivid field]

because the docgen doesn't parse that

else you'll end up with a giant typedef like at https://github.com/discordjs/discord.js/blob/main/src/util/Constants.js#L1049-L1079

[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 jay]

#6456 in discordjs/discord.js by SquareIsNotCool opened <t:1629107884:R>
Missing type property for interaction#options#getMentionable

[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]

but I think what they wanted was just a simpler way to tell which one it was. Having access to resolved is basically the same thing isn't it

[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]

wait thats a thing?

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]

"typescript.inlayHints.parameterNames.enabled": "all" in settings.json. Or search for parameter in vscode settings. You need TS 4.4+ for it

[outer raven]

Not with that option enabled

[ornate topaz]

???

does that option break the library?
runtime errors?

[outer raven]

Yeah I found it later. Won’t be using v4.4 yet but ty

[outer raven]

No jeez

[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 in the typings

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]

I assume missng some parentheses there?

[ruby terrace]

lol, looks like whoever did that rename PR missed those

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

[oak quail]

well i fixed those when adding the new permissions https://github.com/discordjs/discord.js/pull/6466

[oak quail]

wdym

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]

hm, now that i look into it there isnt even a checkAdmin param documented https://advaith.is-in-hyper.space/ed009a75ad.png

[ruby terrace]

the return value of that

[oak quail]

ah right

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

https://github.com/discord/discord-api-docs/issues/640 and i'm to this day not sure if night even understood the problem

[wild flax]

[outer raven]

pretty sure they didn't exist when I made the PR because i went through them all tons of times

[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]

sounds like you're deferring the same interaction twice, use #djs-help-v14 instead

[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]

The error you are getting is, like I said, because you are replying to the interaction in your error handler using .reply instead of .editReply. Please stop flooding this chat now

[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]

What do you mean by 'completely breaks' here? I set my BaseGuildEmojiManager to 0 and managed to react to a message with a custom emoji, or did you mean something else?

[outer raven]

I set mine to 0 too and tried to react using an emoji ID and it crashed my bot

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]

Odd https://gyazo.com/52b37b8d8ccdf9bbdc7c427138338688
What did I do wrong?

[opaque vessel]

You could log line the resolved emoji at line 191 in the message manager I guess. Or maybe I did something wrong, idk, have a look

Did you provide an actual guild emoji object?

[outer raven]

try passing just the ID, which is what I did

[outer raven]

will do in a bit but try that first to see if u can repro

[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]

ah I thought it'd just be the emoji ID.
Well making another call is against the lib's standards of 1 call per method so I guess that's not possible, so a warning in the docs would be best

[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]

The DiscordAPIError Class does actually have this, it just depends on how it gets logged whether or not it is part of the log

[outer raven]

well then would it be possible to update all the dapi errors to include the request path?

[ruby terrace]

it...does?

[outer raven]

it didn't in the error i showed

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

https://advaith.is-in-hyper.space/31726417fa.png

[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]

probably bc the emoji name is missing, did you tried passing a name?
bc the request needs a (random) emoji name and and id.
and when the emoji cache is limited, you can get the name anymore

[outer raven]

I didn’t bc passing an id is more reliable that using the name because we don’t need to change the code if the name changes

[quiet viper]

The name can be a random name, it doesnt have to match to the emoji name.

[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]

What Node.JS ver are you running?

[outer night]

#archive-voice for further discussion thanks

[runic leaf]

16

[analog prawn]

Look around here, this may help. https://www.npmjs.com/package/@discordjs/opus

[wild flax]

You are being so unhelpful its incredible

[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]

Okay, because for example if my bot doesn't need to cache GuildMember roles so I can turn it off

[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]

What day does the deprecation of this apply: https://discord.com/developers/docs/reference#api-versioning ?

[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]

It should probably be called hoistedData then, not options

[copper laurel]

Agreed

[loud jay]

#6472 in discordjs/discord.js by Richienb closed <t:1629331610:R>
Meta tweak

[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]

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]

but you realize that is the majority of the lib's users right

[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]

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]

yeah that is also a better way. Either add comments along the way or document the package itself like collection and the main lib are

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]

I assume you're using some version of this script which is why you can call the API without logging in right

[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]

https://github.com/discordjs/guide/pull/826 theres still this PR too

[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]

Maintainers: see #archive-commando-deprecated please

[wild flax]

Don’t bother. I won’t be accepting any other examples that involve the ready event.

[outer raven]

I like that idea but wouldn’t that be the same as what we have rn? Or is the code to deploy different?

[outer raven]

But what’s the problem with the ready event if it doesn’t spam the api

[wild flax]

There is no problem.

[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]

why would you? My permissions are all done automatically

[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]

I think the script itself isn't the problem, but explaining what the script is doing and the reasoning behind it are

[outer raven]

you put the ids in an array and automatically apply the permissions automatically when deploying

[outer raven]

yeah thats what im saying

it should be explained better

[wild flax]

Not in a readme, no

[wild flax]

Thats assuming all commands have the same perms 👎

[hoary ether]

If the bot is in multiple guilds, you'll also have to specify the guild id of every guild the bot is in. (Unless you loop through the guild cache, at which point you'll have to use .login(), and we've already discussed why it's not good to use .login() for deployment)

[outer raven]

No it’s not? I’m saying have an array of ids per command, which is what I do, and you can customize it freely

[outer raven]

You can also not apply guild permissions and let the owner of each guild customize them through a command

[hoary ether]

That is possible, but that's not automated anymore, is it? We're discussing how to automate permissions overwrite during deployment

[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]

because you can mention voice. look: #222078108977594369

[open flax]

WHAT

HOLY SHIT

I've been waiting for that

thanks

[open flax]

what is the keysymbol to mention a voice channel?

like textbased is #

[ornate topaz]

#! and there is #archive-offtopic for offtopic

[outer raven]

pretty sure it's just <#id>

[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]

probably because that has to be true for the api to return the sent message

https://discord.com/developers/docs/resources/webhook#execute-webhook-query-string-params

[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]

ye but it still should be an option, you don't always need the message

[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]

#archive-interactions

[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]

there's a PR for the guide that addresses most of what you pointed out

[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

[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 jay]

#11 in discordjs/builders by Fyko opened <t:1626131905:R> (changes requested)
feat: create Embed builder
📥 npm i Fyko/djs-builders#embed

[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]

When is this going to be null?
https://discord.js.org/#/docs/main/stable/class/SelectMenuInteraction?scrollTo=component

The same is with buttons. These interactions only arrive if one was interacted in the first place, right? How can it be null?

[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

[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 bough]

InteractionResponses
Interface for classes that support shared interaction response types.

[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 bough]

ColorResolvable
Can be a number, hex string, an RGB array like: ```js (more...)

[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]

do you think that's worth it tho? If anything that should be a separate PR cuz they will need to be removed for v14

[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]

I know my question is probably off topic for this channel but, what's your definition of "proper" in this context? Genuine question because I'm trying to learn

[oak quail]

well they did work

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]

https://discord.js.org/#/docs/main/stable/class/CommandInteractionOptionResolver?scrollTo=getMessage

[opaque vessel]

It's to-do for builders https://github.com/discordjs/builders/issues/28

[sage frigate]

Awesome

[worthy coral]

what zlib library does djs use

nvm. I overlooked zlib-sync

[solemn oyster]

It's... hard to explain actually. But for the most part, we're adhering to standards and being conscious about the impact changes have on our userbase.

[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]

Check this comment https://github.com/discordjs/discord.js/pull/6027#issuecomment-874919431

[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]

I'm incredibly bad at forgetting to export new classes I make from the index, glad someone has fixed it 😄

[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]

So keep it separated as is?

[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]

but slash commands are called ChatInputCommands

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]

Couldn't https://github.com/discordjs/discord.js/blob/main/src/client/actions/UserUpdate.js#L10 be replaced with

const newUser = data.id === client.user.id ? client.user : client.users.cache.get(data.id);

(or equivalent)
so it can not crash if user cache was disabled? (when client user gets updated)

[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]

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]

Yes, I think they are still speculating about whether it is possible to get about me only via oauth2 etc.

[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]

I’m just saying that with the current code if you have an attachment with a name that starts with SPOILER_ and do setSpoiler() it will remove that text, making it not a spoiler

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]

So that means it should be validated if spoiler is false, right? 😄

[outer raven]

Yeah on the second if condition you should check if spoiler is false

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]

What if we keep client.user (user) and guild.me (client as guild member) always cached?

[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]

Uh no?
If client was cached, then that error would not emit

[strange igloo]

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]

The one in -types is exported

[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]

Which version of that do you have installed?

[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]

Oh no it wouldn’t, just said that because some properties reference that class and the link was missing that’s all

[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

[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 jay]

#6525 in discordjs/discord.js by danii opened <t:1629908355:R>
BaseGuildTextChannel Is Typed but Not Exported

[outer raven]

Does anyone know the reason to this?

It seems like the class is exported just fine https://github.com/discordjs/discord.js/blob/d0bc4d7ff037035d4f315a0286b06f0a1ade29c1/typings/index.d.ts#L303

[fallow crater]

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

[loud jay]

#6527 in discordjs/discord.js by Dev-CasperTheGhost opened <t:1629911999:R> (review required)
fix(BaseGuildTextChannel): export BaseGuildTextChannel
📥 npm i Dev-CasperTheGhost/discord.js#fix/fix-6525

[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]

I'm sorry, am I missing something here? What does a json object have to do with cron jobs?

[grand eagle]

I want to create something that can simulate the compositional nature of the builders for cron strings.

[hoary ether]

You can look at the source code in GitHub

discordjs/builders

[grand eagle]

ofc i know I can do that. I was looking for more insight rather than trying to completely figure it out on my own. This is not super helpful.

[hoary ether]

I guess you're right. But at the same time, i don't think it's that hard to figure out what the builder does by simply looking at the source code. The job that it does is relatively very simple and straightforward.

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]

Why would it not be? Have you heard something?

[unique axle]

the typescript rewrite is not versioned yet

v14 will very likely not be the ts rewrite

[coarse ginkgo]

yeah, but was just a question

[coarse ginkgo]

is the rewrite public for people to work on?

[grand eagle]

what does ts rewrite mean exactly?

[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]

so is https://github.com/discordjs/discord.js-modules the rewrite?

[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]

are you guys paid to develop the library? or is this all volunteer work?

[solemn oyster]

All volunteer

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

[grand eagle]

for sure

[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]

Why is this not documented? https://github.com/discordjs/discord.js/blob/main/src/structures/MessageAttachment.js#L15

[warped crater]

even if it was, should be private.

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

when you create a message attachment on your own from a buffer/stream/whatever you can just keep a reference to it, no need to access it back from the structure

[copper laurel]

There are times when things are intentionally not documented

[warped crater]

when its constructed from an incoming message its the URL

its just a really weird field

it doesn't expose new information regardless

[outer raven]

it would be easy to doc tho and it can be private

[warped crater]

is there.. a benefit?

[copper laurel]

PR farming of course

[outer raven]

everything in d.js is documented, even private properties and methods, so if this means users can actually see what properties a MessageAttachment really has then I'd say so yeah

[wild flax]

Nah not everything is

In the past we didn’t document privates really

Indicating they are private therefore

[remote wasp]

One can say that documenting private stuff might help contributors especially new ones in understanding how the lib works 👀
Don't know it's worth doing for current version but can be considered for ts rewrite?

[solemn oyster]

Just like you shouldn't be using discord.js when you're starting with JS, you shouldn't be trying to change internals on your own when you're starting to contribute to d.js, unless of course, you know very well what you're doing

Internals usually hide the most complex code of Discord.js

[hoary ether]

Didn't expect you to call out Rodry like that lmfao

[remote wasp]

Exactly, we forget what our code is doing when we come back to it after a long break. A 100% documentation will not just help new but even let old contributors to quickly grasp what a private piece of code is doing.
It will also improve the developer experience, where a contributor writing a public method gets helpful documentation while calling private methods in it.
Documenting everything is a great thing and with ts rewrite we have a chance to start doing it. We aren't getting any runtime penalty for documenting so I'm unable to understand why it's being seen as a bad thing.

[outer raven]

I don’t PR farm tho, I just open PRs for stuff I stumble across and think is worth fixing/changing, and most get accepted

[outer raven]

Yeah I agree but tbf for this specific property it’s pretty easy to understand what it does, just saying it could be documented if everything else is. Not gonna open a PR solely for that but if I find many others I might, if it’s worth it ofc

[dawn basalt]

What are the plans for something similar to @discordjs/permission-helpers?

[lilac tulip]

what do you guys think about a replyOrFollowUp() method on an interaction? what this method would essentially do is try to call .reply() , and if there already is a reply, instead of throwing an error it would call .followUp()

[tacit crypt]

Similar module to perm-helpers

[dawn basalt]

Hmm, helper method.

[lilac tulip]

well yes it would just be for convenience

[outer raven]

Doesn't followUp just replicate the behavior of reply if there is no reply yet/if the reply has been deferred?

[lilac tulip]

oh does it? if that's the case then the method would be useless xD

[outer raven]

Yeah I think that's done on Discord's side

[lilac tulip]

so reply() is basically redundant? since we can always call followUp()

[outer raven]

I personally dislike followUp so no not really

[lilac tulip]

apart from personal preferences, is it?

[outer raven]

whatever you wanna call it but Discord has an endpoint for that so it has to be there

[lilac tulip]

yeah I don't want to say it should be removed, just wondering because if I can always use followUp() in my code I will

[lilac tulip]

btw, I just tested it and calling followUp() on an interaction that hasn't been replied to throws an error

[unique axle]

that would be expected, because the follow up will reply to the reply - which it can't if there is none

[lilac tulip]

👍 I just wanted to say it because it would've made my idea useless if it worked

[outer raven]

Ah nvm, only acts as editReply if it was deferred then

[grand eagle]

What is being used for managing the commit messages for the library? Stuff like feat: or chore: , etc.

Is that all with Husky and commitlint?

or something else?

[unique axle]

husky enforcing commitlint https://github.com/discordjs/discord.js/blob/main/.commitlintrc.json

[outer raven]

@opaque vessel how do you have an uncached guild to begin with?

[opaque vessel]

Hey hey, sorry my wording was a lil' off. I meant the guild member was uncached (hence the partial bug report) - thank you for pointing this out <: I edited it now

[outer raven]

Ahh alright. I will try to reproduce this and experiment a little tomorrow. If no one else opens a PR to fix it I might since I have a solution in mind but it may not work

Unfortunately any fix to this would be semver major though

So probably not worth the time now, just a minor inconvenience that we will have to deal with later

[grand eagle]

What is the scope field in the commitlint meant for in the repositories? Is it just what component was worked on?

So if I made changes to Message, would I do something like feat(Message): increase character limit

[hallow ocean]

yes, that's right, the area of which the commit was made in

usually it's the class or area of code affected

[grand eagle]

aha, kk thanks

Would rebasing commit messages be the only way of adhering to that standard? I have already made a lot of commits on a repo that did not adhere to the standard.

[hallow ocean]

the maintainers would edit the PR title most of the time before committing them, if it so happens that it's already pushed to the main branch then 🤷‍♂️. but if you can amend the commit then sure, not all rules are strictly followed though

[grand eagle]

ahh, yea, I heard about the squash and merge method of controlling PR's

[ornate topaz]

@outer raven "Scope" doesn't refer only to the files you edit. If a PR does one, specific thing, it should not become a sink for random commits you decide to dump into there regardless of what they do, just because "they touch the same file".
What happens if it turns out that your PR adding new ES features broke something for any reason? It could be reverted, but then we also lose every single thing you decided to dump there that was completely unrelated to the thing that was initially being changed at all.

Also lol, you went "why change 😕" on the PR for links, but then decided to dump it under your own PR

[outer raven]

Yeah I get it but this was a very small thing and it’s ok if that gets reverted.
I said “why change” because the other lad opened a PR just to fix some links in the tests, when it could’ve been bundled somewhere else

[ornate topaz]

small or not, it doesn't change the fact if it's in scope or not

"why change" doesn't sound like "this could be handled in some bigger bulk"
"somewhere else" should still probably be somewhere in scope of fixing old links or a general, non-code chore

and i don't think it's for you to judge what is "too small" to have its own PR

[outer raven]

That’s why I’m not a maintainer, I just gave my opinion on it

Want me to revert it?

[ornate topaz]

IMO yes, but i'm not the one to speak for that

[outer raven]

Should I tag Crawl then

[outer raven]

Alright I just undid that commit and addressed the unresolved conversation, sorry for that

[outer raven]

Also considering this is still pinned, @unique axle have you considered updating this issue? https://github.com/discordjs/discord.js/issues/4961
It still references stuff that was removed in v13 so it's probably better to do so

[loud jay]

#6551 in discordjs/discord.js by tignear opened <t:1630246622:R> (review required)
fix(xxxable): follow more properly with discord behavior
📥 npm i tignear/discord.js#fix/follow-discord

[zenith oracle]

Why is this a major and not just a patch 🤔

[wild flax]

It removes a method

[zenith oracle]

Uh, what method I didn't notice

[burnt cradle]

VoiceChannel#deletable

[zenith oracle]

If this, it's already implemented in GuildChannel... It was an override

Or is it considered major the same, even if it's implemented in the parent class? 🤔
I'm not really informed about this lol

[solemn oyster]

I mentioned it in internal a few hours ago, but Crawl didn't see it

It's corrected now, dw

[zenith oracle]

Oh nice, thx

[outer raven]

Why does awaitMessageComponent now return a collector??

Did anyone test #6476

If anyone knows suneettipirneni's discord please tag him, idk who they are in here

btw it seems like this only happens with awaitMessageComponent, not collectors

[opaque vessel]

Hullooooo @tacit crypt, are you talking to me there :eyes: what I do halp

[tacit crypt]

You install deps

Run..uh, i think build:deno

And push the changes

[opaque vessel]

Ah wow I got 22 changed files :eyes:

You want me to push all of them?

[tacit crypt]

Can you..show them

Bc that sounds off

[dawn merlin]

thats me

[outer raven]

oh hey

would've never guessed that tag lol

[dawn merlin]

I think ik what the issue is but lemme test it first

[opaque vessel]

I managed to sort it out :D It now changes the deno/payloads/v9/ file, the same one as mine

[outer raven]

you essentially made awaitMessageComponent and createMessageComponentCollector return the same thing

[opaque vessel]

Pushed @tacit crypt

[dawn merlin]

yeah and unfortunately the tests I wrote checked the wrong types

[tacit crypt]

Can you also update v8? 😇

[opaque vessel]

Ya! Okay

Is done, am pro

[outer raven]

Would changing the possible type of a property from undefined to null be considered semver major?

[copper laurel]

yes

[outer raven]

alright, won't do that then

[vast crystal]

any plans to add the bulk overwrite endpoints (
https://discord.com/developers/docs/interactions/application-commands#bulk-overwrite-global-application-commands
and
https://discord.com/developers/docs/interactions/application-commands#bulk-overwrite-guild-application-commands)
to ApplicationCommandManager?

oh they are

thank you

😬

[outer raven]

Shouldn't https://github.com/discordjs/discord.js/blob/main/docs/logo.svg be updated or does this logo not even matter

[copper laurel]

Is it being used anywhere

Genuinely wonder how you stumble across this stuff

[shrewd kelp]

For interactions we have .isButton(), .isCommand(), etc, is there any reason things like channels don't have a simular thing? For channels I often have to do channel instanceof TextChannel to ensure its the correct type so it seems a bit oddly inconsistant that interactions use .isWhatever rather than also being interaction instanceof ButtonInteraction. Would be useful for consitancy to add it to channels as well

[copper laurel]

isText()

[rustic bough]

GuildChannel#isText()
Indicates whether this channel is TextBasedChannels text-based.

[shrewd kelp]

oh

Guessing that got added v13?

https://discordjs.guide/additional-info/changes-in-v13.html#channel-1 ah yeah, looks like ill have to read through the docs see if thers any other super helpful things iv missed

[sharp wigeon]

pretty sure that was added in 12.5.3

iirc

[visual hornet]

i don't think it would be included in the additions section if it wasn't added in v13...
also wouldn't that fall into a minor update, not a patch?

[copper laurel]

Who cares

[glad sparrow]

is invalidated event still a thing? Can't find anything about that in discord.dev

oh it is custom event of djs

[grand eagle]

Do we need to sign our commits when submitting PRs?

i'm like 38 commits deep and I just learned about signing commits

does that mean they get signed when the maintainers squash and merge then?

[slate nacelle]

I'm not sure how it works actually.

[real jetty]

Is signing commits really that important?

[copper laurel]

YES ITS CRUCIAL

[solemn oyster]

In Git, you can commit as anyone, which means you can also impersonate them. This is because Git is a decentralised system, and pushing other people's commits (e.g. rebasing a PR with commits from different authors) are required to work. To prevent impersonation, you use GPG/PGP signatures, so everyone can verify it's you the one who committed and pushed, and not somebody else.

[obtuse hazel]

Note that if you commit through the GitHub interface, the commits will be signed by the commiter (on merge for instance)

[ornate topaz]

Commiter? Thought it would be by GitHub

[fallow crater]

Yeah, those will be via GitHub itself Im pretty sure

[obtuse hazel]

Github displays it like if it was the commiter who signed it, but yeah

[visual hornet]

why doesn't ClientVoiceManager extend BaseManager? not really important, but just wondering, i don't see any reason for it to not do that