#djs-in-dev-version

1 messages · Page 6 of 1

uncut kelp
knotty plover
#

It's going to be supported by discord.js

When it's stable

#

Or we're otherwise satisfied with its stability

cerulean charm
#

I just have a question that's kinda overall a general one and discord.js mixed. So idk much about "Polls" yet but will bots be able to use/create them with discord.js? Or are they still being planned on how they will work before they become added to the library.

keen bobcat
#

There's a PR for poll support

cerulean charm
#

Personally, i'm not so great at understanding what people do in those requests so i ask here.

keen bobcat
#

That's the one

cerulean charm
#

Mark when it says "All checks have passed" does that mean discord.js devs are making it or..?

keen bobcat
#

That means it complies with the lint check, etc that everything has to be in line with

cerulean charm
#

But i'm confused i thought discord.js dev's didn't add features that aren't on discord's dev docs

knotty plover
#

Polls are still in beta - although the API exists, the API docs aren't merged yet and I don't think bots can actually send them yet

#

The PR isn't merged for a reason

keen bobcat
#

ignore that souji got it to send one

#

It'll be officially supported when merged, whenever discord puts it into a stable state

cerulean charm
#

Okay, Sorry this stuff just confuses me lol. I'll wait and see what happends. I was wondering how discord.js devs even know what to do when it's not posted on the discord developer docs even.

knotty plover
#

It's kinda the same - that PR links to the PR to add documentation

#

So based on that proposed Discord documentation change to document polls, is a proposed discord.js change to support polls.

cerulean charm
#

Just a question monbrey I've seen in some PR's that people share code snippets is that when people that participate in discord.js and edit code or add it and show examples of what like it does and then i see "vladdy" in there a lot saying if it needs fixed or not too continue. So people can just add code and have it checked to see if it can move on?

knotty plover
#

Uhh, not sure I'm following entirely, but in a PR other people can leave a particular comment type to "Suggest changes". This can be corrections or just different opinions. The person who made the PR can choose to accept the change

cerulean charm
scarlet spear
#

any reason why there's been not even any minor updates in like 5 months? even to the core barebones packages like rest ws for 3 month old changes like skus etc

#

am i better off just using github versions instead of npm

quiet rover
#

whatever are in repo's github releases page are the same as npm versions iirc.

steel haven
scarlet spear
#

rest has a pr merged for an issue i opened like 4 months ago as well but that's idle too

#

on the other hand there hasn't been THAT many changes in the past 5 months so a super minor update like that is kinda pointless but like

#

they have to be released eventually right? is there something they're waiting for?

scarlet spear
steel haven
#

And all packages will be released when they’re ready™️, we don’t give estimates

scarlet spear
#

oh sorry that's my bad on discord-api-types part

#

not really asking for a time estimate but more wondering if a specific pr is being waited on for djs packages or anything along those lines

#

or they just don't feel it's ready™️ mmLol

steel haven
#

You can look at milestones on GitHub to answer that

scarlet spear
#

seems all packages have completed milestones except djs14

#

it seems like they don't like making releases for one package, they always release them all together as one batch release, so rest core ws releases end up sorta relying on djs14 releases

#

obviously i'm not like pestering for releases i'm just curious and asking questions

#

i think for now i'll just use the dev versions

silent hedge
#

the gist of it is just that we dont talk abt this stuff that much

#

like sometimes a feature is nice and everyone will want in on it so its implemented and released immediately

#

other times someone is like "hey we have x y and z in dev for a while now, maybe its a good time for a release"

scarlet spear
silent hedge
#

like, internally

rigid haven
#

might be better to just release on like a monthly basis, and if there's no bigger changes then just do a patch releae

errant idol
boreal knot
#

FWIW, if you're waiting on something that we've already merged the PR for but didn't release yet, you can always use discord.js@dev (and similar for the rest of the packages).

steel haven
#

discord.js@dev

knotty plover
midnight plume
#

User Installations are not yet present on the dev ?

knotty plover
#

Correct

#

User installations are mostly just part of the deployment though, which we recommend doing with /rest so you're free to set the properties

midnight plume
#

nevermind i found a way to manually do it XD

#

thank's postman for existing XDD

image.png
knotty plover
#

I mean... thats basically also what I said to do

#

@discordjs/rest just sends whatever you tell it to Discord API routes

#

But Postman works too

midnight plume
cerulean charm
#

Using yarn how can i install the dev version of? @discordjs/util

cinder wraith
#

probably like with any other manager, by appending @ followed by version or tag

cerulean charm
cinder wraith
#

and how does that prevent you from adding another one?

#

<name>@<tag or version>

#

name being @discordjs/util

cerulean charm
#

Okay, where can i find the newer version of the utils package so i can put it?

cinder wraith
#

npm has always listed package versions

steel haven
#

Not install it as separate dependency

cerulean charm
steel haven
#

Show what you tried then. And how did „the json file“ say it was wrong? Did yarn say it? Or your IDE?

cerulean charm
#

oh wait do i replace the version with dev

cinder wraith
#

yes

#

but not in dependencies

steel haven
#

Outside the dependencies

cerulean charm
#

oh

steel haven
#

Did you try it? Run yarn and see

cerulean charm
#

I'm still getting the issue

image.png
#

That's what i got rn

steel haven
#

Aka remove it from your dependencies: block, only need the resolution

cerulean charm
#

oh

cerulean charm
steel haven
#

Yes, it‘s a sub-dependency of djs. You don’t need it separately installed

cerulean charm
steel haven
#

And?

cerulean charm
#

Still have the error

image.png
steel haven
#

Did you run yarn before? Or just change the package.json without telling yarn to act upon it?

cerulean charm
#

i just editied the file and then told my bot to start yarn start

#

do i need to run just yarn?

steel haven
#

You should learn how your package manager works before attempting to use a dev version of a library tbh…

cerulean charm
#

I will practice it more cause i need too but i like to use the new features but i never setup dev package before.

image.png
steel haven
#

Well, just like we tell users (with good reason) to learn js before asking for help with djs, the same applies for your package manager. Using the dev release is not something we provide hand-holding with. If anything it‘s the opposite

cerulean charm
#

So i went to the yarn site and saw the package number and did this but now there's a different issue

image.png image.png
steel haven
#

Now do the same for /rest

cerulean charm
#

Okay

#

would i need to uninstall the rest? I dont think i can cause it's in the main package

#

okay no not quite

# 
  "dependencies": {
    "@types/mongoose": "^5.11.97",
    "@typescript-eslint/eslint-plugin": "^6.19.1",
    "axios": "^1.6.8",
    "chalk": "^5.3.0",
    "dayjs": "^1.11.10",
    "discord.js": "^14.15.0-dev.1711325411-a1a3a95c9",
    "dotenv": "^16.0.3",
    "eslint": "^8.56.0",
    "fs": "^0.0.1-security",
    "mongoose": "^8.1.1",
    "ms": "^2.1.3",
    "path": "^0.12.7",
    "remove": "^0.1.5",
    "util": "^0.12.5",
    "xtroutils": "^0.0.55",
    "yaml": "^2.4.1",
    "yarn": "^1.22.21"
  },
  "resolutions": {
    "@discordjs/util": "1.1.0-dev.1711325410-a1a3a95c9",
    "@discordjs/rest": "2.3.0-dev.1711325406-a1a3a95c9"
  },
steel haven
#

Wait… is that yarn v1? That is… a bit outdated

cerulean charm
#

idk why that would be

#

let me try to update it

#

updated i believe now

#

yep

#

i've got a whole bunch of discord.js errors now

image.png
steel haven
#

Restart ts-Server

cerulean charm
#

i'm not sure if that's their new method of running

cerulean charm
# steel haven Restart ts-Server

Qjuh after alot of struggling i've learned alot about yarn and figured out how to fix it myself. And i'm all updated and good to go thanks to you. Appreciate your help always

quiet rover
cerulean charm
wheat pewter
#

Is there any work being done on fixing the search for the new docs

#

If I search a class like User it doesn't pop up, instead I get a hundred user members of unrelated classes

#

Thew new docs are pretty much useless because I can't easily pull up what I need

rigid haven
silk topaz
vague coyote
#

Nvm doesnt work anymore hamsterPwease

wheat pewter
#

😦

errant idol
#

can't .setName() and .setDescription() usage be validated in types with generics? so ts users will always get an error if they don't use both .setName() and .setDescription()

#

in slash command builder ^ (and its options too)

steel haven
#

Where should they get that error in your opinion?

#

There are already too many validation layers imho when the API is the actual source of truth

cinder wraith
#

that sounds like adding types for the sake of adding types. ability to do that is cool and all, but if i'm not mistaken the general sentiment is to not do that anymore, as our current amounts of such generics in places we already have them tends to be more annoying to work with than useful for potential safety

errant idol
#

hmm

#

yeah that is understandable

cinder wraith
#

for example, did you know that EmbedBuilder with a subcommand set is not assignable to EmbedBuilder type?

errant idol
#

you can add subcommand to embedbuilder?

cinder wraith
#

*slashcommandbuilder

errant idol
#

um yeah SlashCommandSubcommandOnlyBuilder or smth like that i saw it

cinder wraith
#

because we do type gymnastics with generics to remove you ability to add options to the main command after you added a subcommand to it

errant idol
#

isn't that just addSubcommand(): this is SlashCommandSubcommandOnlyBuilder?

cinder wraith
#

and what is SlashCommandSub...

errant idol
#

wdym?

cinder wraith
#

what is that defined as

errant idol
#

oh let me check

#

yeah Pick and Exclude

#

i guess to make my suggestion possible there needs to be 2 more classes which all need to support the other classes which also need to support these 2 classes and ends up becoming a mess

cinder wraith
#

yeah, and then my code needs to accept all of that somewhere if i want to pass the builder further instead of just using it to create json in place

errant idol
#

yeah i've experienced that

#

could make a type that combines all of the different slash command builders

cinder wraith
#

and name it SlashCommandBuilder

steel haven
#

By following our naming pattern it would be AnySlashCommandBuilder

meager saffron
#

hii

cinder wraith
meager saffron
#

is it possible to get the message content from these types of commands via user apps?

image.png
cinder wraith
meager saffron
#

darn ☹️

cinder wraith
meager saffron
#

i need

#

uhhh idk

cinder wraith
#

you are in wrong channel

#

go to one of those i linked, and ask there

meager saffron
#

but thats not the right channel either since user apps arent supported by discord.js ig idk

#

ill just ask anyways

wheat pewter
#

This category is for development of discord.js itself

knotty plover
#

Wasnt aware it was up for debate

wheat pewter
harsh path
wheat pewter
#

Thanks

south dove
#

Is there already User Installation Commands there for the Builders?

knotty plover
#

no

ebon falcon
#

Hello

lament cloud
#

Is it possible to see how @plain rover registers a user commands?

potent nacelle
steel haven
lament cloud
#

I can only find this, how to create a user command and I couldn’t find it

image.png
knotty plover
#

Yeah we have no documentation on this and it isnt supported by discord.js

#

If you deploy your commands with the @discordjs/rest module it will work

lament cloud
knotty plover
#

No, not even close to that, since thats absolutely not what I said

sturdy thorn
#

So, I've noticed that my code doesn't show any TypeScript error if I fail to pass required properties in my builders... namely, .setStyle() in my ButtonBuilder()
Ultimately, if I run the following code without .setStyle() it will throw an error at runtime due to the missing property. Just wondering if this was an oversight or intended behaviour 🙂

export default {
    data: new SlashCommandBuilder()
        .setDescription("Sends a button!"),
    
    execute: async (interaction: ChatInputCommandInteraction) => {
        const button = new ButtonBuilder()
            .setLabel("Click me!")
            .setCustomId("button")
            .setStyle(ButtonStyle.Primary);

        const row = new ActionRowBuilder<ButtonBuilder>()
            .addComponents(button);
        
        await interaction.reply({
            components: [row],
        });
    },
} as Command;

As you can see, my code should be type-safe, but there appears to be no validation to check if the required properties are present.
I was directed here in-case it was overlooked.

82IpPEB.png
knotty plover
#

Im not sure what sort of TypeError you expect here? The builder itself has validation when it calls toJSON()

#

Are you suggesting that the builder methods should return something akin to IncompleteButton until such time as the necessary functions are called?

#

Thats actually incredibly difficult to achieve

sturdy thorn
#

I was expecting that there would've been a TypeError thrown at some point, perhaps when I pass [row] into components?
So if I used .toJSON() should I do this on row to validate?

knotty plover
#

toJSON will throw a runtime error

#

It's called internally when builders are passed

#

Builders provide runtime validation that can be caught, raw JSON would be much better for type validation

sturdy thorn
#

Gotcha, yeah this was what I sort of intuitively thought would happen

ImDi0wN.png
#

or maybe at the .addComponents() instead

velvet jasper
#

Also instead of using “as”, “satisfies Command” is slightly better

sturdy thorn
velvet jasper
#

It’ll report any type errors more clearly than casting

sturdy thorn
#

Gotcha, thanks for that

knotty plover
#

The Builder doesn't have different types based on which methods have/havent been called

#

That would be kinda a nightmare

sturdy thorn
#

Yeah no worries!
It's nothing major, just something that made me go "oh?"

idle galleon
#

Can’t imagine having a generic for each thing you need to set

#

class ButtonBuilder<Style extends ButtonStyle, LabelSet extends boolean, IdSet extends boolean, UrlSet> {

velvet jasper
#

You just did imagine it

knotty plover
#

🤮

wooden sky
sturdy thorn
errant idol
#

um that kinda sucks in a way imo

sturdy thorn
#

Here's my demo ping.ts file, for example, it tells you that the name is inferred from the file

vmEikIv.png
sturdy thorn
errant idol
#

i'm just used to checking names in the builder

#

and it really confuses the heck out of somebody else

wooden sky
#

I'm used to names in builder too

sturdy thorn
#

I may make it allow you set your own name so it doesn't confuse people, but if the name isn't passed, it gets from filename

#

Before

const { data }: { data: SlashCommandBuilder } = command;
const commandName = file.split(".")[0].toLowerCase();

After

const { data }: { data: SlashCommandBuilder } = command;
const commandName = data.name ?? file.split(".")[0].toLowerCase();

Easy change, now if you set the name manually it will use that name, if you don't set it, it'll use the file name.
Is that better? @errant idol @wooden sky 👼

wooden sky
#

Mhm

#

👍

south dove
#

Is there anything about User Installation Commands yet?

steel haven
#

User-installable apps are currently in preview. During the preview, there are major limitations and known bugs, and API details are subject to change.
As soon as they are stable djs will implement them. But for the most parts they already work with djs. Registering them with /rest and json works. And handling interactionCreate does too

fallow yarrow
#

So I tried posting a user-installable message context menus, though it doesn't seem to show up even though it logged a success, and I authorized the bot

#

Perhaps they don't support that yet, not sure

uncut kelp
#

interaction_types does not exist. If you need help, I would ask in Discord Developers

fallow yarrow
#

You're right, I mispelled it

#

It's actually "integration_types"

#

It shows up now

image.png
obsidian whale
uncut kelp
#

It is

#

The crash-loop behaviour is inadequate error handling on your part regardless

obsidian whale
fallow yarrow
violet nebula
#

Is there a way for bots to use the new polls feature yet or not

rain bramble
violet nebula
kindred fox
#

Events.WebhooksUpdate value is webhookUpdate so I get node deprecation warning (not sure if this is a bug or intentional)

cinder wraith
#

node deprecation warning?

knotty plover
#

wut

floral wave
cinder wraith
#

sure, but that is our deprecation warning, not a node one specifically

kindred fox
cinder wraith
#

yes, this looks like an issue. just that your initial message was a bit confusing as node itself also has some deprecated stuff

quiet rover
cinder wraith
#

the warning? yes;

#

the enum not being updated sounds quite not intentional

quiet rover
#

i would imagine its an oversight but cant put a finger on it either, so might not be intentional then

idle galleon
#

I mean, enum names don’t usually deviate from the value by spelling

quiet rover
#

I see.

cinder wraith
#

and preferably use english as well

#

that's not english

cerulean charm
#

was this PR now fully accepted to be added? I would assume that this means yes. But now all devs gotta add the features so it will take some time.

image.png
tame smelt
#

That just means the PR has no conflicts with the branch and passes all the checks, doesn't mean it's "ready" to be accepted! You'll have to wait and see

cerulean charm
#

Okay just wanted to come and make sure.

lapis thistle
#

There is a docs for dev version 14.15.0?

knotty plover
#

Just switch to main

lapis thistle
knotty plover
#

What do you mean

#

Main docs are dev version docs

lapis thistle
#

what Where is she? I can’t find her?

#

ah well I hadn’t even seen, so it’s just the guide who is not yet available

knotty plover
#

The guide is manually written, so yeah

#

Unless someone actually decidea to write a page for a new feature, that's the guide

#

Everything in there is still accurate

lapis thistle
#

you have not made a guide hide as for v14?

uncut kelp
#

What guide are you looking at?

lapis thistle
#

discord.js

#

and but I wonder, no discord.js staff and paid to create the package for discord?

knotty plover
#

I don't quite understand your question. The guide is up to date and for v14

lapis thistle
#

when v14 was still in development there was the guide that was released long before the official release of v14

knotty plover
#

The only reason we would have done that was because v14 was so significantly different to v13

#

There is no v15 in the works with any major changes that would require a rewrite like that

#

You're looking for something that not only doesn't exist, it has no reason to exist

wary wharf
#

sooo are you guys following the datamining leaks coming out?

#

Looks like modals are getting an update as well as a bunch of new components

uncut kelp
#

It doesn't really matter until Discord documents it

wary wharf
#

yeah true

#

hype its most likely happening so we can finally get more things to do with modals

dawn phoenix
#

kindly contain the hype to #archive-offtopic and keep this for actual in-dev version use and discussions
as jira said, we're implementing things as they are properly documented (read: merge into api-docs) upstream

wary wharf
#

gotcha!

solemn sparrow
#

Is there a PR about updating undici from 5.28.3 to 5.28.4? It would fix some vulnerabilities

uncut kelp
#

We are not even on 5.x

image.png
solemn sparrow
#

what th-

solemn sparrow
uncut kelp
#

In all of them

solemn sparrow
#

Installing the dev version of d.js installs 5.x of undici for me

uncut kelp
solemn sparrow
#

less vulnerabilities now, but rest@dev’s undici is still on 6.7.1 for me

uncut kelp
night latch
#

is there a way to fix this error? I am using the @dev version of discord.js

image.png
silent hedge
#

when using a dev release you have to override all the subpackages too - sometimes

errant idol
#

i like how some guy was asking for help and u turned his code into an example for what he was trying to do lol

south dove
#

Anything about user commands here?

cinder wraith
#

the same thing as already said multiple times

south dove
hazy bison
hoary fox
#

Looks like caused by @mix(SharedNameAndDescription)

solemn sparrow
steel haven
hasty gorge
#

I know this question was prob answered a billion times and I prob even asked it and forgot but are user apps supported in dev version yet? I'm pretty sure there was a pr for it if i remember correctly

rain bramble
hasty gorge
rain bramble
hasty gorge
waxen cape
#

Just upgraded to the dev version of discordjs

right off the bat i get hit with this

anybody know what this is?

image.png image.png
cinder wraith
rigid haven
# 
"overrides": {
    "@discordjs/builders": "dev",
    "@discordjs/collection": "dev",
    "@discordjs/formatters": "dev",
    "@discordjs/rest": "dev",
    "@discordjs/util": "dev",
    "@discordjs/ws": "dev"
},
"dependencies": {
    "discord.js": "dev"
}
waxen cape
waxen cape
#

also, where do i put that

package.json ?

rigid haven
#

yes

waxen cape
#

thanks 🙂

dawn phoenix
#

Regarding subpackage changes

If the current version of discord.js@dev depends on changes in sub-packages that are not yet released, you may need to change the dependency to use the dev version of the responsible sub-package:

npm / pnpm / bun

"overrides": {
  "@discordjs/subpackagenamehere": "dev"  
}

yarn / pnpm / bun

"resolutions": {
  "@discordjs/subpackagenamehere": "dev"  
}
dawn phoenix
floral wave
#

Not sure if it's a typing issue or if it's intentional

if (!interaction.inCachedGuild()) return;

interaction.channel.id // interaction.channel' is possibly 'null'.ts(18047)```
steel haven
#

It’s intentional, because .channel is a getter it‘s possible for the channel to be deleted by the time you access the getter

placid stone
#

Wheres the DJS Guide for v15

rigid haven
#

v15 isn’t a thing yet

placid stone
#

Isnt this channel for v15 development?

rigid haven
#

It’s for the dev version

placid stone
#

So surely there should be a development guide, no?

#

There always was for previous versions

rigid haven
#

The current dev version is 14.15, not v15

placid stone
#

Yeah well I need to use v15 since v14 doesnt have entitlements yet

steel haven
#

there’s no breaking changes in dev version. So no guide needed either

steel haven
placid stone
rigid haven
#

Check pins

placid stone
#

Thanks

placid stone
rigid haven
placid stone
#

Still happens but now it shows

Screenshot_2024-04-28_at_4.46.55_PM.png
uncut kelp
#

Show your package.json

placid stone
# 
{
  "name": "cyclone",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "repository": {
    "type": "git",
    "url": "git+https://github.com/brocosito/DynoClone.git"
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
  "overrides": {
    "@discordjs/builders": "dev",
    "@discordjs/collection": "dev",
    "@discordjs/formatters": "dev",
    "@discordjs/rest": "dev",
    "@discordjs/util": "dev",
    "@discordjs/ws": "dev"
  },
  "dependencies": {
    "@discordjs/builders": "^0.6.0",
    "@discordjs/rest": "^1.3.0",
    "axios": "^1.1.3",
    "colorette": "^2.0.19",
    "connect-mongo": "^4.6.0",
    "console-symbols": "^1.0.0",
    "cron": "^2.1.0",
    "cuid": "^2.1.8",
    "discord-api-types": "^0.22.0",
    "discord-giveaways": "^6.0.1",
    "discord-modals": "^1.3.9",
    "discord.js": "dev",
    "dotenv": "^16.0.3",
    "ejs": "^3.1.8",
    "emoji-regex": "^10.2.1",
    "express": "^4.18.2",
    "express-session": "^1.17.3",
    "is-empty": "^1.2.0",
    "log-symbols": "^5.1.0",
    "mongoose": "^7.5.3",
    "ms": "^2.1.3",
    "node-cron": "^3.0.2",
    "node-schedule": "^2.1.0",
    "node-twitch": "^0.5.0",
    "passport": "^0.6.0",
    "passport-discord": "^0.1.4",
    "passport-oauth2-refresh": "^2.1.0",
    "persistent-scheduler": "^1.0.1",
    "pokedex-promise-v2": "^3.3.2",
    "quickdb": "^1.0.5",
    "quickmongo": "^5.2.0",
    "rss-parser": "^3.12.0",
    "simple-youtube-api": "^5.2.1",
    "snoowrap": "^1.23.0",
    "string-template": "^1.0.0",
    "stripe": "^10.14.0",
    "validator": "^13.7.0"
  }
}
cinder wraith
#

i don't think you need to install the /builders and /rest separately at all

#

or discord-api-types

uncut kelp
#

Yes that would not be correct.

Also, you should only have packages in only one of your overrides and depedencies. Make sure to delete node_modules and install again

keen plover
solemn sparrow
quiet rover
#

it does try to send you to Interface section, but it doesnt really exist on collection's docs

solemn sparrow
#

Its the right route, just the wrong docs type

steel haven
#

That’s fixed in code already, just docs workflow would need to run on v14.14.1 again (works on main as expected). So this discussion is in the wrong place. The dev version is the version where it actually works, #djs-help-v14 needs only one workflow run and would be fixed too

waxen cape
#

Does anyone know if it's still the case that modals only accept text inputs?

Ideally i'd like to use dropdowns in a modal

cinder wraith
#

yes, still only text input, regardless of which d.js version are you using

oak fog
#

does dev version of discord.js has user install?

knotty plover
#

no, dont think so

oak fog
#

please ping me if you give reply 😆

waxen cape
#

hmm

i just deployed my bot to production

and the command i need to initialise the bot isn't showing up on my server 💀

it's there in the development bot though -_-

foggy dune
#

Getting the polyfilldispose error even after I made the changes to the package.json as above

    "@discordjs/builders": "dev",
    "@discordjs/collection": "dev",
    "@discordjs/formatters": "dev",
    "@discordjs/rest": "dev",
    "@discordjs/util": "dev",
    "@discordjs/ws": "dev"
  },
  "dependencies": {
    "@nestjs/cli": "^9.4.2",
    "@nestjs/common": "9.4.0",
    "@nestjs/core": "9.4.0",
    "@nestjs/platform-express": "9.4.0",
    "@nestjs/schematics": "9.1.0",
    "@nestjs/testing": "9.4.0",
    "@prisma/client": "^5.13.0",
    "@types/express": "4.17.17",
    "@types/jest": "29.5.1",
    "@types/node": "18.18.10",
    "@types/supertest": "2.0.12",
    "@typescript-eslint/eslint-plugin": "^5.57.0",
    "@typescript-eslint/parser": "^5.57.0",
    "discord-api-types": "^0.22.0",
    "discord-modals": "^1.3.9",
    "discord.js": "dev",
    "dotenv": "16.3.2",
    "eslint": "^8.37.0",
    "eslint-config-prettier": "^8.8.0",
    "eslint-plugin-prettier": "^4.2.1",
    "jest": "29.5.0",
    "nestjs": "^0.0.1",
    "nvm": "0.0.4",
    "prettier": "^2.8.7",
    "reflect-metadata": "0.1.13",
    "rxjs": "7.8.0",
    "source-map-support": "^0.5.21",
    "supertest": "^6.3.3",
    "ts-jest": "29.1.0",
    "typescript": "^5.3.2"
  },```
uncut kelp
#

If your dependencies aren't installed correctly, then you should regenerate your node_modules folder

foggy dune
foggy dune
fierce lantern
silent hedge
#

that PR needs some attention

#

will have a look again soon

boreal knot
#

I also dont really want to fully remove zlib-sync, but keep it as an alternative

#

esp since we dont know if native zlib is faster or not

night latch
#

yeah still the same

uncut kelp
#

The same as?

night latch
#

after I do overrides

uncut kelp
night latch
#

I deleted node_modules then re-installed the packages still the same

uncut kelp
#

Dunno then

#

Don't see how that's possible

night latch
#

okay I somehow deleted it again along with package-lock.json

#

it works

uncut kelp
#

That's a good idea. Glad it worked out

night latch
#

yeah thanks

night latch
#

so what is new in developer version?

vague coyote
fiery mountain
#

is there a list of things that need to be done, or things people are currently working on?

#

i would like to contribute to the guide but i'm not sure if anyone is working on it right now

wanton crown
#

any idea on when user installs are gonna be supported?

#

I'm already using them without the slash command builder but setting the permissions without them sucks

uncut kelp
wanton crown
#

ah I see

uncut kelp
#

Yeah I'm actually using @discordjs/core, @discordjs/rest, and @discordjs/ws for my little one and it's fine so far. The main library however, is not

wanton crown
#

Yeah, I just tried using discord.js@dev but the builders don't have any option to add context or integration type

#

so for now I just send the command data like this for example:

data: {
  name: 'ban',
  description: 'Bans a member',
  type: ApplicationCommandType.ChatInput,
  contexts: [Context.GUILD],
  integration_types: [IntegrationTypes.GUILD_INSTALL],
  default_member_permissions: `${PermissionFlagsBits.BanMembers}`,
}
tacit dew
wanton crown
#

But I don't want to add them to every command?

keen abyss
#

That's why if statements exist

wanton crown
#

so I'd have to add a new property to all my commands which is exactly what I'm doing already with contexts and integration types

#

I'd rather just wait until this releases for everyone to use

robust badge
#

Does discord.js support "User App" type?

potent nacelle
#

no but there is pr

pastel flare
#

Question, why the removal of "Target"?

Answrr provided: #archive-offtopic message

also removes the ability to ping people
bc that was obnoxious af to handle

Screenshot_20240506_140728_Discord.jpg
keen bobcat
#

this is not a question about d.js development

pastel flare
keen bobcat
sinful heath
#

@boreal knot Regarding adding tests for #10255, do you still want me to throw them in SlashCommands.test.ts with everything else? I ask because I see that practically all of the current tests in there are for runtime as opposed to strictly type checking which is what the tests for this PR would be for, so I want to double-check with you guys before moving forward

boreal knot
#

yeah thats fine imo, idk if those tests get type checked

sinful heath
#

Vitest isn't screaming at me if I force a TS error in there, so I don't think so. I'll move forward with that anyways, cheers

silent hedge
#

adding a type test like this does nothing meguFace

boreal knot
#

there is vitest typecheck we could probably use

silent hedge
#

we should enable that

#

i've ran into this in the monorepo before where

#

we changed something

#

and tests wouldn't have compiled for months

#

but ci still passed since they worked at runtime

#

its kinda nasty

steel haven
#

So the test I added was useless toomeguFace

sinful heath
#

Should I skip tests for this then? Or is type-checking gonna get enabled

#

Cause I don't wanna add more runtime tests since they won't do anything to prevent this specific issue

meager crag
#

Who will test the tests themselves?

idle galleon
#

Mathematicians

sinful heath
steel haven
sinful heath
#

I'll go do that then

meager crag
#

@uncut kelp: congrats on the good first issue!

uncut kelp
#

Please stop mentioning me about that

meager crag
#

have I before? 😐

haughty sorrel
meager crag
#

Apologies for the depressing predictability

#

On the subject of the follow channel function, GuildChannelManager#addFollower currently implies through JSDoc/.d.ts that it only accepts a NewsChannel as the source argument, but doesn't do anything to check/assert that. I presume the API would complain if the source channel weren't an announcement channel anyway?

uncut kelp
#

Yes

meager crag
#

Would it be worth saving an API call if the argument were a channel object of the wrong type?

keen bobcat
#

it's not the library's job to make those checks. doing so would mean a whole lot of extra code all over the place (before making any request gated by a permission), and then having to update the code if/when discord changes things, which could then lead to an unexpected breaking change necessitating a new major version sooner than planned...

meager crag
#

Conditionally resolving an id based on instanceof checks is just the behaviour of all Resolvables, no?

silent hedge
#

it's not our job to validate this sort of thing

#

and it never will be

#

this is most harshly felt in how GuildMemberRoleManager#update doesn't automatically deal with managed roles

#

it's something that's consistent throughout the library

meager crag
#

Makes sense.

potent nacelle
#

personally, i think that discord libraries should not validate user inputs ever

#

it should be up to discord api

idle galleon
#

Afaik, builders extracted the extra validators (which can be disabled) that used to be in d.js. D.js should only have type checks that are necessary to resolve an object into a type that Discord api would expect. Passing in the expected object should go straight to Discord api otherwise

hasty gorge
#

anywhere i can find user apps well explained since yall havent added them yet?

rain bramble
hasty gorge
#

are there any good docs about it anywhere

#

ig i can find them on ddevs website prob

rain bramble
hasty gorge
scarlet tangle
#

Hi
Is there someone working to implement the message forwarding feature in Djs so that it's ready as soon as Discord release it ?

uncut kelp
#

There is no open pull request regarding it

cinder wraith
uncut kelp
#

For discord.js

hasty gorge
#

kind of a weird question, but can we make debug logs a bit more consistent

#

the padding is completely random

PyBujmL.png
#

sometimes its one tab it seems sometimes two

#

sometimes none

#

first world problems i know

uncut kelp
#

I don't believe that has to do with us

hasty gorge
uncut kelp
#

No I think it's a problem with your logger

hasty gorge
#

uhm i dont think so

#

here i'll just use console.log

hasty gorge
#

its either discord or djs

#

i mean its not really an issue

#

its just annoying kinda

uncut kelp
#

Hmm

#

Yeah I had a quick look, it's on us

#

It's not a priority though but it could be fixed in the upcoming version

hasty gorge
#

yeah as i said its not really an issue

#

would be great if it was fixed tho, thats why i put here in dev channel

hasty gorge
dull mulchBOT
hasty gorge
#

ight thanks

loud tide
#

So... Is there user installable app support in discordjs?

uncut kelp
#

Once it's not in preview

loud tide
#

What you mean by that?

uncut kelp
#

When it is not in preview, it will be

loud tide
#

Discord has it in preview?

uncut kelp
#

Yes

loud tide
#

Oh

rough kernel
#

@nimble cypress

meager crag
#

@tawdry mantle just quickly regarding your comment on the TS issue. class merging in general wasn't possible prior to TS 5.5, even for module augmentation (example). the issue was that under certain conditions, aliased symbols (not just classes) bypassed mergeability checks, and it happened that this applied directly to DJS's usage case because of the way EventEmitter is exported in @types/node

#

it might be worth clarifying so that the maintainers have a better idea of why this has become a problem now, and for other people searching for the same thing

rustic plinth
#

why is <User>.createDM named create, doesn't it just fetch the dm channel

uncut kelp
cinder wraith
#

can't fetch if it doesn't exist yet

solemn sparrow
#

Getting a failed test on latest rebase for my PR? I tried a --force to see if that would work but no dice

image.png
steel haven
#

Did you pnpm install --frozen-lockfile again after rebase before commit?

solemn sparrow
latent timber
#

Friends, I have a giveaway bot, but when I make a draw in this bot, after a while I get the interaction failed error. I asked the coder, he said the update has arrived, discord.js something, how can I fix it?

cinder wraith
#

That has nothing to do with dev version.
It also doesn't sound like an issue with d.js but rather your code or eventually host

latent timber
#

Could you please help me?

#

I have no knowledge about coding

cursive venture
#

ask the person that made the bot then

#

this isnt the channel for that and as mentioned likely isnt a djs issue

latent timber
#

doesn't help

cinder wraith
#

We can't either

latent timber
#

Why does it give the access failed error when participating in the raffle? When I want to end the raffle manually, the bot cannot find the raffle.

cursive venture
#

you didnt code the bot so how are we supposed to know

#

how do you even expect help with 0 coding knowledge. Ask the person that made the bot

velvet jasper
#

so did they update the new member icon?

fierce lantern
#

are there any benchmarks from /ws from using native zlib vs zlib-sync? would be nice to have native zlib support in main discord.js

silent hedge
next zodiac
#

hey

cursive venture
meager crag
#

@hoary fox I think you are confusing undefined with null here. undefined very much is a primitive type

hoary fox
#

yeah i did

grand sierra
#

anyone can assist me with something in discordjs?

cursive venture
brazen knoll
#

why are both <SlashCommandBuilder>.setDMPermissions(true) and <SlashCommandBuilder>.setContexts(<InteractionContextType.BotDM) a thing?
Do they not do the same thing?

uncut kelp
#

Yes

brazen knoll
#

what's the difference between them?

uncut kelp
#

One is deprecated

brazen knoll
#

curious because its not marked as deprecated

uncut kelp
#

It will be

brazen knoll
#

alr

uncut kelp
#

Discord is moving towards integration types and contexts to allow more granular control over how an application is added and in what context a command may be used

brazen knoll
#

is <ApplicationCommand>.contexts and <ApplicationCommand>.integtrationType not a thing yet or will this never be a thing?
and if the latter, how do i find out what Context/IntegrationType a <ChatInputCommandInteraction>.command has?

knotty plover
#

Not a thing yet

brazen knoll
#

alright thank you

knotty plover
#

I don't think it will ever be a thing on an interaction honestly

brazen knoll
#

so then how do i find out?

knotty plover
#

I guess via it's command you could actually

uncut kelp
#

The message will state how it was invoked

cinder wraith
#

Context is there below it, right?

uncut kelp
#

Yaa

brazen knoll
#

which then means not a thing yet like monbrey said

brazen knoll
#

im not receiving message component interactions in group dms
is there a partial or intent i need for this?
normal chat input commands work

#

(not sure about select components, but def not buttons)

steel haven
#

How are you listening to the message component interactions?

brazen knoll
#

via interactionCreate event

steel haven
brazen knoll
#

Yes

steel haven
real spruce
#

please dm me when you need a developer

knotty plover
#

We do not, thank you

twilit bobcat
#

is there a specific node version I should use when running pnpm install on the monorepo? I get a really weird error with zlib-sync, it looks like it's trying to compile c files or something like that

#

I'm currently pruning my pnpm cache to see if that fixes it

#

I'm on node 22

#

that was the second try just in case, but the first one it said the same error

#

I must have a gigantic pnpm cache since the prune has been running for like 5 minutes lol

fierce lantern
#

i think zlib-sync doesnt support node 22 (even though it somehow works for me), theres an open issue in its repo

#

ci uses node 20, maybe try that

twilit bobcat
#

just as you said that and I was about to cancel the prune, it finally finished, I'll try switching to 20, thanks!

twilit bobcat
#

yep, that worked, thanks!

unkempt quarry
#

guys, is there any eta on when app emojis will be added

uncut kelp
#

No

unkempt quarry
#

ok, thx

errant idol
twilit bobcat
#

try in main branch

#

version branches' source seeking seem to not work, at least for me

dull mulchBOT
forest elm
#

This pull request should fix that issue, just needs to be reviewed and merged

dull mulchBOT
keen bobcat
undone crater
#

When watching for messages, forwarded messages come in without any content. Is this supported in the dev version? I'm currently using discord.js@14.16.0-dev.1721866227-bf6761a44

rustic plinth
undone crater
vague coyote
undone crater
#

ah okay. That explains it!

vague coyote
zealous otter
#

message forwarding isn't officially out so if you try to send a message reference with the forward type you'll just hit a 403 so the pr won't be merged until it's rolled out i believe

steel haven
zealous otter
#

yes? it's still forbidden though so it would be weird to merge it

#

tho what do i know

rigid haven
#

i think it's being rolled out on a per-user basis

#

some people in my server are able to use it

keen bobcat
#

That's irrelevant to the bot API. When it's available to bots and documented is when features get added

rigid haven
#

But bots are already able to receive forwarded messages, and the documentation PR has been merged

steel haven
#

It‘s not about receiving. It‘s about forwarding themselves

cursive venture
#

Ask discord

#

We only provide what discord provides

rigid haven
steel haven
#

Both is documented already. So both can be added now

cinder wraith
#

really?

verbal estuary
#

Does the indev version have Integration user install and the new features on discord?

tame smelt
#

If yu are asking about user install., Only builder (for Commands) support is in dev version, the other stuff (like ApplicationCommandManager, Availability of the new properties in the recieved data, etc) are yet to be added

dull mulchBOT
tame smelt
#

It'll be available when this gets merged ^

verbal estuary
tame smelt
#

More or less, though once you have the commands deployed, handling it is not much of a difference except for few quirks (e.g uncached guilds, group dms...). But yeah you'll have to wait for the above pr to be merged to get all of those

verbal estuary
cinder wraith
verbal estuary
# cinder wraith User-installable apps do not carry the bot user with them

Wym bot user, i can access the bot user thru <Client> instance, its not about that, more i mean the user of the command itself. since presence statuses and activitiy statuses are thru <GuildMember> instance, will that change? And will it be possible to check VoiceState within the DMs with the bot?

keen bobcat
#

If discord does so, then d.js will follow it, but that's not anything we can determine. Better to check the API docs if it has anything or ask in ddevs

cinder wraith
#

me having your app user-installed, and using it in a group DM does not make your bot's account exist in that group dm

#

that said, i don't know what exactly discord happens to expose about the user using your command for contexts where you cannot just read that data via your app's bot user being in the same server

verbal estuary
#

Thank you for your answers, I appreciate it.

neat cradle
#

ClientOptions.options.ws cannot be null anymore?

I updated my version of discord.js to discord.js@dev and if I don't set a presence object in the client options my bot won't start

TypeError [ClientInvalidOption]: The ws.presence option must be an object

I checked in Client.js and its looks like we can't anymore, so i wonder why

    if (typeof options.ws.presence !== 'object' || options.ws.presence === null) {
      throw new DiscordjsTypeError(ErrorCodes.ClientInvalidOption, 'ws.presence', 'an object');
    }

My overrides :

    "overrides": {
        "@discordjs/builders": "dev",
        "@discordjs/core": "dev",
        "@discordjs/discord-api-types": "dev",
        "@discordjs/collection": "dev"
    }
idle galleon
#

presence: null doesn’t rly make sense considering member.presence is only null when the member's presence is uncached

forest elm
neat cradle
# idle galleon Did you try setting it to undefined or not setting it at all?

At first, I had this,

 
        this.WhiteClient = new Client({ intents: [GatewayIntentBits.Guilds, GatewayIntentBits.GuildMessages, GatewayIntentBits.DirectMessages, GatewayIntentBits.GuildMessageReactions, GatewayIntentBits.DirectMessageReactions, GatewayIntentBits.GuildMembers, GatewayIntentBits.GuildWebhooks, GatewayIntentBits.MessageContent], partials: [Partials.Message, Partials.Channel, Partials.Reaction, ] });

And I got the type error, so I tried adding a presence and it works, I don't get the error anymore but the presence doesn't do anything, I think it's not implemented yet.

        this.WhiteClient = new Client({ 
            intents: [GatewayIntentBits.Guilds, GatewayIntentBits.GuildMessages, GatewayIntentBits.DirectMessages, GatewayIntentBits.GuildMessageReactions, GatewayIntentBits.DirectMessageReactions, GatewayIntentBits.GuildMembers, GatewayIntentBits.GuildWebhooks, GatewayIntentBits.MessageContent], 
            partials: [Partials.Message, Partials.Channel, Partials.Reaction, ],
            ws:{
                presence:{
                    status: PresenceUpdateStatus.Online,
                    activities: [
                        {
                            name: "/help",
                            type: ActivityType.Listening
                        }
                    ],
                    since:null,
                    afk: false
                }
            }
        });
neat cradle
idle galleon
#

Def a bug

neat cradle
#

It's really weird because in the Client.js file it's written as if it were prohibited and it should be defined (_validateOptions function)

neat cradle
cinder wraith
#

for the cases where it's provided

#

would be great to have it complain about getting a false instead of an object

forest elm
#

we should probably just remove that, the other options that are passed along to the submodules arent being validated either, just the top-level object

cinder wraith
#

well, there is the same check for top-level presence

#

i'm guessing the difference is that
this.presence = new ClientPresence(this, this.options.presence);
but
this.options.ws.presence = this.presence._parse(this.options.presence);
?

#

although i guess only the former changed in that PR
meh, too late for thinking for me

neat cradle
#

I think it's only the type check that shouldn't be here, the PR doesn't seem wrong to me. It will just throw an error to peoples who haven't set ws.presence in the Client Options

dull mulchBOT
fringe cypress
#

Is there any way I can install the current main branch?

vague coyote
#

you can install the dev version which updates every 12 hours iirc
(npm i discord.js@dev)

meager crag
#

@tawdry mantle I really didn't follow her response at all... and I don't see why all the cleanup work (minus the static method changes) wouldn't be fine to merge?

tawdry mantle
#

yeah, I think just removing the symbol and documenting that generics for those cases must be passed manually is probably the way to go

#

I do wonder if we'll ever see typescript be able to infer from ancestors type parameters

#

it certainly won't be easy to implement, but it seems like something that should work

meager crag
#

Not easy to search whether it's been asked before, but couldn't see that it obviously had

meager crag
#

I suspect the only clean option is to leave those as fully event-map-naive.

tawdry mantle
#

I was gonna say I can just noInfer them but that seems like something we can't use in a core DT package yet

#

There is a way I can make it only work when you pass generics though

sinful heath
#

@tame smelt Regarding #1046, you might want to also add types in /rest/v{version}/guild.ts voice.ts as Almeida pointed out just now to follow the convention of having types detailing the response data for the various routes. Something like this at least from my perspective

image.png
#

Something else I realized, I think it'd be a good idea to comb through and see if there's any other JSDoc comments that have the old (and now invalid) API docs URL for voice states and update those URLs the new (and valid) one

tame smelt
#

Great idea, will do that

tame smelt
knotty plover
#

Because a PR hasn't been written / merged yet

tame smelt
#

Oh. I wasn't sure if it was meant to be that way.

brisk elbow
#

Any updates about updates to modals? (Other input options)

rigid haven
#

discord.js can only add features that discord has implemented, and they have not implemented that

brisk elbow
#

I know that, I was only curious if you guys have any updates

rigid haven
cerulean charm
#

does discord.js support user-installable apps yet or in some version i can use them in?

keen bobcat
#

One of the PRs is merged, one is still waiting approval

cerulean charm
#

oh okay maybe it will be worth waiting for the second one

median viper
keen abyss
#

Update node nothing to do with the dev version

rigid haven
cerulean charm
ripe umbra
#

are user-app-commands supported in the current dev branch or not just yet

sinful heath
#

For @discordjs/builders, yes, but for mainlib discord.js, no

ripe umbra
#

thanks

ripe umbra
steel haven
#

For builders? Yes, dev build

ripe umbra
#

thanks

ripe umbra
plain roverBOT
ripe umbra
#

cheers

plain roverBOT
ripe umbra
#

thanks

#

Got it working! Thank you! 🙂, can now use bot Slash commands in dms and guilds

tame smelt
#

Should be, if the commands are deployed with proper installation contexts and bot app is installed to the user

cinder wraith
#

app and bot are distinct things, please don't mix them for clarity sake

#

especially in this case, where it is not possible at all for the app to come with its bot in such install

tame smelt
#

Yeah mb, force of habit soujiComf

inner slate
#

what is wrong in here?

await client.cluster.broadcastEval(async (c, context) => {
    // Import the necessary modules
    const Discord = require('discord.js');
    context.message = new Discord.EmbedBuilder(context.message);

    await c.users.cache.get(context.discordId).send({ embeds: [context.message] });
},  { 
        context: { discordId: discord_id, message: message },
        cluster: cluster
    }
);

Error [TypeError]: Cannot read properties of undefined (reading 'send')

sinful heath
#

The user is not cached. Use c.users.send(context.discordId, { embeds: [context.message] }) instead which doesn't rely on the user being cached. For future questions not pertaining specifically to the development version of discord.js packages, please see #how-to-get-help

plain roverBOT
inner slate
tame smelt
#

What would be the way to go about adding a method for fetching VoiceState (since it's now currently allowed over the REST API)? Obviously, DJS relies heavily on caches (which is also true for VoiceStateManager). Since it's possible to fetch VoiceState without the GUILD_VOICE_STATES intent, I think it wouldn't make sense to add the result from the fetch to the cache since it won't be updated if the application doesn't have the intent. So something like checking the cache and returning if it exists, if not, fetching from the API and returning that data (without adding it to the cache?)

steel haven
#

By adding a fetch() method both to VoiceStatesManager and VoiceState the same way those already exist for other structures and their managers

#

And yes, it should be added to the cache, the same way we do for fetched messages, members etc. independent of intents

tame smelt
#

Hmm, good to know. Thanks

proven jasper
#

I am not sure if it's the correct channel either, pardon me

idle galleon
#

Apparently the former includes where it’s inherited from

#

Def not intentional btw

proven jasper
#

Where's my reward dogeHaHa

ripe umbra
#

Is there an way to know if a user has authorised user commands with your app, like is there a check you can do

tame smelt
#

no

ripe umbra
#

ok thanks

dull mulchBOT
steel haven
tame smelt
#

@hoary fox regarding your comment here, there is in core (getVoiceState). Or are you talking about something along the lines of fetchMe for VoiceStateManager or simply @me in fetch params ?

meager crag
#

@tawdry mantle do you think it's worth considering closing #10358 without depending on a change to DT? I don't see this one getting resolved, particularly not the static methods element

tawdry mantle
#

We have thoughts yes. Mostly switching to AEE like the rest of our packages

meager crag
#

yeah, I was going to make the point that using EE generics would be a regression anyway for anyone who hadn't got that far with updating @types/node, since the type parameter was only added about five months ago

#

at least AEE is something you have control over

tawdry mantle
#

you can even use AEE in nodes static methods

meager crag
#

it's nice that they implemented those agnostically

tawdry mantle
#

Would've been really nice if EventEmitterConstructor was an interface like many of the other _Constructor ones

meager crag
#

well the irony is that iirc EE isn't even a class in its current implementation

tawdry mantle
#

it's an interface, then an interface + class

meager crag
#

I mean in JS-land

tawdry mantle
#

oh

#

yeah probably

meager crag
#

I believe it's just a constructable function

tawdry mantle
#

that would be correct

image.png
inner slate
#

hey, Im using discord.js in dev version I keep getting this error:

                ^
TypeError [Error]: Cannot read properties of undefined (reading 'sessionInfo')
    at WebSocketManager.<anonymous> (/home/container/node_modules/discord.js/src/client/websocket/WebSocketManager.js:268:17)
#

these are my overrides

  "overrides": {
    "@discordjs/builders": "dev",
    "@discordjs/collection": "dev",
    "@discordjs/formatters": "dev",
    "@discordjs/rest": "dev",
    "@discordjs/util": "dev",
    "@discordjs/ws": "dev"
  },
#

FIX
Remove "@discordjs/ws": "dev" override in your package.json

dull mulchBOT
meager crag
olive tundra
#

^^^The one from Developers Application

dull mulchBOT
plain roverBOT
#

discord Users Resource
Users in Discord are generally considered the base entity. Users can spawn across the entire platform, be members of
read more

cinder wraith
glossy gyro
steel haven
glossy gyro
proven jasper
cursive venture
#

i believe they are on the BuilderButtonComponent class

proven jasper
#

Found it
What does the ButtonBuilder one do then

#

Also, that duplicate items problem hasn't yet gone

haughty sorrel
haughty sorrel
#

I guess some workflow hasn't been run since then or something, @steel haven?

#

Can you also show what duplicate items you're talking about?

steel haven
steel haven
proven jasper
steel haven
proven jasper
#

That's all I know of

steel haven
proven jasper
#

Also, off topic, did you forgive me?

#

Main doesn't have it now

lusty wind
#

Is there a documentation for the dev version?

sinful heath
#

Yes, simply select "main" in the version dropdown on the lefthand side of the docs page

lusty wind
#

Does it appear in the mobile version?

#

nvm, I'm blind

lusty wind
#

client.application.emojis.cache is empty.
How do I get an application emoji by name?

#

Hm, I have an idea

steel haven
lusty wind
lusty wind
steel haven
#

Same as for guild emoji. Fetch all, then .find on the collection

lusty wind
#

thanks for the help anyway

barren portal
#

Do Application Emojis get cached on startup or do I have to fetch them myself first?

tame smelt
#

Considering it doesn't arrive through gateway, i'd imagine you have to fetch them

topaz loom
#

Hi how do you install the development version of discord js ??

#

nvm found it

#

npm i discord.js@dev

sterile pilot
#

How is this done?

image.png
cinder wraith
#

The status or the contents?

#

Although, this is not related to the dev version of discord.js

scarlet tangle
#

hello guys

rustic plinth
scarlet tangle
#

I was just saying hello

steel haven
rigid haven
analog ocean
#

👋🏼👋🏼

zealous otter
#

i cant see it well on mobile but it seems like its not nullable

rigid haven
#

no i think it's our fault

#

i thiink this is supposed to have all the same fields as an object from the api, but it doesn't rn
(/src/client/actions/MessgeReactionAdd.js L36)

image.png image.png
analog ocean
#

Good day. I watched the video ran all the steps.

I have two issues.
First is I get no pong back when I do ping.
And the step were you take the http and introduce it to the bot watcher to make sure it’s always on

I get no http

steel haven
#

There is no official video for djs. And this is the wrong channel for support of stable djs versions, this is only for the dev release. Use #djs-help-v14 or ask the content creator that made the video you refer to

analog ocean
#

Thank you

sweet flare
#

You should consider migrating to TS it's a ton of work ik but in the long run it'll be easier to maintain your project rather than having JS and a massive unwieldy 7000 line typings file

knotty plover
#

Most of the modules have already migrated across and we'll do the main lib eventually

#

Then we can finally spend all our time maintaining a precarious chain of TS build dependencies ready to break at a moment's notice rather than our code

errant idol
#

can't we set [Guilds] as default intents when intents isn't specified? or is djs supposed to not provide extra help at all with interacting with the dapi

steel haven
#

Why would we? If someone doesn’t want Guilds intent they shouldn’t get it. We‘re an API wrapper and let the user do what they want. Not our job to make sure the user knows what they want

sweet flare
#

I'm not a huge fan of every single SlashCommandOption type being it's own import. What was stopping you from simply having one SlashCommandOption and specifying the type in a type property? It seems like the only ones with actually differing methods are Number, Integer, and String.

steel haven
#

Where would you import them separately? If you want to specify them without distinction you can also just use raw json

sweet flare
#

You will have to import multiple if a slash command takes multiple options of different type. (It's not a huge deal but it does make the imports very long)

steel haven
#

No you don’t, if you use the arrow function shorthands

#

SlashCommandBuilder suffices as import then

silent hedge
#

that's like 3 exceptions immediately

#

some of which were added later on/not at the release of the feature API-wise

#

if "many imports" is the concern here, I think you have your priorities wrong, and even then, as pointed out, the interface lets you pass in a callback which makes us construct one for you internally

steel haven
#

Not to mention that channel also has special methods. And so do subcommandgroup and subcommand. Which leaves us with less options that have the same properties/methods compared to those that don’t

sweet flare
#

You could handle differing methods at least typing wise using conditional types based on the type property.

I don't really like the arrow function syntax of building commands, I find it confusing, I build my commands like lego bricks like this:

const userOption = new SlashCommandMentionableOption()
    .setName("user")
    .setDescription("User")
            
const subcommand = new SlashCommandSubcommandBuilder()
    .setName("subcommand")
    .setDescription("description")
    .addMentionableOption(userOption)

const slashCommand = new SlashCommandBuilder()
    .setName("base command")
    .setDescription("description")
    .addSubcommand(subcommand)
    .toJSON()
#

I would prefer to have a single SlashCommandOption and use something like .setType("mentionable") or pass the type to constructor

steel haven
#

What’s the use of builders to you here? Compared to just using typed JSON?

sweet flare
#

How do I use json? I am using the builders because that was documented in the guide

silent hedge
#

you think conditional types are less confusing than.. a callback?

sweet flare
#

I mean, for you the implementation will be a bit more complicated. But for users using the library, I find it a lot quicker than having to import every type you need

steel haven
#

No, you just refuse to use the easy way

cinder wraith
#

VSC has auto imports, btw

silent hedge
#

yeah sorry, under specific use cases what you're proposing with "conditional types" is infinitely more complicated and whenever we've done something like this we've regretted it later even if it seemed like a good idea at first glance

cinder wraith
#

And you can always import * and your argument about import count falls apart, really

silent hedge
#

while your concern with "it's a lot of imports" has a solution already there that's super simple, but you just think it's "confusing" meguFace

#

if you still want to "build your stuff like legos" then.. make the callback a separate variable and pass it as a parameter, but then you're back to importing, just only as a type :^)

steel haven
#

And new SlashCommandOption(SlashCommandOptionType.User) doesn’t sound easier to anyone compared to new SlashCommandUserOption()

sweet flare
#

It does for me. It lets me quickly copy over the code to a different command and quickly change the types without bothering with different imports.

I feel like the complexity is being overblown as well. It's just changing a type, only like three types have like 2 extra methods. You are copying the same code over to so many classes, and generally isn't a good practice to repeat yourself.

haughty sorrel
#

You don't need to import every type if you add them like this and those subcommand and option will be typed properly

const slashCommand = new SlashCommandBuilder()
    .setName("base command")
    .setDescription("description")
    .addSubcommand(subcommand => subcommand.setName("subcommand")
        .setDescription("description")
        .addMentionableOption(option => option.setName("user").setDescription("User")))
    .toJSON()
steel haven
sweet flare
steel haven
steel haven
#

Nothing against your feedback, but there have been many discussions and RFCs on builders design over the year. Maybe look into them and then (if you still think your feedback after being here for two weeks is valuable) make an issue on GitHub telling us about the gains of your approach over the current one and how it achieves everything that was requested in the RFC

sweet flare
#

Well you actually already did most of the work with combining them with that mixin, but it isn't pushed to users that will have to import each of these different classes manually

steel haven
#

Read up. All about that statement of yours has been said already. It‘s a non-issue

silent hedge
#

I think this conversation has ran its course already, you don't have a compelling argument for your suggested changes. I'd advise learning a little about code maintainability and things like that before chiming in on library design in the future ^^

sweet flare
#

I still don't see how it is easier to have

import {SlashCommandStringOption, SlashCommandChannelOption, SlashCommandBooleanOption, SlashCommandMentionableOption, SlashCommandRoleOption, SlashCommandAttachmentOption} from "discord.js"

..rather than

import {SlashCommandOption} from "discord.js"

This is about the ease of use when adding slash commands to my bot. Plus it makes the code look better, the current really long imports don't look that great.

steel haven
#

Let me make it clearer to you then: this discussion is over. blobstop
This channel is for help with the in-dev version of discord.js. None of what you said was about that in the first place

sweet flare
#

Can you at least export a helper class? Like SlashCommandOption that takes the type in constructor and it returns the appropriate option class.

silent hedge
#

no

sweet flare
#

Fine. I'll do it in my code then. If I feel like it i'll make a pr and hope the people on github have a different opinion.

jade harness
keen bobcat
#

please read a conversation full before commenting, especially as this one has been concluded

sweet flare
#

I have an issue with your linter, it makes the spacing look bad

Screenshot_2024-09-06_at_6.29.02_PM.png
boreal knot
#

I have an issue with your pyramid, it should be back in Egypt. Mappings like those should be done either via an intermediary interface with a fallback to never or reconsidered via unions that can be infered from a constant value

meager crag
#

yo dawg, I heard you like conditionals, so we put conditionals in your conditionals

sweet flare
#

Ok I split into union types. If anyone wants to discuss this further you can do it in the pr I opened.

rigid haven
cinder wraith
still crater
#

Is there a reason why guild.channels.fetch(id) is nullable but the function throws a DiscordAPIError when the channel could not be found?

idle galleon
sweet flare
#

I think you should get rid of AttachmentBuilder and EmbedBuilder and just have Attachment and Embed. The way things are now, all the getters are in eg. Embed and the setters are in EmbedBuilder and it feels... unnecessary? It's simpler to join the classes and neither of them are interactions like the rest of the "builders".

twilit bobcat
cinder wraith
#

we've been over this several times already

#

it is not simpler to join the classes

#

you cannot set a video in an embed you send

twilit bobcat
#

neither of them are interactions like the rest of the "builders"
I don't think builders (the package) is meant to be used only for interactions, it's called just "builders", not "interaction-builders" or something

sweet flare
twilit bobcat
#

that's a raw object

#

Embed is a wrapper around it with some utility methods and other wrappers inside of it

knotty plover
#

They used to be merged, that approach has several problems, we no longer do that anymore

#

Receiving a structure from the API is intended to be readonly, not something that is mutable

#

You can do EmbedBuilder.from(Embed) to create a structure that can be modified for sending

sweet flare
#

I still think you could merge them and have a .clone() method, when people want to edit a received embed (not a new one) they can use embed.clone().setX(..)

cinder wraith
sweet flare
#

You handle the state of whether it's readonly in the class. In typescript, it'll probably be Embed<false> and Embed<true> if it's editable

cinder wraith
#

hm?

#

that sounds... awful

knotty plover
#

Please no more generics they're so awful

idle galleon
#

Embed isn’t supposed to be editable tho?

#

Yea, I prefer to keep them separate

#

Make it clear that you shouldn’t be editing stuff directly from the Message

sweet flare
#

You could throw an error when they try to edit when it's not set to editable, that's what I meant by handling readonly state. Alternatively, I would also prefer renaming embed to something like RawEmbed and make EmbedBuilder the Embed class.

cinder wraith
#

RawEmbed? but it isn't raw object, that's APIEmbed already

#

and also renaming (for like 5th back-and-forth now) EmbedBuilder to Embed suddenly makes a builder that isn't named a builder

sweet flare
#

Is EmbedBuilder really a builder? When I think of the builders they all have multiple levels of nesting eg. you have to attach button to an action row, or text input to an action row to a modal, but an embed is only a single level. I think it's just a class with .set() methods, not a builder.

keen bobcat
#

you attach fields or description or thumbnail or image or or or... just like with a slash command builder, you attach a name, a description, an option

cinder wraith
#

we are not going to turn EmbedBuilder into a "proper" builder with a MessagePayloadBuilder you'd .setContent().addEmbeds() to

#

and yes, you just described a builder

#

just because you happen to need to use a ButtonBuilder with ActionRowBuilder doesn't change what ButtonBuilder does (which also happens to only have a few set()s, making your attempted distinction here mostly useless)

knotty plover
#

I dont mean for this to be combative or antagonistic, but you seem quite intent on making what amounts to fairly small changes for personal preference. I don't see these things as delivering significant value or enhancement to the library.

A suggestion to rename a class is actually hugely disruptive - we've done it before, probably a little too often, and every time we do in a major version update people HATE us for it because of how much editing and renaming is required in their code.

#

Im curious as to why you feel these changes are so important

twilit bobcat
#

though you aren't mentioning the .build() method, probably the most important part of a builder, and what makes it a builder in the first place

#

it isn't just a mutable object ("a class with .set() methods"), it's meant to "build" another complex object, an api embed

cinder wraith
#

we have .toJSON() that accomplishes the functionality of .build()

twilit bobcat
#

oh yeah, that, forgot the naming

cinder wraith
#

which is called internally in places, that's why there's a type for it

twilit bobcat
#

I also think it the package could be improved in some places, eg I wish there was a way to clone every builder (not all of them accept data in their constructors), but what you're describing was already a thing and it was confusing for some users, for instance people were trying to mutate messages received from the api and expected that to edit the message

#

making it throw an error would be confusing as well, why would it have those methods then? pretty sure it breaks the liskov substitution principle

sweet flare
#

Ok just forget it.

cinder wraith
#

(not all of them accept data in their constructors)
isn't that what the .from() static is for?

twilit bobcat
#

not all of them have that either, I think only the component builders do (which makes sense, since you do get components from the api a lot)

#

I'm specifically thinking about the command ones

cinder wraith
#

but from the looks of it

#

only the discord.js's EmbedBuilder adds the .from()

image.png
#

the one in /builders doesn't have that (but then it takes data in constructor anyway)

twilit bobcat
#

yeah but command builders don't take data nor have a from method, so there's pretty much no way other than doing the copy manually

#

which is a workaround, but not the best lol

keen bobcat
#

Why would you need to copy a command? Thonk

cinder wraith
#

might have fetched it

silent hedge
zealous otter
#

every time you get a merge issue on pnpm-lock.yaml, just run pnpm i. It'll solve itself
am i doing it wrong chat

image.png
forest elm
#

that's not pnpm-lock.yaml

zealous otter
#

o true i cant read

twilit bobcat
# keen bobcat Why would you need to copy a command? <:Thonk:264701195573133315>

it was a niche use case which is why I didn't make a pr or opened an issue about it, I was writing my command serialization and I wanted to automatically fill subcommands (each subcommand was a class with its own data property, which was a subcommand builder), problem is if I make the command builder a property then subcommands will be added every time through serialization since there isn't a setSubCommands() either, so one solution was to clone it

#

I just made it a method in the end, which did the work

twilit bobcat
sweet flare
#

What is the point of fetchReply? Why would I want to receive an uncached message
I also needed to patch this up.

// @ts-expect-error
interaction.reply = ((originalReply) => {
    return function (options: InteractionReplyOptions) {
        if (typeof options === "string") options = {content: options}
        return originalReply.call(this, {fetchReply: true, ...options})
    }
})(interaction.reply)
knotty plover
#

I don't quite understand your question. The point of it is because until very recently the Discord API for responding to an interaction didn't return the message, and it had to be fetched manually if you wanted the reference to it

#

Which many people did, to mimic the behaviour of channel.send

#

I'm not sure when you'd be receiving an uncached message

dawn phoenix
knotty plover
#

Yeah, and it's still behind an additional parameter

#

Which we'll move to support instead of fetchReply, but at the time this was the only way to get it

sweet flare
dawn phoenix
#

ah, i see, looking at the code we do indeed not do the query param there nod

#

you do get the contents, because you authored it

knotty plover
#

You mean, you always want it to return the message? Instead of the default behaviour which is false?

We don't implement defaults that incur additional API calls. That behaviour should be up to the developer

#

That would be an additional request and latency on every single reply for everyone who doesn't want that

sweet flare
#

I almost always want it to be true. That's why I patched it

knotty plover
#

Okay, great

#

When we add support for with_response we'll reconsider the default behaviour

knotty plover
craggy iron
#

Hey
I am looking for someone who has knowledge about discord.js
Please DM me its urgent

knotty plover
craggy iron
#

okok

sweet flare
#

I noticed a few names are not grammatically correct.
PermissionFlagsBits -> Should be PermissionFlagBits
PermissionsBitField -> Should be PermissionBitField
PermissionsString -> Should be PermissionString

rigid haven
#

personally, i think it's more important to be consistent throughout the library. do other bits/bitfields use singular or plural?

sweet flare
#

Most use singular Permission

#

As for the first one I just think two plurals one after the other sounds awkward.

keen bobcat
#

"permission flags" and "permissions" refer to something that can contain multiple of them (multiple bits, multiple flags)

sinful helm
dark light
#

to be fair it is incorrect and i think basing the validity of a change on its size is not the right way to go

#

but like cobalt said, what matters is how other bitfields handle it and go with that

cinder wraith
#

These are the other BitFields we have, and all of them use plural - xFlags and Intents

image.png
#

The only one of the 3 originally mentioned that I could probably get behind is the PermissionString, as for me it looks like library refers to things that are multiple (be it as a Collection/Array or a BitField) with plural, while PermissionsString is a keyof typeof PermissionFlagsBits, meaning it's technically a single string out of some specified ones.

sweet flare
#

The only other thing I know that uses bits is GatewayIntentBits and that uses a singular before the bits. It's not GatewayIntentsBits

twilit bobcat
# sweet flare The only other thing I know that uses bits is `GatewayIntentBits` and that uses ...
  • PermissionFlagsBits: bits of permission flags, flags are also commonly used as plural when talking about bitfields since they aren't really used by themselves, they'll pretty much always used in group
  • PermissionsBitField: a bitfield representing multiple permissions, I think it's clearer in plural because it conveys the idea that the single bitfield represents multiple permissions, not that one bitfield is used for one permission (PermissionBitField)
  • PermissionsString: I do kind of agree with it as well, since it does only represent one permission, not multiple
keen abyss
scarlet mortar
tender flame
#

RequestAbortedError [AbortError]: Request aborted
discord.js v14.13.0
it appeared when i was try to a command

image.png
#

like this cmd

image.png
knotty plover
#

v14.13 is definitely not the dev version

tender flame
knotty plover
tender flame
knotty plover
#

Its the still-in-development version, which may contain code that hasn't been prepared for a specific release yet

#

May be more unstable than regular versions

tender flame
#

sorry dude

#

wrong room

meager crag
twilit bobcat
pulsar jacinth
twilit bobcat
#

yeah I was mentioning it here just in case I could open a pr for it, but upon thinking about it I think it'd also require updating the MessageUpdate action and I don't want to mess with that lol

#

I'll just open an issue

steel haven
twilit bobcat
#

well I guess it doesn't need to since it'd never be a partial, but wouldn't it be ideal?

steel haven
#

there's nothing to change there. what do you mean? the oldMessage can still be partial, new message is the patch of old message and won't be partial. JS land behavior is already correct. only the ts type for the event isn't

twilit bobcat
#

I must've missunderstood how getMessage works then

steel haven
#

the whole notion of the type PartialMessage is ts only

twilit bobcat
#

I can just submit a pr for it if that's the case

steel haven
twilit bobcat
#

ah, that clears it

twilit bobcat
#

will builders v2 be in v14 or v15?

tame smelt
#

v15 obv, as it's breaking

twilit bobcat
#

yeah thought so, but wanted to ask just in case since it wasn't technically a djs change, but one of its packages

tame smelt
#

It's pinned at non-breaking version in the main lib, I imagine until v15 is out

steel haven
#

It will be re-exported and used internally in v15. But nothing stops you from using it in v14 as separate dependency. Just need to make sure to pass the .toJSON() results to djs functions then, not the builders themselves

tame smelt
#

is there any plan to rename NewsChannel to AnnouncementChannel to be more in line with api naming?

uncut kelp
#

@boreal knot^ maybe

boreal knot
tame smelt
#

I have something ready that I can open a pr for, if it is in the plan that is

rain bramble
#

Why not. discord-api-types already did

uncut kelp
#

I'd say just open it and we'll see what happens

tame smelt
#

Okay

queen ore
cinder wraith
#

if you meant released, well, no clue

queen ore
#

I meant release

keen bobcat
#

The library does not do deadlines or ETAs for releases

zealous otter
#

@uncut kelp real quick , how did you fix my messed up rebase last time? i have tried rebasing two different ways and i have messed it up again ^_^

uncut kelp
#

I went back to a prior commit (so the bad stuff wasn't here locally) and rebased again

#

Are you rebasing with your fork's main? If so, it's not up to date. That could be why you're messing up

zealous otter
zealous otter
#

i am missing something because if i try to rebase it just fast forwards and doesn't let me amend anything

silent hedge
zealous otter
#

yep

silent hedge
#

what did you run

#

i guess you did it

#

if thats the state of the pr you want

zealous otter
#

it just diverged the history to where i wanted at one point so i cherry picked the commits back in 😭 overall major skill issue

silent hedge
#

now, make sure your upstream points to discordjs/discord.js

git fetch upstream
git rebase upstream/main

#

nothing else

zealous otter
#

swear i rebased how i did in the past 😔

#

ok thanks for the help gang

#

hypothetically if ci failed for something unaffected by my PR is there anything i should do

silent hedge
#

yes. cry

zealous otter
#

oh ok

silent hedge
#

waiting for the re-run

#

very strange failure either way considering main is fine

zealous otter
#

(it was builders)

silent hedge
#

yeah i saw

tame smelt
silent hedge
#

p sure you were looking wrong at the output

#

todo stuff does get output as warnings

#

you must've had some other error too

#

yeah your CI failed with an eslint error

#

its in the middle of the output, some line is longer than 121 max

#

pnpm format in the root should do it

tame smelt
#

No, I'm pretty sure it was something along the "unexpected todo comments", similar to the test fail...

silent hedge
#

nah, i make this mistake too

#

its like 5 todo warnings, 1 error in the middle and another 5 warnings sometimes

#

its hard to see

tame smelt
#

Hmm! Might have to get back to it then, when I get the chance

silent hedge
tame smelt
#

I think the line length might be it, will check it later and fix 👍

silent hedge
#

ye nws

zealous otter
#

oh ok now it's rest too

silent hedge
#

yeah that's just a bad I/O dependent test that fails sometimes

#

i reran it

#

and ok! back to that one

#

someone else can have a look or i will try to tonight, but im drained

#

likely tomorrow on my end

#

i suspect some weird branch state still, cus other PRs/main arent behaving this way

#

or maybe something w the vitest configs

#

it does seem like an outdated test after builders v2 but i cant tell why its only a problem now

zealous otter
#

seems that i shouldve deleted the lockfile after undoing all those bad rebase commits cause that was the issue for ci

#

ty for fix

silent hedge
#

oh makes sense

inner slate
#

Hey, I'm using dev version ^15.0.0-dev.1728475516-c36728a81
Everytime I try to start my app this error comes up:

TypeError [Error]: Class extends value undefined is not a constructor or null
    at Object.<anonymous> (C:\Users\Gh0st\Desktop\Projetcs\AuthenticateMe\V4\verification.js\node_modules\discord.js\src\structures\ButtonBuilder.js:12:29)

here are my overrides for discordjs

"@discordjs/builders": "dev",
"@discordjs/collection": "dev",
"@discordjs/formatters": "dev",
"@discordjs/rest": "dev",
"@discordjs/util": "dev",
"@discordjs/ws": "dev"

Any insights would be extremely helpful

knotty plover
#

I'm not sure discord.js has been updated to use the dev release of builders.

inner slate
knotty plover
#

Just... don't override builders

#

Though tbh Im not sure anyway

silent hedge
inner slate
silent hedge
#

thonk

#

you should open an issue

plain roverBOT
steel haven
inner slate
tame smelt
meager crag
#

Is there a Word of God regarding runtime parameter validation in Collection methods? In a lot of instances (eg. ensure(), equals()), the parameter types are checked at the start, either throwing a TypeError or short-circuiting. In many others, particularly methods expecting Collection arguments (eg. sort(), intersection()), there's no validation, and an invalid parameter will raise a runtime error at some point during execution.

twilit bobcat
#

pretty sure it should be in all methods, it'd look like they're missing

#

you could make a PR for it

#

djs also does runtime validation for instance

steel haven
#

Mainlib discord.js isn’t a typescript package though, so doesn’t relate. And equals doesn’t really check the type either (just checks if it‘s falsy).
And all methods expecting a function as parameter check for it being a function before trying to call it.