factoid: added prefix impl

.prettierrc.cjs

@@ -1,3 +1,3 @@
 module.exports = {
-  ...require('gts/.prettierrc.json')
-}
+  ...require('gts/.prettierrc.json'),
+};

.vscode/extensions.json

@@ -1,9 +1,9 @@
 {
-    // See https://go.microsoft.com/fwlink/?LinkId=827846 to learn about workspace recommendations.
-    // Extension identifier format: ${publisher}.${name}. Example: vscode.csharp
+  // See https://go.microsoft.com/fwlink/?LinkId=827846 to learn about workspace recommendations.
+  // Extension identifier format: ${publisher}.${name}. Example: vscode.csharp
 
-    // List of extensions which should be recommended for users of this workspace.
-    "recommendations": ["cspell.cspell", "microsoft.eslint"],
-    // List of extensions recommended by VS Code that should not be recommended for users of this workspace.
-    "unwantedRecommendations": []
+  // List of extensions which should be recommended for users of this workspace.
+  "recommendations": ["cspell.cspell", "microsoft.eslint"],
+  // List of extensions recommended by VS Code that should not be recommended for users of this workspace.
+  "unwantedRecommendations": []
 }

.vscode/launch.json

@@ -1,18 +1,18 @@
 {
-    // Use IntelliSense to learn about possible attributes.
-    // Hover to view descriptions of existing attributes.
-    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
-    "version": "0.2.0",
-    "configurations": [
-        {
-            "type": "node",
-            "request": "launch",
-            "name": "Launch Program",
-            "skipFiles": ["<node_internals>/**"],
-            "program": "${workspaceFolder}\\target\\core\\main.js",
-            "preLaunchTask": "tsc: build - tsconfig.json",
-            "outFiles": ["${workspaceFolder}/target/**/*.js"],
-            "args": ["--enable-source-maps"]
-        }
-    ]
+  // Use IntelliSense to learn about possible attributes.
+  // Hover to view descriptions of existing attributes.
+  // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
+  "version": "0.2.0",
+  "configurations": [
+    {
+      "type": "node",
+      "request": "launch",
+      "name": "Launch Program",
+      "skipFiles": ["<node_internals>/**"],
+      "program": "${workspaceFolder}\\target\\core\\main.js",
+      "preLaunchTask": "tsc: build - tsconfig.json",
+      "outFiles": ["${workspaceFolder}/target/**/*.js"],
+      "args": ["--enable-source-maps"]
+    }
+  ]
 }

.vscode/settings.json

@@ -1,16 +1,16 @@
 {
-    "cSpell.words": [
-        "channelmap",
-        "INITDB",
-        "loggingchannel",
-        "popconfirm",
-        "readcursor",
-        "ringbuffer",
-        "submod",
-        "turingbot",
-        "unlogged"
-    ],
-    "yaml.schemas": {
-        "kubernetes://schema/apps/v1%40deployment": "file:///c%3A/Users/James%20Boehme/Documents/GitHub/TuringBot/k8s/dev.yaml"
-    }
+  "cSpell.words": [
+    "channelmap",
+    "INITDB",
+    "loggingchannel",
+    "popconfirm",
+    "readcursor",
+    "ringbuffer",
+    "submod",
+    "turingbot",
+    "unlogged"
+  ],
+  "yaml.schemas": {
+    "kubernetes://schema/apps/v1%40deployment": "file:///c%3A/Users/James%20Boehme/Documents/GitHub/TuringBot/k8s/dev.yaml"
+  }
 }

Dockerfile

@@ -1,6 +1,6 @@
 # https://nodejs.org/en/docs/guides/nodejs-docker-webapp
 # Defining what image we want to build from https://hub.docker.com/_/node
-FROM node:16
+FROM node:20
 
 # Create a directory for everything to be installed, this is the container working dir for future commands
 WORKDIR /usr/src/turing-bot

config.default.jsonc

@@ -1,29 +1,29 @@
 {
-    "logging": {
-        /**
-         * Different levels of verbose logging.
-         *
-         * 0: No logging, no events will be logged
-         *
-         * 1: Very minimalist logging, including core and module starting, as well as module failure.
-         *
-         * 2: Slightly more verbose logging, may log some important info events
-         *
-         * 3: Will log commands used and all info passed through eventLogger
-         *
-         * 4:
-         */
-        "stdout": {
-            "verboseLevel": 2
-        },
-        // It is an option to have the bot DM certain users for events, it's suggested to leave this disabled or on a very low level.
-        "directMessageLogging": {
-            "userIds": [],
-            "verboseLevel": 0
-        },
-        "loggingChannel": {
-            "loggingChannelId": "",
-            "verboseLevel": 2
-        }
+  "logging": {
+    /**
+     * Different levels of verbose logging.
+     *
+     * 0: No logging, no events will be logged
+     *
+     * 1: Very minimalist logging, including core and module starting, as well as module failure.
+     *
+     * 2: Slightly more verbose logging, may log some important info events
+     *
+     * 3: Will log commands used and all info passed through eventLogger
+     *
+     * 4:
+     */
+    "stdout": {
+      "verboseLevel": 2
+    },
+    // It is an option to have the bot DM certain users for events, it's suggested to leave this disabled or on a very low level.
+    "directMessageLogging": {
+      "userIds": [],
+      "verboseLevel": 0
+    },
+    "loggingChannel": {
+      "loggingChannelId": "",
+      "verboseLevel": 2
     }
+  }
 }

docs/arch/ADR_01.md

@@ -17,8 +17,8 @@ this should be a fairly pure, from the ground up representation of my plans.
 
 I want:
 
--   A way for developers to define and reference dependencies easily, without ever needing to touch the core.
--   Useful error messages that are returned when a command is used, that explain what was not available, and (maybe) why
+- A way for developers to define and reference dependencies easily, without ever needing to touch the core.
+- Useful error messages that are returned when a command is used, that explain what was not available, and (maybe) why
 
 A module could have a list of dependencies passed to the constructor, and before execution, the executor can verify that all dependencies are ready to be accessed.
 If any of the dependencies are not accessible, an error message could returned that's actually helpful, maybe something along the lines of "This command has unmet dependencies: \[deps\]"

docs/design.md

@@ -8,23 +8,23 @@ Because this is being built as a replacement to TechSupportBot, there is some cr
 
 Minimum targets include:
 
--   Message logging. This implementation should log messages in a mirrored Logging category. This implementation should handle message events (creation, editing, deletion), and automatically create logging threads that mirror the logged channel. The implementation should handle the massive scale that comes with logging a high volume of messages, and support manual logging, like commands used.
--   Factoids. This implementation should include the management of factoids (creation, editing, documenting, and deleting). It should not be bound to a single prefix.
--   User moderation. This implementation should include per-channel message logging, as well as an easy framework to moderate users (kick, ban, time out)
--   Support for unit tests
--   Simple deployment. Deployment should require minimal configuration. a Makefile should be used to simplify processes.
+- Message logging. This implementation should log messages in a mirrored Logging category. This implementation should handle message events (creation, editing, deletion), and automatically create logging threads that mirror the logged channel. The implementation should handle the massive scale that comes with logging a high volume of messages, and support manual logging, like commands used.
+- Factoids. This implementation should include the management of factoids (creation, editing, documenting, and deleting). It should not be bound to a single prefix.
+- User moderation. This implementation should include per-channel message logging, as well as an easy framework to moderate users (kick, ban, time out)
+- Support for unit tests
+- Simple deployment. Deployment should require minimal configuration. a Makefile should be used to simplify processes.
 
 Non-critical high priority targets:
 
--   Google CSE (image search, text search, youtube, pagination)
+- Google CSE (image search, text search, youtube, pagination)
 
 Non-critical targets:
 
--   Complete extension parity with TechSupportBot
+- Complete extension parity with TechSupportBot
 
 ## Non-targets
 
--   Multi-server support. This proves to increase configuration, and I feel that the tradeoff of computational power for running multiple instances is worth it.
+- Multi-server support. This proves to increase configuration, and I feel that the tradeoff of computational power for running multiple instances is worth it.
 
 # Design Choices
 
@@ -41,8 +41,8 @@ TypeScript was chosen to allow for greater resiliency over standard JavaScript.
 
 While there are many pros to this decision, there are some drawbacks to be made aware of.
 
--   Resiliency. Javascript and Typescript do not have as robust handling of errors as some alternatives, like Rust. We should try to mitigate this by making use of the `Promise` pattern where possible.
--   Performance. Javascript and Typescript are less performant than other possible language choices, however I feel that the performance is still sufficient, and the positives that come with the Discord.js ecosystem outweigh the performance disadvantage.
+- Resiliency. Javascript and Typescript do not have as robust handling of errors as some alternatives, like Rust. We should try to mitigate this by making use of the `Promise` pattern where possible.
+- Performance. Javascript and Typescript are less performant than other possible language choices, however I feel that the performance is still sufficient, and the positives that come with the Discord.js ecosystem outweigh the performance disadvantage.
 
 Kubernetes was chosen because it offers features like Service Discovery and Probing. It would allow for the creation of resiliency clustering. This will introduce initial development complexity, but careful documentation and configuration will mitigate this. The ability to run resiliency nodes on different devices would avoid reliability being dependant on a single server, as this has presented issues in the past.
 

docs/guidelines.md

@@ -6,63 +6,63 @@ Please refer to the resources list at the bottom of this section for more commen
 
 Code should be thouroughly commented and documented, especially the `core`. Docstrings should be used liberally, and should be in the following locations.
 
--   At the top of files. This docstring should contain a high level summary of the code contained in the file. The below example is for a `ping` module
+- At the top of files. This docstring should contain a high level summary of the code contained in the file. The below example is for a `ping` module
 
 ```typescript
 /*
  * Command that sends an embed containing uptime, meant to indicate that the bot is running.
  */
 ```
 
--   Variable definitions. This docstring should at minimum contain a type.
--   Class definitions. This docstring should contain a description of the class
--   Function definitions. This docstring should explain what the function does, as well as the types of all arguments and return values.
+- Variable definitions. This docstring should at minimum contain a type.
+- Class definitions. This docstring should contain a description of the class
+- Function definitions. This docstring should explain what the function does, as well as the types of all arguments and return values.
 
 There are more usecases where docstrings might be used, but they should be used in all the above cases unless you are confident it is not needed. Should you need to add comments later, mark the relevant section with a `TODO` comment.
 
 Comments should adhere to the best practices linked below
 
 ## Documentation
 
--   https://www.typescriptlang.org/docs/handbook/jsdoc-supported-types.html
+- https://www.typescriptlang.org/docs/handbook/jsdoc-supported-types.html
 
 ## Best practices
 
--   https://stackoverflow.blog/2021/12/23/best-practices-for-writing-code-comments/
--   https://mitcommlab.mit.edu/broad/commkit/coding-and-comment-style/
+- https://stackoverflow.blog/2021/12/23/best-practices-for-writing-code-comments/
+- https://mitcommlab.mit.edu/broad/commkit/coding-and-comment-style/
 
 # Whitespace
 
 ## Spaces
 
--   There should be one space after a comma, none before. A newline may also be used if you are formatting an object or array with JSON style formatting, with a newline after every declaration.
--   There should be one space on either side of an assignment operator or boolean comparison. Correct formatting of this will be structured similar to `val = thing`, or `val >= thing`.
--   Statements (`if`, `for`, `while`, `function` are to be formatted with a space between the identifier, the arguments, and the context. Correct formatting may look like:
+- There should be one space after a comma, none before. A newline may also be used if you are formatting an object or array with JSON style formatting, with a newline after every declaration.
+- There should be one space on either side of an assignment operator or boolean comparison. Correct formatting of this will be structured similar to `val = thing`, or `val >= thing`.
+- Statements (`if`, `for`, `while`, `function` are to be formatted with a space between the identifier, the arguments, and the context. Correct formatting may look like:
 
 ```javascript
 if (val == thing) {
-    doTheThing();
+  doTheThing();
 }
 ```
 
 ## Tabs
 
--   Tabs are to be composed of 4 spaces.
+- Tabs are to be composed of 4 spaces.
 
 ## Newlines
 
--   Newlines are to be LF.
--   Preferred syntax for files includes two or more newlines after library inclusions, one newline after function declarations, and wherever needed to seperate code into logical sections.
+- Newlines are to be LF.
+- Preferred syntax for files includes two or more newlines after library inclusions, one newline after function declarations, and wherever needed to seperate code into logical sections.
 
 # Variable Names
 
 Proper variable naming greatly contributes to the readability and maintainability of code. Names should not be abbreviated in the core, and abbreviation should be kept to a minimum during module development, especially regarding function calls.
 Some general rules to follow:
 
--   Names should denote single values vs plural values. If a name is denoting type, it's generally not a good variable name. Where a good name for an array of dog names might be `dogs`, a bad name could be `dog` or `dogsArray`.
--   Names should generally be pronounceable, if you can't pronounce a variable name, it may not be a good description of the purpose of the variable.
--   Don't use different words for the same meaning. Having variables named `parsedData`, `processedDta`, and `parsedData` can lead to confusion, and is an indication of badly named variables.
--   Functions should be a verb or verb phrase (generally a verb followed by a noun).
+- Names should denote single values vs plural values. If a name is denoting type, it's generally not a good variable name. Where a good name for an array of dog names might be `dogs`, a bad name could be `dog` or `dogsArray`.
+- Names should generally be pronounceable, if you can't pronounce a variable name, it may not be a good description of the purpose of the variable.
+- Don't use different words for the same meaning. Having variables named `parsedData`, `processedDta`, and `parsedData` can lead to confusion, and is an indication of badly named variables.
+- Functions should be a verb or verb phrase (generally a verb followed by a noun).
 
 ## Resources
 

jsdoc.json

@@ -1,28 +1,28 @@
 {
-    "source": {
-        "includePattern": ".+\\.(j|t)s(doc|x)?$",
-        "include": ["src/core", "README.md", "package.json"]
-    },
-    "plugins": ["plugins/markdown", "better-docs/typescript"],
-    "opts": {
-        "encoding": "utf8",
-        "readme": "./README.md",
-        "destination": "docs/jsdoc/",
-        "recurse": true,
-        "verbose": true,
-        "template": "./node_modules/clean-jsdoc-theme",
-        "theme_opts": {
-            "default_theme": "dark"
-        }
-    },
-    "templates": {
-        "cleverLinks": true
-    },
-    "markdown": {
-        "hardwrap": false,
-        "idInHeadings": true
-    },
-    "tags": {
-        "allowUnknownTags": ["optional"]
+  "source": {
+    "includePattern": ".+\\.(j|t)s(doc|x)?$",
+    "include": ["src/core", "README.md", "package.json"]
+  },
+  "plugins": ["plugins/markdown", "better-docs/typescript"],
+  "opts": {
+    "encoding": "utf8",
+    "readme": "./README.md",
+    "destination": "docs/jsdoc/",
+    "recurse": true,
+    "verbose": true,
+    "template": "./node_modules/clean-jsdoc-theme",
+    "theme_opts": {
+      "default_theme": "dark"
     }
+  },
+  "templates": {
+    "cleverLinks": true
+  },
+  "markdown": {
+    "hardwrap": false,
+    "idInHeadings": true
+  },
+  "tags": {
+    "allowUnknownTags": ["optional"]
+  }
 }