Some ecstatic title goes here

[UnseenFaith]

~Now that custom structures is merged into Discord.js#master, I can safely work towards updating Komada and putting it back on it's track to its first official release. This will either be a minor bump or Komada's official first release, depending on how much or how far I decide to go on some of the things I want to add.~

~Testers for this PR would be appreciated.~

Moving this over here because the PR was clustered with way too much shit and I lost track of what was being done. Everything from this point onward's will be little, small additions instead of one big PR. Some of the stuff on this list is already done, but not checked off as well.

Planned Things (Will definitely add)

• [ ] New Settings (and maybe a SettingGateway port to Pieces if people want the extra option)
  • The current Settings system is quite daunting for new users, and I'd like to create a simple solution that doesn't require much effort to learn or use.
• [ ] New Argument Prompting System
  • The current argument prompting system blows. It doesn't work as intended half of the time and it could be a completely better solution. As of 99a7734 argument prompting has been removed completely from Komada, pending a better implementation.
• [ ] Readd CommandEditing
  • Broke it with Custom-Structure changes, probably just as simple as porting over the methods to the KomadaMessage class.
• [ ] Remove these dumb eslint devdependencies.

Breaking Changes

• permLevels -> PermissionLevels (index.js)
  • PermissionLevels now caches the levels inside of an array, and you can specify the number of levels by passing it in the constructor. An owner-only level will be added at the highest level you specify.
  • <PermLevels>.addLevel(level, brk, func) => <PermLevels>.add(level, brk, func)
  • <PermLevels>.reset(level) -> Resets the specified level back to default (basically a delete function)
• Finalizers
  • Finalizers now require a configuration object.
  • The only property currently is "enabled". That's not to say that more won't be added a later date though.

exports.conf {
  enabled: true,
};

Low Priority Things (Might be or Might not be added)

• [ ] Localization
  • There hasn't been much demand for Localization, but this could be useful implementing nonetheless.
• [ ] Rewrite KomadaConsole
  • It works, but it could be improved in several portions and made easier to use
• [ ] Add extra events for Commands
  • commandRan, commandInhibited, thing of these nature.
• [ ] Custom Messages for Required Arguments
  • Allow users to pass messages into Komada's internal ArgumentParsing so they don't have to use Optional Arguments just to throw their own custom messages.
• [ ] Better Error Handling
  • Create a better error handling system that replaces the dumb one I added specifically for argument parsing, which let users identify problems easier and faster.
• [ ] Logs
  • I'd like to add the ability to read and write to log streams for certain things in Komada, like errors, command runs, things of that nature. Although this would be a nice feature, I'm not sure how feasible it is for Komada's user base.
• [ ] Dashboard
  • Something I've been wanting to do for awhile now is giving Users the ability to programmatically create their dashboard using Komada. Unfortunately this would take a very long time and the concept design would be hard to understand, but there's definitely potential here.
• [ ] More Documentation
  • Documentation is always good, and the website is quite lacking it. I'd like to have more examples added to the website, or even something like a Quick Starter Guide, to help those ease into the framework easily.
• [ ] Persistent KomadaStorage
  • People were using SettingGateway to store things not even related to settings, such as tags commands. While I'm not opposed to creativity, I would prefer if there was a Persistent Module within Komada that could be used freely without all the constraints that SettingGateway has.
• [ ] DataStores
  • Komada might benefit from DataStores like in Klasa and could reduce a lot of code duplication.
• [ ] Inhibitors
  • Make Inhibitors Asynchronous again, because I like making people suffer.
• [ ] Extendables
  • Make extendables reloadable.
• [ ] Stats
  • Some stats would be and useful, such as most command used in guild, most command used by user, etc.
• [ ] RichMenu/Display
  • Port these over from Klasa, shouldn't be too hard.
• [ ] Help Changes
  • I'd like to create a new help command or even better a HelpTemplate so that issues don't crop up when using the default help command.
• [ ] Implement the ability to custom load things
  • Equivalent to Klasa's CustomPieces and CustomDataStores... but in Komada format.
• [ ] QoL Changes
  • Store Command Object References instead of just strings of the command.
  • Monitor to reply with prefix. (Similar to the one currently in Klasa)
  • Maybe start validating pieces loaded into Komada?
  • The README could use a fresh coat of paint by someone currently developing the framework and not a previous developer.

Completely New Things

• Disable/Enable
  • Enabling/Disabling is now persistent through bot lives.
• Finalizer Documentation
  • "Finally" added Finalizer documentation...
• The Curvature of Komada
  • You can sub-categorize all pieces in Komada.
• Duration, Stopwatch and Timestamp classes
  • Three new classes to do simple things around the framework.
  • Duration turns time into a human-readable format to indicate how long something has passed. (such as that used in the stats command)
  • Stopwatch is a port from Klasa that gives you better control over node's perf_hooks
  • Timestamp turns time into a timestamp, such as that used in the CommandLogs.

Updated Things

• ArgumentParsing has been slightly changed, although this is subject to change.
• Loader has been completely refactored.
• Reload/Disable/Enable Command

(If Applicable) What Issue does it fix?

Makes Komada Great Again.