[Bot] Customize Typings Based on DesiredProperties

[Skillz4Killz]

Is your feature request related to a problem? Please describe.
It would be better to have typings be generated automatically based on the desired properties the user provides.

Describe the solution you'd like

• Possibly a CLI like npx prisma generate where we do npx discordeno generate
• Typescript generic that user provides on createTransformers<>() which can provide custom ones

Describe alternatives you've considered

Additional context

With current solution it is not typesafe as a desiredPropety could be set to false and yet the typings say it exists. We could make all properties optional but that isn't exactly a good UX either.

[MatthewSH]

Would love to hop in on this conversation since it's been a topic of conversation with us on Discord, mainly around desiredProperties. I know our conversation has more geared towards a DD CLI.

I'm not opposed to a CLI, I think a CLI makes sense. It allows those who use TypeScript that type safety. I can say from experience that this threw me for a loop as well, mainly cause I didn't know desiredProperties existed. I was calling properties that TS expected but failed when running.

Having proper documentation, typing, and/or CLI could've mitigated that surprise and frustration for me.

On the CLI generation...
Initial feeling without looking at any other CLIs or generators that exist I think there's a couple options. I'll give a couple thoughts.

JS File

Squashed the details to make this issue shorter

Pros

• Could be imported/required into the implementation file and be used directly without the need for assert { type: 'json' } using JSON
• Since it's actual code you could leverage it to create custom transformers or customizers, that is if we're limiting it to just the createTransformers method
• Has the full power of JS without being limited to primitives (such as JSON, YAML, or TOML)

Cons

• Lack of typing, since it's JS only but could still leverage JSDoc using import('my-types').Transformers for example? Quick thought there.
• Would still need to allow importing of JS files in your TSConfig which may not be desired
• Different languages in one codebase

Discordeno Changes

We would have to change this line to no longer pass in an empty object. We could, depending on the implementation of the config, just pass in the config.

User Side

import myConfig from './discordeno.config.js'

createBot({
  config: myConfig
})

On the Discordeno side we could change it to:

{
  transformers: createTransformers(myConfig.transformers ?? {}),
}

We would also have to change the default desiredProperties

desiredProperties: {
  attachment: {
    id: false,
    filename: false,
    contentType: false,
    size: false,
    url: false,
    proxyUrl: false,
    height: false,
    width: false,
    ephemeral: false,
    description: false,
  },
  // all the other properties here
  // Then spread the options.desiredProperties
  ...options.desiredProperties
}

Doing it this way would allow defaults and protect for future additions while also overwriting the object's properties as a last step. In this case, based on the example below, the entire attachment object would be all true because we saved spread operation to the last step.

Example Config

Using export default would require ES6+ if I recal.

discordeno.config.js

export default {
  transformers: {
    desiredProperties: {
      attachment: {
        id: true,
        filename: true,
        contentType: true,
        size: true,
        url: true,
        proxyUrl: true,
        height: true,
        width: true,
        ephemeral: true,
        description: true,
      }
    }
  }
}

JSON

Squashed the details to make this issue shorter

Pros

• Configuration through JSON is normal, although less so with things like Webpack and others? At least normal from personal experience
• It's known and can be restrictive to primitive values, can be good or bad.
• You can provide JSON schemas which most popular editors support in some way to real time validate the schema, you can even version it if you want.

Cons

• Is it restrictive, wouldn't give DD flexibility like you could with JS implementation since it would be restricted to primitive JSON types. So no custom transformers.
• You'd have to use assert { type: 'json' } wherever you import it
• You'd have to allow JSON modules in TSConfig
• Could potentially cause typing issues, just a theory
• Biggest Con is that the $schema would have to be maintained or generated on release which is another point of potential failure or extra time spend

Discordeno Changes

Same as the JS implementation as I previously documented. That's going to be more or less the same for both. User side would be similar, just adding the assert { type: 'json' } instead of importing the file.

Example Config

{
  "$schema": "https://some.schema/discordeno-19.0.0.json",
  "transformers": {
    "desiredProperties": {
      "attachment": {
        "id": true,
        "filename": "true"
      }
    }
  }
}

I won't list out all the items.

My Opinion

My personal opinion is to go the JS route. CLI could look like:

npx discordeno generate types

We could also create a shortcut with dd so instead of npx discordeno we could use npx dd.

Inside the CLI we could look for a discordeno.config.js file and require it in and generate a typing file based of it.

[github-actions]

This issue has gone stale for over a month. If this issue is useful, leave a comment below. Otherwise, it will be closed shortly.

[MatthewSH]

Bump for stale bot