#@discordjs/builders

1757 messages · Page 2 of 2 (latest)

quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
#
almeidx
[discordjs/discord.js] Pull request opened: #10802 fix: message builders
  • Added clearParse, clearRoles, and clearUsers methods to the AllowedMentionsBuilder, since passing an empty array and omitting the these fields behave differently
  • Strictened assertions
  • Removed AttachmentBuilder#clearId, as it is a required field
  • Added missing MessageBuilder#setEmbeds
  • Added missing MessageReferenceBuilder#setFailIfNotExists
  • Improve/fix documentation
  • Consistency:tm:
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
#
Jiralite
[discordjs/discord.js] Pull request opened: #10805 fix(textInput): Value must be at least 1 character in length

Please describe the changes this PR makes and why it should be merged:
Will throw this error otherwise: data.components[1].components[0].value[BASE_TYPE_MIN_LENGTH]: Must be 1 or more in length.

Status and versioning classification:

  • Code changes have been tested against the Discord API, or there are no code changes
  • I know how to update typings and have done so, or typings don't need updating
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
#
Qjuh
[discordjs/discord.js] New review comment on pull request #10802: fix: message builders

On second thought this relies on the assumption that the passed function returns the same builder it gets passed. While that should normally the case we don‘t actually require it anywhere yet. If you create a new Builder inside the callback and return that it should work as intended, but wouldn’t with this change.
Same applies to all the other places this was done

quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
#
almeidx
[discordjs/discord.js] New review comment on pull request #10802: fix: message builders

you‘re now restricting people from returning stuff from the callback. Why?

It's an update function. If you want to create a new builder, use set

What’s the benefit?

Consistency

This seems to me like a classic example of „breaking change just because we can“

This is not released.

Especially since it‘s not consistent with the rest of the builders anymore

Every single update* function:

https://github.com/discordjs/discord.js/blob/abc5d99ce89bad64d0ad0d7d68310e61...

quartz atlasBOT
quartz atlasBOT
#
almeidx
[discordjs/discord.js] New branch created: docs/builders
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
winged compass
#

@discordjs/builders

quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
#
thorminate
[discordjs/discord.js] New comment on issue #11027: Add a .isEmpty() method to ContainerBuilders (may be applicable to other builders)

In what context would you not know what you have added? Can we see an example of where this would be useful?

i have this paginator which accepts an array of container snippets (functions which adds components to a container) if somehow, all of these would just leave the container blank after being assembled, it would not go too well for me.

also this shouldn't be that hard to implement, it just checks if the data.components array is empty.

quartz atlasBOT
#
thorminate
[discordjs/discord.js] Pull request opened: #11028 feat(ContainerBuilder): add isEmpty method

Please describe the changes this PR makes and why it should be merged:
Adds an isEmpty method to the ContainerBuilder class, which checks if the container has no child components.
This provides a simple way for developers to verify container state without manually inspecting its contents.

Status and versioning classification:

  • This PR changes the library's interface (methods or parameters added)
#
thorminate
[discordjs/discord.js] New comment on pull request #11028: feat(ContainerBuilder): add isEmpty method

I see your point — the method doesn’t expose new functionality beyond checking .components.length.
My intention was to provide a convenience/QoL helper for readability and to make the intent clearer in code (e.g., if (container.isEmpty()) reads more naturally than if (container.components.length === 0)).
That said, I understand if this doesn’t fit the library’s design philosophy, and I’m fine with closing the PR if you decide its unnecessary.

quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
#
DanieliusDev
[discordjs/discord.js] Issue opened: #11057 MessageContentBuilder - easily create message content with formatting

Which application or package is this feature request for?

builders

Feature

When creating message content, code can look very messy and possibly unclear. For example:

// this is a VERY simple example, code may be far larger than this with complex logic
interaction.reply(`${heading("Here is a list:")}\n${unorderedList(["something 1", "something 2"])}`);

Note: technically you could make a content variable and use += to make it easier to read (useful for conditiona...

quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
#
didinele
[discordjs/discord.js] New comment on pull request #11124: feat(builders): refinements

Maybe add a test case of a simple & useful scenario? That could be nice to see! Reason I ask is because the documentation given for refining doesn't seem to solve a problem?

Will do. But the idea is that when you have a large block of logic that does a lot of conditional work on a builder, it can feel a bit "disconnected" and other logic can sneak in the middle, you also can end up introducing a lot of variables.

With refine you can get rid of a lot of that:

<TextBasedChanne...
#
faceboy1392
[discordjs/discord.js] New review comment on pull request #11124: feat(builders): refinements

I proposed this idea originally in the "random convo", (and I think I first saw the idea somewhere else). The main reason is I just otherwise find it pretty inconvenient when I'm working with a long chain of builder method calls.

In my experience, it's sometimes annoying to conditionally modify the builder with external if statements and all that, rather than being able to put everything in one long expression. Especially when dealing with components nested inside other components/objects...

#
faceboy1392
[discordjs/discord.js] New comment on pull request #11124: feat(builders): refinements

I'd say it's a valuable addition.

Maybe add a test case of a simple & useful scenario? That could be nice to see! Reason I ask is because the documentation given for refining doesn't seem to solve a problem?

I proposed this idea originally in that "random convo", (and I think I first saw the idea somewhere else). The main reason is I just otherwise find it pretty inconvenient when I'm working with a long chain of builder method calls.

In my experience, it's sometimes annoying...

quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
#
Jiralite
[discordjs/discord.js] New comment on issue #11181: TextInputBuilder#setValue() no longer allows empty strings, but Discord API does

I cannot reproduce this on v14. Furthermore, your code example is incorrect also: text input builders must have a style. Ergo, I believe you are not actually supplying what you are doing.

Can you provide what you are actually doing? My testing (copied and pasted your code sample with style):

import {
  ModalBuilder,
  LabelBuilder,
  TextInputBuilder,
  TextInputStyle,
} from "discord.js";

const modal = new ModalBuilder()
  .setCustomId("some_custom_id")
  .setTitle("some tit...
#
CuteNikki
[discordjs/discord.js] New comment on issue #11181: TextInputBuilder#setValue() no longer allows empty strings, but Discord API does

@Jiralite i simplified my code sample. The code that I'm actually using looks like this:

export function getEvalModal(locale: string, depth: string | number, code?: string) {
  return new ModalBuilder()
    .setCustomId('eval')
    .setTitle(t('eval.modal.title', { lng: locale }))
    .addLabelComponents(
      new LabelBuilder().setLabel(t('eval.modal.code', { lng: locale })).setTextInputComponent(
        new TextInputBuilder()
          .setCustomId('code')
          .setPlaceholder...
#
CuteNikki
[discordjs/discord.js] New comment on issue #11181: TextInputBuilder#setValue() no longer allows empty strings, but Discord API does

Can you provide your full error? You also only supplied the first line. Can you send the whole stack trace (and never omit it)?

✖ Too small: expected string to have >=1 characters
  → at component.value
    err: {
      "type": "ValidationError",
      "message": "✖ Too small: expected string to have >=1 characters\n  → at component.value: [\n  {\n    \"origin\": \"string\",\n    \"code\": \"too_small\",\n    \"minimum\": 1,\n    \"inclusive\": true,\n    \"path\": [\n      \"component\...
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
#
didinele
[discordjs/discord.js] Issue opened: #11289 In multiple instances, builders just uses z.string() for Snowflakes

Which package is this bug report for?

builders

Issue description

One of many examples

https://github.com/discordjs/discord.js/blob/0b122633717bfa9f3a0ffe71a33c32f7afc319df/packages/builders/src/components/Assertions.ts#L67

Code sample

Versions

Current main branch of builders

Issue priority

Medium (should be fixed soon)

Which partials do you have configured?

Not applicable

Which gateway intents are you subscribing to?

Not applicable
...

quartz atlasBOT
#
rie03p
[discordjs/discord.js] Pull request opened: #11290 fix(builders): add proper snowflake validation

close #11289

Please describe the changes this PR makes and why it should be merged:

This PR adds proper Snowflake validation to the builders package. Previously, multiple instances were using plain z.string() for Snowflake IDs, which didn't validate that the values are numeric strings as required by Discord's Snowflake format.

Changes:

  • Added snowflakePredicate (z.string().regex(/^\d{17,20}$/)) to validate Snowflake format
  • Replaced z.string() with `snowflakePredica...
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
#
imnaiyar
[discordjs/discord.js] Issue opened: #11297 Wrong method usage in ContainerBuilder example

Which package is this bug report for?

builders

Issue description

https://discord.js.org/docs/packages/builders/1.13.0/ContainerBuilder:Class#constructor,
Here .addComponents is shown which doesn't exist

I didn't check if there are any other instances of this elsewhere too

Code sample

Versions

Not applicable

Issue priority

Low (slightly annoying)

Which partials do you have configured?

Not applicable

Which gateway intents are you subsc...

quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
#
didinele
[discordjs/discord.js] Issue opened: #11305 Investigate toJSON(validationOverride) callsites

Which application or package is this feature request for?

builders

Feature

In light of #11304, it's probably worth checking if we can easily similarly address all other places where the package behaves this way for the sake of consistency. It's OK if the outcome is that we leave some of them as-is, but internal sentiment is we should be moving to always toJSON(false)

Relevant investigation sites:

#
Jiralite
[discordjs/discord.js] Issue opened: #11309 Refactor chat input command subcommands overrides

Investigate whether the validation override can be changed to false.

https://github.com/discordjs/discord.js/blob/02fc101069aed994f7ee4579d114706047025ddd/packages/builders/src/interactions/commands/chatInput/ChatInputCommandSubcommands.ts#L77

https://github.com/discordjs/discord.js/blob/02fc101069aed994f7ee4579d114706047025ddd/packages/builders/src/interactions/commands/chatInput/ChatInputCommandSubcommands.ts#L110

quartz atlasBOT
quartz atlasBOT
#
almeidx
[discord.js] Branch refactor/validation-on-chatinputcommand was force-pushed to `18c8ae9`

Compare changes

#
almeidx
[discord.js] Branch refactor/validation-on-chatinputcommand was force-pushed to `4772957`

Compare changes

quartz atlasBOT
quartz atlasBOT
#
Jiralite
[discordjs/discord.js] New review comment on pull request #11290: fix(builders): add proper snowflake validation

It alters it because we're being strict on input: snowflakes for editing and numbers for uploading, which is the documented way.

Also you miss the point, the string "0" will work too

0 or "0", it's all stringified anyway:

https://github.com/discordjs/discord.js/blob/02fc101069aed994f7ee4579d114706047025ddd/packages/builders/src/messages/Attachment.ts#L151

Someone shouldn't be passing "0" though, right? That seems like a mistake...

quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
#
Exodo0
[discordjs/discord.js] Pull request opened: #11330 fix(builders): handle 0 as valid attachment ID

Description

Fixes #11314

AttachmentBuilder.getRawFile() was using a falsy check (this.data.id ? ...) to determine whether the attachment ID existed.
Because 0 is a valid ID but is falsy in JavaScript, the method incorrectly treated it as missing, producing an invalid file reference.

This PR updates the condition to properly detect the presence of the id property, allowing 0 to be handled correctly.

Changes

  • Replaced the falsy check this.data.id? ... with a pro...
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
#
Jiralite
[discordjs/discord.js] Pull request opened: #11338 fix(Message): Optional parameter for setting allowed mentions

Per the documentation, all keys are optional.[^1] This means {} should be an allowed value (and does work to prevent everything). To achieve this, you would have to do this:

const message = new MessageBuilder()
	.setContent('test')
	.setAllowedMentions((allowedMentions) => allowedMentions);

With this pull request, supplying nothing will default to {}:

const message = new MessageBuilder()
	.setContent('test')
	.setAllowedMentions();

[...

quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
#
almeidx
[discord.js] Branch refactor/validation-on-chatinputcommand was force-pushed to `3f449bc`

Compare changes

quartz atlasBOT
#
almeidx
[discord.js] Branch refactor/validation-on-chatinputcommand was force-pushed to `273547b`

Compare changes

quartz atlasBOT
quartz atlasBOT
#
yokkkoso
[discordjs/discord.js] Issue opened: #11370 Wrong minimal length for emoji name

Which package is this bug report for?

builders

Issue description

Currently minimal length for emoji name is 2 (https://github.com/discordjs/discord.js/blob/427636ee7555a92fa9780cd78f28cc0037b9241c/packages/builders/src/components/Assertions.ts#L8), but some emoji, like ✅ have 1 length, so if you try to use this emoji in buttons or other components, a validation error will appear.

Code sample

Versions

  • discord.js - 15.0.0-dev.1766016119-427...
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
#
Qjuh
[discordjs/discord.js] New comment on pull request #11291: fix(builders): improve component validation predicates

As far as I can see the main aspect of this PR has been done and merged by #11290 already. The change from check() to superRefine() is merely syntactical sugar (since superRefine calls check internally to do the exact same thing). So the only thing this really changes are the strictObject assertions, but I don't see what issue they fix, as that would only make it throw instead of stripping extraneous properties.

quartz atlasBOT
quartz atlasBOT
#
Qjuh
[discordjs/discord.js] New review comment on pull request #11410: feat(builders): add checkbox, checkboxgroup, and radiogroup builders

This shouldn't validate on addOptions call already, because then it'll throw as soon as you add options one by one, because having only one options is invalid. Same applies to checkbox group but less severe. But even there a builder should be allowed to be in a state where it has more or less options than allowed, as long as that changes before the builder gets turned into JSON.

quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
#
faceboy1392
[discordjs/discord.js] New review comment on pull request #11410: feat(builders): add checkbox, checkboxgroup, and radiogroup builders

I kinda refer to the whole set as "checkbox components", even if technically only two of them are actually checkboxes. I'm not really sure what else to call this group of components as a whole. I similarly have the five classes (3 components and 2 option types) in src/components/checkbox/, so the test file is named consistently with that folder. Should I rename the file/maybe split it up into 2-3 more precisely-named files?

quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
#
Dramex
[discordjs/discord.js] Pull request opened: #11498 feat(ContainerBuilder): support ColorResolvable in setAccentColor

Summary

  • Adds a small resolveColor helper to @discordjs/builders that accepts a raw integer, a #rrggbb hex string, or an [r, g, b] tuple. The semantics mirror resolveColor in the main discord.js package (both accept the same shapes and use the same range check).
  • ContainerBuilder#setAccentColor now routes through it, so users can do .setAccentColor('#00af89') or .setAccentColor([0, 175, 137]) in addition to raw integers.

Why

ContainerBuilder#setAccentColor previ...

#
Dramex
[discordjs/discord.js] New comment on pull request #11498: feat(ContainerBuilder): support ColorResolvable in setAccentColor

Good catch, this was a real bug. Verified all four cases in a REPL against the previous logic:

input previous result status
[0, 0, 300] 300 (0x12C) passed, wrong
[0, 256, 0] 65536 (0x10000) passed, wrong
[-1, 0, 0] -65536 caught by range check, but incidentally
[1.9, 0, 0] 65536 (1 << 16, truncated via <<) passed, wrong
[300, 0, 0] 19660800 caught by range check, but incidentally

Pushed a fix that vali...

#
Dramex
[discordjs/discord.js] New review comment on pull request #11498: feat(ContainerBuilder): support ColorResolvable in setAccentColor

Intentionally matching the existing style of the surrounding util/* imports in this file:

import { normalizeArray, type RestOrArray } from '../../util/normalizeArray';
import { resolveBuilder } from '../../util/resolveBuilder';
import { validate } from '../../util/validation';

Adding the .js extension here would make the new import the odd one out. Happy to switch if the maintainers want a separate pass normalizing every util import to .js, but that feels out of scope for this...

#
Dramex
[discordjs/discord.js] New review comment on pull request #11498: feat(ContainerBuilder): support ColorResolvable in setAccentColor

Intentionally scoped. The Colors enum, 'Random', and 'Default' all live in the main discord.js package (alongside the Colors map and DiscordjsError instances), which @discordjs/builders doesn't depend on. Pulling them in here would widen the builders package surface. The linked issue (#11496) specifically asks for hex-string / tuple parity, so the resolver targets that and leaves the richer alias set to the main package's own resolveColor. Happy to follow up with a doc note po...

quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
#
didinele
[discordjs/discord.js] New comment on pull request #11498: feat(ContainerBuilder): support ColorResolvable in setAccentColor

I'm not really sold on this. There's maybe an argument to be made about RGB tuples, since they're somewhat common in other graphics processing contexts, but I see pretty much absolutely no use in accepting #${string} - 0x prefix on number literals accomplishes the same thing, doesn't ask for parsing base 16 numbers, is as readable, and allows math out of the box in your own code for basic color transformations you might run on your own color constants/

quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
quartz atlasBOT
#
freepinkg
[discordjs/discord.js] Pull request opened: #11543 feat(builders): add ColorResolvable support to ContainerBuilder and EmbedBuilder

Summary

ContainerBuilder#setAccentColor and EmbedBuilder#setColor now accept ColorResolvable (number, hex string, RGB tuple, 'Random', 'Default') instead of only number, bringing consistency with the rest of the API.

Related Issue

Closes #11496

Changes

  • packages/builders/src/util/colors.ts — new module exporting ColorResolvable type and resolveColor() utility
  • packages/builders/src/components/v2/Container.ts — setAccentColor now accepts ColorResolvable and resolv...
quartz atlasBOT