cordis-lib / cordis Goto Github PK

/channels/:channelid - channel ID is always considered major, unless the route is exactly /channels/:channelid

@zaida04 if you have time and could PR this, I'm literally just way too fucking full of stuff to do to waste 15 mintues on a PR. I'll do this on Sunday otherwise when I'll push a lot of other changes for 0.1.7

Ref: https://github.com/cordis-lib/cordis/blob/main/libs/gateway/src/websocket/Cluster.ts#L196

I think this config looks acceptable for our commit messages.

From there we can use this to generate our changelog.

Thoughts on my chosen commit-lint config? @zaida04

I'd like to:

• make @cordis/brokers support various protocols and tools other than RMQ
• update the spec to it
• move the implemented gateway service into its own repo - something like cordis-lib/rmq-gateway
• start implementing more microservices that may be useful

Is your feature request related to a problem? Please describe.
With #24 (0.1.6) the size of the gateway service has been reduced significantly but it still feels fairly large.

Describe the ideal solution
I feel like this could be pushed further significantly by using a bundler such as rollup, snowpack or webpack.

Describe alternatives you've considered
Leaving it as is, I suppose, but I believe the size optimization is worth it.

Example Code

import { RestManager } from "@cordis/rest";
import { buildRestRouter } from "@cordis/routers";

const manager = new RestManager(process.env.DISCORD_TOKEN);
const rest = buildRestRouter(manager);

await rest.channels["500765481788112916"].messages.post({
      data: {
            content: "TESTING MESSAGES",
            tts: false,
            embed: {},
      },
});

Issue

In the data object, the keys tts and embed are invalid because data is expecting only a Record<string, string>, which should be improper considering things like objects can be nested in the body and values like booleans and numbers also exist.

Potential Solution

change Record<string, string> to Record<string, any>

Is your feature request related to a problem? Please describe.
Releasing versions manually is pain.

Describe the ideal solution
Would be neat to figure out a way to automatically push out a release via Actions. Think all we'd have to do is to monitor the version in the root package.json and see if it's changed - and, if it did, run pnpm run release from the current main branch.

Describe alternatives you've considered
Sticking to the current approach, but pain

Currently decided things about this release:

• It will be a breaking release, as described bellow.
• When it's being released is unknown. As usual, we roll out new versions on Sundays unless there's emergency fixes, so it'll be "on the sunday corresponding to the week it's done in" Coming out this week!

Done:

• The introduction of @cordis/util with #32
  • @cordis/snowflake is getting entirely deprecated, becoming a part of util instead
  • makeDiscordCdnUrl is being from @cordis/common moved into @cordis/util [BREAKING]
  • #46 is being resolved
  • #29 is being resolved, with the primary goal of having helper functions for all most documented API endpoints exposed by Discord
• #35 - Small breaking change removing a few redundant methods from RedisStore [BREAKING]
• #52 - Gets rid of some left-over implicit caching done by @cordis/gateway [BREAKING]
• #59 - Deprecation of @cordis/routers in favor of placing its functionality into @cordis/rest
• #60 - The ability to resume a gateway connection while initially connecting to the gateway.
• #61 - The ability of injecting dependencies and own functionality into the Cordis gateway service without the need of forking or overwriting the base source file.

The iterator for the redis-store package could use some heavy optimizations using hscan - just haven't quite figured out how to do yet.

Purpose

There is a clear dependency on @cordis/rest in @cordis/router, meaning others cannot use the router for their own rest managers, making it unnecessary to be in it's own package.

Alternative solution would be to establish a RestManager standard so that others can use our router for their own purposes.

Context

I have to refactor how certain things work atm, I think I'll create a simple React front page for docs that makes use of GitHub's API to serve typedoc documentation.

CI needs some work as well on this repo for how docgen works - just a bit of a headache atm not going to lie.

As shown here buckets are created, added to a hashmap on the Rest class and never cleaned up.

A TTL doesn't sound like a particularly clean approach to solving this, but some sort of life team system is most certainly needed.

A bot for the community server that'd require lots of packets and data would demonstrate more sides of the toolchain, with the actual need for a complex monorepo, even though It'd still run single gateway cluster (which I plan on covering later on individually).

Read about what a pure ESM package is here.

More info in #93

Currently blocked by Jest support.

Which cordis libraries/services are you facing this issue in?:

• @cordis/rest

Please describe the problem you are having in as much detail as possible:
In some ungodly way, I managed to get a Bucket to always return on this conditional chain - causing the Promise to never resolve in Mutex#claim - needs more investigation.

Include a reproducible code sample here, if possible:
Unclear how to exactly repro.

Further details:

• @cordis/rest version: 0.3.0

• Node.js version: v15.11.0

• Operating system: GNU/Linux Alpine under Docker

• Priority this issue should have – please be realistic and elaborate if possible: high

Feature Request

A helper library that provides abstraction over writing endpoints for common routes. This will be structured in a FP manner, accepting arguments that will be concatenated into the endpoints. It will also handle having typings for each endpoint body (discord-api-types??).

Function List:

(Moved to #32)

This issue caused broker code to simply not compile.

The fix is already present in typescript@rc - it should stay that way until the official 4.2 release.

All I have to do is wait for 4.2 to come out properly and update typescript across the repo.

https://discord.com/developers/docs/resources/webhook#execute-webhook
specifically the wait query string param

No clue if this should expand to other http methods

Just noticed a bunch of junk local code on my system from older project iterations laid around due to file renames. :|

Should consider using something like rimraf in the publish script to purge all dist and types dirs before publishing. No big deal overall, this problem will fix itself next release.

To clarify, there's junk files present in the releases that aren't exported at all.

For a start, @cordis/routers should support generics like the RestManager in @cordis/rest does for the data - to offer extra safety.

Second off, files should be marked as optional on post

Cordis has reached a point where it has been reliably used in bots processing load from hundreds of thousands of users in production.

No doubt, there were issues and bumps, but over all, I can say that it went fairly well and that I'm about ready to push something I consider "stable".

There's a few things that need to be done for this 1.0.0 release:

• #76
• #83
• #84
• #86
• #87
• #88
• #79

Code

Issue

This line prompts the eslint error of Operands of '+' operation must either be both strings or both numbers cause of this.startingShard + this.shardCount;
This is because even though there is a check earlier for if shardCount is auto and reassigns it to reccomendedShards, the "auto" value still falls through. This can be fixed with a type assertion guaranteeing this.shardCount is a number.

Solution

this.startingShard + this.shardCount; => this.startingShard + (this.shardCount as number)

will create PR shortly

Request

Add a docs workflow to ensure we have up to date docs and have less reliance on manual work

When?

On push to master (e.x. merged prs or straight commits)

Steps

• will build the libs
• build the typedoc docs
• push to https://github.com/cordis-lib/cordis-lib.github.io

Additional Notes

We will need to make use of the GITHUB_TOKEN environment variable in order to have permissions to push straight to the master branch of cordis-lib.github.io

Currently NPM pages look fairly stale.

Adding a new package that uses JavaScript Proxies to "route" requests sounds really cool.

We'd have an abstract class for a start, and then we'd add some built-in implementations, one of them just making requests using @cordis/rest

Would look something similar to discord.js client.api

Example:

instance.users[someUserId].get(); // <- calls `RestManager#get` with `/users/:id`

Gateway README.md is using old WebsocketManager which has been long renamed to Cluster. This has been fixed in 308908e - will close once that has been properly released/docs have been updated.

Which cordis libraries/services are you facing this issue in?:

• @cordis/gateway

Please describe the problem you are having in as much detail as possible:
@cordis/gateway will not install with nodejs v16.

This means a couple of things:

• it is unusable stand-alone for folks trying to adapt v16 early
• @cordis/gateway-service cannot update to v16 atm.

How fix? Unclear. The issue comes from a lack of support for v16 from erlpack. I attempted to fix this by forking it (and polishing!) with the intention of releasing under @cordis/erlpack - but just as I was done with the code I noticed that the actual problem was - nan. That's where the v16 support is missing.

Unfortunately I do not have the time nor the knowledge needed to move away the fork from nan atm - but I fully intend to do so in the future.

I'd expect this will be solved at the very least when v16 becomes LTS, if not earlier.

Further details:

• @cordis/gateway version: 0.3.0
• Node.js version: 16.1.0 - effects all 16.x
• Operating system: Windows 10, using WSL2 5.4.72-microsoft-standard-WSL2, Linux Alpine NodeJS images
• Priority this issue should have – please be realistic and elaborate if possible: medium

This is a critical bug.

Ref: onClose function

In case the websocket closes with a code that doesn't have an explicit case, such as the abnormal 1006 I just got nothing will be done. There's no default case to have it just destroy with fatal: true, reconnect: true, causing the gateway shard to enter a state where it keeps on trying to send heartbeats only for ws to throw every single time. There's no recovery that can be made from this stage.

Which cordis libraries/services are you facing this issue in?:

• @cordis/rest

Please describe the problem you are having in as much detail as possible:
Quite simply, subsequent requests can end up preserving route information from previously made requests. The fix is to make method mutable and to reset it before calling rest.make

Further details:

• @cordis/rest version: 0.3.0
• Node.js version: 16.2.0
• Operating system: Linux Alpine under Docker
• Priority this issue should have – please be realistic and elaborate if possible: high

Line 68 uses bindExchange, but apparently that's only used to bind one exchange to another. Have to use bindQueue instead.

https://cordis.didinele.me/modules/routers.html#buildrestrouter

In the example,

const user = await routers.users[someUserId].get();

should be

const user = await router.users[someUserId].get();