Retro-compatibly of channels types for stored data

[DraftProducts]

Is your feature request related to a problem? Please describe.

Everyone knows that v13 brings a lot of breaking changes, but some of those are more problematic than others.
We can do without Structures (it's a huge pain in the ass but it's better for everyone), a naming convention can be replaced, but types that can be stored to be referenced like channel types are more difficult.

For all bots witch were used before this v13, a disgusting think like that is needed.

const compatibilityTypes = {
    'text': 'GUILD_TEXT',
    'voice': 'GUILD_VOICE',
    'category': 'GUILD_CATEGORY',
    'news': 'GUILD_NEWS',
    'store':'GUILD_STORE',
    'GUILD_TEXT': 'GUILD_TEXT',
    'GUILD_VOICE': 'GUILD_VOICE',
    'GUILD_CATEGORY': 'GUILD_CATEGORY',
    'GUILD_NEWS': 'GUILD_NEWS',
    'GUILD_STORE':'GUILD_STORE',
    'GUILD_NEWS_THREAD': 'GUILD_NEWS_THREAD',
    'GUILD_PUBLIC_THREAD': 'GUILD_PUBLIC_THREAD',
    'GUILD_PRIVATE_THREAD': 'GUILD_PRIVATE_THREAD',
    'GUILD_STAGE_VOICE': 'GUILD_STAGE_VOICE',
};

Describe the ideal solution
Add an intern retro-compatibly in TypeResolvable.
I can work on it if it's needed.

Describe alternatives you've considered
We could roll back this commit because it brings only breaking changes and nothing new.

[monbrey]

You haven't explained at all what exactly this is needed for - I'm going to guess something like having these old type values stored in a database?

Run an update.

update channel_table
set type = 'GUILD_TEXT'
where type = 'text';

Or maybe you use mongo

db.collection('channel_table').updateMany(
  { type: 'text' },
  { $set: { type: 'GUILD_TEXT' } }
);

Or use your little object map.

The change was not breaking just for the sake of breaking - it makes the types more consistent with both Discords channel type names, and the uppercase nature of other constants in the lib.

This wouldn't even be breaking if you used the ChannelTypes constant instead of magic strings.

[DraftProducts]

For example, I would use my personal case, a backup feature, which stores desired data of servers to restore differences between the actual version and the backup when it's asked by a user.
when I was doing the backup, the data of channels were formatted into simples objects, then it was stringified and stored in my database (SQLite in 2017 so no JSONb type).

The "magic string" was given by discord.js himself in stable version.

I agree that those types are more consistent with Discords channel type names in API, like all others breaking changes of this v13 version it's a good move but some of them can have an impact that can not be properly resolved with a refactor of ours code-base.

The goal is just to show that it can be a problem (for sure, I can resolve it with a simple object), but most of the developers would migrate from v12 to v13 when it would be released, it's just an issue to say it and think about it, this case would not be the only one.

[iCrawl]

For future proof thinking I think it would be better if people didn't rely on some output we give them, especially not for their own data structures and map them always to their own 👍