#Website
1333 messages · Page 2 of 2 (latest)
Please describe the changes this PR makes and why it should be merged:
Removes several special treatments for the discord-api-types package in docs pipeline that are obsolete now that they are on the same website.
Status and versioning classification:
Please describe the changes this PR makes and why it should be merged:
Supersedes #8417
Introduces a generic structure implementation for the main lib (and others) to build on.
⚠️ This is currently in a very early proof of concept stage published as a PR to formulate ideas and solidify the intended structure (ha) of the module.
TODO:
- [ ] Application
- [ ] Audit Log
- [ ] Auto Moderation
- [ ] Channel
- [x] Channels
- [x] Mixins
- [x] DM
- [x] Guild
- [x] Text
- [...
*/
public override toString() {
return this.url ?? '';
Should this use the expiresAt and createdAt getters instead?
This is a utility getter of our own, to me it doesn't make sense to return an empty string here
return this.code ? `${RouteBases.invite}/${this.code}` : null;
export * from './mixins/index.js';
export * from './ForumTag.js';
export * from './PermissionOverwrite.js';
export * from './ThreadMetadata.js';
export * from './Channel.js';
export * from './AnnouncementChannel.js';
export * from './ChannelOwnerMixin.js';
export * from './ChannelParentMixin.js';
export * from './ChannelPermissionMixin.js';
export * from './ChannelPinMixin.js';
export * from './ChannelSlowmodeMixin.js';
export * from './ChannelTopicMixin.js';
export * from './ChannelWebhookMixin.js';
export * from './DMChannelMixin.js';
export * from './GuildChannelMixin.js';
export * from './TextChannelMixin.js';
export * from './ThreadChannelMixin.js';
export * from './ThreadOn...
/**
* @param data - The raw data received from the API for the connection
*/
public constructor(data: Omit<APIConnection, Omitted>) {
data.permission_overwrites = this.permissionOverwrites.map((overwrite) => overwrite.toJSON());
Facilitating bigints? 👀
return this.id ? DiscordSnowflake.timestampFrom(this.id as string) : null;
* @typeParam Omitted - Specify the properties that will not be stored in the raw data field as a union, implement via `DataTemplate`
Which application is this bug report for?
Documentation
Issue description
In line 346, there is a duplicated word in the line "Specifies whether the message should be written to the the tool's output log". Note that the comment contains a duplicated word “the the”.
Steps to Reproduce
- Visit https://github.com/discordjs/discord.js/blob/main/api-extractor.json.
- Search using Command/CTRL + F or jump to line 346 to visit the comment "Specifies whether the ...
c0415ef fix: background on pages with little content - almeidx
Fixes the background of the main content not occupying the entire screen on pages with little content, like:
db8c1d3 fix: background on pages with little content (#... - almeidx
The favicon.svg was actually just a base64 encoded PNG. It wasn't a proper useable/scalable SVG.
Built svg from the main logo
D.JS in the svg is 1/sqrt(2) * width and placed horizontally and vertically center.
Status and versioning classification:
This PR only includes non-code changes, like changes to documentation, README, etc.
I'm not convinced this is an improvement:
- this is a favicon, it won't ever show anywhere in a size were being scalable matters
- on mobile safari the new svg icon actually looks worse than the png (maybe because safari sucks at rendering SVG)
- on mobile safari the new svg icon actually looks worse than the png (maybe because safari sucks at rendering SVG)
Ah ok, nevermind then
Thanks for the review, closing this.
The svg can be useful to get high quality image.
<details>
<summary>like:</summary>
</details>
Which application is this bug report for?
Documentation
Issue description
The code example in the documentation uses import and top-level await:
import { REST, Routes } from 'discord.js';
await rest.put(...);
This throws a SyntaxError unless the project is set up as an ES module, either by:
-
Adding
"type": "module"in package.json, or -
Renaming the file extension to
.mjs
Even though the TOP they mentions "Node.js 22.12.0 or newer", that alone isn’t enoug...
As of version 22.7 node uses syntax detection and the example should run with a warning about re-parsing causing a performance overhead along with instructions on how to remove those [^1]. Accordingly, the recommended version 22.12.0 (though, really, people should generally use the recommended LTS) is beyond that point and should work as advertised.
(node:6378) [MODULE_TYPELESS_PACKAGE_JSON] Warning: Module type of file:///Users/user/Documents/test/index.js is not specified and it doesn'...
👋Thanks for the quick response!
I did some deeper testing with Node.js v22.16.0 and I wanted to clarify why the example still fails for me (and likely others too):
Although Node 22+ supports auto module detection with a warning, it still throws a fatal SyntaxError when import is used at the top of a .js file without either:
"type": "module"inpackage.json, or- using a
.mjsfile extension.
Even after adding a harmless line likeconsole.log()above theimport, Node shows th...
Can you please provide your setup, because I also cannot reproduce this. Can you find a source for your claims too?
I think your issue here is that you explicitly have "type": "commonjs" in your package.json.
@almostSouji @Jiralite @Qjuh @millette
Yes, you guys are absolutely right — my package.json had "type": "commonjs", and removing it resolved the issue.
But I’d still suggest updating the example with a short note, because:
When someone runs npm init -y, the generated package.json defaults to "type": "commonjs", which causes this example to fail with a SyntaxError.
So for most users, running the example as-is in a new Node project still won't work unless they:
- remove ...
I appreciate you updating the documentation to clarify the ESM requirement—it'll help avoid confusion for others too!
about half the files viewed, more to come later
Semantically, I think I'd prefer if we went with public here. Protected constructors feel a bit silly when the class is already abstract and requires extending.
public constructor(data: Readonly<Partial<DataType>>, ..._rest: unknown[]) {
perhaps I'm wrong, but I don't see us mutating this anywhere
protected readonly static DataTemplate: Record<string, unknown> = {};
or sorry, I forget which one our linter likes, might be
protected static readonly DataTemplate: Record<string, unknown> = {};
So, are we going to stick with _ prefixes for private/protected methods? As far as I know, none of the new codebases really do this (and if some do, we should agree on something and stick to it everywhere)
Why not abstract? So classes that don't have any work to do here don't need to implement? Not sure I love that, we could go this route instead if we want to avoid empty implementations everywhere:
protected _optimizeData?(_data: Partial<DataType>): void;
and calls do this._optimizeData.?(); (kMixinConstruct also follows this pattern)
(notice the lack of an abstract keyword, that actually requires explicitly specifying it in the subclass even if you don't want...
static properties can't use the generic, as it's only present on instances, not the class itself.
This method gets defined/overridden in the Mixin process. Making it optional instead of an empty function body would mean that every implementation of a Structure would have to do the optional chaining of that method call in their constructor. kMixinConstruct works completely different, as it's not a method that gets overridden but instead all of them get combined into a single function that gets called in the Structure base class here if present. Implementers don't need to worry about th...
Right. That's quite annoying. Anyone else have ideas on how to improve the safety here?
alright, I'm split on it then; up to others
Ideally substructures (which objects as properties technically are) would be cloned in their _toJSON() applied after this in the Mixin. When that happens the structuredClone of that object would be completely replaced/overwritten again and we have unneeded overhead. So the real question is if we want to rely on implementation always overriding in Mixin or extended class if there are substructures or if we want to go the safe (but less performant) route of always deep cloning (structuredCl...
If that's the design pattern we're opting for and we can accomplish this without structuredClone, then I think with some decent unit test coverage we can afford going the the override route
Maybe inspire from @sapphire/bitfield and make the enum be passed in? But then we'd basically have a factory of bitfields 🫠...
You're right, only @discordjs/voice does and only for private methods, and even there it's probably more historic reasons and not a current decision. Will remove the prefix.
Just realized that the _toJSON() pattern in the mixins need a slight adjustment to get it in line with [kMixinConstruct] and the omission of the _ prefix on protected methods.
What if we also make these symbols instead of strings? Just a thought, not a request
Confused about the todo and why we don't just do APIChannel & { type: Type }
pro tip: you can define ['constructor']: typeof BitField<Flags, Type> on the class level to skip all this casting, or make a getter function for it (https://www.typescriptlang.org/play/?#code/MYGwhgzhAECiAeYC2AHEBTAPAdQPYHdp14AXdAOwBMYByMG6AH2hoCMaA+aAbwCgBISulBgATumgQSYEgEtgRRKgwAFUbhQAuaCVEBXdAG5eAoSPHQA2jWC5yU-cBK5RNALraSATxTpcAMzglNCw8fA5jU2FwC29fSgA1MBADbTDI-n89cgAKAEoeAX5ZQJySAAtZCAA6OPRE5INoAF5WlnoCvn5uiqrq23tdPScXauJkELUNIv4AelnoRaXllYA9AH4igF8TbvnoAEEQMlFyGVkAN3Rd-l6akdEx4NV1FCL9la...
Nit 2: emails need to update from other pkgs
If this becomes a common check, please make a typeguard function for this and reuse it
function isIdSet(id: unknown): id is string | bigint {
return typeof id === 'string' || typeof id === 'bigint';
}
protected static override DefaultBit = 0n;
Circling back to this, I'm starting to lean more towards using symbols for all internal functions (even patch) but I'm not fully set to just doing that... discussion needed
Well, I was going to initially say, is there a reason why we want numbers at all? Is the BigInt overhead that big for numbers that would fit in number anyway?
I'm not big on this at all. Is there a good reason why we'd want to do this? Even with the properties I'm a little iffy, I think that's a justified evil because you can't have #members accessible in child classes
I'm a big fan of sapphire/bitfield 😅, if we can accustom our users to it (and it doesn't make some sort of abstraction very difficult), I personally wouldn't be against just using it in our stuff.
This works nicely for properties, but fails on new this.constructor(...) because BitField is abstract. Any ideas for those cases too? (https://www.typescriptlang.org/play/?ssl=23&ssc=1&pln=24&pc=1#code/IYIwzgLgTsDGEAJYBthjAgogD2AWwAdkBTAHgHUB7AdwWOwmIDsATDAcmHYQB8F2Q7AHwIA3gCgAkC2IpgUYgkjAIAS1h1chEgAUolAgC4E0AK7EA3OKky5ChAG12sSk0hRT8SlHYBdYxAAngTElABmWFpEZFTUQlY2sqj2QSEsAGrAyObGsQmSYaZMABQAlGJSkqoRxRAAFqpgAHSpxBlZ5ggAvD38XOUSkkP1jU0ubmZeUE30+NF6BpWSAPTLCOsbm1sAegD8lQC+1kOrCACCyIxQTCqqAG7E...
I'm confused too, hence the "find out why". But I assume it is because APIPublicThreadChannel etc. are types and not interfaces. Will try something and maybe PR another dtypes if that's the issue.
as standalone function in utils/ you mean?
We do need a way to know how to JSONify it (as string or number). If it's not based on type of the bitfield property then we need to store that information separately.
Initially I came up with
type NonAbstract<Constructor> = Constructor extends abstract new (...args: infer Args) => infer Instance ? new (...args: Args) => Instance : never;
but that got rid of static props, but with some tweaking I got this:
https://www.typescriptlang.org/play/?#code/C4TwDgpgBAcg9gOwIICMDOwBOBDAxsAHgBUoIAPYCBAEzSm3Sz2CgQgHcoAKAOj+0wBzNAC56CEAEooAXgB84kApkAoKFBLlKNOgww58rDtz48BwsQEsEAMwiYoSIWmnyo1uw4CSCDNgS4EGrqUAD83GycvPzOYk7Crgo+fgEQ0gBkUAAKlrgA1sQANFB5ECBw...
Imho the main advantage of having them be symbols is to not accidentally have an actual property on a structure that has the same name. So it makes sense to use symbols for anything we only use internally (here and in mainlib). But as soon as we want end users to also use it (which is the case for DataTemplate and optimizeData afaict) they shouldn't be symbols.
Also needs adding on the step "Build docs with main api-extractor" above.
_patch is a specific case because some structures do benefit from having a patch() method that is essentially a direct call to the associated patch route
If that's the intention then naming it _patch() while allowing a patch() is a horrible approach imho, as that leads to bad maintainability, as those two are easily confusable.
worthy of note that it is entirely possible to have references when you are not constructing sub-structures, when you are, that data is theoretically not even present in kData anymore (to avoid double-cache)
I'm open for any way to do this here. The current implementation is just a 1:1 port of current mainlib BitField and its manual typings.
So we should structuredClone() after all?
Yeah I'm not a huge fan of this not having the _ prefix, it's public everywhere else because it has to be called outside of the structures by the caching library but really isn't meant to be called by the end consumer. It's workable but I'd suggest one of the following
- Leave it protected everywhere else and force <Structure>['patch']
- Revert to _patch
The default is to omit these from raw data and optimize them instead
export class Invite<Omitted extends keyof APIActualInvite | '' = 'created_at' | 'expires_at'> extends Structure<APIActualInvite, Omitted> {
I appreciate notating like this, and we should definitely do it.
I had wondered if maybe there should be a little bit more of a write up in this package's readme about a couple of the intracacies like this (and to help indicate it's not meant for direct use in most cases?)
That's embarrassing....
"Chai Kohen <[email protected]>"
This may technically be under caching but also ditto to having this not be in something we don't get to use in mainlib
I'd say it makes sense to but only in cases where we need to? The problem is detecting that, it's still faster than just blindly strucutredCloning to check through values, but I don't love it
I don't see why we shouldn't use sapphire if it has what we want, haven't looked into it but this is part of a rather large changeset so as long as it's close we can notate the minor differences in the upgrade guide
But what would be the correct ChannelDataType for that 'unknown' then? Because dtypes won't allow an unknown type in the generic of APIChannelBase<T> which would be the best fit imho
APIPartialChannel I guess, the only thing different is the type guarantee and flags....and given that you have to skirt type safety on this anyways it's probably fine?
protected clone(patchPayload?: Readonly<Partial<DataType>> = {}): typeof this {
export * from './AppliedTagsMixin.js';
export * from './ChannelOwnerMixin.js';
export * from './DMChannelMixin.js';
export * from './GroupDMMixin.js';
This is the only mixin that has omitted, I can't remember if it actually is necessary to have it in the mixins or not.
export class ThreadMetadata<Omitted extends keyof APIThreadMetadata | '' = 'archive_timestamp' | 'create_timestamp'> extends Structure<
APIThreadMetadata,
Omitted
> {
It was kept as _patch because of https://github.com/discordjs/discord.js/pull/10900#discussion_r2173485976 as it is public in other classes so it needs another indicator of not being intended for end user usage.
though I will mention, I don't have a lot of thoughts on the structures themselves. at a glance, things seem OK.
Looks pretty good as a starting point. There's probably a few things we'll discover as we develop the rest of the module but it will be easier to deal with in smaller PRs from this point.
Instead of "1", can we reference VideoQualityMode.Auto?
#10738
{ message = "^types", group = "Typings"},
Why is this here? Surely it's not true by default?
How come this is {@link discord-api-types/v10#PermissionFlagsBits.ManageThreads} but line 83 in packages/structures/src/channels/ThreadMetadata.ts has {@link PermissionFlagsBits.ManageThreads}? I assume one of them is wrong.
Website
Shouldn't these assertions be this is this & MixInClass? Cause otherwise won't TS narrow the type to ONLY those properties?
Do you need the NonAbstract type at all?
Might as well
`Cannot convert bitfield value ${this.bitfield} to number, as it is bigger than ${Number.MAX_SAFE_INTEGER}`,
s/discord/Discord in comments
Cloning every time the getter is called sounds like a side effect that should
- be removed
- be documented
So I'll open the wound again. What do we think about making all of these methods (excluding toJSON) symbols? I can esp think clone() could at some point be used to represent something else other than the re-create this class?
What's the motivation for that? This is meant to be used by the end-user to allow them to remove unwanted properties from the structure
At first glance making it a symbol only seems to make it more obscure and potentially harder to use
For an uninformed user that will just look like a "random" number though...
While as it is currently, it shows them where the value comes from.
How about both? bigger than ${Number.MAX_SAFE_INTEGER} (the maximum safe integer)?
The point is this isn't for users to just define unless they know what they're doing... I mean this ties into https://github.com/discordjs/discord.js/pull/10900#discussion_r2181068448
* The ids of the set of tags that have been applied to a thread in a {@link (ForumChannel:class)} or a {@link (MediaChannel:class)}.
Yes, else new this.constructor(...) errors because can't instantiate abstract classes.
the _patch() maybe could/should be a symbol now with all the reasoning for protected/public and _ prefix shenanigans. For clone() I'm indifferent. To me Class#clone() should always re-create the class, anything else would be counter-intuitive for anyone using it (and in other OOP languages even is enforced to do so) so I don't quite get what you're thinkinh of there.
The one defined here. APIInvite but with all additional properties of APIExtendedInvite as optional.
The intention here was that Structures should not be mutable. Unless I'm confused returning the array directly would mean the user could mutate it. I'm fine with changing it either way you deem appropriate though.
Tried applying that change, but this causes an OOM error on running tsc, probably because the this reference in the typeguard makes it quirky in the mixins. This might need some more thought, happy if someone has an idea how to do it correctly without v8 (apparently) running into an endless recursion loop. Or if this even is a typescript bug and shouldn't happen in the first place
Good news: it's not an infinite recursion
bad news: with more than 5 of these typeguards v8 reaches its limits on my M2 with 8GB RAM
I generally agree, though this is a case where there's fair runtime penalty for enforcing immutability.
I'd say it'd be good if we enforced it type-level anyways, and probably settle for just that (i.e. return readonly T[])
mmm, not good
the typeguard in its current form is also not really acceptable, since I'd imagine it leads into weird cases like
if (!channel.isThread()) return;
// can't use the normal `Channel` props now?
It's meant to be readonly (and was in many places, but forgotten in others). Does that satisfy your worry about users defining it?
I don't know any OOP language that enforces clone to return a new instance of the class, and I can absolutely imagine somebody implementing clone() as send a discord request that recreates this structure with a new id, like cloning a text channel for example. It's why I'd rather it also be a symbol like patch, but if others don't agree then c'est la vie, let it be
Not really, imo still should be a symbol but 🤷
Does that exist at all, returned from Discord? 👀
I can absolutely imagine somebody implementing
clone()assend a discord request that recreates this structure with a new id, like cloning a text channel for example.
You don't have to imagine it as that's precisely what discord.js does. TextChannel#clone()
I think we should rename clone() back to _clone(), as it also is done in discord.js currently.
Java: https://docs.oracle.com/javase/7/docs/api/java/lang/Object.html#clone()
C#: https://learn.microsoft.com/en-us/dotnet/api/system.icloneable?view=netcore-3.1
C++: uses copy constructors instead, so fair, they don't
Ruby: https://docs.ruby-lang.org/en/3.4/Kernel.html#method-i-clone
Python: they use deepcopy and copy instead of clone indeed
PHP: they use the __clone() method https://www.php.net/manual/en/language.oop5.cloning.php
I could go on but I guess you see what i mean
Since we need to rename it anyways, lets also symbol it, consistency with patch
I agree to symbol it in this case
I'm with almeidx here, making it a symbol defeats the whole purpose of it being usable by the end user.
How? They just import the symbol from structures and define it on their class, similar to patch or clone? Am I missing something?
Discoverability for one. It's also much worse DX.
There's basically 2 levels of end-user. The actual end-users, i.e. users of discord.js, and other libs extending structures, like discord.js itself will
Patch and clone I think would realistically only be used by the latter, which maybe justifies "hiding" them behind symbols. DataTemplate is meant to be used by the actual end users, and in my eyes is one of the selling points of /structures
This @ts-expect-error comment is actually suppressing 2 errors, one of which seems unexpected as it isn't related to the reasoning in the comment.
Moving the arguments into a new line reveals the second error, on the Object.assign() call, specifically the clone:
No overload matches this call.
Overload 1 of 4, '(target: {}, source: Readonly<Partial<DataType>>): Readonly<Partial<DataType>>', gave the following error.
Argument of type 'DataType' is not assignable to parameter...
What exactly is the point of all this logic? Why would we use structuredClone just if we have nested objects? Not a blocker for the PR but I wanna know XD
Symbol's not wanted but we should use DataTemplatePropertyName / OptimizeDataPropertyName when defining this field, lest we end up renaming it at some point and miss this 🙃
Use the id function you wrote for another place
Based on the benchmark and internal discussion here #1145525943411155045 message
Wouldn't hurt to add a comment explaining that
To prevent errors like this, we could do something like:
// @ts-expect-error constructor is of abstract class is unknown
return new this.constructor( // Ensure the ts-expect-error only applies to the constructor call
patchPayload ? Object.assign(clone, patchPayload) : clone
);
I understand the idea, but that would mean that users implementing this would either
- also do
protected static override readonly [DataTemplatePropertyName]: ...making it same/worse than symbols - use
protected static override readonly DataTemplate: ...and not match how it's written in the base class, which is also weird (and face the same issue if renamed)
The purpose of the variables forDataTemplatePropertyNameis merely to be used in theMixinfunction, which is in another file....
1 is not applicable and 2 is fine because the override flag would throw an error if we ever rename the field... I don't understand whats wrong with that?
I just find it weird to have users extend and override a field but expect them to write it differently than how it is written in the base class property they extend/override.
Maybe the added tests suffice to ensure what you're worried about instead?
- [Discord Developers Discord server][discord-developers]
[discord-developers]: https://discord.gg/discord-developers
Which application is this bug report for?
Documentation
Issue description
This issue is for both Documentation and Guide.
First we start with Documentation:
'Routes' does not exist.
'GatewayIntentBits' does not exist.
'GatewayIntentBits' does not exist.
NPM:
Other documentation says Node 22 is require...
If the exports you are describing do not exist, then discord.js would be totally broken as no API requests would be made and you would not be able to connect to the gateway. All hell would break loose in the support server (for years), but alas, nothing of the sort is happening. Things are not working out for you because of unknown reasons – you have not provided enough information to work with. You should head over to the support server and see how we can help.
A...
I'd also love to hear if you say it doesn't work because running that code throws an error or because intellisense isn't picking it up. If its the former, please make a repository with reproduction samples so we can investigate, otherwise... Its most likely a misconfigured jsconfig/tsconfig
I'm not entirely sure what the problem is, but I opened the project in VSC instead of WebStorm and everything showed up. I'm a little annoyed that WS doesn't know about everything, so I'll just continue with VSC.
Missing stuff:
https://github.com/discordjs/discord.js/blob/943c39e4c068447c9...
"description": "A minimal Electron application using @discordjs/rpc with JavaScript.",
A minimal Electron application using @discordjs/rpc with JavaScript.
"description": "A minimal Electron application using @discordjs.rpc with TypeScript.",
A minimal Electron application using @discordjs/rpc with TypeScript.
* The {@link https://github.com/discordjs/discord.js/blob/main/packages/rpc#readme | @discordjs/rpc} version
Which application is this bug report for?
Documentation
Issue description
In discord-api-types, we use the @unstable tag on several types to denote that a specific type, field, enum value, etc, is currently not fully documented, but does exist, and as such should not be relied upon. The djs docs website doesn't handle those tags quite nicely
Steps to Reproduce
Look at https://discord-api-types.dev/api/discord-api-types-v10/enum/UserFlags#Quarantined, then https://discord.js...
Please describe the changes this PR makes and why it should be merged:
Needed for discord-api-types.
Depends on https://github.com/discordjs/discord-api-types/pull/1405
Status and versioning classification:
Please describe the changes this PR makes and why it should be merged:
Status and versioning classification:
886d4a7 fix(website): don't error if unstable node miss... - Qjuh
Resolves an application error when visiting the landing page of an unknown package.
Example link: https://discordjs.dev/docs/packages/unknown/main
} catch (error) {
if ('code' in error && error.code === 'ENOENT') {
notFound();
}
throw error;
}
a990eef fix: 404 for an unknown package's landing page ... - Jiralite
cf86ddb fix: remove unused stuff - Jiralite
Nothing is utilising https://github.com/discordjs/docs any more. That repository is redundant. We can probably remove old.discordjs.dev too whilst we're at it.
Alongside this, I've removed the relevant code paths that committed to that repository and updated relevant code elsewhere.
Which application is this bug report for?
Documentation
Issue description
There's a bit of a discrepancy between the FAQ guides and the documentation and would love some clarification. I'm just confused as to where these get methods are being defined for roles, as the docs use fetch requests instead.
I see that interaction.options is defined by BaseInteraction. In the common use case of adding roles based on reactions, I don't think this works and you would need to use the `R...
21cb5f8 fix: sort package versions - Jiralite
Round 2 of #10695. SQLite isn't great here, so resorted to using semver.
The motivation this time is discord-api-types.
[discord.js] Branch fix/sort-package-versions was force-pushed to `6aa80b8`
[discord.js] Branch fix/sort-package-versions was force-pushed to `7356b04`
68476e0 refactor: remove spaces - Jiralite
fc8a496 fix: header link on packages with entrypoints - almeidx
Fixes this link for packages with entrypoints. As is, this is a 404 as its missing the entrypoint at the end of the URL
Before:
Which application is this bug report for?
Documentation
Issue description
The documentation example for ContainerBuilder shows a method call:
.addComponents(separator, section)
However, .addComponents() does not exist in the discord.js builders API.
The correct methods are:
- .addSeparatorComponents(separator)
- .addSectionComponents(section)
This incorrect example appears in:
packages/builders/src/components/v2/Container.ts
This can confuse developers and cause TypeError...
Which application is this bug report for?
Documentation
Issue description
On the documentation page for EmbedBuilder, the extends BuildersEmbed link points to a 404 page.
Because of this, there is no accessible documentation for Embeds.
Steps to Reproduce
- Go to https://discord.js.org/docs/packages/discord.js/14.25.1/EmbedBuilder:Class
- Click on "extends BuildersEmbed"
Versions
- Mozilla Firefox for Linux Mint 148.0.2 (64-bit)
- Linux Mint (Cinnamon)
Issue ...
This was answered just now on Discord but for anyone else in the future (until it's fixed), the workaround is to change the package to builders (top select menu on the left) and search for EmbedBuilder there. Specifically this is an issue with overriden and re-exported classes (most builders do this) and sadly it's been known for a while, just not that big of a priority
Which application is this bug report for?
Documentation
Issue description
Clicking on the link to various type properties leads to a 404 error on the docs. Searching for them also leads to a 404 error.
I have noted this down as a medium priority issue, as multiple pages of the documentation are completely missing. It does not seem particularly urgent but I believe it is more than a minor annoyance.
Steps to Reproduce
Example:
Which application is this bug report for?
Documentation
Issue description
Currently, all the title says is "discord.js", the version number, and then "discord.js" again.
This is not helpful at all when using the browsing history or when you have several tabs.
It would be much better if there were, for example, User:class | discord.js (version), UserFlags:Enum | discord.js (version), etc.
I remember that this had already been an issue in the past, and it had been fixed, so th...
Not a maintainer, but the current website code seems to explain part of this.
In apps/website/src/app/docs/packages/[packageName]/[version]/[[...item]]/page.tsx, generateMetadata() parses the item path and then does:
const titlePart = decodedItemName.split(':')?.[0] ?? decodedItemName;
return {
title: `${titlePart} (${packageName} - ${version})`,
};
So for a docs item like User:Class or UserFlags:Enum, the page title intentionally drops the :Class / :Enum part. The...