First, add support for bot managers (basically co-owners) and a command for transferring ownership. Ownership can only be transferred to bot managers (for an extra layer of...security?).

And this change also calls for change to the _instance.json file:
Update _instance.json to replace ownerId with botOwner and appOwner.
This is because there will be ambiguity between whether ownerId refers to the owner of the app or the owner of the bot (which may change if ownership can be transferred).

To-Do:

• Add bot managers
• Add transfer ownership command
• Replace ownerId in _instance.json with botOwner and appOwner

Formatting is ugly.

wth prettier?!

Fix formatting:

• Increase max width
• use curly braces for all if / else statements
• write clean code...

Also, check if there are any better formatters out there...
😔😔😔

Avoid using null.

Use undefined instead of null.

Currently, BaseCommand#chip needs to be explicitly set by whoever writes the code, like so:

class Cmd extends BaseCommand {
  constructor() {
      super({
          name: 'cmd',
          description: 'cmd descr',
          chip: 'the-chip'
      });
  }
}

But people who write code are dumb and make lots of mistakes. A typo or forgetting to add the chip field while creating commands could be a common error. Instead, automatically set chip inside the loadChip function to make it easier for everyone!

The launcher should be able to install Citrine using git (default to master?)
Also, the launcher should take arguments. If not arguments are provided, open the interactive menu.

i.e for the current launcher, move "main" to a separate "interactiveLauncher" function, and then parse the arguments to see if any are provided.

const args = parseArgs();

if (args.recompile) recompileCitrine();
else if (args['someOtherArg']) doSomething();
else interactiveLauncher();

If needed, move the launcher to a separate repo (probably when it will be capable of installing citrine using git)
Also if needed, re-write the launcher in a cli-friendly language (which can produce an executable)

Implement winston for logging

🎉 Citrine is finally close to a v0.1.0 public release!

v1.0.0 TODOs:

• Launcher (#8)
• Logo should be finalized (#5)
• Finish the help command (#10)
• Fix formatter bug (#7)
• package-lock??? (#9)

Start work on wiki / docs.

Does JSDoc work with typescript? 🤔🤔

Also, once wiki / docs / changelog is ready, make the version badge link to that instead of the repo

Implement JsonIO and then the Json dbDriver.

Check out fs-nextra for atomic and safe json file handling.

Launcher TODOs (for v0.1.0):

• Add License in View Credits / License page
• Link to GitHub contributors page in View Credits / License
• Link to Djs docs, nodejs docs in View Guides / Documentations page

Add timestamps to the loggers and exceptions?

Use typescript for the built-in chips, it's faster and easier to develop, plus it'll be more consistent with the rest of the core codebase for citrine. ✨

The current BaseCommand and SubCommand classes are basically the same with very small differences. Would it be better to just combine them into one Command class? It would simplify a lot of logic....

For getParent and getBase, they would simply return undefined for base commands. They could also be turned into getters/setters to make it simpler.

Try and see if the chip property for BaseCommands can somehow be handled behind-the-scenes instead of having to specify it for every base command, because that would be great.

Other than that, everything is identical for BaseCommand and SubCommand.

Urgent (for #6)

• Add a default help message when no args are given.

Other TODOs:

• Able to list all commands
• Able to list all chips
• Able to give help for chips (commands, description, author)

Since BaseCommand and SubCommand are separate classes now, there's no need to have an id property for them. Instead, use instanceof to check for BaseCommand/SubCommand because there now there won't be any circular dependencies.

Currently, event listeners can be added/removed through the ./bin/Events directory (which is then read by the client's initEvents method) or by adding them to the client in the load/unload functions inside _setup.js for chips (which are called whenever chips are loaded/unloaded).

It would be simpler to just remove the whole initEvents thing, and just add/remove events through the _setup.js file. For events that must always be loaded, they can be added in the _setup.js file for the core chip, since the core chip is always loaded and cannot be unloaded. Most of the default event listeners can also be moved to the core chip setup, unless they are more appropriate in another chip. It should also help with startup speed since the client won't have to read extra files from the Events directory.

Then, we can also get rid of initChips and move its functionality inside the launch method. This will again be better since there will be only one method for loading chips, and events will also be handled by that. On top of that, only the launch method will be needed to start the client.

For the stable/bin and stable/src branches, reduce installation size by limiting included files in the repository.

So, no need for the linting/formatting/tsc config files etc.

🌈 🌈 🌈 🌈

For the love of God, learn English.

Plz fix typos / grammar throughout code.

🤢