#archive-library-discussion
25085 messages · Page 26 of 26 (latest)
Then it's sent to the API
ill make a pr later
why?
Bc it’s a bug?
oh wait I missed a few messages
v13 should still support string for channel.type
hey @tacit crypt (think its better to talk here? about discord-api-types#502)
even tho the docs says it, i tested myself and it doesn't work, you can test in this url: https://cdn.discordapp.com/banners/277496071897481216/a_114df53592ae20557666470b5e741966.gif?size=
cc @outer raven (you were also in the discussion)
well iirc they don't support resizing gifts
Was that change reverted or did it never land
I know for a fact Discord supports more than just powers of two and ive seen prs to add that on djs
but i still can't get the image with static images 👀
tested with vladdy's banner (only with power of two, of course)
https://github.com/discordjs/discord.js/pull/6844 this is what I was talking about, guess it never landed on discord’s side but was merged on djs
It was asked to be reverted in both linked pull requests, but that never happened
Reverted? When
On both those linked pull requests on what you just linked
Those aren’t linked but alright
https://github.com/discord/discord-api-docs/issues/4031#issuecomment-963456127 apparently discord doesn’t like these
Did anyone ever revert these tho
Oh it wasn’t “reverted” just was never added to rest and thats what djs uses now
Alright guess I was behind on the news then
They "work"/worked, that is true, but they're not recommended
so I will leave it with number type and use the docs to say it only accepts numbers power of two between 16 and 4096, thanks guys :)
Pls make the type specific 
I don't see Vlad changing their stance anywhere
@swift zealot no need to close your pr
Just change the target branch to v13
Lol, my apologies. I've never had to do that before lol
I would have reopened it but I deleted the branch without thinking.
It's been a long day. 😁
iirc you can restore branch in the pr page
same button of delete branch
Did you still want to make the PR?
As long as you didn’t delete the fork you can restore the branch
I opened another one
I wasn't thinking at all to be honest
@vernal rose are you sure your root hoisting also makes it possible to run the commands inside the packages too
without having to run them on the root
or use the workspace focus cli from yarn
I know for sure you can't make the changes to the /website directory
Since we use npm on vercel to install stuff from that folder
because yarn doesn't work there correctly
eslint, prettier are installed inside of the package too so you can run the command from there. For release, yarn workspace or turbo can work from root. If u want I can add the cliff-jumper inside of all the packages again but those eslint plugin and config can be used in root
yeah its mainly the binaries I need
since for releases I execute most stuff inside the packages folders
and not on root
but youll have to fully revert the changes to the website
done btw ci is failing but ig it's not related to my changes
its not
thx
https://github.com/discordjs/discord.js/blob/65d1879/packages/builders/src/messages/formatters.ts#L54 Why do these formatter functions use the generic type C extends string and not directly string as a parameter?
look at the return type.
its so underscore('abc') returns '__abc__' rather than string
it's just a stricter type
got it thanks
is djs ever going to remove support to just do channel.send(string), so you need to do channel.send({ content: string })?
I think it's a very commonly used way of sending a message in a channel and it's the only single helper overload so... possibly not? But idk
For my opnion, it can stay as it is.
I dont see a reason for removing it
same
It won't be removed.
Why did you do this update that needs to specify if it's content or embed??
I also don't understand, could you explain?
that's what discord requires
When creating a message, apps must provide a value for at least one of
content,embeds,sticker_ids, orfiles[n].
I think they're referring to why we don't allow .send(embed) and it was because overloads like this were unintuitive and break easily, particularly when they then had to send another object for message options.
The content string is friendly enough for both users and maintainers to keep
can i ask, why does https://discord.js.org/#/docs/discord.js/main/class/TextChannel?scrollTo=awaitMessages return a Collection? how are you supposed to index a collection of data where you cant know the keys. wouldn't it make more sense to use an array?
the idea is that you collect things you want to process, iteration is a valid construct for that, what would indexing help there?
at the end of the day collections are used whenever we can associate a unique key with an instance in a "collection" of structures
if you want to index it, you can just spread the iterator, or you can iterate to process the elements in order
A
Mapobject iterates its elements in insertion order
in 9/10 cases where people want an array in here they probably don't need one
And a map is easily convertible to an array whereas the opposite isn’t true
It is true, using the Map's constructor, just requires a few more characters
You can’t just slap any array in the map constructor, you have to map it
new Map(arr.map((e) => [e.id, e]));
is there any updates or planned things going on with https://github.com/discordjs/discord.js/pull/7204
There's a new RFC for it, and I'll implement it in its due time
oo, havent heard of that, can you link it please? sorry for taking ur time
or is this it?
https://github.com/discordjs/discord.js/issues/8084
Yes, it is
okay, thanks
Any news on this? And is this something that will be implemented correctly in the discord.js library?
I think it's still in development
There is no reason for it to not be implemented
Moved to tagged post in #992669226403909652