Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[CLI] npx discordeno generate #3190

Open
Skillz4Killz opened this issue Nov 27, 2023 · 3 comments · May be fixed by #3255 or #3453
Open

[CLI] npx discordeno generate #3190

Skillz4Killz opened this issue Nov 27, 2023 · 3 comments · May be fixed by #3255 or #3453
Assignees
Labels
t-feat A new feature
Milestone

Comments

@Skillz4Killz
Copy link
Contributor

I've created a basic mockup of how this code should work. Need to finish this up with 1 type before we start implementing for all types.

Try to see if we can get the Message.id type created.

@MatthewSH
Copy link
Contributor

Is the mockup anywhere? Curious to see whatcha thinking.

@Fleny113
Copy link
Contributor

Fleny113 commented Dec 1, 2023

In a situation where you only enabled the Message.id for example, what should be the state of the other values in the type? I thought about 3 possibile implementation

  • Setting the value of the "undesired" propriety to never
  • Marking it as nullable
  • Removing the propriety from the type at all

Setting the value to never or making it as nullable enables to add a comment on them but

  • For the never you could still pass the value and don't get TS errors if the function is typed with any, unknown, never or with generics that allow never
  • For the nullable this does still present the issue of the TS errors not being reliable but could also implicitly give an information that is not true: the fact that you might get the value, or it could conflict with values that are actually nullable from the discord docs

While removing them might be even more confusing that it is at the moment where at runtime you don't get the values but you are going to get a TS error about the prop not exiting, but this does pose an additional problem as an empty interface means NonNullable<unknown> for Typescript and not an empty object

There is a tradeoff to be made and i think that the never for all proprieties (even tho might be the most complex on the implementation lever) could be the best one as the cases where you don't get the TS errors are very specific and one of the cases implies poorly typed functions

Also, this applies if you don't enable anything at all, so given the message id example, on the channel it would be all never, all nullable or empty

@H01001000
Copy link
Contributor

Or make it as a setting

@H01001000 H01001000 added the t-feat A new feature label Dec 1, 2023
@H01001000 H01001000 linked a pull request Dec 3, 2023 that will close this issue
@H01001000 H01001000 modified the milestones: v19, v19.1 Dec 7, 2023
@Fleny113 Fleny113 linked a pull request Feb 22, 2024 that will close this issue
28 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
t-feat A new feature
Projects
Status: Todo
Development

Successfully merging a pull request may close this issue.

4 participants