dirigeants/core

Discord API library

core's Issues

Actions System

Role Positioning

RoleStore#highest
GuildMemberRoleStore#highest
Role#comparePositions()
GuildMember#managable
GuildMember#kickable
GuildMember#banable
...
Anything else related

GuildMemberStore#fetch() should return all members

Should be able to fetch all members from a specific guild

dirigeants/cache Tests

Structure#toJSON()

Many of the structures don't have or override the toJSON behavior, to provide more info, and structures that don't extend the base Structure (such as Application) needs to have their own toJSON method so that they can be JSON.stringified without circular reference errors

Plugin System

dirigeants/timer-manager Tests

Channel Pins Support

Routes.channelPin // message.pin() / channel.pins.add() / channel.pins.remove()
Routes.channelPins // channel.pins.fetch()

Channel#pins should be a ProxyCache to Channel#messages with add() / remove() / fetch() methods. Message#pin() would internally call this.channel.pins.add(this.id). Could probably do the same for a Message#unpin()

Ensure all utils have updated npm ignore, docs branch and building, etc based on the updated util template (except dapi-types since it doesn't need tests/docs)

dirigeants/ws Tests

Audit Log Support

Routes.guildAuditLog // guild.fetchAuditLogs()?

Issue sending images

So whenever I try to send an image URL or set an image in the embed constructor it removes -photo- from the URL string.
This can be seen here https://ur-dad.is-inside.me/Z5osb9n7.png

Icons and Avatars

User and GuildMember both need an avatarURL and displayAvatarURL method, and Guild, Team, and Application should have an iconURL method (Application probably needs a method to show app assets as well)

Channel Webhooks Support and Guild Fetch Webhooks

Routes.channelWebhooks // channel.webhooks.fetch() / channel.webhooks.add() (we can sub in channel.webhooks.remove() with the webhook / webhookTokened routes)
Routes.guildWebhooks // guild.webhooks.fetch()? since we can only fetch here, this seems wrong... maybe guild.fetchWebhooks()

Tests

This repo will require a high level of unit testing. We can use nock just like we use in the dirigeants/rest repo, but actually returning raw API data. If we find a decent ws mock we will use that too, otherwise, we will replace the .ws property with an event emitter.

Structures & Stores

Invite creation and deletion

A way to create and delete invites on channels is needed

Extender System

Vue 3 Website based on tsdocs json output

[Security] Workflow build.yml is using vulnerable action actions/checkout

The workflow build.yml is referencing action actions/checkout using references v1. However this reference is missing the commit a6747255bd19d7a757dbdda8c654a9f84db19839 which may contain fix to the some vulnerability.
The vulnerability fix that is missing by actions version could be related to:
(1) CVE fix
(2) upgrade of vulnerable dependency
(3) fix to secret leak and others.
Please consider to update the reference to the action.

[bug] [typescript] Projects using @klasa/core do not compile

Due to the main code having some // @ts-ignore comments which are not carried over to the build .d.ts files, projects currently using TypeScript and @klasa/core do not compile. Trying to compile a project that is basically the ping example from the readme (sample repo: https://bitbucket.org/Favna/klasa-core-test/) gives the following errors:

$ tsc -b src
node_modules/@klasa/core/dist/src/lib/pieces/base/Store.d.ts:71:5 - error TS2416: Property 'set' in type 'Store<V>' is not assignable to the same property in base type 'Cache<string, V>'.
  Type '(piece: V) => V | null' is not assignable to type '(key: string, value: V) => this'.
    Types of parameters 'piece' and 'key' are incompatible.
      Type 'string' is not assignable to type 'V'.
        'V' could be instantiated with an arbitrary type which could be unrelated to 'string'.

71     set(piece: V): V | null;
       ~~~

node_modules/@klasa/core/dist/src/lib/caching/stores/GuildEmojiStore.d.ts:57:15 - error TS2416: Property '_add' in type 'GuildEmojiStore' is not assignable to the same property in base type 'DataStore<GuildEmoji>'.
  Type '(data: APIEmojiData) => GuildEmoji' is not assignable to type '(data: { [k: string]: any; id: string; }) => GuildEmoji'.
    Types of parameters 'data' and 'data' are incompatible.
      Property 'name' is missing in type '{ [k: string]: any; id: string; }' but required in type 'APIEmojiData'.

57     protected _add(data: APIEmojiData): GuildEmoji;
                 ~~~~

  node_modules/@klasa/dapi-types/dist/index.d.ts:231:5
    231     name: string | null;
            ~~~~
    'name' is declared here.

node_modules/@klasa/core/dist/src/lib/caching/stores/GuildInviteStore.d.ts:43:15 - error TS2416: Property '_add' in type 'GuildInviteStore' is not assignable to the same property in base type 'DataStore<Invite>'.
  Type '(data: APIInviteData) => Invite' is not assignable to type '(data: { [k: string]: any; id: string; }) => Invite'.
    Types of parameters 'data' and 'data' are incompatible.
      Type '{ [k: string]: any; id: string; }' is missing the following properties from type 'APIInviteData': code, channel

43     protected _add(data: APIInviteData): Invite;
                 ~~~~

node_modules/@klasa/core/dist/src/lib/caching/stores/GuildMemberStore.d.ts:69:15 - error TS2416: Property '_add' in type 'GuildMemberStore' is not assignable to the same property in base type 'DataStore<GuildMember>'.
  Type '(data: MemberData) => GuildMember' is not assignable to type '(data: { [k: string]: any; id: string; }) => GuildMember'.
    Types of parameters 'data' and 'data' are incompatible.
      Type '{ [k: string]: any; id: string; }' is not assignable to type 'MemberData'.
        Type '{ [k: string]: any; id: string; }' is missing the following properties from type 'APIGuildMemberData': nick, roles, joined_at, deaf, mute

69     protected _add(data: MemberData): GuildMember;
                 ~~~~

node_modules/@klasa/core/dist/src/lib/caching/stores/PresenceStore.d.ts:27:15 - error TS2416: Property '_add' in type 'PresenceStore' is not assignable to the same property in base type 'DataStore<Presence>'.
  Type '(data: APIPresenceUpdateData) => Presence' is not assignable to type '(data: { [k: string]: any; id: string; }) => Presence'.
    Types of parameters 'data' and 'data' are incompatible.
      Property 'user' is missing in type '{ [k: string]: any; id: string; }' but required in type 'APIPresenceUpdateData'.

27     protected _add(data: APIPresenceUpdateData): Presence;
                 ~~~~

  node_modules/@klasa/dapi-types/dist/index.d.ts:490:5
    490     user: {
            ~~~~
    'user' is declared here.

node_modules/@klasa/core/dist/src/lib/caching/stores/VoiceStateStore.d.ts:27:15 - error TS2416: Property '_add' in type 'VoiceStateStore' is not assignable to the same property in base type 'DataStore<VoiceState>'.
  Type '(data: APIVoiceStatePartial) => VoiceState' is not assignable to type '(data: { [k: string]: any; id: string; }) => VoiceState'.
    Types of parameters 'data' and 'data' are incompatible.
      Type '{ [k: string]: any; id: string; }' is missing the following properties from type 'APIVoiceStatePartial': channel_id, user_id, session_id, deaf, and 4 more.

27     protected _add(data: APIVoiceStatePartial): VoiceState;
                 ~~~~

node_modules/@klasa/core/dist/src/lib/caching/stores/InviteStore.d.ts:37:15 - error TS2416: Property '_add' in type 'InviteStore' is not assignable to the same property in base type 'DataStore<Invite>'.
  Type '(data: APIInviteData) => Invite' is not assignable to type '(data: { [k: string]: any; id: string; }) => Invite'.
    Types of parameters 'data' and 'data' are incompatible.
      Type '{ [k: string]: any; id: string; }' is not assignable to type 'APIInviteData'.

37     protected _add(data: APIInviteData): Invite;
                 ~~~~

node_modules/@klasa/core/dist/src/lib/caching/stores/BanStore.d.ts:83:15 - error TS2416: Property '_add' in type 'BanStore' is not assignable to the same property in base type 'DataStore<Ban>'.
  Type '(data: { guild_id: string; user: APIUserData; }) => Ban' is not assignable to type '(data: { [k: string]: any; id: string; }) => Ban'.
    Types of parameters 'data' and 'data' are incompatible.
      Type '{ [k: string]: any; id: string; }' is missing the following properties from type '{ guild_id: string; user: APIUserData; }': guild_id, user

83     protected _add(data: GuildBanAddDispatch['d']): Ban;
                 ~~~~


Found 8 errors.

error Command failed with exit code 1.

Taking a closer look at the top one:

node_modules/@klasa/core/dist/src/lib/pieces/base/Store.d.ts:71:5 - error TS2416: Property 'set' in type 'Store<V>' is not assignable to the same property in base type 'Cache<string, V>'.
  Type '(piece: V) => V | null' is not assignable to type '(key: string, value: V) => this'.
    Types of parameters 'piece' and 'key' are incompatible.
      Type 'string' is not assignable to type 'V'.
        'V' could be instantiated with an arbitrary type which could be unrelated to 'string'.

71     set(piece: V): V | null;
       ~~~

This code in the source is, with a // @ts-ignore comment.

core/src/lib/pieces/base/Store.ts

Lines 117 to 128 in a82ce41

	/**
	* Sets up a piece in our store.
	* @since 0.0.1
	* @param piece The piece we are setting up
	*/
	// eslint-disable-next-line @typescript-eslint/ban-ts-ignore
	// @ts-ignore
	public set(piece: V): V | null {
	if (!(piece instanceof this.holds)) {
	this.client.emit('error', `Only ${this} may be stored in this Store.`);
	return null;
	}

However the code that's in dist/src/lib/pieces/base/Store.d.ts does not (full file: https://unpkg.com/browse/@klasa/[email protected]/dist/src/lib/pieces/base/Store.d.ts):

/**
--
67 | * Sets up a piece in our store.
68 | * @since 0.0.1
69 | * @param piece The piece we are setting up
70 | */
71 | set(piece: V): V \| null;

That said, currently the only way for TypeScript users to use @klasa/core is by setting skipLibCheck to true in their tsconfig's. This is far from ideal and it would be better if these tsignore's can be resolved in the main code so they are no longer required.

Member Nickname Editing Support

Routes.guildMemberNickname // member.setNickname()?

[RFC] Rename repository to reflect future package name

Summary

On various days in the past weeks we have been discussing the definitive name that Project Blue will have once we publish the first stable release to NPM. After some discussion, and if I may so humble, my own suggestion of a set of @dirigeants/core (Project Blue), @dirigeants/framework (Project Red) and @dirigeants/voice (Project Green) it seemed like the suggestion was appealing to many. These names are however not yet seen on GitHub and this should change before we publish our API library to NPM.

Motivation

First of all, a repository name that doesn't also reflect the name of the package that it is publishing can be extremely confusing, for example take various packages that have node-<something> as their repository name, but only <something> as their package name.

Secondly, giving this repository a proper name will give it a much more professional look and represent its state of getting every closer to a first official release.

And lastly giving this repository a proper name is also a first step to properly describing it in a README, something that's a must have before we can publish the package and which should always start with the name of the package in some way or another, ergo that information has to be locked in.

Detailed design

Assuming the names as was suggested before and reiterated in the summary then there are various reasons to go with these names

• They fully reflect this GitHub organization, the name of the GitHub organization is Dirigeants and so the packages should be scoped under Dirigeants
• The names of core, framework and voice do not need whole essays* to explain them. They're concise, to the point, easy to type and easy to remember.
• To my knowledge this would make us the first development team to make proper use of GitHub organizations as well as NPM organizations, if anything from the very start (i.e. DiscordJS moved to a GitHub organization only much later in its lifetime). This grants us a great distinction from other API libraries for Discord and distinction is something we will very much need in a landscape where there are many different API libraries and frameworks to use for developing Discord bots.
• All other related repositories, such as dirigeants/ws, should have their descriptions updated to reflect the new name.

Drawbacks

When we rename this repository it is only fitting that in chat we will also start referring to this project by its official name, for example "diricore". This will take some getting used to.

Alternatives

It has been considered that rather than publishing under the @dirigeants scope that we would publish these packages under the @klasa scope to NPM. This however loops back to what I said about repository name reflecting the package name and vice versa. If we publish the packages as @klasa/core then it would make sense to either rename this GitHub organization to klasa (and rename all the old klasa related repositories as well to avoid unnecessary confusion). As @kyranet has managed to get ownership rights in the @dirigeants scope on NPM however it should no longer be an issue to use the @dirigeants scope.

Unresolved questions

• Will we republish packages such as dirigeants/ws as @dirigeants/ws and use npm deprecate on the current packages?
  • Subquestion: Will we do this along with the first release of @dirigeants/core and if so, will the these packages get auto-bumped to v1.0.0 in order to match the version number of @dirigeants/core?
  • Alternatively if the packages are not republished under the proper scope, will they still get auto-bumped to v1.0.0?
• Which repositories on this GitHub org are actually relevant for the @dirigeants/core? This should be documented somewhere. Ideally that place would be either through wikipages on this repository (being the "main" repository) or on a repository simply called docs where we will put all documentation that is not directly API documentation.

* 108 words for Klasa, but leave it to Kyra to come up with a more convoluted lore than solving Goldbach's Conjecture

Member Search Support

Routes.guildMembersSearch // guild.members.search()? it is named search in the api, but this is the only place...

ClientUser

ClientUser#setUsername()
ClientUser#setAvatar()
ClientUser#presence<ClientPresence>#modify()?
ClientUser#presence<ClientPresence>#setStatus()?
ClientUser#presence<ClientPresence>#activity<ClientActivity>#modify()?
...
Anything else ClientUser related

dirigeants/rest Tests