Updated desiredProperties in transformers to be generic so that it can be used to retrive the bot desired properties, and removed the option from `CreateBotOptions.transformers.desiredProperties` as that would cause the typings for the bot to be incorrect
Co-authored-by: Awesome Stickz <awesome@stickz.dev>
* api-docs!: Modal Selects
* Fix transformer to handle the new response types
* Remove `Component` for consistency
Other interaction response types do not have `Component` in their names, so neither should the TextDisplay and Label interaction response types.
* Fix type errors in component transformers
---------
Co-authored-by: Awesome Stickz <awesome@stickz.dev>
* chore(website): Remove styled-components
This also allows us to remove the loading screen on page load as the styles are now loaded by the browser itself.
* chore(website): Update dependencies
* Remove clsx
* Update dependencies
Also update markdown onBrokenMarkdownLinks options as it now deprecated in favor of markdown.hooks.onBrokenMarkdownLinks
* Update dependencies
* build(rest-passthrough): Use typescript to build
It doesn't make a lot of sense for something like this to use SWC to build + this needed typescript with a tsconfig anyway for a typecheck
* Add tsconfig
* Remove .swcrc and copy tsconfig in docker
---------
Co-authored-by: Awesome Stickz <awesome@stickz.dev>
Since we build the .js files and the .d.ts files in 2 different steps, you could run the tsc build and then the swc one, making swc delete the tsc build.
This is somewhat mitigated if you ran the tsc build with turbo as it will restore the cache, but it is annoying + the TS server in vscode for example will someone require you to restart it as it did not found the declration files for the package while it was building.
I did not find any good reason for this flag to be present, as while it will preserve files that no longer have a source, this matters only for local builds, as CI will always cleanly build the packages (and this issue exists with type declration as well anyway)
Co-authored-by: Awesome Stickz <awesome@stickz.dev>
* feat(types,bot): Add Label component and new modal stuff
Since now there are some fields that are only in responses the types got a bit more complicated
* Add char limits to label label & desc
* update comments
* fix format
* Move Require to shared.ts
* code review
---------
Co-authored-by: Awesome Stickz <awesome@stickz.dev>
* api-docs: banner, avatar, and bio on modify current member
* Update packages/types/src/discordeno/guild.ts
Co-authored-by: Awesome Stickz <awesome@stickz.dev>
---------
Co-authored-by: Awesome Stickz <awesome@stickz.dev>
Currently the big bot gateway worker was sending camelCase packets to the bot which caused the transformers in `@discordeno/bot` to not find most of the properties they need in the payload.
This changes the docs to show to override the forwardToBot method to send the packets as-is to the bot.
Co-authored-by: Awesome Stickz <awesome@stickz.dev>
forwardToBot has been removed in favor of directly using the events.message.
the default implementation for forwardToBot used to camelize the packet, however in most cases you want to preserve the snake_case, and for those that need camelCase it can be easly done in the message event function.
This also removes the gateway.preferSnakeCase option as it no longer has a use
The typedoc config is now only in the top-level config file instead of also being one per package
and all internal APIs are now marked as private so typedoc won't generate documentation for them, however we still need to export them to avoid typedoc warnings
The new internal APIs that are exported, since are marked as `@private` can have breaking changes without notices
* refactor(transformers)!: Use type helper to define customizers
This allows us to ensure that customizers always follow the correct types for the transformers and we don't have 2 places to add the types.
* remove outdated comment in transformInteractionDataResolved
* remove not needed cast
* remove not needed cast
Currently we import from `index.js` files where we could simply import the actual file(s) or module we need.
This also creates a bit of confusion since it isn't obvious from where stuff is coming from, especially when we are importing types such as `Discord<XYZ>` types both from `@discordeno/types` and a `index.js` in the same file, one such example is `transformers/reverse/component.ts`.
As far as I can tell, this does not have any specific advantage beside readability, maybe something with tree-shaking. (and for us, tree-shaking doesn't really matter)
The only files that still import index.js files are:
- index.js files themself
- bot/src/handlers.js since it does a `import * as handlers from './handlers/index.js'` and the alternative is like 90 lines of imports
Co-authored-by: Link <link20050703@gmail.com>
* chore(.github): Add @discordeno/team to most codeowners
Also removes /.github/sync.yml, that file does not exist
* Remove explit mentions
They are already in the team, so they do get the perms anyway
* Update .github/CODEOWNERS
Co-authored-by: Link <link20050703@gmail.com>
---------
Co-authored-by: Link <link20050703@gmail.com>
* fix(types)!: Split and fix discordeno.ts
* fix some mistakes
* remove now not needed @ts-expect-error
* Apply code review suggestions
* Fix test type errors
* Revert "Apply code review suggestions"
This reverts commit 7a0cea84b3.
* Restore some of the changes from the revert
---------
Co-authored-by: Link <lts20050703@gmail.com>
This is not the actual benchmark we have (and we don't even run the one we do have)
instead this is a Deno version of the benchmark and i can't find anything
that uses this benchmark
This is also somewhat annoying to keep as something the Typescript Server
may decide to typecheck those files and it will complain no stop because
it can't find what `Deno` is and doesn't understand importing urls
The task currently opens up as soon as visual studio code opens the folder
and it is very much annoying since it pops up immediately and also for example
for me it makes my pc lag quite a bit due to the amount of files being watched
and git processes that it spawns to calculate the hashes (this is at least
my understanding of what it is doing with all the git processes)
