#archive-library-discussion

25217 messages · Page 21 of 26

golden mortar
#

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

lilac tulip
#

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 vkawaiihide

#

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
lilac tulip
#

oh alright so the method he suggested would be cleanerAABongocatFat

outer raven
#

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
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
dawn merlin
solemn oyster
#

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

outer raven
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
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
outer raven
#

yeah lol

real jetty
#

rodry4contrib

copper laurel
copper laurel
ruby terrace
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
dim ridge
#

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

woeful rain
#

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
woeful rain
dawn merlin
woeful rain
#

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

dim ridge
dawn merlin
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
#

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

but apparently they meant in the output

tacit crypt
#

ALTHOUGH to be fair, it should've been applicationGuildCommandPermissions

#

who did this

dawn merlin
peak zinc
# 
const entry = this.holds ? new this.holds(this.client, data, ...extras) : data;
#

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

outer raven
#

are components fixed in the latest dev release?

wild flax
#

Likely not

dawn merlin
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
vernal rose
visual hornet
#

there's a typecheck right before it

copper garden
#

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

vernal rose
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
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
solemn oyster
#

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

vernal rose
#

yeah got it

outer raven
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 prayge

slate nacelle
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
#

djs ships with the dapi-types enums included

cursive jackal
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
icy bronze
#

damn I was wondering what I was doing wrong

#

can confirm that builders doesn't exist lol

outer raven
#

builders does exist kek

icy bronze
#

I mean

#

yeah

flint zephyr
#

Why is Collection archived?

outer raven
#

because monorepo

slate nacelle
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
#

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 blobthumbsup

peak zinc
# dawn merlin I use `npm link` for this

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

#

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
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
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
vernal rose
copper laurel
#

I dont understand why you think the interaction would have it

rustic boughBOT
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
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
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
velvet tide
dawn basalt
#

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

loud jayBOT
vernal rose
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
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

wicked rain
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
loud jayBOT
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
rocky latch
outer raven
#

Const enums vs regular enums and possible switch

gusty sorrel
#

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
idle cypress
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
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
icy bronze
#

thank you, exactly what I need djsGame

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
#

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
# wild flax Maybe you shouldn’t judge a unfinished product

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
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
outer raven
outer raven
tacit crypt
#

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

outer raven
#

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 meguFace

outer raven
#

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
wild flax
#

¯_(ツ)_/¯

outer raven
outer raven
tacit crypt
outer raven
#

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
#

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
#

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
# wild flax And while I appreciate getting instant feedback from a community on changes and ...

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
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
ruby terrace
outer raven
#

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
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 jayBOT
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
outer raven
ruby terrace
#

re-read that PR

outer raven
#

Which part

ruby terrace
#

the upstream one

river linden
#

Thanks all. Shame its a year later and still no update from discord

outer raven
#

Is it intentional that the EnumResolvers class has no jsdoc? It would be nice to have it show up on the docs

solemn oyster
#

Possibly not

#

Everything should ideally have jsdocs

raven vigil
#

Why errors thrown by functions are not documented? i.e. MessageManager.delete(id) throws a DiscordAPIError if no message with that id is found, but how am I supposed to know as it is not mentioned in the documentation for that function?

#

I'm trying to look on the documentation for the official Discord API, but there are no mentions about errors that can occur there

#

So it is just trial and error?

zenith oracle
wild flax
#

Pretty much all promises can reject and you should handle that

#

Which I would categorize as a general understanding when it comes to using JavaScript

raven vigil
#

I am coming from Java, so that was not obvious, thank you

dawn merlin
#

Oh yeah I forgot you have to handle all possible exceptions in java

raven vigil
#

Yes, it is good practice to declare all possible exception in method signature so that the compiler won't let you not handle it

outer raven
#

The functions on DJSError.js all have JSDocs but they're not inside a class so they're not displayed on the docs. Should they be removed?

copper laurel
#

No? Surely if you want to solve something here the better option would be if they are displayed. Even then at the very least having documented source code is better than undocumented

analog oyster
#

the docs could have another section for standalone functions

outer raven
copper laurel
#

I don't know what the best/right solution is but I'm against removing the jsdoc just because it isn't parsed - documented source code is still good

#

Intellisense probably still picks it up

outer raven
#

meh there doesn't seem to be an easy way to document this so I'll leave it be

#

CI has been failing on every commit now, I keep having to force push for it to run again and work, did something break?

spice thicket
#

Why do we manually have to call .toString() on numbers for message embed fields

visual hornet
#

input validation, you can also put it in a template string

spice thicket
#

But I feel like if u passa number it should automatically parce it to a string

dawn merlin
idle cypress
#

Congrats on passing the 6000 commits on main branch

void rivet
slate nacelle
#

Doesn't appear in audit logs, at least didn't the last time I chcked.

#

So I'd say that box is wrong. (Or the behavior changed)

void rivet
#

okay then sure, i'll test again to make sure

slate nacelle
#

do it

opaque vessel
#

I'm pretty sure bots deleting a message doesn't show up in audit logs lol

visual hornet
#

a few other actions are labelled as supporting the reason but don't show it as well iirc

void rivet
#

yeah i couldn't get it on the audit log
thanks

outer raven
wild flax
#

Won't happen

wild flax
#

Doesn’t belong here

#

That’s what’s wrong

velvet egret
#

mb

strange crane
#

When shards are spawning and you try to perform an operation (broadcastEval or fetchClientValues), the manager throws the error SHARDING_IN_PROCESS
In my opinion, the ShardingManager should either perform the eval on the shards that are spawned and ready or we should have an event that emits when all shards are spawned are ready so users can perform the operations without any errors
Just my thoughts 🤷‍♂️

warped crater
#

perform the eval on the shards that are spawned and ready
👎 this is just outright unpredictable behavior - it isn't guaranteed to be the same on every start up

#

an error is the correct behavior even if an event were to be added for this usecase

strange crane
outer raven
dawn merlin
outer raven
# dawn merlin https://kentcdodds.com/blog/inversion-of-control

I see your point. I mean we’ve had full string conversion and now we have no conversion at all. I think a balance between those two could be to support numbers and strings since those are the only two types that can be safely converted to strings. In this case it would just be an if statement since all the others have the possibility of breaking

warped crater
#

not a fan

#

the argument of "cannot have unexpected behavior" doesn't really bring much when the idea is that implicit conversions shouldn't be made period

outer raven
#

No matter what

zenith oracle
outer raven
#

I know it is but there’s a difference between displaying [object Object] and 5

dawn merlin
# outer raven I see your point. I mean we’ve had full string conversion and now we have no con...

So let’s assume this is added, someone comes up and says “hey how come the method accepts numbers but not bigints, I mean if it supports numbers it might as well!” Ok we add support for bigints since numbers are in fact supported. Then someone else comes and says “hey your library accepts numbers bigints and strings, why not accept a Boolean as well, it’s a primitive too!” Ok makes sense we add support for booleans to be passed in. Finally someone comes and says “you support all primitive types in this method except objects, why not just add that in for completeness” we support for it completeness. Now we’ve ended up with a function that’s a black box in terms of input and has to do five different checks for its input. TLDR; You need to stick to an parameter type and keep it.

outer raven
dawn merlin
visual hornet
#

just like no one wants to display true or false without any context, even though those would be stringified cleanly too
field values for yes/no states

outer raven
outer raven
#

If you want yes or no, you pass yes or no

real jetty
#

As someone who doesn't see much of this from internals, this just sounds like the usual "I want djs to friendly guessthings for me" which djs has moved away from in the last year or two

dawn merlin
real jetty
#

the goal for djs has been to give specific things to get specific outs

outer raven
visual hornet
# outer raven That’s not user-friendly

but it's not an [object Object], so an argument could be made that it's useful. not saying it is, but someone could say that with a similar argument to the "number to string is the same thing" argument

outer raven
#

There’s literally no risk with that

outer raven
visual hornet
# 
name: "Is this statement true or false"
value: true | false

yes it's arbitrary, but still, that argument could be made

wild flax
#

What is “clean” even at this point

outer raven
wild flax
#

That makes no sense sorry

#

Again, it won’t happen

wild flax
outer raven
#

because the quotes are removed

dawn merlin
#

But it’s always a string in the embed that’s the point

wild flax
#

It doesn’t change that this would be one of the only places in the lib where we start to transform and coerce user input

#

Just because someone thinks it’s “clean”, whatever that means

#

Please don’t impose some weird concepts that don’t exist

#

Read some actual language concept books

outer raven
#

I'm not imposing anything, it's a simple suggestion being discussed on a discussion channel. After all, isn't that what this is for? I told you what looks clean to me, that's all. It may make no difference for you, and I'm not extremely bothered by it either, just a nice QOL thing, just like string types were. But thanks, you're super nice as usual

wild flax
#

Idk, I don’t care mostly

#

It’s like we say reasons why and all that comes back is “but X and Y and Z”

#

And then we say some more reasons and it’s “but A and B and C” lol

#

No offense but we already answered the “why” I’m unsure why we need to explain further and further and looks like it’s not something that gets accepted as a reason, while we should accept whatever comes in as feedback lol

outer raven
#

to every argument there's a counter-argument, and that's how discussions work. I understand you may not want that for X Y and Z, but some people might and in most of these topics we're just discussing QOL, which has been getting reduced over time in djs but I don't wanna get into that again

wild flax
#

For every QoL change so far we’ve introduced some alternative

#

That is almost as equal

#

Minus the Embeds

#

We even ended up keeping the permission stuff

copper laurel
#

The clean argument is really dumb either way

#

If it makes your code "cleaner" by not having to include .toString(), then it has made discord.js's code "dirtier" because we do have to include toString()

#

Its not like the conversion doesn't still need to happen, the so-called "dirty" code has just moved

#

Which means it isn't actually clean or dirty at all, its a necessary conversion step. And as per the inversion of control principles, that step belongs in your code

outer raven
#

Did the image URL methods change to the rest syntax?

#

so format is now extension

dawn merlin
#

think so

outer raven
#

and now we can't pass camelCase properties to the builder constructors

#

could we make classes extending the builder classes that convert camelCase to snake_case and send it over?

#

along with other stuff that might be needed

dawn merlin
#

you could

wild flax
#

It seems like a really odd pattern to even pass a manually created object to the embed constructor

#

Why get an instance if you already have the object?

dawn merlin
outer raven
wild flax
#

🤔

outer raven
#

since, with the setAuthor and setFooter deprecations, the functions no longer have any advantage when compared to the raw object, so might as well just pass it like that

wild flax
#

At this point why even use a builder

outer raven
wild flax
#

It’s just taking up memory

#

But you don’t use them like you said lol

outer raven
#

I don't use them on declaration

#

I use them later on in the code

#

when actually modifying a value

#

I find that to be cleaner than an assignment

#

and it also allows me to do this (different builder, same issue)

dawn merlin
#

I had this conversation with rodry already 🙃

outer raven
#

yes we did

wild flax
#

Ah, I guess we just need a toSnakeCase function then

#

And we should be fine

outer raven
#

how about the types?

wild flax
#

Generics I guess

outer raven
#

cuz I did try that, but some types were a mess because of unions

#

like the button type is a union of a bunch of other types and you can't simply replace a property

wild flax
#

I mean allowing both will mess up your expectations instead of types

#

What takes priority

#

Snake or camel? And why?

#

Arbitrarily decided?

outer raven
#

just like it was already happening with djs embeds, it's the type that comes first until you add a property exclusive to one of the types

#

then it starts expecting all properties to be either snake or camel cased

wild flax
#

So what exactly wouldn’t work with a toSnakeCase function

outer raven
#

the function works, but button types are a union of link and customId button interfaces, so we have to re-type them all

#

I tried to avoid that with a type generic that replaced props but it didn't quite work due to that

#

at least to me, if anyone knows how to fix that please be my guest

#

but I tried with Omit and it didn't work

copper laurel
#

I dont see why the types need to be changed. If there are utility functions to convert casing, the constructors can stay as they are and you just convert your object to suit the accepted input

#

new Embed(toSnakeCase(rawCamelCaseEmbedObject))

outer raven
#

and either way if djs or builders provides the function, you need the types for that function

copper laurel
#

As in MessageEmbed.toSnakeCase() with types for that output?

#

A standalone utility function would have generic types

solemn oyster
copper laurel
#

Though I do find that amusing wouldn't it be relatively simple to ensure the capital letter is followed by a lowercase one before inserting an underscore?

#

In the case of consecutive capitals, underscore then lowercase until an already lowercase is following

#

Of course that'll probably break some other parsing instead

dawn merlin
copper laurel
#

Sort of?

#

If you target capitals specifically yes, if you target changes in casing its sort of manageable

#

I havent done any technical feasibility of course lol

#

Just a rough unfinished thought

solemn oyster
copper laurel
#

yes

#

fair

solemn oyster
#

We used a package for that, and the type hell it had to strict type the conversions was already enough bad as it was

copper laurel
#

customURLFormat has changes at mU and again at Fo

#

And at those spots specifically, an underscore is required before the capital letter

#

Then toLowerCase the lot

#

I know that phrase isnt in djs I just wanted one where it was in the middle

vernal rose
#

I just found a bug in MessageEmbed#length in djs v13 but it's not present in Embed#length in builder so should i create a pr to fix it in MessageEmbed as people will still use v13 after v14 release?

dawn merlin
vernal rose
# dawn merlin what's the bug?

If use

Embed.setFooter(null)

It sets this.footer={}

So here footer is defined but footer.text isn't so when using MessageEmbed#length it checks

this.footer?.text.length here text is undefined so it'll throw error

#

In builder it sets footer to undefined so it's not throwing err

dawn merlin
#

ok so it's fine now?

vernal rose
dawn merlin
#

Oh I mean we don’t usually take prs to stable releases soo it’ll probably have to stay

copper laurel
#

v14 will be a lot less breaking than previous majors

vernal rose
copper laurel
#

Probably not necessary, people will be able to upgrade easily

#

I don't think there will be much need to maintain a 13.6.1 alongside it, but there's no harm in opening a simple PR like that I guess

vernal rose
vernal rose
outer raven
dawn merlin
outer raven
#

aight that's a 1 character PR

outer raven
#

Shouldn't the first one work? How are we supposed to add intents now?

dawn merlin
outer raven
#

but that should work too, right?

dawn merlin
outer raven
#

could just be removed

dawn merlin
outer raven
#

aight ig

#

then maybe deprecate it?

dawn merlin
#

I'll just mark it as private in the typings

#

or can you just append that to your PR?

outer raven
#

oh yeah sure

#

then maybe it should be marked as private in the docs too?

dawn merlin
#

also I figured out why it doesn't work, I have to use typeof Enum not just Enum

#

go ahead an add that in as well, since it doesn't hurt

outer raven
dawn merlin
outer raven
#

I did

#

ill add typeof for now and keep it public, I dunno how to fix that error

dawn merlin
outer raven
#

right

#

ye that fixes it, thanks

outer raven
wild flax
#

Won’t render

#

Use private

slate nacelle
#

Why make it private?

wild flax
#

Discussion above

slate nacelle
#

I don't see any, just some assumption that I have no idea where it came from.

outer raven
slate nacelle
#

That's the assumption I meant.

#

How are people supposed to know which flags belong to this bitfield now?
Read the source?

outer raven
#

the names are pretty similar but I see your point yeah

#

should I revert?

slate nacelle
#

I don't know, I seem to be the only one with any concerns here.

outer raven
#

that is a valid concern tho, I didn't think of that

outer raven
dawn merlin
#

My reasoning for wanting them private was that BitFields used to serve both the purpose of an enum and a BitField class. Now that we’re using -types it no longer needs to act as an enum. The enum values only need to be used internally now to make sure certain methods work. As for knowing what enums to use, I think it’s relatively intuitive to find the analogous -types enum, and if you’re using typescript the enum types are defined via generics.

outer raven
#

I'm honestly fine with both approaches, although I'm more tempted to make them public again, but I'll go with whatever the maintainers prefer

solemn oyster
#

I'm ok with making them public so they can use it over importing a package they most likely did not install

outer raven
#

they don't have to import from -types, they're re-exported from djs

sweet galleon
#

Does anyone know the release cycle of discord-api-types & discord.js - waiting for a merged bug fix to be released

dawn merlin
sweet galleon
dawn merlin
#

but no schedule

outer raven
#

Why is the ApplicationCommandPermissionsManager#set method called set and not edit? The endpoints it calls are either edit or batch edit so I feel like that would make more sense?

wild flax
#

Is it a PUT

#

because then set is accurate

analog oyster
#

yes it is

wild flax
#

There we go then

outer raven
#

so if we call batch edit and only provide some command ids, do the commands that get left out get their permissions reset?

wild flax
#

Same with commands yes

graceful ravine
#

More of a technical question rather than a discussion, but when is manager cache actually used internally? Every event sends along all the user data necessary to construct a djs structure (right?) and from what I've seen in the codebase I think it just overwrites the cache when that happens. (Might be wrong there). So when is it being used, apart from explicitly getting a value from a manager?

real jetty
#

Oh yeah also guilds, discord doesn’t send that again after startup (obviously except for guildCreate)

graceful ravine
# real jetty > Every event sends along all the user data necessary to construct a djs structu...

Yeah forgot about partials, however I'm not currently listening to any events that send partials, in that case cache would be minimally used right? (apart from guilds like you said) Asking mostly because we currently have a sponsored vps with minimal memory, so as long as most of the events send along the necessary data to create a djs structure we can make a relatively small limited cache.

solemn oyster
#

That's a dangerous proposal, Darkerink

wild flax
#

If I can forward the death threats to you

#

¯_(ツ)_/¯

copper laurel
#

The cache is used way more often than you might think

copper laurel
#

Manager#fetch will check cache first

void rivet
#

i'm super late to this but okay what about this now? the issue was that the library sets default values which are already api default values

wild flax
#

Yeah sure

void rivet
#

well i haven't kept up with any of the changes
i'll go look for some now

limit_defaulted_to_max
https://discord.js.org/#/docs/discord.js/main/typedef/FetchReactionUsersOptions's limit

redundant_default_values

https://discord.js.org/#/docs/discord.js/main/class/GuildManager?scrollTo=fetch's limit
https://discord.js.org/#/docs/discord.js/main/typedef/GuildListMembersOptions's limit
https://discord.js.org/#/docs/discord.js/main/typedef/GuildSearchMembersOptions's limit
https://discord.js.org/#/docs/discord.js/main/typedef/GuildPruneMembersOptions's days and count

https://discord.com/developers/docs/resources/channel#create-channel-invite
https://discord.js.org/#/docs/discord.js/main/typedef/CreateInviteOptions's maxAge maxUses unique and temporary
https://discord.js.org/#/docs/discord.js/main/typedef/ChannelLogsQueryOptions's limit
https://discord.js.org/#/docs/discord.js/main/typedef/ReplyOptions's failIfNotExists

vast fiber
#

I've had a message that's edited every 10 seconds to update an embed in it for a couple years now I think, and recently the embed started to not update after a while, even though the message itself gets "edited". any insight on this?

analog oyster
wild flax
#

It might be 3/15 I think

#

So 3 edits every 15 seconds max

void rivet
wild flax
#

Feel free to open a PR

#

Someone will likely chime in if there’s more and tell you

void rivet
#

also curious as to why MessageManager.fetch fetches 50 messages and not 100 like some other methods like <Client>.guilds.fetch() and <MessageReaction>.users.fetch()
I was under the impression they'd fetch all they could by default

opaque vessel
#

If you don't supply a message limit, the API defaults to 50 for messages

void rivet
opaque vessel
#

I am aware
Then... that's why

#

I don't think we should be setting default values if the API has a default value though

#

Imo if we set default values when the API has defaults already, we should remove them and leave that to the API

#

I don't think we should get the max just cause

void rivet
opaque vessel
#

Yea they should all change

#

All of them should go poof

void rivet
#

that is the plan
but just to confirm what you're saying, even the methods like <MessageReaction>.users.fetch() shouldn't by default fetch with the limit set to max?

opaque vessel
#

Yea, I would say leave that to Discord

#

If a user wants max, they can specify it, it's no big deal

void rivet
#

trying to find more default values i came across something elsejs const newData = await this.client.rest.patch(Routes.channel(this.id), { body: { ... lock_permissions: data.lockPermissions, rate_limit_per_user: data.rateLimitPerUser, default_auto_archive_duration: data.defaultAutoArchiveDuration, permission_overwrites, }, how come https://discord.com/developers/docs/resources/channel#modify-channel-json-params-guild-channel doesn't mention a lock_permissions field?
has it been removed?

opaque vessel
#

Not looked into it but changing a channel's position has a lock_permissions JSON parameter to sync with the new parent. Maybe it works but just isn't documented?

void rivet
# void rivet well i haven't kept up with any of the changes i'll go look for some now limi...

these are all i could find, surprisingly, the only method where the limit by default was fetching the max (and wasn't already the api default) was the one listed, some existing methods like <Guild>.fetchAuditLogs never set a default value
https://discord.js.org/#/docs/discord.js/main/class/GuildManager?scrollTo=fetch some of the methods just lists the api default on the documentation even though it's not hardcoded

foggy blaze
#

Hey, can anyone fill me up with the future of bot prefixs? I have a bot that only runs on my server, should I be worried and rewrite my bot in order to support slash commands? Or is this something that noone knows until time comes (april)?

real jetty
foggy blaze
copper laurel
#

Slash Commands are generally better anyway, and you should probably be rewriting to make benefit of the ongoing new features that will be released for them

ornate topaz
#

Cc @opaque vessel

foggy blaze
copper laurel
#

The command being correct?

#

Sure typing messages might be slightly quicker for power users, but having an integrated UI, tab completion of options, choices, autocomplete suggestions, user/channel/role resolution handled by Discord

#

All far more powerful

foggy blaze
#

Yeah i agree, any idea if slash command scale and run faster than bot prefixes? Or is it the same.

copper laurel
#

I wouldnt expect there to be any difference though newer versions of discord.js have becoming increasingly lighter in terms of memory footprint and performance

foggy blaze
#

Alright, ill take that into consideration. Cheers for the info!

opaque vessel
ornate topaz
#

well, then description for it seems to be incorrect?

#

since it implies similar behavior to passing no parameters to other fetch() methods, that do end up fetching everything, more so as the options are optional

opaque vessel
#

Oh yeah, that's incorrect

raven juniper
#

I could have sworn I made a PR that clarified that

analog oyster
outer raven
#

yeah I think it's safe to assume that 0 is no flags, that doesn't need to be in -types

tacit crypt
#

...Thats an interesting find

#

And yeah makes no sense for it to be in the enum

#

although it doesn't hurt to have

analog oyster
#

it does hurt because otherwise that will have to be accounted for in discord.js

outer raven
#

yeah bc it gets put in the permissions array

#

I can PR

#

oh I guess not

alpine bough
#

or it has nothing to do? lol

slate nacelle
#

I think our intention is to not document api defaults (although I think that slipped in on some occurences), but our own defaults.

alpine bough
#

alright, thanks :)

outer raven
#

uhm @wild flax i was about to push something to that PR that jiralite mentioned

#

oops

wild flax
#

if you still want changes, make sure to put it in draft mode then

#

and they were most likely unrelated anyway

outer raven
#

sorry it was a small thing, I was gonna get it done when I got home

#

they weren't actually

vernal rose
#

what about adding them in optionalDependencies in package.json?

atleast butterutil and utf-8-validate as they don't need visual studio installed

copper laurel
#

That still gets installed automatically I believe

wild flax
#

It does

outer raven
#

why do errors look like this now?

opaque vessel
#

Source maps or something

analog oyster
outer raven
#

I didn't change my code tho, so something changed on the lib

analog oyster
#

yes, /rest is being minified

outer raven
#

why tho

#

why can't we have DiscordAPIError anymore lol

analog oyster
outer raven
#

Can we remove that?

#

turning minify off does fix it

#

minify saves a total of 15kb, from 34kb with minify off to 19kb with minify on. I mean it is a reduction but if these errors are supposed to be shown I think we should have better names and 15kb never made a difference anyway

#

managed to get the same size while keeping the names, the only thing that keeps weird names is the error stack, is this preferred or can I PR with a slightly bigger file size that keeps all function and class names

rough roost
#

It makes no sense for djs to care about size, it should be turned off completely

outer raven
#

I mean there must be a reason why they added minify

zenith oracle
#

Tsup supports a preserveNames options, which is also used in /collection

#

Maybe it should be used here too?

outer raven
#

I don't think that's enough

#

because if we wanna trace back an error, the source code is an absolute pain to look at

analog oyster
#

i dont understand why theres a sudden urge to minify stuff 🤔

zenith oracle
analog oyster
#

at C.runRequest
is the problem, i guess

ruby terrace
#

Tbh, if you want to look at the source code for that, you probably should already be familiar with the lib and know exactly where those functions are. Unless you are In the unlikely scenario it’s a lib issue, that part of the stack trace is practically irrelevant.

outer raven
ruby terrace
#

Not in every library, for /rest it does though, there aren’t that many functions. I can read that error just fine

tacit crypt
ruby terrace
#

Fwiw I don’t care about minification, I think some people will though

tacit crypt
#

also i'm 90% sure the sourcemaps fix the errors in your console so you can go on github and see it

ruby terrace
#

Yeah that’s kinda the point of sourcemaps

wild flax
#

Just enable source maps in node

#

js errors will always be a pain to look at when the code base is in ts

#

It won’t really match up either way

#

But if you use source maps the problem is easily solved

outer raven
dawn merlin
outer raven
outer raven
#

otherwise that error wouldn't be pointing to a ts file

dawn merlin
#

all I can say is that it should work, otherwise everyone creating ts libraries wouldn't be able to see the source when they debug

outer raven
#

when I click the linked file and line yes it does, but it still says C.runRequest 🤔

solemn oyster
#

node --enable-source-maps . or similarly set the NODE_OPTIONS env to --enable-source-maps

outer raven
#

do I have to include that in the start command every time I start my bot

#

ill try the env

solemn oyster
#

If you use Docker, you can also add ENV NODE_OPTIONS="--enable-source-maps" before your CMD and you're all set, although I'd argue this solution is less useful for most

outer raven
#

alright thanks! Does that mean I don't need source-map-support?

solemn oyster
#

That's right ^^

#

I have been using that flag myself for almost as long as it's been out (of experimental) in v15, works pretty well

outer raven
#

alright, thank you

solemn oyster
#

@outer raven people are whining about the performance impact of validation, if we add extra properties, it'd cause an even bigger performance impact.

Also, we'd need to hide that property somehow because it'd get serialised if it's left enumerable

outer raven
#

1 single property is less performant?

#

didnt know that then sorry

#

the name unsafe sounds scary tho lol

solemn oyster
#

It's meant to be scary

dawn merlin
#

I'm open to names that are synonyms to unsafe

solemn oyster
#

Rust uses unsafe to give you raw power and performance, while it also discourages developers from using it

copper laurel
#

If you want it less scary but accurate you could use Unvalidated

#

But I think unsafe is fine

golden mortar
#

or it could have the normal naming and validated components could be prefixed with safe

#

either way good job siris 😄

copper laurel
#

That would encourage people to use the unsafe ones by default, probably not what's intended

golden mortar
#

that's what i'm suggesting more or less

copper laurel
#

While I personally would probably use the unsafe ones (or not builders at all tbh) they're intentionally presented as validation being normal, unsafe being the alternative. I don't believe anyone wants to flip that

woeful rain
#

Is there any possibility for the PR https://github.com/discordjs/discord.js/pull/7200 to be merged into discord.js stable, so still up to v13 version? A lot of people would surely appreciate it, since it's coming out any minute now and some people don't want to wait a year for news (djs major version comes out mostly every year) and don't want to use the unstable dev version either.

vernal rose
vernal rose
#

If I use inGuild() in a partial message it makes it Message<true> but acc to src it doesn't checks for cached message it just checks for in guildId. So ig this typeguerd is wrong. Is it's intentional or a mistake?

ornate topaz
#

Yeah, because the name if it is misleading

#

It's called "cached" but it is more of a "inGuild"

icy bronze
#

Hey, would be nice to have a djs-rest channel for futur help and suggestions

#

I was wondering if it would be possible to add a "default format" option for the CDN, I don't like the webp one and having the format option in every cdn function of my code is meh. (I know format was renamed but I forgot the new name)

wild flax
#

Not a huge fan of global settings

icy bronze
#

well it could be added to the rest options ?

neon flower
#

While debug turned on my bot stopped sending heartbeats after 15 - 20 mins and went offline while the process is still online. Anyone know what can be a reason for that

wild flax
#

Doesn’t change my view

icy bronze
#

Ill do it on my fork then but im having issues compiling the rest package, can I share it here to get some help?

wild flax
#

Unsure in what issues youd run

#

but feel free

icy bronze
#

will do when I get home ty

scenic meadow
#

is it possible to keep the packages updated whenever i start the bot?
like for example something like in package.json

"dependencies": {
  "packageName": "latest"
}
analog oyster
#

read the channel topic

quiet viper
icy bronze
#

here is my issue, seems like it get the tsup config right but the tsconfig isn't being read in the correct folder

scenic meadow
quiet viper
wild flax
#

When installing or something?

#

Guess youll have to also change this command here

#

And supply -p with the correct location of the tsconfig

icy bronze
wild flax
#

then youll have to do what I said

#

otherwise this wont work

icy bronze
#

aight lemme try

icy bronze
#

i'm having difficulties using the -p flag, it always return an error with Cannot read file '/home/koyamie/koya.gg/binteractions/node_modules/tsconfig.json'.

#

i've even tried to specify the full path from root

wild flax
#

How do you use it

icy bronze
#

I'm installing the package and with my postinstall script I do npm run build (which I changed to "build": "tsup && tsc --emitDeclarationOnly --incremental --project tsconfig.json",)

#

but the project option doesn't work, I have tested changing path or providing the full path it always return this path: node_modules/tsconfig.json

analog oyster
#

because /rests tsconfig.json uses the root tsconfig.json in the monorepo

icy bronze
#

oh

#

make sense

#

damn yeah the extends props

#

thank you, sorry for the mess that was my issue

dawn merlin
#

So like my myprofile = applyOptions(rest.cdn.profile)

#

The you can reuse that function anywhere

wild flax
#

^

#

But

#

They prolly want djs to return it

icy bronze
#

I'm not sure to understand sorry

outer raven
#

So with the recent switch to /builders, embeds and components no longer get transformed from snake_case to camelCase when receiving them through the API and this is the only place in the library where this seems to happen. Can we make a class on discord.js that extends /builders and implements that? I'd be willing to open a PR for this with the types as well

void rivet
#

on builders
<Embed>.setFields
takes a rest parameter

    /**
     * Sets the embed's fields (max 25).
     * @param fields The fields to set
     */
    public setFields(...fields: APIEmbedField[]) {
        this.spliceFields(0, this.fields.length, ...fields);
        return this;
    }

while for some reason <ActionRow>.setComponents takes an array

    /**
     * Sets the components in this action row
     * @param components The components to set this row to
     */
    public setComponents(components: T[]) {
        Reflect.set(this, 'components', [...components]);
        return this;
    }
``` shouldn't these be consistent?
outer raven
#

should be yeah

void rivet
#

setChoices is a weird one

public setChoices<Input extends [name: string, value: T][]>(
        choices: Input,
    ): Input extends []
``` it takes an array of arrays
instead of objects like setFields
outer raven
#

yeah that should probably be an object too

void rivet
#

okay but a rest parameter too, right?
we're trying to make these methods all have arrays or rest parameters?

outer raven
#

I think so yeah

#

you probably dont need the type generic either

void rivet
#

so what, just make a new type for this?
i don't know if APIApplicationCommandOptionChoice can be used since APIApplicationCommandOptionChoice["value"] is typed as string | number

outer raven
#

that is fine since it can be a string or number

void rivet
#

these methods are called on string/integer/number options specifically

outer raven
#

yeah which is why value can be a string or a number

void rivet
#

the point i was making was that why would SlashCommandStringOption.setChoices take a number as it's value?
other methods like addChoice lets you use the type based on what type of option it is
it uses the generic

outer raven
#

then follow that ig

void rivet
#

okay so..
make a pr which changes all these methods to now take rest parameters and make setChoices take objects to be consistent with setFields, sounds good?

outer raven
void rivet
#

okay then, i'll make that shortly 🤠

outer raven
real jetty
rocky latch
void rivet
#

okay i am done
i have tested it and they seem fine, before i push, what do i name this object? i'm calling it ChoiceData for now

outer raven
dawn merlin
outer raven
#

😕

#

was this related to the recent turbo update?

solemn oyster
#

The latest turbo update works fine to me on Windows 11, have you tried reinstalling node_modules?

outer raven
#

yeah did that and it seems to work now, weird

void rivet
#

@outer raven did you want me to actually get rid of the generic or will it stay?

outer raven
#

I found it to be redundant but if it solves an edge case in TS it can stay

void rivet
#

okay then

dawn merlin
# void rivet okay then

you actually can remove the generic, we found out recently that the cases where setChoices couldn't be used are still show up in TS regardless of input

#

just have it return this as well

void rivet
#

wait what cases?

#

ahhh

# 
    public setAutocomplete<U extends boolean>(
        autocomplete: U,
    ): U extends true
        ? Omit<this, 'addChoice' | 'addChoices'>
        : this & Pick<ApplicationCommandOptionWithChoicesAndAutocompleteMixin<T>, 'addChoice' | 'addChoices'> {
``` that's because `setChoices` was never used on Omit
dawn merlin
#

no, like for example your current code won't allow setAutocomplete after setChoices, but if you do something like setName after setChoices, it still allows setAutocomplete

void rivet
#

oh yeah that makes sense

dawn merlin
#

probably gonna PR those conditional types out since they aren't reliable anyways

void rivet
#

so it's a separate pr or do i do it here?

dawn merlin
#

you can do that one method if you want

void rivet
#

hmm, then i think it'd be better if it were a separate pr where both are removed at once

dawn merlin
#

ok

void rivet
#

thanks again both of you 🙂

#

also this is unrelated to this particular pr but i had a few questions

about the setEmoji methods, following up on this conversation now only taking an object instead of an EmojiResolvable, is that intended behavior?

should the documentation for the methods list the API defaults as it's own default value?
like https://discord.js.org/#/docs/discord.js/stable/typedef/FetchGuildsOptions this lists limit's default as 200, in the code it doesn't set a default value, it's actually the api default that's mentioned here

and aren't the builder methods like addFields, addComponents dropping support for arrays to be passed and are only supporting rest parameters to be passed?

woeful rain
#

Discord.js v15 will already be in TypeScript?

unique axle
#

we do not give version numbers to milestones that are on the roadmap

copper laurel
#

I'm not sure why this is necessary

#

Just for property consistency?

copper laurel
outer raven
# copper laurel Can you clarify the benefit of this?

Consistency with property names (everything in djs is camelCased except for stuff imported from builders)
Ability to use types and utility function from djs in these classes (e.g. Util.resolveColor)
Ability to pass an object to the constructor of these classes with its properties in camelCase, just like we could in v13

This would all be easier if we just didn’t use builders at all, but since that change was made we’re gonna need dirty fixes for these issues

copper laurel
#

I tend to agree, I personally think the way builders have replaced discord.js components is a mess. Property consistency would be nice, I'm assuming the child class constructor would just convert the incoming object to snake_case and pass to super()?

#

The color thing, couldnt care less either way tbh. Hex literal numbers exist

dawn merlin
#

I thought we were sticking to snake case json payloads, I closed my pr bc it was suggested that decamelization would be handled by the user

#

It would also allow us to use -types directly

copper laurel
dawn merlin
#

Anywhere snake case is accepted

copper laurel
#

But it isnt camel case in those situations

#

Where is the camelCase object coming from - are we suggesting the user is going to write it in the wrong case just to pass it through a decamelize function for the constructor?

#

Theres no reason to do that

#

Rodry is making the opposite point, and I agree with him, that builders are completely inconsistent with the rest of discord.js because there is never any camelCase involved

woeful rain
copper laurel
#

Dont know, minify wasn't my decision nor was I involved in any discussion around it, and I also think its dumb

outer raven
outer raven
copper laurel
#

So... make it a constant hex literal?

#

Unless I'm missing something here

outer raven
#

Well I personally don’t know what hex blurple is and it changed recently so having just “BLURPLE” in the code is much more helpful as we can be sure we’re sticking to Discord’s branding

ornate topaz
#

youy can't get closer to source than this

outer raven
copper laurel
#

I disagree that embeds should accept strings to address that, but I'd agree with keeping the colors constant or enum, whatever that was

outer raven
ornate topaz
#

i'd rather open it once and make myself a constants file

#

and reuse it

copper laurel
#

See this is the problem, /builders were originally designed to be for the /rest package. Having camelCase properties in /builders would have made absolutely no sense since in that ecosystem its a waste of time converting them

ornate topaz
#

making 0 difference in usage apart from where it comes from

outer raven
copper laurel
#

But now they're in discord.js too, where their casing doesnt align

dawn merlin
outer raven
#

Every other method in djs does camelCase to snake_case convertion, why is that a problem in builders?

dawn merlin
copper laurel
#

Or at least this is the reason it originally made no sense for them to be doing that conversion

outer raven
#

Well yeah but now that they’re in djs, it should follow the same rules

#

Originally it was fine because it was even mentioned that builders should not be used with djs

outer raven
dawn merlin
wild flax
#

@copper laurel this is about a quite nice use case anyway

outer raven
#

Every property you pass is in camelCase, every property in a structure is in camelCase

wild flax
#

It’s about supplying a camelcase object in the constructor of a builder, to then use the methods on it

#

Instead of constructing it solely via an object, or use the builder methods solely

copper laurel
#

Why would you write that object in camelCase knowing that the constructor doesn't accept camelCase

dawn merlin
#

but we're not supporting camelCase payload either right?

wild flax
#

*nice = niche

outer raven
copper laurel
#

I agree that's a niche, but also agree that the design of builders is inconsistent with the rest of discord.js

outer raven
copper laurel
#

I think the monorepo and cross-package dependencies is overall a far worse experience for the user

outer raven
#

Yeah that’s for sure

wild flax
#

Not sure how the mono repo is related to that now

copper laurel
#

I think the docs link issue has been resolved

wild flax
#

I mean yes, it wasn’t meant to be a permanent issue

copper laurel
#

Installing individual dependencies from GitHub is still difficult. Is there a plan to have an @amber obsidian release for every package?

#

ahh damnit sorry

#

@dev

wild flax
#

Unlikely, maybe

outer raven
wild flax
#

Our package is pretty unique in people even wanting to install via GitHub

#

Like you never see that anywhere else really lol

outer raven
#

That’s only true when there aren’t prereleases

ornate topaz
#

also kinda sad that there was no mention at all about stuff moving to monorepo on separate repos

outer raven
copper laurel
#

:thonk: curious actually, does npm link work if you run it from the correct package subdirectory?

#

Thinking of forks

wild flax
#

Lol

outer raven
ornate topaz
#

seems weird to also not mention the fact that it's a monorepo in the monorepo readme as well, but i suppose there is only a single dir that isn't dotdir now, so eh

outer raven
# wild flax No, not really

If people care about the development of a package they will. Heck some people even install node from their master branch and it appears on their release cycle graph

wild flax
#

No, really not. It rarely happens

#

You can die on that hill if you want, but 99% of TS written packages out there simply don’t support that use case at all

#

Neither do they dev releases or pre-releases

outer raven
#

TS itself does dev releases

wild flax
#

What has that to do with libraries

#

tsc is a compiler

dawn merlin
wild flax
#

You can clone it, build it yourself, and run the binary

#

We aren’t a binary

outer raven
outer raven
wild flax
#

No

outer raven
#

There’s been prs on djs to fix bugs from ts pre-releases

wild flax
#

It’s a cli tool

#

It’s not a library

#

Need a rust tool to run on a dev version? Clone it, build it, run it

#

You can’t easily do that with libraries, that’s just a fact

#

Sure you could do the same approach and npm link it, but then you might as well just do that

#

It has nothing to do with dev or pre-releases

dawn merlin
#

even if ts wasn't a cli tool, they do specific manual beta releases, something we've never done

#

like it's feature complete, it just is getting tested by the community

outer raven
outer raven
dawn merlin
#

? anything could be done, that's not much of a point

outer raven
#

We’ve kinda drifted away from the main point which was the /builders integration with djs and how that’s caused a hot mess of issues and inconsistencies

wild flax
#

🤨

outer raven
#

Do you realize how complicated that is when we could just install stuff directly before?

wild flax
#

And you realize that we already do things that others wouldn’t even attempt to?

#

And just because our setup isn’t 100% ready yet, it’s like everyone acts like it is lol

#

I’m the only one that does organizational stuff here, esp repo setups and all

#

And I don’t care about v14 to be stable, so yes CI doesn’t “throw” errors, because it doesn’t need to

#

The packages “in development” work with each other.

#

v14 being the only one with constant dev releases, not working with not released changes of the other packages is a given here

outer raven
#

A good way to have people not complain about a product in development would be to have a public roadmap of features that you want to add to v14 before releasing, instead of just discussing that internally. People also wanna help so having that would help them pick a feature to work on and PR, and you could direct them to that list if they complain about something that is there

wild flax
#

The main complaint here is purely organizational + builders discrepancy

#

And no one can really help with dev releases because of npm access restricted to maintainers

tacit crypt
#

I swear there's so many topics going on, please thread them because I see concerns about the whole camelCase vs snake_case and now @dev releases and something else about them

outer raven
outer raven
wild flax
#

How’s that help if it can’t even be properly tested and would potentially need a lot of follow up prs instead of just someone doing it that has actual control over it to actually fix it

tacit crypt
#

I didn't say you do it, but if that topic is planned to be discussed further pls thread it 🙏

outer raven
#

Builders discrepancies with DJS

outer raven
wild flax
#

Yeah and that’s nonsense

#

There’s things that I don’t want to teach people and them doing it wrong or me having to correct them over and over, or worse them not responding for days

#

I might as well do it myself

outer raven
#

You have push access to every PR too

#

Most at least, I doubt anyone disables that

tacit crypt
#

That's.. irrelevant? By that point Crawl can just do it himself without needing a middleman for it

outer raven
#

I’ve never seen someone call a roadmap “nonsense”, that’s def one I wasn’t expecting lol

wild flax
#

I wasn’t responding to a roadmap at all

tacit crypt
#

Crawl never called the roadmap ^

outer raven
wild flax
#

But letting others do prs that are of organizational nature, or generally PRing things we rather handle ourselves

#

The first interaction PR set us back MONTHS

#

For having support for them

#

I’d rather not run into this again

outer raven
#

I’m not saying the community should be doing prs like the monorepo one, but minor features are harmless

outer raven
#

It was a bad experience, sure, but those are the quirks of open source

#

Most of the time people making PRs in djs know what they’re doing

solemn oyster
#

You're missing the experience factor, besides, I think I said this already, but we communicate a lot in internal channels, and those who aren't part of the proficient+ team just don't have access to those, so there isn't much of a coordination either

wild flax
wild flax
#

Sorry but

#

I’m not sure if you make it sound like you know better or… undermine however we are involved in OSS

outer raven
outer raven
solemn oyster
outer raven
solemn oyster
#

Then check issues

#

I don't know why are you looking for stuff to do while checking stuff that's basically done

#

I have a few issues open that have a lot of thumbs up but so far almost no feedback in them, even though they improve performance and memory usage *drastically*

outer raven
#

some of your issues have already been set back to v15

solemn oyster
#

You can still provide design ideas

outer raven
#

there was never an issue about converting everything to discord-api-types enums

outer raven
quiet viper
outer raven
#

New features should also not get merged until they’re done properly

wild flax
#

Says who

outer raven
#

Common sense idk

copper laurel
#

It's not like things get merged intentionally unfinished

wild flax
#

New features shouldn’t get released until done properly

#

They can get merged whenever

#

But then again, discord releases unfinished and not thought out stuff all the time