archive-library-discussion

[vernal rose]

@dawn merlin

[visual hornet]

interaction.options.getMember("user", true) throws an error when the input is a user but not a member.
that seems like an expected behavior to me?

[dawn merlin]

Yeahhhh that’s fine

[vernal rose]

How u can set the options to member only? Bcz it's input can be a user

[visual hornet]

just check for the output of getMember, or catch the error if you have that required set

[vernal rose]

U mean we should do a try and catch. We can just set it to false but but what I'm saying is required have no use in getMember

[visual hornet]

it... has the same use as it does in the other getX methods

[vernal rose]

In other cases we define that it should be required or not but in this case we can't

[dawn merlin]

no it does, compile-time types means that if something doesn't/cannot satisfy the expected type, an error is acceptable

[visual hornet]

im really not seeing the problem with this, if the user isn't in the guild then throwing the error (along with the typeguard thing) seems like expected behavior.
to me, at least.

[dawn merlin]

yeah no, there isn't a problem, I just forgot it threw

[vernal rose]

Ik that and that's why I was using true to avoid ts check now when i got a error in my bot so I remove all required and added if !member check to all cmds

[dawn merlin]

a try/catch should be used with true then

or switch to getUser()

[copper laurel]

This seems to have gone past lib discussion into general support on how to use these methods

[vernal rose]

Hm better use false to avoid a let and try/catch xD but I solved my issue so I thought it should be changed in lib but leave now

And for type check case u can just add a if statement to check if no member and Typescript will remove the null after that line

[dawn merlin]

I do agree that ultimately enforcing a try/catch, is not a great DX. I think a better solution for this would to have a type-guard ie Interaction.options.isMember('option-name'). This method would gaurantee that options.getMember('option-name') will always be a non-nullable GuildMember. I'll play around with this and see if anything comes to fruition.

Or just remove the required parameter 😉

Leaning towards the latter since (ignoring network errors) you can’t ever guarantee getMember is not-null compile-time. Setting required to true is just basically lying to you that it’s not null. It’s one thing to set required to true and have your option have required set to false. But you as a developer already know what options are required and which ones aren’t before runtime. getMember isn’t ever known to be present by a developer before runtime so it’s a different circumstance.

[vernal rose]

sorry for late response but this is what i was saying. Btw if u plan to remove the parameter then if possible lmk so that i can do my first contribution to djs 😅

[dawn merlin]

You don’t need to wait on anyone, you can make the PR whenever

[vernal rose]

Thank you

[vernal rose]

are there any specific reason why every other method's required is set to false by default in CommandInteractionOptionResolver but for getSubCommand and getSubCommandGroup it's true?

[outer raven]

because why would you be trying to get a subcommand or a subcommand group in a command that doesn't have such a thing

[vernal rose]

subcommand groups and sub commands can be used I mean like this

{
  options: [
    {
      type: "subcommandgroup"
    },
    {
      type: "subcommand"
     }
  ]
}

In this case when using 2nd one means sub command then there will be no subcommand group then it'll throw error but the subcommandGroup is present in that command. So it can also be default to false.

Idk if u understood what i mean because my English is so bad 😄

[outer raven]

that's why you can pass the parameter as false for those niche cases, but in most cases the subcommand (group) will be required

[vernal rose]

hm yeah. But like all other's have default to false so it can also be set to false unlike subcommand which should be default to true.

[outer raven]

you can always make a PR but I doubt it would be accepted because iirc that was a conscious decision when the initial pr was made

[honest barn]

i noticed in some places that arrow functions that return an object usejs () => { return { foo: 'bar' } }when () => ({ foo: 'bar' }) could be used, which is easier to read, is this intended? i can probably make a pr changing it, but i wanted some feedback first

[dawn merlin]

I don’t think it’s intentional I think the formatter does that automatically but you can see

[alpine bough]

is nor a typo?

should it be not?

[wild flax]

No

[alpine bough]

ok, thanks

[real jetty]

If builders is going to pre validate names for slashies could it be expanded to show the string in question and the specific error with it? Taking about these errors btw:
ZodError: [
{
"validation": "regex",
"code": "invalid_string",
"message": "Invalid",
"path": []
}

[tacit crypt]

We're planning on replacing zod so in the future errors will be much more useful

[quiet viper]

https://github.com/discordjs/discord.js/blob/main/src/rest/RequestHandler.js#L292
Currently when encountering a high amount of invalid requests it just fires the event.
Is this Idea in plan/something for the future?:

• When the Invalid Request Count hits a specific (userset) amount, it will stop all requests until the count/ratelimit resets (or the requests will be dropped - not the best solution)

[wild flax]

Don't think so

you can keep track of it yourself

[copper laurel]

@dawn merlin we can discuss the middleware concept here rather than fill Github if you want

I very much do want to support it, so please consider it constructive criticism lol

[dawn merlin]

Yeah that’s fine

[sonic frigate]

What about "custom" events?
Like an event: guildFetch
Which will be triggered on every fetch of a guild
So you could extend the cache with data like settings from a database related to that guild.
or like memberFetch
So you could for example fetch custom data about that member such as subscriptions, economy / rank stuff

Just an idea, I guess at this moment you'd need to do it on apiResponse I guess and then check the requested path

[visual hornet]

i mean, you could just add those yourself to your own code

[sonic frigate]

Let me guess, by looping through the cache's?

[visual hornet]

well no, just whichever ones you need or want

[sonic frigate]

That doesn't make any sense to me, elaborate please.

[visual hornet]

if you need guildFetch, then make that event, emit it after fetching guilds or add it to your version of djs within GuildManager#fetch or Guild#fetch

i don't see how an event for fetching guilds would relate to database fetching

[sonic frigate]

Add it to your version, is basically something you don't want to do as it get's lost every time you update your D.JS.

Manually after obtaining guild data would still not be satisfying as you'd still required to do multiple manual checks after that.

It's a feature I could see being useful to other people as well.

---

i don't see how an event for fetching guilds would relate to database fetching
It's an event... so you can smash your own sauce onto something that's being done, this was just an example.

In this case, it would be for fetching settings in a database.
Could be used to fetching data in a file.

Just data you might need more than once without the requirement to keep checking it.

Example: A bot log channel.
Fetching it once from the database right after the initial fetch that cached the guild wouldn't you require to check if the bot log channel id is in the cache on every single command you have.
If the guild is in the cache, the bot log channel exists as well.

On member fetch as example:
You could check if the member has a VIP membership active.
If not, take off the VIP role.
If they do, add or keep it.

On that you can also (re-) load your economy data.
On that you can also (re-) load the ranking data.

As this is always triggered when a guild or member is fetched, this data always exists and thus does not require an additional if (data !== undefined) -> obtain data

The event won't be triggered when the fetch data returned is from the cache.

[visual hornet]

that seems like something an extension would do, these aren't exactly gateway events from discord, no?
and also with those examples, you still need to add checks such as for the guild being unavailable, the bot losing perms, the channel being deleted, the member leaving, so this isn't going to be doing much anyways in those cases
said checks on "member fetch" seem to be better off based on fetching from the database than based on fetching from discord

[sonic frigate]

It's part of an automation.

These aren't gateway events no.
Doesn't mean it couldn't be a feature.

What does a guild unavailability or the bot losing perms have to do with your custom settings?
Pretty much nothing if you'd ask me.

Your last sentence is exactly what this event can be useful for.
The event is triggered AFTER it's fetched from discord to add your data to the cached version.

Thus adding your own sauce on it. hence that's what events are for.

[visual hornet]

Your last sentence is exactly what this event can be useful for.
so... if you need to remove vip from a member, you're just going to wait til that member gets randomly fetched?
again, you can just fetch from the database, check, then fetch the member yourself

that's what promises are for, not events

[sonic frigate]

So you insist on looping through 1000's of guilds per client possibly millions of members as well
Then run over each member on bot startup just to obtain the data.
Running a query the same amount of times as an event would be triggered. When this could be extended by triggering an event when the object you are working with is going to be necessary.

Again these are just examples this event would fit.

[visual hornet]

if you're referring to bulk fetch, then there's already an event for that, guildMembersChunk
those members aren't going to be randomly fetched reliably, you're still going to have to fetch them to do whatever you need to. for rankings or economy or whatever that you mentioned, those can all just be fetched on demand or cached

[sonic frigate]

Didn't know about guildMembersChunk
But it is exactly what I was talking about for on memberFetch.
This event is exactly what it could be useful for on guilds
However, guilds are already fetched on the beginning.
On a side note, guildMembersChunk would or wouldn't it be triggered when you fetch one member.

[visual hornet]

probably not, seeing as it's called Chunk and always gives a collection. but i don't know, i haven't used/tested it much.

as far as i can tell from discord docs, no

[sonic frigate]

Answer is no, and neither happens when the guild initially fetches the members (automatically after login)

[visual hornet]

because those a) aren't fetching b) aren't a request?

those are sent with guildCreate

[sonic frigate]

GuildCreate is triggered when a bot joins your guild....

[visual hornet]

https://discord.com/developers/docs/topics/gateway#guild-create

Guild Create
This event can be sent in three different scenarios:

1. When a user is initially connecting, to lazily load and backfill information for all unavailable guilds sent in the Ready event. Guilds that are unavailable due to an outage will send a Guild Delete event.
2. When a Guild becomes available again to the client.
3. When the current user joins a new Guild.

[sonic frigate]

Emitted whenever the client joins a guild.
https://discord.js.org/#/docs/main/stable/class/Client?scrollTo=e-guildCreate

[visual hornet]

im referring to the gateway event, not the djs event.

[sonic frigate]

I'm talking about djs events not gateway events whatsoever.

[copper laurel]

Every discord.js event corresponds to a gateway event

What you're describing though is modifying the internal structures that get stored in discord.js caches - exactly one of the major issues that resulted in the removal of Structures.extend

[visual hornet]

guildCreate for an unavailable guild acts as a patch for the guild instead of emitting the client event, though.

[sonic frigate]

Doesn't need to modify the cache, it's what the user desires to do with it.
Simply said:
a guild is fetched from discord
Event: apiRequest is triggered
When the response is received: event apiResponse is triggered
feature request: event: guildFetchedis triggered

a member is fetched from members:
Event: apiRequest is triggered
When the response is received: event apiResponse is triggered
feature request: event: memberFetchedis triggered

event guildFetch or memberFetch to fetch from discord wasn't what I meant, it's an event being triggered after it has been fetched from discord.

[copper laurel]

Way too much feature bloat imo, as you said you're free to implement those custom behaviours in apiRequest and apiResponse

[sonic frigate]

Like the event ready is when the client becomes available

[visual hornet]

you can just use the promise resolution from actually fetching them though

[copper laurel]

Those methods were introduced to allow users to act when API requests have occurred

[copper laurel]

This is another good point - additional events such as memberFetched are not going to execute before the promise resolves where you actually fetched a member

So whatever data you intend to expand isnt going to be returned yet

[sonic frigate]

If the member (or guild) isn't fetched, it's neither in the cache, the data isn't required at all then

[copper laurel]

Thats not what I said

Anyway, Im of the opinion that adding events for when every possible type of structure has been fetched is excessive feature bloat that offers very little to the actual execution of the fetches

[sonic frigate]

Not every. I only see it usable for guilds and members (atm) to be honest.

[visual hornet]

that's what you see, but if these do get implemented, someone's going to want them for other structures

[copper laurel]

Just because you only have those use cases doesn't mean others wont - if we're going to add a feature of this design, it would be done consistently

But, we probably wont

[sonic frigate]

Then that's fine as well. But anyways I'm out. Just a feature idea, turned down, cool. No need for me to spend more time on that then.

[outer raven]

@wild flax could you add if: github.repository_owner == 'discordjs' to the first line of each job in the documentation CI so that the workflow doesn't fail on forks?

[real jetty]

ayee monorepo setup, about time

👍

[quiet viper]

yeah saw it too, a quick question:
Does it mean that the existing code will be dropped soon and replaced with the ts code (like the rest ones) ?

[vernal rose]

I think so

[real jetty]

probably, typescript is better anyways

type safe

🌈

[ruby terrace]

this is already almost done

for /rest at least

[outer raven]

Is it worth making a PR for this?

[quiet viper]

As this includes a lot of breaking changes (like the @discordjs/sharder) will it be released in a new version like v15.x or even v14.x ?

Or is the plan: slowly replacing the parts with ts?
(sorry for the internal questions, will give me more planning safety...)

[ruby terrace]

/rest is planned for v14

[golden mortar]

so how would /rest work with undici

or is that just gonna be scrapped?

[ruby terrace]

the idea is to replace each module over time, and if its semver major then its semver major

I'm gonna port your pr to /rest, been waiting for the monorepo

[golden mortar]

nock doesnt work with undici, which means all tests need to be ported 😐

along with other issues such as using response.buffer, etc. (i did try to do the work)

[ruby terrace]

we're aware of that

[golden mortar]

thats great to hear

[ruby terrace]

my plan is to get /rest into djs, then implement undici in a semver:major bump of /rest

[golden mortar]

are u planning on waiting for nock support or were u planning on rewriting all of the tests using undici's mock client?

[wild flax]

Nock doesn’t work?

How come?

[golden mortar]

nock mocks the http(s) modules which undici doesnt use

[wild flax]

And yeah our second choice after nock would be https://mswjs.io

Which should work?

Since it also works in browsers

[golden mortar]

https://github.com/nock/nock/issues/2183

i messed with a few mocking libs that mocked sockets but didnt get very far lol

mostly from https://github.com/nock/nock/discussions/2247

[solemn oyster]

I plan to have /sharder done for v14.0.0

[ruby terrace]

Thanks for this, looks like nock may be pretty close https://github.com/nock/nock/discussions/2247#discussioncomment-1902118, maybe by the time I get to tests it'll be ready 🤞

[golden mortar]

doesn't appear to work either

[honest barn]

since d.js is a monorepo now, do module related prs go there, or they still go to the individual repo?

[opaque vessel]

The other ones have been archived

[honest barn]

cool thanks

[outer raven]

Has anyone else gotten this error after the monorepo change when committing to djs? I recently reset my PC so I'm not sure if it's related to that or the monorepo change

also I already updated all deps

[ruby terrace]

change the line endings in yarn.lock

[outer raven]

lf?

[ruby terrace]

if you're on windows it has to be crlf

[outer raven]

oh alright

[wild flax]

but dont commit it

lol

just change it for now

[ruby terrace]

it won't commit IIRC

[wild flax]

it will eventually be fixed in turbo

[ruby terrace]

I changed mine and commited and git just ignored it

[wild flax]

you sure can make it commit, but git will prolly convert it to lf again

[ruby terrace]

yeah, so it noops in the diff

[outer raven]

yeah that fixed it, thanks

[outer raven]

was this change intentional?

the rule was completely removed and lower-case seems to be the default, which no longer allows us to put class names in the scope

[wild flax]

yeah

[outer raven]

oh okay

so should I put the class name in lower case?

[wild flax]

sure

[outer raven]

alright

[wild flax]

or rather

not put the class name

but a somewhat generic one

instead of "CommandInteraction" its ok to just put "interaction" or "interactions"

[outer raven]

oh alright

this PR is very specific so I'll go with the class name but I'll keep that in mind for the future

Pretty sure I've seen this error before but I'm not sure what caused it and I'm getting this on the latest main commit, any ideas on what could've caused it?

I would try to debug but we can't install packages from github with the monorepo anymore

[tacit crypt]

restart ts server

[tacit crypt]

We've been deploying @next releases for several months now, which you're supposed to use instead of git installs

[solemn oyster]

yarn link, or run yarn pack in the d.js folder and paste the zip's contents into your bot's node_modules

[outer raven]

those are released once every 12 hours, not useful when going commit by commit

[opaque vessel]

What about resetting to commit hashes? Like git reset --hard <commit>

[outer raven]

yeah I know how to do it, it's a bit more tedious now but I can try to find the commit if you wish

yeah that's what I was thinking

[solemn oyster]

I think you want git bisect here

[opaque vessel]

Ah yeah, even better

[outer raven]

yeah so it was https://github.com/discordjs/discord.js/pull/7197 but I'm not exactly sure why
maybe @dawn merlin knows?

[outer raven]

context

we should probs add type tests for these functions

[real jetty]

It seems we cannot access to CommandInteractionOptionResolver after PR #7197, since options field has been moved to ChatInputCommandInteraction class

[dawn merlin]

I’ll be home in like 5min

[outer raven]

oh btw that's an actual js error, not a TS error only

[dawn merlin]

uh oh

[real jetty]

😂

[dawn merlin]

which type guard are you using for TS?

[outer raven]

none, plain old CommandInteraction

[dawn merlin]

is this straight from the event listener?

[outer raven]

it's in a command file which is typed like that

comes from this function

[dawn merlin]

ok but like does your command file handle both chat input and context menus or just chat input?

[outer raven]

just chat input

[dawn merlin]

Then you have the wrong type, it should be ChatInputCommandInteraction

[outer raven]

ahhh

[dawn merlin]

BaseCommandInteraction -> CommandInteraction

[outer raven]

so should we never use CommandInteraction from not on?

[dawn merlin]

no you can use CommandInteraction, but it should only be used in cases where you expect a context menu or a chat input command

[outer raven]

well then we'd need to cast it to use the options class right

[dawn merlin]

or use a typeguard yes, it's the exact same like before expect it's not called BaseCommandInteraction

[outer raven]

got it, thanks

so the js error should be fixed by #7210

[dawn merlin]

@real jetty did you just open that PR?

[real jetty]

nope

[icy bronze]

did it cuz I had the same issue

[outer raven]

@wild flax sorry for the ping, since the last publish dev failed and most issues seem to be fixed now, could you re-run the script?

[vernal rose]

As the repo is now in ts so it'll use import/export. And vscode have a settings for import

organizeImport or smt like that which organizes all imports which isn't used in djs. So is it's worth making a pr to disable that setting in .vscode folder?

[outer raven]

that setting isn't enabled by default and you shouldn't be able to commit with that anyway because eslint should fix issues before that if you run the git hook

[vernal rose]

Yeah that is disable by default. But eslint allowed me to commit. I committed from terminal and all the tests passed.

[outer raven]

sounds like a you issue
the repo shouldn't need to disable a setting that comes disabled by default, and the eslint rule is much better

[vernal rose]

Yeah that's why asked here before making a pr. Ty

[outer raven]

the maintainers may think otherwise tho so ig wait for them, but it would surprise me

[ruby terrace]

if you're talking in packages/discord.js eslint doesn't run in the typings file

its dtslint

[vernal rose]

ic dtslint run only in gh actions and not in git hook?

btw r u gonna migrate to @typescript/eslint?

[ruby terrace]

eslint doesn't work on d.ts files

[vernal rose]

oh ic

[ruby terrace]

its a non issue since typescript rewrite is happening sooner rather than later

[dawn merlin]

It does it just doesn’t have the same rules dtslint has

[ruby terrace]

some of it works, last time I tried it failed on the tests.d.ts

[balmy slate]

is there any example of a dynamic command parser for subcommands or subcommand groups?

[vernal rose]

pls use #djs-help-v14 for help

Current labeler only adds labels based on files changes.

https://github.com/rafaelalmeidatk/webhook-labeler

This webhook can be used to label like

created by: discord core maintainer

this is used in nextjs

[dawn merlin]

what's the point of this if gh already tells you who's a member and who isn't

[copper laurel]

Yeah I dont really see the benefit of that

[vernal rose]

yeah that makes sense

[vernal rose]

I was talking with the owner and he said this.

[copper laurel]

...okay?

[vernal rose]

if i've understood correctly what he've said then he means if anyone who isn't a member of djs creates a pr then the current labelers won't work

nvm ig it's working in djs as it worked for Rodry's pr so leave it

[ruby terrace]

if you were to make a pr to your own fork it wouldn't work, that's fine

[delicate sigil]

why you guys gonna shut down v12?

@ruby terrace any idea?

[ruby terrace]

its already shut down, it will stop working soon anyways when discord stops supporting the gateay/api version it uses

[delicate sigil]

oh

[copper laurel]

wdym why

Becuase we made v13

[outer raven]

Dev releases are broken because the eslint hook is failing I think

[vernal rose]

why this is showing? It wasn't showing these errors last time

[solemn oyster]

Because whatever used to cause a type error, not longer does it

[vernal rose]

oh

[vernal rose]

btw I'm not able to commit what's wrong here?

[solemn oyster]

Go to the yarn.lock file and change LF to CRLF

[vernal rose]

Idk how to do that 👀

[vernal rose]

how can i do that?

[solemn oyster]

Bottom right side in VSCode, where it says "LF"

[vernal rose]

oh okay ty

[outer raven]

maybe pin this here?

[vernal rose]

that one worked but now. I didn't touched role file then how can i solve it?

[outer raven]

wait for #7215 to be merged

[vernal rose]

ok. my pr have conflict so i was fixing that and now

[solemn oyster]

Yeah, main's green

So that's a merge conflict on your side

Oh wait, it isn't

[outer raven]

hm?

[vernal rose]

conflict isn't in role file. It's

nvm

[unique axle]

comaptibillity with twilight http proxy

[outer raven]

Can someone try re-running the publish dev script again? Last one failed because of the unused process so maybe it will work now

All dev versions on npm are deprecated now and the last one was published 10 days ago

[wild flax]

Still fails because of the unused directives apparently

but I can't reproduce running the same commands locally

[outer raven]

the unused directives can be removed tho right?

[wild flax]

I dunno

[real jetty]

https://github.com/discordjs/discord.js/pull/7218 😅

[outer raven]

are you the author of that PR?

[sullen idol]

For the Permissions constructor, as a parameter, can you add like a permission object to return a bitfield? Example:

const { Permissions } = require('discord.js');
console.log(new Permissions({ SEND_MESSAGES: true, /*extra perms*/ }));
//object was created by hand, not of permission class or wtv
//throws invalid bitfield error

[slate nacelle]

That's not exactly suitable for the permissions constructor, since it's actually 2 bitfields (3 if you want to be pedantic), we have this instead: https://discord.js.org/#/docs/discord.js/stable/class/PermissionOverwrites?scrollTo=s-resolveOverwriteOptions

[sullen idol]

Alr lemme see

[woeful rain]

I know a few people have farmed PR requests using bump licenses. I understand that it's been closed but in a few packages like voice it's been accepted. Now that the discord.js repo is like a monorepo, it says 2020 - 2021. Shouldn't this be changed to 2020 purely so that we don't have to make these pull requests every year afterwards?

All packages with "xxxx - xxxx": voice, collection
Without license: rest

[dawn merlin]

The year doesn’t need to be updated regardless

[woeful rain]

Okay, but wouldn't it be better if there was only a starting year in each license? One more thing, there is no license in the rest package.

[dawn merlin]

I’m mean I’m sure rest needs a license, a ticket should probably be created for that I’m not sure about the ranges

[sullen idol]

GuildMemberRoleManager.add(), tho it says it accepts role objects it doesnt

[opaque vessel]

Make an issue with a reproducible code sample if you've found an issue

[errant brook]

just a note to the core contribs

it'd be nice if you guys could update the old readmes to point out that the code has been moved to discordjs/discord.js/packages/

[wild flax]

What old readmes

[vernal rose]

Ig the old repo readme in github which are now archived

[vernal rose]

I was testing the latest issue of GuildMember never type and saw this.

If I do if inCachedGuild then return, then the interaction should become interaction<"raw"> but it's the default now. Is it's a bug? asking because i don't have much knowledge of these this is type

[wild flax]

if its not in a cached guild

it needs to be a raw interaction

lol

or rather one with a raw guild

[vernal rose]

yeah but the type is still "raw" | "cached"

after searching a bit i found that it's not possible if that inCachedGuild is true only then the type will narrow else it will be the same

[drifting knot]

should the main djs repo be using yarn 2+? i'd be happy to PR if yes

[wild flax]

Turbo doesn’t work with yarn2+

[drifting knot]

eh... it does in my experience

[wild flax]

It does not

[drifting knot]

have you run into issues with it?

i know their docs explicitly say it doesn't but like

[wild flax]

Jared himself said it doesn’t, and yeah we’ve run into cache hit misses constantly when running yarn 3

[drifting knot]

hm ok

[dawn merlin]

@golden mortar will you be opening another PR to /rest for undici?

[golden mortar]

maybe, if ckohen doesn't beat me to it (#archive-library-discussion message)

the problem with /rest is that you'd have to rewrite every single test to use undici's mock client (which isn't api compatible with nock) and no other mock libraries work

and undici's mock client doesn't have as many features as nock

[wild flax]

Undici has a mock client?

And it could maybe be extended, we don’t use a whole lot of stuff I guess

[golden mortar]

it does! https://undici.nodejs.org/#/docs/api/MockClient

although this is about as far as i got rewriting the tests https://www.toptal.com/developers/hastebin/adelebajuc.typescript

[wild flax]

You can intercept

So i guess you can do anything you want then

Just more own code

[golden mortar]

yeah nock's api is way nicer with the chaining

and there are a lot of tests that need to be rewritten

[drifting knot]

hm, seems like yarn 1's lack of a "workspace:* dependency version feature is why lint needs a build first

[solemn oyster]

@outer raven hot take, you can make an utility method to abstract all those nullish and dates

[outer raven]

like a convertToDate method?

[solemn oyster]

Oh wait, it's just 2 usages, I thought it'd be more places

[outer raven]

nah I looked everywhere and its only those two

could come in handy in the future though ?

[wild flax]

Nah

No unnecessary abstraction

[solemn oyster]

Nah, we can look into that if we run into the case of needing more dates

[outer raven]

aight

[outer raven]

@wild flax instead of using an action to assign reviewers why don’t you just add a CODEOWNERS file

[wild flax]

I see no reason to

[outer raven]

It runs faster and already exists on github itself, the action ends up being useless because it does the same

[wild flax]

The people you choose as code owners must have write permissions for the repository.

[outer raven]

Don’t all maintainers do?

[wild flax]

Also code owners is a bit more than just "add this person to the review"

[outer raven]

The only other use is if you have branch protection rules which you don’t

Although it would automate more things too

And would make it more clear to the author of the PR what needs to happen in order for their PR to be merged

[opaque vessel]

Hulloooooo @drifting knot, I think your pull request regarding Turbo optimisation may have caused this lil' issue:
https://github.com/discordjs/discord.js/runs/4755241901?check_suite_focus=true
are you able to look into it? It worked fine before that change it seems

[drifting knot]

ugh, was hoping this wouldn't happen on CI too

could you revert my PR?

[opaque vessel]

@wild flax ^ x:

[drifting knot]

for whatever reason, turbo only sometimes runs the build script before lint

[wild flax]

[drifting knot]

i spent a while resting ^build vs build in the dependsOn array locally

super inconsistent results

i assume it's a bug on their side

[wild flax]

There’s also a bug if you turn on parallelization

Where it fully ignores the dependsOn lol

[drifting knot]

lmfao

[errant brook]

discordjs/builders
discordjs/collection
discordjs/voice

[wild flax]

@remote wasp can you rebase this:
https://github.com/discordjs/discord.js/pull/6642

[vernal rose]

https://github.com/discordjs/discord.js/runs/4762790759?check_suite_focus=true

Here EventEmitter was used in docs. If he removes the import then EventEmitter will be undefined in docs but if he imports then it'll cause lint fail due to unused var. Than what's the solution?

[opaque vessel]

Without explicitly denying rules, just remove the JSDoc

[vernal rose]

You mean remove {EventEmitter} from jsdocs?

Means the param line or only this type?

[opaque vessel]

All of it

/**
 * Decrements max listeners by one for a given emitter, if they are not zero.
 * @param {EventEmitter | process} emitter
 * @private
 */
decrementMaxListeners(emitter) {
  const maxListeners = emitter.getMaxListeners();
  if (maxListeners !== 0) {
    emitter.setMaxListeners(maxListeners - 1);
  }
}

To

decrementMaxListeners(emitter) {
  const maxListeners = emitter.getMaxListeners();
  if (maxListeners !== 0) {
    emitter.setMaxListeners(maxListeners - 1);
  }
}

Then it won't show up in the documentation at all... since it's private I guess this is a viable solution without disabling valid JSDoc rule or unused imports rule

@solemn oyster what do you think^

Actually all he did was forget a description :thinking: seems fixed now

[vernal rose]

Yeah and he remove the EventEmitter import from 2nd file which was causing error last time. Now he removex so its undefined in docs.

[opaque vessel]

EventEmitter will link to https://nodejs.org/dist/latest/docs/api/events.html#events_class_eventemitter everything looks good now!

[vernal rose]

So there is no need to change anything else right?

[opaque vessel]

Other than what I just dumped as a review just now x:

[remote wasp]

👍

[vernal rose]

We can no longer add a Pascel case subject. So should I create a pr to change these?

[dawn merlin]

What page is that?

[copper laurel]

probably the contributing guidelines or something

[vernal rose]

https://github.com/discordjs/discord.js/blob/main/.github/COMMIT_CONVENTION.md

[dawn merlin]

Oh yeah, I though this had to do with the enum PR lol

[vernal rose]

xD btw should i create a pr to change them?

[dawn merlin]

Yeah you don’t need my permission

[vernal rose]

changing only 2nd one. Do i need to change 1st one too?

[dawn merlin]

Just open a PR and if there’s something wrong we’ll let you know

[vernal rose]

ty

[warped crater]

thoughts on adding a spoiler prop to https://discord.js.org/#/docs/main/stable/typedef/FileOptions that just takes a boolean

I found myself needing to spoiler an image I wanted to post via URL and it felt so unintuitive at first

I did know I could prefix the filename with SPOILER_ but then I was like "how do I actually pass the file now" until I noticed BufferResolvable does take URLs

regardless of how intuitive it is right now - feel like this is the sort of thing the library should offer 'abstraction' for

[opaque vessel]

Make a new MessageAttachment then https://discord.js.org/#/docs/discord.js/stable/class/MessageAttachment?scrollTo=setSpoiler

[warped crater]

I did notice the class but having to make an instance for a task this trivial feels off.

[opaque vessel]

It's also a trivial task to prefix SPOILER_, but adding a boolean option would result in duplicate code

[wild flax]

https://giphy.com/gifs/moodman-morgan-freeman-hes-right-you-know-duM6JZemPlOjUyqmxd

[fervent walrus]

is v14 of the library going to have packages/sharder?

[vernal rose]

@fervent walrus

[fervent walrus]

noice

[hot echo]

Is Interaction.locale coming soon?

[dawn merlin]

it's in the latest dev build, if you're brave enough to use it

[hot echo]

I'm not

Thanks though

[outer raven]

Installing the dev releases and updating breaking changes as they come is better than updating it all at once btw

[idle glade]

Hope this is the right channel, apologies if not does, or will in the near future have support for the other application command types, USER and MESSAGE? or will it just be CHAT_INPUT commands?

(https://discord.com/developers/docs/interactions/application-commands#application-command-object-application-command-types)

[unique axle]

These are already supported under the term "context menu", see #archive-interactions pins

[errant brook]

when im committing the formatting git hook errors out at this, i didn't touch this file so what should i do? skip the hooks and commit? or should i fix the issue if possible (this will be out of scope for my pr)

[wild flax]

That shouldn’t be an issue

Make sure to reinstall node modules

[errant brook]

oh ok, doing that

yeah that fixed it, thanks!

[icy bronze]

@tacit crypt did I do it wrong or uh?

i'm re-thinking of my pr

[analog oyster]

not much else you can do that wouldn't take too much effort / keep things readable

[icy bronze]

I mean

[dawn merlin]

Looks fine

[icy bronze]

ok

ty

[tacit crypt]

Nono, it was more of a poke to why we should be using enums for these in the future

[icy bronze]

yeah that got me wrong lmao

[analog oyster]

[icy bronze]

i'm not event sure of the changes

I need to test more

I get ChatInput as this._hoistedOptions[0]?.type, or it's a subcommand

and the name fits my subcommand name

welp another PR

nvm I will add it to the one I made

[icy bronze]

Option "content" is of type: String; expected STRING.

[outer raven]

Why is the old PLAYING activity type called Game on discord-api-types?

[analog oyster]

@dawn merlin why not add a locale enum in -types and then use that on discord.js?
in response to: https://github.com/discordjs/discord.js/pull/7261#issuecomment-1011395464

[dawn merlin]

thats a good point

[outer raven]

That doesn’t sound like a good idea to me but ok

[outer raven]

hate to be that guy but could this be merged before the next dev release? Currently some things are throwing type errors where they shouldn't and this should fix them all https://github.com/discordjs/discord.js/pull/7260

[devout fjord]

idk if it fits here, but can we talk about whose idea it was to depricate using strings for the footer, author (and as far as i can tell also for fields). Now we have to use objects, which isnt bad per se. but if you are like me and have a utility bot with 30+ commands, all of which have atleast 2 or 3 different embeds which it can send back it kinda will be a lot to change wont it?

[golden mortar]

the idea was to line up the api with /builders for an eventual transition, since it's only deprecated you can take ur time replacing strings

[devout fjord]

i mean ig

but having a blah blah blah is deprecated error spamming your console isnt the funnest thing in the world, tho my db also spams console so i guess i cant complain

[golden mortar]

the deprecation message should only show up the first time you use it which isnt really spam

[devout fjord]

well yes, but for testing i restart my bot a lot, meaning i see it many more times. which ig cant really be changed on their end

[wild flax]

man, that really sucks to hear

[unique axle]

deprecated error spamming your console
Deprecations are not errors on patch and minor versions

[devout fjord]

ye its not really an error, but still an annoying msg

anyways

guess ik what ill be doing this weekend

tbh the only reson i even updated was because interaction.editeReply() wasnt working anymore, which eventually was due to a different issue but still

also this situation could have been avoided if only i didnt just add stupid commands noone will ever use. e.g. /dogeify, /curseify, /uwuify (as for what those do, dont ask) and the 3 text to image commands, 1 is normal, 1 uses mc blocks and 1 uses an ai to try and make an image out of text. which could probably just be sub commands.

[ornate topaz]

i think you could do a single find and replace in vsc using regex.

[devout fjord]

hmmm, well yes but how would i be able to still keep the contents of the footer

and even if i do keep the content and like replace only the first part i still need to add an extra bracket at every command

[dawn merlin]

look I'll do it for you how does that sound?

[unique axle]

let's stick to developing discord.js in this channel, please, for regex and general chat we have #archive-offtopic

[devout fjord]

nahh

[peak zinc]

i have a question about the new monorepo setup... https://github.com/discordjs/discord.js/pull/7175

for other packages who were previously using some of the subpackages (i.e. collections only), what does this mean for them?

will those other packages still receive updates on npm? will there be any change to how dependent projects should organize their dependencies?

[vivid field]

there won't be a change regarding npm releases and such

[peak zinc]

or is it recommended for other people to just stop using collections lol

[unique axle]

the packages are still released to NPM as before, the only thing that changes is that issues and PRs will go to the main repository now

[vivid field]

it's easier to apply changes across multiple projects this way

[ruby terrace]

Nothing is changing in how you as a user consume the discord.js ecosystem, its just ^

[peak zinc]

ah, ok, thanks

my project uses d.js collections and i was worried this would break something in the future

ty!

oh, one more thing

why isn't discord-api-types package being moved to main repo as well?

[ruby terrace]

I think because its npm package isn't scoped to @discordjs and its designed to be independent of discord.js

[peak zinc]

isn't collections package even more loosely related to djs than api types?

[unique axle]

one might think that at first, but collection only exists because of discord.js needing a k/v structure for caches in the first place

whereas api types are more likely to be used by other libraries

[ruby terrace]

also another collection exists on npm so we need to scope it to publish

[peak zinc]

more likely than collections???

[peak zinc]

^

[vivid field]

in most cases a map is enough, whereas the discord api types are way more complex and feature-rich

[ruby terrace]

yeah, Collection is an extension of Map and...beat me to it

[peak zinc]

interesting

[peak zinc]

so why exactly does collections exist again? like why wouldn't regular map work

for d.js

collections only adds some utility methods to maps right?

[vivid field]

yeah

but they're pretty useful in this case

[ruby terrace]

Probably the most important thing is filter

[vivid field]

filter and find I'd say

[ruby terrace]

oh right, forgot about find

[outer raven]

Will the issues on the old archived repos ever be transferred to djs?

[opaque vessel]

Nah

If they're still around, they should be made anew

[dawn merlin]

I thought gh had a "transfer issue" button

[solemn oyster]

I mean... Map is already a K/V structure

[outer raven]

And it does

It would be pretty easy considering they’re all on the same org

[copper garden]

Is the MessageEmbed.setFooter method with a single string supposed to be deprecated?

The docs seems to suggest that only the second parameter of setFooter is deprecated, nothing about the first parameter as string

[visual hornet]

i don't think so? same as the setAuthor allowing a single string?

[outer raven]

It won’t anymore

So ig yeah that is intentional

[ornate topaz]

what is

cause those 2 messages seem to contradict each other

[visual hornet]

"setAuthor won't allow a single string, so setFooter with a single string being deprecated is intentional"?
seems fine to me

[vernal rose]

Both footer and author will now accept a object and no more single string

[ornate topaz]

but the original question asked if it is meant to be deprecated at all since docs don't say that it is deprecated

[vernal rose]

https://github.com/discordjs/discord.js/blob/2bb40fd767cf5918e3ba422ff73082734bfa05b0/packages/discord.js/typings/index.d.ts#L1688

U can check this typing for details

[visual hornet]

ah, i see what you mean there

[vernal rose]

Yeah single string is deprecated if u see the typing but it's not mentioned in docs probably adding it in the description will be good

[copper garden]

So the setAuthor deprecation implementation needs to be fixed too if the typings are correct

[vernal rose]

Typing and implementation both r correct but ig there should be a msg about deprecated string in the docs

[copper garden]

Currently as implemented, setAuthor(string) does not trigger a deprecation message. But setAuthor(string, string) does

[vernal rose]

Oh ic lemme try

[vernal rose]

But anyways as there will be no 13.6.0 (as per ik) and v14 will use /builder so I don't think a fix is necessary what do u think?

[copper garden]

A fix is necessary to provide accurate documentation

[vernal rose]

If u check https://github.com/discordjs/discord.js/blob/2bb40fd767cf5918e3ba422ff73082734bfa05b0/packages/discord.js/src/structures/MessageEmbed.js#L439 then it should emit a deprecated warning

Author my bad lemme check tha

Currently as implemented, setAuthor(string) does not trigger a deprecation message. But setAuthor(string, string) does

https://github.com/discordjs/discord.js/blob/2bb40fd767cf5918e3ba422ff73082734bfa05b0/packages/discord.js/src/structures/MessageEmbed.js#L380

It should emit for only a string. docs need a clarification

[copper garden]

According to the PR, it’s supposed to be conforming to what the builders package implemented, which means setAuthor is not supposed to take a string.

[loud jay]

#7153 in discordjs/discord.js by Jiralite merged <t:1640772256:R>
refactor(MessageEmbed): Deprecate strings for setAuthor() (completely) and setFooter()

[vernal rose]

Yeah. Ok lemme first confirm that r u saying about it needs to be fixed in docs or in code.

[copper garden]

That was my question

[vernal rose]

The code is correct and typings too. Both says that if u pass a string as the 1st parameter then it'll throw depreciation warning

But in docs it says only for 2nd parameter and not about 1st parameter

[copper garden]

The typings, docs, and implementation are inconsistent with each other when it comes to setFooter and setAuthor

[vernal rose]

Implementation and typings aren't inconsistent if I've checked correctly bcz both says if 1st parameter is string then it's deprecated

[copper garden]

The typings says that strings are completely deprecated.
The docs says that string parameters after the first one are deprecated.
The implementation is halfway: single string allowed for setAuthor, but no strings allowed for setFooter

[vernal rose]

In implementation single string is also deprecated. Yeah doc only says about 2nd param and not 1st that's what I said in above msg

[zenith oracle]

Not sure if this is known but on the latest 2 dev releases I get TypeError [COMMAND_INTERACTION_OPTION_NO_SUB_COMMAND]: No subcommand specified for interaction. even if there is a subcommand. Downgrading to 14.0.0-dev.1641945998.1479e40 worked and debugging the code with the latest version I can see that the option is present in the raw options data.

[wild flax]

Is known

Dev releases have no guarantee

[zenith oracle]

Ok 👍

[woeful rain]

locale is undefined in interactionCreate event (defined in WS INTERACTION_CREATE event)

• I don't see the addition of the locale in the interactionCreate event, but the discord itself returns the locale.

14.0.0-dev.1642032388.2bb40fd

latest djs dev

[opaque vessel]

I cannot reproduce, you very much likely are not even running on that commit being as it's not autocompleting for you

[woeful rain]

its my problem

resolved, thanks

[fervent walrus]

Does it make any performance difference by importing/requiring setInterval from 'node:timers'?
I have seen discord.js importing setInterval and setTimeout from 'node:timers' module when its globally available.

[opaque vessel]

Not sure about performance but Node.js considers it to be a best practice to do so

[fervent walrus]

oh, I thought it was for documentation purposes

[woeful rain]

From kyranet's PR (https://github.com/discordjs/discord.js/pull/7157):
For the performance kids, because the globals are now const assigned, it's faster than pulling from the global, since the value cannot change.

[lethal storm]

Hello library people. When might a version with the new interaction locale property hit stable?

[real jetty]

v14 most likely

[golden mortar]

on latest dev version, MessageButton.setStyle with a value from the ButtonStyle enum crashes, is this known?

import { MessageActionRow, MessageButton, ButtonStyle } from 'discord.js';

new MessageActionRow().addComponents(
    new MessageButton()
        .setCustomId('primary')
        .setLabel('test')
        .setStyle(ButtonStyle.Primary)
);

[dawn merlin]

yes components are currently non-functional on dev

[golden mortar]

thanks 👍

[lethal storm]

Oh, I see

[lethal storm]

Speak of the devil

[real jetty]

what does discord.js use for keep connection alive and receiving data?

[dawn merlin]

https://discord.com/developers/docs/topics/gateway#heartbeat

[real jetty]

so an interval with heartbeat?

how do I generate a session_id tho?

[dawn merlin]

https://discord.gg/discord-developers

[analog oyster]

I just realised the return type of GuildBanManager.create() is a promise of GuildMember | User | Snowflake

but why

[unique axle]

it resolves the best it can
if the user was a member of the server (and cached), a GuildMember is returned
if the user was cached, a User is returned (was not a member of the server, "hackban")
if the user was not cached, the ID is all we can provide

[analog oyster]

i know what it is doing, i was asking why. why not return a single thing, or nothing at all since if you're using that method then you'll already have at least the user id

[wild flax]

I don’t see the problem

[outer raven]

There’s been a discussion here about making managers not return anything and that was one of the reasons why

I think it would be much better for it to not resolve anything and let the user decide what they want

[wild flax]

🤨

[outer raven]

I don’t remember where that is anymore but I think @copper laurel was in it

[copper laurel]

How do they have any choice if it doesn't return anything

I dont remember caring about this one, dumb hill to die on

I certainly don't think all managers should not return anything

[radiant iron]

Add timeout in fetchAuditLog, I cant fetch audit log for timeout

[unique axle]

Timeouts are of type 24 MEMBER_UPDATE

[opaque vessel]

@radiant iron ^

[radiant iron]

oh, thank you so much

[azure hull]

RESTPostAPIApplicationCommandsJSONBody is supported for ApplicationCommand#equals and ApplicationCommand#edit right? From the code it looks like it. But the typings don't allow it.
Bug or am I wrong?

I'm on d.js v13.5.0

[hardy plume]

i noticed the master branch moved to workspaces. is there any chance that interaction stuff will be abstracted into its own package so it could then be used with something like an http server?

[wild flax]

It’d have to be a new package

[outer raven]

then it was probably someone else but I'm sure someone said something along the lines of "we should make the managers return whatever the API returns (which in most cases is nothing) and only return usable structures when calling the methods on those structures itself

[outer raven]

why does npm run build:deno create 132 new files on discord-api-types? I'm trying to commit something small and all of these files get added for some reason

[dawn merlin]

is the from the git hook or are you running this manually?

[ornate topaz]

because it builds for deno?

[outer raven]

Git hook

[outer raven]

I only changed a few lines in some files, didn’t add any so it shouldn’t be committing stuff I didn’t do right

Or is it fine to PR with that

[fallow crater]

Is there a reason why <Interaction>.locale is typed as string over something like InteractionLocale? Just curious, and asking if it'd be worth making a PR for it

[outer raven]

I believe that was suggested and someone was gonna do that

[fallow crater]

👍, I don't mind doing it if they aren't able to

[wild flax]

-types isn’t released yet with it iirc

So you couldn’t even do it if you wanted to

And 13.6.0 most likely won’t get it

[fallow crater]

ah, alright

[outer raven]

@tacit crypt do you know if this is normal?

[tacit crypt]

Did you clean:node before?

@outer raven

[outer raven]

should I?

I did and then undid it

[tacit crypt]

You shouldn't have any built files

Before running build:deno

[outer raven]

oh right now it did work

weird, but I made the PR without that mess anyways so it's all good

[analog oyster]

the problem is that the function has extra complexity for no reason, and the return type is more unpredictable

the more reasonable return type is guildmember|null since you wont be able to fetch the member afterwards because.. they were banned

like i said, if you're using that method then you'll already know, at least, the users id
so you can always get the user from the cache/fetch them yourself

making the function return guildmember|null or nothing at all would remove unnecessary complexity from the function

[copper laurel]

But a reliable return type would be Snowflake

Because we can always return that

[outer raven]

But that’s useless because you already have it

[copper laurel]

I know

But its no more useless than null

/ not returning anything

[outer raven]

But not returning anything makes way more sense

It sticks to the API behavior

[vernal rose]

when fetching a GuildTextBasedChannel's message it returns Collection of Message<boolean> instead of Message<true> is it's intentional?

[warped crater]

I assume that'd be this signature? https://github.com/discordjs/discord.js/blob/main/packages/discord.js/typings/index.d.ts#L3064-L3067

yeah this just returns Message without passing in a generic

this seems like its type parameter could be inferred unless there's something I'm missing

[outer raven]

yeah you could say that is always cached

since you literally just fetched it

[warped crater]

well, not always

you could literally pass cache: false

[outer raven]

that's not what this type parameter means

[warped crater]

oh yeah nvm I just saw the types

[outer raven]

the cached boolean is whether some properties are present or not

[warped crater]

yeah this seems like it could just be Message<true> then unless there's something I'm missing

[outer raven]

actually it's weird because that type parameter assumes things that aren't necessarily true

it seems like it's used for messages in guilds

[analog oyster]

you can pass true if the messagemanager is from a guild channel

[warped crater]

hm

[analog oyster]

the name "cached" for the generic type in message isn't very accurate

i suppose the MessageManager could also have a "cached" parameter so you can pass it down to the messages

[warped crater]

yeah I see now

[vernal rose]

https://github.com/discordjs/discord.js/blob/7c07976018728154be0ce0314d3e8dfe8eb9ed5b/packages/discord.js/typings/index.d.ts#L1536

Yeah I think this true isn't for cached but it's for message in guild.

[outer raven]

yeah so maybe that name should be adjusted

[outer raven]

Can we bring back #djs-at-dev for users of the dev versions? Or maybe once they're fixed but it would make sense now that we're going into v14

[atomic locust]

ButtonInteraction {
  type: 'MESSAGE_COMPONENT',
  id: '932222868455055380',
  applicationId: '919328973585002606',
  channelId: '931943047741210655',
  guildId: '925331433831170058',
  user: User {
    id: '853394858895343636',
    bot: false,
    system: false,
    flags: UserFlags { bitfield: 0 },
    username: 'Sopow',
    discriminator: '7130',
    avatar: 'a4b3672e77d23278ff7c931aad0ca838',
    banner: undefined,
    accentColor: undefined
  },
``` i logged interaction, but there is no channel
In the documentation, channel exist https://discord.js.org/#/docs/discord.js/stable/class/ButtonInteraction?scrollTo=channel

what is this bug ?

[void rivet]

it's not a bug, channel is a getter

[atomic locust]

that is to say ?

[visual hornet]

it's not a property, it's not going to show up when you log the object

[ornate topaz]

not everything is going to be displayed when you're logging entire objects, javascript does have a way to set properties as non-enumerable, and discord.js utilses that.
if you want to see all properties, go to documention for respective class, or try logging the value directly, instead of object that contains it

[rough roost]

you can still log private properties and getters if you really want to, see showHidden and getters https://nodejs.org/api/util.html#utilinspectobject-options

[upper moss]

Hi i think i found a bug in @discordjs/voice. Problem is: when i disconnect the voiceconnection and also stop the player i see 2 Sockets being not disposed when i look at the process._getActiveHandles() but if the player goes to idle because the resource finished rather then me using AudioPlayer.stop() it properly disposes that sockets is this my code problem or if anyone can replicate this should i make an issue on gh repo

[visual hornet]

if you can reproduce it on your own i think you could go ahead and make the issue to see if other people can reproduce it?

[upper moss]

i am not sure if it is because of my dependencies, node version etc etc because of nobody ever pointing at this problem in anywhere so i didnt wanted to open an issue first

[zenith oracle]

If you can reproduce the issue with a minimal reproducible example you can create an issue, then, if the problem is not in the package, the issue will be closed

[upper moss]

okay i am making an issue

[zenith oracle]

I see in the README, where are listed the optional packages, that erlpack is one of them, suggesting to install it using npm i discord/erlpack:

erlpack for significantly faster WebSocket data (de)serialisation (npm install discord/erlpack)
But I see that erlpack is also published on npm so it's possible to use npm i erlpack.
Is it suggested to install the package from GitHub for a specific reason?

[wild flax]

Yes the published one is not published by discord

[zenith oracle]

Oh, thank you very much

[lofty birch]

Is there any reason MessageComponentInteractions don't have a messageId? They have a channelId and guildId

[opaque vessel]

Discord sends a channel_id so we show a channel id. Discord sends a guild_id so we show a guild id. Discord does not send a message_id. Discord sends the entire message object. Just get the id from there

[outer raven]

Is there a typedef similar to GuildChannelResolvable but without ThreadChannel?

[lofty birch]

👍

[opaque vessel]

Nu-uh

[unique axle]

⚠️ WHO PINGED ME?!?!?!
We have been experiencing a mention raid, our bot took care of it (#mod-log)
No, you don't need to complain about it
Yes, we will action shitposting in response to mention raids

[golden mortar]

do u guys think EventEmitter subclasses should be passed captureRejections? this allows proper error handling for async callbacks https://nodejs.org/api/events.html#capture-rejections-of-promises. ive noticed a few spots in the code where this occurs and obviously most users probably have async callbacks in some capacity

for a real world example...

client.on('ready', () => console.log('ready'));
client.on('error', (e) => console.error(e.message));

client.on('messageCreate', async (m) => {
    // do some async task here that throws an error
    throw new Error('whoops');
});

this will no longer exit the program with an unhandledRejection

[outer raven]

you could make a PR for that

[raven juniper]

this is incorrect, that's not what the error event is for -- e: didn't realize this was #archive-library-discussion and there's a pr or something oops

[golden mortar]

with captureRejections, eventemitter auto emits the error event, regardless of how discord.js uses it as well

i've checked and the example works as expected

[raven juniper]

i thought this was support when i opened the server continue on

[opaque vessel]

Doesn't this say... experimental? o,o

[golden mortar]

yes but it has been there since around 2019 so i dont think it matters much

[opaque vessel]

If it doesn't matter much, then they should remove the warning :P

But they haven't, so I'm uncomfortable with it

[golden mortar]

https://github.com/nodejs/node/commit/9a85efaa7f5f22c6905bf47d672dd73738787437

they have for v18 i guess? same with Blob & Web streams too

[opaque vessel]

o,o

[outer raven]

v14 will probably release with node v18? idk

or probably similarly to v13, which released with v16 as a requirement while it was on current still but it hit lts later

[lilac tulip]

so we wont have to have try/catch in every async listener anymore?

[golden mortar]

as long as you have an error listener

[lilac tulip]

so it‘s the same as if I listen to unhandledRejection and handle rejections there

[golden mortar]

unhandledRejection event doesn't handle the errors, it just tells you there was an unhandled rejection

[lilac tulip]

https://nodejs.org/api/process.html#event-unhandledrejection

wait roly

rlly*

I thought it also handled them

I‘m not home atm to test it

[lilac tulip]

so I just tested unhandledRejection and it indeed prevents the program from crashing

[golden mortar]

preventing the program from exiting and handling rejections are two very different things

const fd = fs.openSync('.'); // might throw error
// later on
fs.close(fd, ...);

although unhandledRejection prevents the program from crashing, you are still leaking file descriptors (for example)

[lilac tulip]

I dont really get the difference

idk what file descriptors are but nvm this is not the right channel

[maiden raptor]

Wouldn't be good if it specified in the docs the permissions needed for both the bot and the user to run functions for example create a channel, timeout someone...

[unique axle]

we cannot feasibly document permissions, discord can change them at will without any prior notice

they are documented upstream on discord api docs, but it's not feasible to copy these via PRs every time they're changed either
most that i can personally see happening there is a link to the upstream docs as to which endpoint is used

[ruby terrace]

Node 18 is too far out for that, it won't even be in development yet

[ruby terrace]

Even if listening to unhandledRejection prevents the program from crashing, that's mostly so you can log it and exit cleanly

[lilac tulip]

oh alright so the method he suggested would be cleaner

[outer raven]

it hits LTS in october this year, just like node 16 did last year

now idk how long v14 development is gonna last

[ruby terrace]

that's really far out

considering the amount of features Discord is gonna add to get over the line for message intent and we've said no more v13 releases? I think you get the picture

[outer raven]

yeah I see what you mean

so would the plan be to have v14 out by april?

[solemn oyster]

No, far earlier than that

[dawn merlin]

v14 should at least ship with modal support

[copper laurel]

Planning specific numbers on specific dates is troublesome when it comes to keeping up with Discord's release cycle

The date shouldnt matter. Just increment the version based on the changes we're making

[analog oyster]

both of these have the v14 milestone
and at least the second one includes plenty of changes that would have to be tested

[solemn oyster]

We also won't require Node.js v18 (geez, that's quite the version number) until it's near LTS or LTS, if it brings something useful

Second one is v15/TS

[analog oyster]

[ruby terrace]

yeah we should probably...migrate that to a v15 milestone now

[solemn oyster]

Yeah, whenever Crawl makes it

[ruby terrace]

I wanted to get that in too, but there's already a lot of big stuff in v14, and its not the ts rewrite

[dawn merlin]

The issue tracker doesn’t show everything, we want to make more internal changes like using /rest within djs

[solemn oyster]

We don't want the v14 update to be as breaking as v13 was, as simple as that

[outer raven]

wait raw data storage isn't coming to v14?

[solemn oyster]

Nope, it's hell to do that change without TypeScript

And there's still stuff to discuss

[outer raven]

oh alright

[ruby terrace]

more...incremental, most of the breaking changes are removals of deprecated v13 things

[solemn oyster]

Because we want raw data storage to be beneficial, not a burden for those who are trying to scale their bots

Yup, we basically want to do major releases more frequently, as opposed to making large major releases every year or so

That way it's a lot easier to update between versions

[outer raven]

just don't pull a dotenv who releases 3 major versions in a weekend

[solemn oyster]

lol no

I think we want to do 2-3 majors a year, depending on how much stuff we want to do during that year

[outer raven]

that's nice

[solemn oyster]

And ofc also depending on what Discord releases

[analog oyster]

with a few patch & minor versions in between

[outer raven]

yeah lol

[real jetty]

rodry4contrib

[copper laurel]

This should also alleviate some of the pressure on people to upgrade major versions if its less likely v13 is going to break while we work on v14, v15 etc

[copper laurel]

Not relevant to this channel, thanks

[ruby terrace]

this is what I'm really looking forward to, we're ahead of the curve on api versions now, so v13 isn't in imminent demise like v12 is

[karmic leaf]

I'm not sure where to post this, and it doesn't feel important enough to go make an issue on the github.

But I feel like it'd be worth while to put a comment in the https://github.com/discordjs/builders readme that says it has been moved into a monorepo of the main repository. Cause right now it looks like it was archived for no reason and archived generally means "not supported anymore"

I'd make a PR but it's archived so 🤷‍♂️

Something like this at the top of the file

## @discordjs/builders has been moved into the main Discord.JS GitHub repo. New link: https://github.com/discordjs/discord.js/tree/main/packages/builders

Especially because the guide still links to the builders repository.

[outer raven]

Yeah the other packages should say the same, not sure if one can commit to archived repos though

[woeful rain]

I recently came across that djs v14 uses discord-api-types which is cool. I was just a bit puzzled by the Subcommand thing, why is it Subcommand and not SubCommand when in UPPER_CASE it is SUB_COMMAND so in PascalCase it should be SubCommand

[dawn merlin]

I think dapi-types has it correct because it’s one word in the docs: https://discord.com/developers/docs/interactions/application-commands#subcommands-and-subcommand-groups

[dim ridge]

Will the event messageCreate disappear after April? Or still accessible?

[woeful rain]

accessible

but if you want to see content, you need have message intent

[dim ridge]

People are lazy.. Starting a / command takes them too long 😅

[woeful rain]

okay, because i saw this

[woeful rain]

Slash commands are really good

[dawn merlin]

Yeah think it’s a mistake in djs

[woeful rain]

Also, why did you choose PascalCase when discord uses UPPER_CASE in their documentation?

[dim ridge]

I mean, a user already has to upload an image (and the bot read out its content). That step often is already too much 😂. < In my case

[dawn merlin]

It’s TS convention to use PascalCase enums

[peak zinc]

why do GuildEmojiRoleManager and GuildMemberRoleManager extend DataManager, when most of the other managers extend CachedManager?

is this a mistake?

[tacit crypt]

It's intentional, since they don't store data but rather point to it

[peak zinc]

interesting

what exactly is the difference?

between datamanager/cachedmanager

don't they both have a cache

[strange igloo]

If you take a look at the source code you can notice the cache getter actually hides a redirection to another collection that's external, rather than an internal cache (which is what CachedManager offers)

https://github.com/discordjs/discord.js/blob/main/packages/discord.js/src/managers/GuildEmojiRoleManager.js

DataManager does indeed not have a cache, and the getter just throws an error if you try to access it
CachedManager does have one and its cache getter points to it

[peak zinc]

ahh ok ty

[peak zinc]

in what situation would this.holds be falsy?? https://github.com/discordjs/discord.js/blob/12ffa069aa8b247e945fef16a543f41c2c391bf1/packages/discord.js/src/managers/CachedManager.js#L44

(i think this is a permalink for what you are referring to? i couldn't find a .d.ts) https://github.com/discordjs/discord-api-types/blob/03b8d3fee032fb77213389019baa2b80377dcfdc/rest/v9/index.ts#L756

[opaque vessel]

Only guild commands can have permissions on them, so there's only one thing it can ever be

[peak zinc]

(source? where???)

[opaque vessel]

If you realise that then the distinction isn't needed

Not our problem? They should read up on the routes they're going to use lol

[peak zinc]

can someone explain to me where this d.ts file comes from

i thought github was the source already

does that show up after installing and building the package?

[opaque vessel]

When it's compiled d.ts are made

[peak zinc]

ahhh ok

[dawn merlin]

Depends it can be hand-written or generated

[tacit crypt]

Route names for the method are usually build from what the route says (guildMembers, guildBans, invite, channelMessages) etc. Annoying? Yes. Consistent? Also yes

[peak zinc]

yea I'm just curious where this particular one comes from, cuz he said "there's a d.ts in the 'source'"

but apparently they meant in the output

[tacit crypt]

ALTHOUGH to be fair, it should've been applicationGuildCommandPermissions

who did this

[dawn merlin]

Yeah in most TS projects it’s generated

[peak zinc]

does anyone happen to know the reasoning behind this check

const entry = this.holds ? new this.holds(this.client, data, ...extras) : data;

wondering if there is any situation where data would actually be returned

[outer raven]

are components fixed in the latest dev release?

[wild flax]

Likely not

[dawn merlin]

They might be since they got replaced with builders but you can test them out

[outer raven]

I'll try then

So components are but interaction.options.getSubcommand() isn't, I guess that will be fixed by the enums PR

[ruby terrace]

That's not true anyways, global commands can have permissions, it is just scoped to a guild

[vernal rose]

https://github.com/discordjs/discord.js/blob/164589c5516a847457444d11098981d557b6778b/packages/discord.js/src/client/Client.js#L477

here isNaN is used and isNaN don't check that is the input is a string or number. Is this intentional?

[visual hornet]

there's a typecheck right before it

[copper garden]

Could change it to use Number.isNaN, which does both

[vernal rose]

yeah

[copper garden]

Or actually no, we need it to return true if it’s not a number type

Number.isNaN only checks for NaN

[visual hornet]

you would still need the type check yeah, Number.isNaN is more specific to NaN
just seems unnecessary to me.

[vernal rose]

Number.isNaN checks for number type as well as NaN or probably Number.isFinite can be used

[copper garden]

I think some of them can take Infinity tho

[visual hornet]

it gives false for strings which can't replace the typecheck, so why bother

[copper garden]

It would also give false for NaN, which is correct

[visual hornet]

meant Number.isNaN

[vernal rose]

yeah just checked it + Number.isFinite also can't be used bcz of the infinity so current implementation is correct

[solemn oyster]

All it does is v !== v, it doesn't check for the type

The global isNaN does Number.isNaN(Number(v)), which parses values to a number

[vernal rose]

yeah got it

[outer raven]

Publish Dev has been failing sometimes recently, could you try rerunning it? https://github.com/discordjs/discord.js/runs/4867272929?check_suite_focus=true

[slate nacelle]

I submitted a PR to address that.

[outer raven]

Thank you!

[outer raven]

Can we get a manual run of publish dev pls

[slate nacelle]

Done

[outer raven]

Thank you!

On the latest dev the component constructors are exported from builders but they don't exist there yet do they?

It seems like there hasn't been a builders release since that was added so that won't work

[icy bronze]

would you guys recommend using enum resolver or importing types or just putting the raw number in code

[dawn merlin]

I recommend using the enum, ie ChannelType.GuildText

djs ships with the dapi-types enums included

[cursive jackal]

Import enum. If you use TypeScript and you needed to use the square bracket notation (Type[0] or Type['TYPE']) use resolver.

[icy bronze]

aight, I'm not familiar with enums so I don't want to start editing hundred lindes of codes and realizing it wasn't the best way

I was more hesitating with importing types and just put raw number like Button.setStyle(1)

but importing is more reliable I guess

[dawn merlin]

yeah you should avoid magic numbers if possible

[icy bronze]

gotcha

[outer raven]

boop Can we get a builders release?

[icy bronze]

damn I was wondering what I was doing wrong

can confirm that builders doesn't exist lol

[outer raven]

builders does exist

[icy bronze]

I mean

yeah

[flint zephyr]

Why is Collection archived?

[outer raven]

because monorepo

[slate nacelle]

^ https://github.com/discordjs/discord.js/tree/main/packages/collection

[flint zephyr]

Oh I see

[peak zinc]

is there some sort of workflow set up for edit-build-test loop for contributors? i.e. i am making some changes and would like to test them with a sample bot while I work, is there an easy way to do this in place?

[dawn merlin]

Usually you'll just do tests manually with your own bot

[peak zinc]

besides running npm pack, moving the tarball to a testing folder, installing from the tarball, every single time i change something

[dawn merlin]

I use npm link for this

creates a symlink between your testing project and the djs code

[peak zinc]

is that reliable? I think I read somewhere that npm pack is the only way to ensure that nothing breaks

b/c some sort of weirdness with the linkage

[dawn merlin]

I mean I've had no problems with npm link, it's worked as expected

[peak zinc]

no problems with path resolution or anything?

[dawn merlin]

nope

[peak zinc]

hmm, okay, thank you

[peak zinc]

npm link is designed to install a development package and see the changes in real time without having to keep re-installing it. (You do need to either re-link or npm rebuild -g to update compiled packages, of course.)
what do you do to update the package after making changes?

[dawn merlin]

wdym, as long as the file is saved the package is updated automatically

it's linked

[analog oyster]

this is the point of using symlinks

[peak zinc]

oh, the npm docs seems to think you need to "re-link" it for some reason

unless I'm misunderstanding it

[dawn merlin]

what they're saying in the docs is if you have code that's compiled/transpiled that needs to be run

[peak zinc]

then you'd have to re-link each time? 😵‍💫

[dawn merlin]

discord.js is javascript without any compilation step so it doesn't need to build

you'll only need to link once and just edit the package like normal

[peak zinc]

ah ok, tyty

[wild flax]

There won't be any releases until 2 upstream issues are solved from git cliff

[outer raven]

oh I've been running into issues with git cliff myself, can you link me those?

[wild flax]

Or rather 1, the second isn't so important

Thats the one we need to wait on:
https://github.com/orhun/git-cliff/issues/48

This one is a nice-to-have:
https://github.com/orhun/git-cliff/issues/47

Both are supposedly possible, so they are most likely just bugs and not working correctly

[outer raven]

Thank you! Will check those out

[analog oyster]

@dawn merlin why would this be nullable? in the class itself it only relies on the message id

[dawn merlin]

because of polymorhism, if a child class can be nullable then the parent class also must be nullable

[analog oyster]

well, do we really have to only rely on the thread_metadata.create_timestamp thing, why cant we just use the ids to get the timestamps on threads too

[dawn merlin]

thats why ts only allows it this way

[dawn merlin]

uhh idk, lemme see

[opaque vessel]

The id of a thread is the message's id, so it's not the creation time

[dawn merlin]

Ah ok

[analog oyster]

ah okay, makes sense why they are sending it then

if that's the case then this is not correct

[dawn merlin]

Yup

[dawn merlin]

Wanna point out it won’t really affect that much anyways bc there’s separate events for thread creation and channel creation and they’re typed properly. So it’ll never be nullable on “channelCreate”

[vernal rose]

why button interaction don't have style property?

https://discord.com/developers/docs/interactions/message-components#button-object-button-structure seems like APIMessageButton have it

[copper laurel]

I dont understand why you think the interaction would have it

[rustic bough]

<:_:874569322742308864> ButtonInteraction#component
The component which was interacted with

[copper laurel]

You can access the button and get style from there if you really need to know for some reason

[vernal rose]

oh ty

[velvet tide]

never got around to ask this, but out of curiosity, what was the reason behind the removal of timeout on Message#delete?

[copper laurel]

The timeout being internal to the method meant it was out of the users control, couldnt be error handled, couldnt be cancelled etc

Using setTimeout yourself is just far more adaptable

[flint zephyr]

I wish to contribute to discord.js, but the codebase is massive. Where do I start digging in?

[copper laurel]

I'd start with the issues I guess, or follow discussions in this channel - you dont just "dig in" and changing/writing stuff

Really depends on what sort of change you intend to make

You can also watch for new Discord API features, but we have such a big community that its almost a race to contribute to that sometimes

[lament shoal]

is there a list of deprecated things that are going to be removed in the next major version so i can prepare early?

[opaque vessel]

Not yet

[outer raven]

a good way to find them is to search for process.emitWarning on the stable branch of the repo

[lament shoal]

oh that's smart

thank you both

[dawn merlin]

@outer raven Is v14 working for you now?

[outer raven]

No because we need a builders release

so haven't been able to test other stuff yet

[dawn merlin]

Oh yeah

[outer raven]

btw why isn't the CI failing because of that?

[solemn oyster]

Because it's using the local builders code, not the npm code

[outer raven]

Wouldn’t it be possible to change that so we know when it’s fixed?

[wild flax]

thats not really desirable lol

[outer raven]

I think it would because then you’d be able to see errors that pop up when using the package externally which should be the point of those tests right

[wild flax]

🤔

that'd make development unnecessary hard

you couldn't change something in /rest or /collection anymore and then test it in discord.js without a release

[vernal rose]

also this is one of the reason why people make monorepo to test all package compatibility with other without installing

[velvet tide]

that makes sense. perfect. thanks for the answer!

[dawn basalt]

Are xDelete events deprecated or not recommended for use? (in v14)

[loud jay]

#7092 in discordjs/discord.js by kyranet merged <t:1641642095:R>
refactor: remove deleted field

[vernal rose]

They aren't deprecated. Deleted property is removed from all the classes read linked issue to know more.

These 2 things aren't related ig

[idle cypress]

Is there a recap on what features and changes are planned for v14?

[copper laurel]

Not yet

[outer raven]

how are breaking changes detected by the changelog generator? Do we need to add something to the commit description?

I only see this in the config file which doesn't tell me much

[ruby terrace]

not sure if this is how it picks it up, but there's a piece about breaking changes in the conventional commit guide https://github.com/discordjs/discord.js/blob/main/.github/COMMIT_CONVENTION.md

[outer raven]

yeah I added that to my commit description but tbh I haven't seen anyone else do that so it probably doesn't matter too much

[wild flax]

You can also add an exclamation mark

Like “feat!: asd”

Or “feat(scope)!: asd”

[outer raven]

oh I'll do that then

[vernal rose]

So all other breaking changes won't be in changelog? Which don't have breaking in description or ! Before subject

[outer raven]

They will be there but not as [breaking]

But that doesn’t matter because there’s always a converting guide

[solemn oyster]

No

We're using ^2.6.1, as you can see in https://github.com/discordjs/discord.js/blob/stable/package.json#L60. Package managers resolve to the latest minor and patch within the v2 range, so they'll resolve that version as 2.6.7

You can see the semver compatibility here: https://jubianchi.github.io/semver-check/#/^2.6.1/2.6.7

[wicked rain]

https://github.com/advisories/GHSA-r683-j2x4-v87g
You may need to update node-fetch to 3.11

[wild flax]

No we don't, read the message above

[slate nacelle]

Cookie header leaked
We don't use cookies

[wicked rain]

well ok

anyway it's always good to do updates

but you tell me that it's not urgent ok 🙃

[wild flax]

You are aware that 3.x is ESM only right?

It wouldn’t even work if we updated

Not for anyone using CJS

[wicked rain]

oh yeah i didnt know

[real jetty]

also iirc node-fetch is releasing security updates for v2 still

[loud jay]

#7324 in discordjs/discord.js by YodaLightsabr closed <t:1642879503:R>
fix: update node-fetch to 2.6.7

[pastel zealot]

nice, came here to ask about the CVE and you guys are on it

[opaque vessel]

There's nothing to do though

[pastel zealot]

I see, just finished reading through that gh issue

[cold snow]

lol same here, glad it's a false positive after all

[rocky latch]

@wild flax My https://github.com/discordjs/discord.js/pull/6782 PR is one of the only PRs without a milestone, was this forgotten or is this intentional?

[outer raven]

Const enums vs regular enums and possible switch

[gusty sorrel]

looks like this is fixed

reinstalled pkgs

shows no vulnerabilities

[wicked rain]

Yeah so do i

[idle cypress]

is there any ETA for V14? I can't wait to run it and start my new djs series....

[dawn merlin]

not anytime soon

[idle cypress]

but arent the prs all ready?

[opaque vessel]

There is a lot more to be done

[dawn merlin]

the PR's aren't a representation of the progress overall

[idle cypress]

How can I look at the progress, and maybe work on contributing?

[outer raven]

look at the open PRs

[real jetty]

look at the current issues on github?

[outer raven]

also you can already use v14 by installing dev versions

[idle cypress]

ok thx, I'll take a look into what I can do

[outer raven]

speaking of which, now that they're somewhat fixed, can we get #djs-at-dev back?

[icy bronze]

I have noticed that uploading emoji to a server has a high ratelimit when it's hit, the issue is that the rest handler is queuing a request that can take up to 15 minutes to be retried, I would like to avoid that and warn my users about the ratelimit instead of just having a request pending (can cause issues with interactions because it expires after 15 mins and the editReply function will fail).
Any way to do that?

[slate nacelle]

Something like that has been implemented already:
https://discord.js.org/#/docs/discord.js/stable/typedef/ClientOptions -> rejectOnRateLimit

[icy bronze]

thank you, exactly what I need

[icy bronze]

function is very powerful

rejectOnRateLimit: (data) => {
    return (
      (data.method === 'POST') &&
      /\/guilds\/\d{16,19}\/emojis/.test(data.path) &&
      (data.timeout > 30_000)
    );
  },```
made something like this 😁

I'm a bit confused by route & path difference tho, if anyone is down explaining

[slate nacelle]

Route is used to group rate limits (strip out non major ids and group all reaction endpoints together).
Path is the actual path being used for HTTP.

[icy bronze]

aight, path is good for my use then

[outer raven]

@solemn oyster I guess this went unnoticed, what's your opinion on this? https://github.com/discordjs/discord.js/pull/7067#pullrequestreview-860259281

[solemn oyster]

We're not doing that for /collection anymore, so I don't see why should we for /builders's Embed

[outer raven]

we're not doing it for collection because it became obsolete, but I was told an equals method wouldn't make sense on builders so that's why I think we should have it on djs

and the use cases for the equals function are perfectly valid and I don't think it should be removed without a reasonable alternative

[dawn merlin]

i'd rather it be on the json the builder produces rather than on the builder class directly

[outer raven]

how would you have a method on an object?

[dawn merlin]

it wouldn't be on an object it would be a pure function

[outer raven]

but would that belong in builders? It feels weird

[dawn merlin]

doesn't have to

[outer raven]

Well then where would it go?

[dawn merlin]

either djs or builders

[outer raven]

I'll make a PR to add it to djs Util then, but I feel like yall should start thinking twice before removing perfectly valid features and actually listening to feedback. v14 so far seems like it's just a bunch of removed features for the sake of it with no replacement for them

[wild flax]

🤔

Maybe you shouldn’t judge a unfinished product

[outer raven]

Im judging what I’ve seen so far. This alternative I’m suggesting could’ve shipped with kyra’s PR but it didn’t because it seemed like it was disregarded. Also #Const enums vs regular enums and possible switch got negative feedback once again and for no reason from what I saw, and that one doesn’t have an alternative other than the one proposed (to my knowledge at least, correct me if I’m wrong)

[golden mortar]

I expected the embed pr to go through either way, so I implemented my own Embed class that works fine with typescript. You can do something similar and include your own utility methods (equals, etc) if it makes a difference

[outer raven]

But the point of a library is to help with those utility methods unless it’s something very very specific to your bot. Of course we can all go and make our own functions but then we should also just not have a library at all

[golden mortar]

I don't care much about stuff getting removed as I don't expect the lib to hold my hand and keep in technical debt so i can use unneeded utility methods that aren't being used elsewhere in the library

although I do agree that MessageEmbed should have remained

[dawn merlin]

I'm honestly still really on-the-fence about const enums

[tacit crypt]

There won't be any more enums or const enums. 🙂

Just objects

Tbh as much as I want to keep them, holy fuck do they cause headaches

[copper laurel]

What would those objects look like? And typings? Would it be similar to how we defined things in the djs Constants.js file, and then with things like keyof typeof TheConstantObject

[analog oyster]

https://github.com/tc39/proposal-record-tuple could potentially be used in the future when/if it becomes a thing

[outer raven]

will that be live before that PR I mentioned is merged so that the methods don't have to be removed?

[outer raven]

the style of the Permissions object is what they'd be aiming for I believe

[tacit crypt]

-types is not tied to d.js at all, for all I know those methods will still vanish, idk

[outer raven]

I know it isn't tied but many types are used by djs and in this case in particular those methods are being removed because of the eventual TS rewrite

so if there's a plan to change that and if that won't be an issue by the time the TS rewrite arrives, I believe we could keep those @dawn merlin?

[tacit crypt]

again

It won't return pascal case strings

[outer raven]

why not though?

what else should it return

I think it would be harder to convert them all back to upper case

[copper laurel]

SaRcAsMcAsE

[outer raven]

hm?

I honestly just wanna understand the issue, because I think people couldn't care less how it's displayed, as long as it is displayed in some way other than magic numbers, so if you tell me what the issue is maybe we can work out other ideas that aren't a pain to maintain?

[copper laurel]

It was a meme I dont think we should use that casing

[outer raven]

it's what the maintainers decided to go with for the enums, not saying I prefer it either, but any other casing option seems to be a pain

although it would be fairly easy to convert with regex

[quiet viper]

Could you give a usecase, where the casing will take place and how it will look like?

[wild flax]

You could easily have your own resolver from those numbers

¯_(ツ)_/¯

[outer raven]

What?

[outer raven]

It involves bit shifting which is not easy to make and even harder to read which is why I’d rather have that in the library

[tacit crypt]

You get a..class..with .has on it

All you'd do is go through each bit and figure out if it's present

[outer raven]

I know but the point of toArray is to display the flags to a user and yes I know we can make that but so can the library

If it has supported this method for ages there is literally no reason to stop now when it can be perfectly avoided

Once again it seems like you’re breaking stuff for the sake of breaking

[wild flax]

Its rather for the sake of not having to keep updating and releasing stuff to get an accurate representation of permissions

If a new perm is added, wed have to add it and release a new version otherwise you won't see it or get it listed

While now, its a bit different

But this point can be argued back and forth

Not to mention renamed permissions

[outer raven]

You will always have to add it to discord-api-types no matter what and will need a new version for it to be usable, I don’t think this would change any of that

And if we transform the permission name with regex you don’t even need to add it to discord.js itself

[wild flax]

Doesn’t change the latter part

We’ve had that like 2 times by now where we had duplicate keys because of renames too

[wild flax]

And now we dip into territory that seems really like some weird solution for the names

I understand wanting readable names to a degree, but your strong input on changes that are not final are just a bit discouraging to keep discussing

I don’t know if I like this better, but it’s better for maintenance for now, that’s why it’s merged

If I update to -dev and use it for a while, I (or other maintainers too) might realize that it would indeed be beneficial or awkward not to have it

And it can always be added later in the dev flow

I can remove whole classes for a while, only to realize they are kinda handy to have and add them back like 3 weeks later

The current state of development does not reflect anything really

In software development there is this awfully annoying pitfall where you keep adding stuff, but never think about how to refactor or move forward from a structure you really dislike keeping.
By completely removing certain features or parts and later reimplementing it, you get around that and bring in some new ideas on how to handle things and freshen / lighten your overhead

So yes, some things are also simply for the sake of breaking stuff. Will it stay broken like this? God knows. V14 is far from finished by now

And while I appreciate getting instant feedback from a community on changes and the development process, it gets a bit far expecting us to always have a 100% foolproof solution and working main/dev branch that people run “production” bots on

[outer raven]

I understand that and there’s still a long way to go, my reaction stems from the responses I’ve been seeing on this channel because for me personally that method is important and I’ve even considered making a small package purely for handling bitfields in djs and converting them to readable strings. I also know the dev versions aren’t supposed to be used on production but I like to make breaking changes to my bot as they come out instead of making all of them at once when v14 officially releases

My main concern here is the lack of plans to reintroduce this as almost every other thing that was removed had an alternative, when this doesn’t yet

[outer raven]

Also about this, I know -types doesn’t follow the same version scheme as djs but if -types makes a breaking change to the name of a value in an enum and djs is exporting that enum, that will inevitably be a breaking change so you’d end up with the exact same problem, right?

[stray halo]

I have a problem installing discordjs/opus on wsl2

is that a bug or it doesn't support wsl2?

[real jetty]

Are you on node 17?

[wild flax]

There is no such thing as "not supporting wsl2"

[outer raven]

Would it be fine to change ThreadChannel#setLocked to set both locked and archived to the provided value? Having a thread with locked set to true and archived to false does nothing and the thread needs to be archived for it to show up as locked in the client. Either that or I think we should add a note to the docs mentioning this somewhat odd behavior

[compact raptor]

Literally an actual Linux kernel

[ruby terrace]

I thought of setLocked as a way to lock threads for when they auto archive, not lock and archive

[outer raven]

you can't do that though

you have to unarchive it and then archive it again

and there's no such thing as locking without archiving

[outer raven]

@ruby terrace so op on this?

[ruby terrace]

You don’t need to ping me to get a response, I’ll respond when I have time.

When I added threads you could lock and it stayed locked when it auto archived.

Test it again, if locked doesn’t apply without archiving at the same time, make a pr

[outer raven]

my bad
Well at the moment you can lock a thread which won't do anything visibly, and will only lock the thread when it is archived or autoarchived. If you have an archived thread you have to unarchive it to then lock it later, so I believe this isn't the behavior you're describing right?

[ruby terrace]

The first part is what I was explaining

[outer raven]

I mean it does get saved in the API but has no effect until the thread is archived, which makes it a bit useless in my eyes

but if that's the intended behavior then I won't touch it

[loud jay]

#7345 in discordjs/discord.js by Raiden-Ei opened <t:1643169109:R>
Can't start bot with CHANNEL partial

[river linden]

Hi all, quick question. Reading the Discord API docs, there is a note that Membership Screening has been removed from the documentation. Does that mean the endpoints for getting/setting the server rules in the membership screening page are also removed? Or are they just undocumented? Main point of my question: does Discord JS have functions to get/set membership screening settings just like it currently has for the welcome screen?

[ruby terrace]

There was a PR in the past (https://github.com/discordjs/discord.js/pull/5144) but we can't implement things we don't have documentation for so we're still waiting on discord

[outer raven]

The upstream pr was merged tho?

[ruby terrace]

re-read that PR