apps/discord-bot/src/structures/managers/messageCommands.ts (1)

11-11: ⚠️ Potential issue

Security: Avoid using file:/// protocol in dynamic imports

Similar to the EventManager, using the file:/// protocol in dynamic imports poses security risks.

apps/discord-bot/src/events/errorManager.ts (3)

1-15: Consider implementing a more robust error handling strategy

The current error handling implementation could be enhanced with several production-ready features.

Recommendations:

1. Implement error categorization to handle different types of errors differently
2. Add error reporting service integration (e.g., Sentry)
3. Implement recovery mechanisms for non-fatal errors
4. Add rate limiting for error logging to prevent spam
5. Include context information in error logs (e.g., command being executed, user info)
6. Consider implementing a custom error class for bot-specific errors

Example implementation structure:

import type { ClientEvent } from '../types.js';

interface BotError extends Error {
  context?: {
    command?: string;
    userId?: string;
    guildId?: string;
  };
}

class ErrorManager {
  private static errorCount = 0;
  private static readonly ERROR_THRESHOLD = 10;
  private static readonly RESET_INTERVAL = 60000; // 1 minute

  static initialize(): void {
    setInterval(() => {
      this.errorCount = 0;
    }, this.RESET_INTERVAL);
  }

  static handleError(error: BotError): void {
    this.errorCount++;
    
    if (this.errorCount > this.ERROR_THRESHOLD) {
      console.error('[CRITICAL] Error threshold exceeded');
      process.exit(1);
    }

    // Log error with context
    console.error('[Bot Error]', {
      name: error.name,
      message: error.message,
      stack: error.stack,
      context: error.context
    });

    // TODO: Add error reporting service integration
  }
}

export const Event: ClientEvent = {
  name: 'errorManager',
  customEvent: true,
  run: (): void => {
    ErrorManager.initialize();

    process.on('unhandledRejection', (error: Error) => {
      ErrorManager.handleError(error as BotError);
    });

    process.on('uncaughtException', (error: Error) => {
      ErrorManager.handleError(error as BotError);
      process.exit(1);
    });
  },
};

---

1-2: Consider using more specific error types

The current implementation uses the generic Error type, which might miss specific Discord.js error properties.

Consider using Discord.js specific error types:

- import type { ClientEvent } from '../types.js'
+ import type { ClientEvent } from '../types.js'
+ import { DiscordAPIError, HTTPError } from 'discord.js'

---

4-7: Add JSDoc documentation for the event handler

Adding documentation will help other developers understand the purpose and behavior of this error manager.

Consider adding this documentation:

+/**
+ * Global error handler for the Discord bot
+ * Catches and processes unhandled rejections and uncaught exceptions
+ * to prevent the bot from crashing silently
+ */
export const Event: ClientEvent = {
  name: 'errorManager',
  customEvent: true,
  run: (): void => {

apps/discord-bot/src/structures/commandOptions/onlyChannels.ts (2)

5-8: Consider splitting complex condition for better readability

The compound condition could be more maintainable if split into separate checks.

-  if (!command.onlyChannels || !Array.isArray(command.onlyChannels) || !message.guild)
+  if (!command.onlyChannels) return true
+  if (!Array.isArray(command.onlyChannels)) return true
+  if (!message.guild) return true

---

27-27: Fix grammatical error in error message

There's a grammatical error in the error message description.

-  .setDescription(`The command you tried to execute cannot be ran in the current channel. Please execute the command in of these authorized channels:\n${command.onlyChannels.map(channelId => `↳ <#${channelId}>`).join('\n')}`)
+  .setDescription(`The command you tried to execute cannot be run in the current channel. Please execute the command in one of these authorized channels:\n${command.onlyChannels.map(channelId => `↳ <#${channelId}>`).join('\n')}`)

apps/discord-bot/src/structures/commandOptions/onlyGuilds.ts (1)

5-8: Consider improving the early return condition readability

The current condition combines multiple checks in one line. Consider breaking it down for better maintainability.

-  if (!command.onlyGuilds || !Array.isArray(command.onlyGuilds) || !message.guild)
+  if (!command.onlyGuilds) return true;
+  if (!Array.isArray(command.onlyGuilds)) return true;
+  if (!message.guild) return true;

apps/discord-bot/src/interactions/slashCommands/ping.ts (1)

5-5: Enhance command description for better user experience

The current description "Pong" is too brief. Consider providing a more informative description that explains what the command does.

-  description: 'Pong',
+  description: 'Check the bot\'s current WebSocket latency',

apps/discord-bot/src/messageCommands/ping.ts (2)

4-15: Consider adding cooldown mechanism

To prevent potential abuse, consider implementing a cooldown mechanism for the ping command.

Would you like me to provide an implementation of a cooldown system that can be reused across commands?

---

1-15: Add JSDoc documentation

Consider adding JSDoc documentation to improve code maintainability and help other contributors understand the command's purpose and usage.

+/**
+ * @command Ping
+ * @description Check the bot's current WebSocket latency
+ * @alias pong
+ * @example !ping
+ */
 export const MsgCommand: MessageCommand = {

apps/discord-bot/src/structures/commandOptions/guildCooldown.ts (1)

5-8: Consider improving function name and early return clarity.

While the implementation is correct, consider these improvements:

1. The function name could be more concise (e.g., checkGuildCooldown)
2. The early return conditions could be more explicit by separating them into individual checks

-export async function guildCooldownFN(
+export async function checkGuildCooldown(
   client: DiscordClient,
   message: Message | Interaction<'cached'>,
   command: AnyCommand,
   interactionType: InteractionTypeOptions
 ): Promise<boolean> {
-  if (!command.guildCooldown || Number.isNaN(command.guildCooldown) || !message.guild)
+  if (!command.guildCooldown) {
+    return true
+  }
+  if (Number.isNaN(command.guildCooldown)) {
+    return true
+  }
+  if (!message.guild) {
     return true
+  }

apps/discord-bot/src/messageCommands/eval.ts (2)

28-39: Clarify optional flags usage
The code removes certain flags (e.g., --silent) and modifies the snippet based on others. Consider documenting or logging the flags applied, so it’s clear why and how certain lines are removed or transformed during runtime.

---

60-66: Restrict error content
In case of errors, the entire error message (potentially including stack traces) is sent to the channel. Even though restricted to owners, you may want to ensure that secret details such as environment variables or stack details are not exposed.

apps/discord-bot/src/bot.ts (3)

17-33: Consider error handling around client login
No try/catch is wrapping the login process. If the token is invalid, the script may fail silently. Consider wrapping this in a try/catch to provide explicit error logs or fallback.

---

35-45: Persist cooldown management carefully
The JSON file stands as a single point of failure. If the file is removed or corrupted, cooldown data is lost. Consider a persistent store or error handling to gracefully recover from file I/O failures.

---

46-53: Tests and documentation
No tests or user-facing documentation accompany this scaffold, per your PR notes. Consider adding basic test coverage for the initialization flow and step-by-step instructions for new contributors.

apps/discord-bot/src/events/interactionCreate.ts (2)

8-16: Provide user feedback if slash command not found
Currently, the code returns without notifying the user if a slash command doesn’t exist. For clarity, consider responding with a short message like “Command not recognized.”

---

18-26: Autocomplete fallback
Same as slash commands, if an autocomplete is not recognized or not implemented, consider providing a fallback or log message for debugging.

apps/discord-bot/src/structures/managers/slashCommands.ts (3)

38-40: Skip reason
In case slash commands are ignored for not having a name or description, consider logging the skip reason. It helps debugging misconfigured commands.

---

74-76: Context menu validation
Similar to slash commands, a short log line would help you track which context menus are ignored.

---

99-113: Handle the commented out error block
The error handling is commented out. Consider reintroducing this to provide feedback if guild or global command registration fails.

apps/discord-bot/src/types.ts (4)

19-47: Extensive command options may benefit from grouping or partials.
You have a large set of optional properties for permissions, cooldown, and restrictions. Consider grouping related properties (e.g., all cooldown options) or using separate partial interfaces for improved maintainability.

---

49-55: MessageCommand interface is clear.
Returning void or Promise is straightforward for message commands. Consider specifying an explicit Promise to standardize asynchronous command patterns.

---

57-63: Event handling remains flexible.
The generic run signature is flexible but can obscure type safety. If feasible, refine argument typings for better IntelliSense and error checking, rather than using (...args: any[]).

---

96-105: SlashCommand interface is well-formed.
Everything is consistent with standard slash commands usage. Possibly consider an additional property to specify ephemeral replies if desired in the future.

apps/discord-bot/src/interactions/buttons/deleteOutput.ts (1)

1-9: Handle potential message state errors.
The command strictly deletes the interaction’s message. Consider adding checks to handle ephemeral or already-deleted messages, as Discord may throw errors if the message is no longer available.

apps/discord-bot/src/interactions/modalForms/exampleModal.ts (1)

1-10: Simple and effective modal usage.
The reply handling is straightforward. Consider making the reply ephemeral if it only concerns the user submitting the modal to keep the channel clutter-free.

apps/discord-bot/src/interactions/selectMenus/selectMenuExample.ts (1)

4-12: Consider if this example code should be in production

This appears to be template/example code. Consider either:

1. Removing it if not needed for production
2. Making it more meaningful for actual use
3. Moving it to a examples/ or templates/ directory

Also, add JSDoc documentation for the exported Menu constant.

+/**
+ * Example select menu handler demonstrating basic Discord interaction patterns.
+ * @todo Replace with actual implementation or move to examples directory
+ */
 export const Menu: SelectMenu = {

apps/discord-bot/src/structures/managers/selectMenus.ts (1)

15-16: Simplify optional chaining usage

The double optional chaining on buttonCommand?.ignore is redundant since we've already checked for buttonCommand's existence.

- if (!selectMenu?.ignore && selectMenu?.name)
+ if (!selectMenu.ignore && selectMenu.name)

apps/discord-bot/src/interactions/contextMenus/getUsername.ts (1)

9-9: Remove unnecessary type assertion

The type assertion can be avoided by properly typing the interaction parameter in the function signature.

- run: (interaction): void => {
-   interaction = interaction as UserContextMenuCommandInteraction<'cached'>
+ run: (interaction: UserContextMenuCommandInteraction<'cached'>): Promise<void> => {

apps/discord-bot/src/structures/managers/buttonCommands.ts (2)

5-18: Consider creating a base manager class to reduce duplication

The ButtonManager implementation is very similar to SelectMenuManager and other interaction managers. Consider creating a base manager class to reduce code duplication.

Example implementation:

abstract class BaseInteractionManager<T> {
  protected abstract readonly interactionType: string;
  
  async initialize(client: DiscordClient, rootPath: string): Promise<void> {
    const files = fileReader(`${rootPath}/interactions/${this.interactionType}`);
    if (!files.length) return;

    for (const file of files) {
      try {
        const interaction: T = (await import(file))?.export;
        if (!interaction) continue;

        if (!interaction.ignore && interaction.name) {
          this.addToClient(client, interaction);
        }
      } catch (error) {
        console.error(`Failed to load ${this.interactionType} from ${file}:`, error);
      }
    }
  }

  protected abstract addToClient(client: DiscordClient, interaction: T): void;
}

class ButtonManager extends BaseInteractionManager<ButtonCommand> {
  protected readonly interactionType = 'buttons';
  
  protected addToClient(client: DiscordClient, button: ButtonCommand): void {
    client.buttonCommands?.set(button.name, button);
  }
}

---

15-16: Fix redundant optional chaining

Similar to the SelectMenuManager, the optional chaining is redundant here.

- if (!buttonCommand?.ignore && buttonCommand?.name)
+ if (!buttonCommand.ignore && buttonCommand.name)

apps/discord-bot/src/messageCommands/callSelectMenu.ts (1)

10-26: Consider extracting UI strings to constants

The menu text and options are hardcoded. Consider extracting these to constants or a configuration file for easier maintenance and localization.

Example:

const MENU_STRINGS = {
  content: 'Cookies SelectMenu',
  placeholder: 'Free Cookies!',
  options: [{
    label: 'Click for cookies!',
    description: 'Freeee!',
    value: 'CookieBox',
  }]
} as const;

apps/discord-bot/src/interactions/slashCommands/exampleModal.ts (1)

4-6: Add JSDoc documentation for the slash command

Add documentation to describe the command's purpose, usage, and parameters.

+/**
+ * Test modal command to demonstrate modal functionality
+ * @example
+ * /testmodal
+ */
 export const Slash: SlashCommand = {
   name: 'testmodal',
   description: 'Test Modal',

apps/discord-bot/src/structures/commandOptions/onlyUsers.ts (3)

9-11: Simplify user ID check

The current user ID check is overly complex and could be simplified.

-  if (command.onlyUsers.includes(((message as Interaction<'cached'>).user ?? (message as Message).author)?.id)) {
+  const userId = 'user' in message ? message.user.id : message.author.id;
+  if (command.onlyUsers.includes(userId)) {
     return true
   }

---

18-29: Enhance error message with allowed users information

The current error message could be more helpful by listing the allowed users.

     message.channel.send({
       embeds: [new EmbedBuilder()
         .setColor('DarkRed')
         .setTimestamp()
         .setAuthor({
           name: message.member?.user.globalName ?? message.member?.user.username ?? '',
           iconURL: message.member?.user.displayAvatarURL(),
         })
         .setThumbnail(client.user.displayAvatarURL())
-        .setDescription('The command you tried to execute couldn\'t be ran as you are not one of the authorized users.'),
+        .setDescription('This command is restricted to specific users.')
+        .addFields({
+          name: 'Authorized Users',
+          value: command.onlyUsers.map(id => `<@${id}>`).join(', ') || 'None specified'
+        }),
       ],
     })

---

31-31: Remove unnecessary semicolon

The semicolon after the else block is unnecessary and should be removed.

-  };
+  }

🧰 Tools

🪛 Biome (1.9.4)

[error] 31-31: This code is unreachable

... because either this statement, ...

... this statement, ...

... this statement, ...

... this statement, ...

... or this statement will return from the function beforehand

(lint/correctness/noUnreachable)

apps/discord-bot/src/structures/commandOptions/onlyRoles.ts (2)

18-29: Enhance error message with role names

Add role names alongside mentions for better clarity.

     message.channel.send({
       embeds: [new EmbedBuilder()
         .setColor('DarkRed')
         .setTimestamp()
         .setAuthor({
           name: message.member?.user.globalName ?? message.member?.user.username ?? '',
           iconURL: message.member?.user.displayAvatarURL(),
         })
         .setThumbnail(client.user.displayAvatarURL())
-        .setDescription(`The command you tried to execute couldn't be executed as you are missing one of these required roles:\n${command.onlyRoles.map((roleID: string) => `↳ <@&${roleID}>`).join('\n')}`),
+        .setDescription('This command requires specific roles to execute.')
+        .addFields({
+          name: 'Required Roles',
+          value: command.onlyRoles.map(roleID => {
+            const role = message.guild?.roles.cache.get(roleID);
+            return `↳ <@&${roleID}>${role ? ` (${role.name})` : ''}`;
+          }).join('\n') || 'None specified'
+        }),
       ],
     })

---

31-31: Remove unnecessary semicolon

The semicolon after the else block is unnecessary and should be removed.

-  };
+  }

🧰 Tools

🪛 Biome (1.9.4)

[error] 31-32: This code is unreachable

... because either this statement, ...

... this statement, ...

... this statement, ...

... this statement, ...

... or this statement will return from the function beforehand

(lint/correctness/noUnreachable)

apps/discord-bot/src/structures/commandOptions/ownerOnly.ts (2)

24-26: Simplify user display name retrieval

The current nested nullish coalescing could be simplified for better readability.

-            name: message.member?.user.globalName ?? message.member?.user.username ?? '',
-            iconURL: message.member?.user.displayAvatarURL(),
+            name: message.member?.user.displayName ?? 'Unknown User',
+            iconURL: message.member?.user.displayAvatarURL() ?? client.user.defaultAvatarURL,

---

32-32: Remove unnecessary semicolon

The semicolon after the closing brace is unnecessary.

-  };
+  }

🧰 Tools

🪛 Biome (1.9.4)

[error] 32-32: This code is unreachable

... because either this statement, ...

... this statement, ...

... this statement, ...

... this statement, ...

... or this statement will return from the function beforehand

(lint/correctness/noUnreachable)

apps/discord-bot/src/events/messageCreate.ts (1)

8-8: Consider adding rate limiting

The message handler should implement rate limiting to prevent spam and abuse.

Would you like me to provide an implementation for a rate limiting mechanism?

apps/discord-bot/src/structures/commandOptions/anyUserPermissions.ts (1)

1-31: Add unit tests for permission checks

The PR description mentions that tests are missing. This security-critical functionality should be thoroughly tested.

Would you like me to help create unit tests for the permission checking functionality?

apps/discord-bot/src/structures/commandOptions/anyClientPermissions.ts (2)

17-28: Add error handling for message sending

The message sending operation could fail silently. Consider adding error handling and returning appropriate feedback.

-    message.channel.send({
+    await message.channel.send({
       embeds: [new EmbedBuilder()
         // ... embed configuration ...
       ],
-    })
+    }).catch(error => {
+      console.error('Failed to send permission error message:', error);
+    });

---

1-31: Consider extracting common embed creation logic

The embed creation logic is duplicated across multiple permission check files. Consider extracting it into a shared utility function.

Would you like me to help create a shared utility for creating error embeds?

apps/discord-bot/src/structures/commandOptions/allUserPermissions.ts (1)

1-34: Standardize permission types across files

The permission types are inconsistent across files (bigint vs PermissionsString). Consider standardizing the approach.

Consider using PermissionsString consistently across all permission-related files for better type safety and maintainability.

🧰 Tools

🪛 Biome (1.9.4)

[error] 33-34: This code is unreachable

... because either this statement, ...

... this statement, ...

... this statement, ...

... this statement, ...

... or this statement will return from the function beforehand

(lint/correctness/noUnreachable)

apps/discord-bot/src/structures/commandOptions/allClientPermissions.ts (2)

1-34: Consider creating a shared permission checking module

There's significant code duplication across the permission checking files. Consider creating a shared module for permission checking logic.

I recommend creating a PermissionChecker class that encapsulates the common permission checking logic and provides methods for both client and user permission checks. This would:

1. Reduce code duplication
2. Centralize permission handling logic
3. Make it easier to maintain and modify permission checking behavior

Would you like me to help design this shared module?

🧰 Tools

🪛 Biome (1.9.4)

[error] 33-34: This code is unreachable

... because either this statement, ...

... this statement, ...

... this statement, ...

... this statement, ...

... or this statement will return from the function beforehand

(lint/correctness/noUnreachable)

---

1-34: Add unit tests for permission checking

Given that permission checking is critical for command execution, comprehensive unit tests should be added.

Would you like me to help create unit tests for the permission checking functionality? The tests should cover:

1. Various permission combinations
2. Edge cases with null/undefined values
3. Error message generation
4. Integration with command processing

🧰 Tools

🪛 Biome (1.9.4)

[error] 33-34: This code is unreachable

... because either this statement, ...

... this statement, ...

... this statement, ...

... this statement, ...

... or this statement will return from the function beforehand

(lint/correctness/noUnreachable)

apps/discord-bot/src/structures/commandOptions/processor.ts (1)

17-17: Add explicit return type and function name for better maintainability

The default export uses an anonymous arrow function without an explicit return type.

Consider this improvement:

-export default async (client: DiscordClient, message: Message | Interaction<'cached'>, command: AnyCommand, interactionType: InteractionTypeOptions) => {
+export default async function processCommandOptions(
+  client: DiscordClient,
+  message: Message | Interaction<'cached'>,
+  command: AnyCommand,
+  interactionType: InteractionTypeOptions
+): Promise<boolean> {

apps/discord-bot/src/structures/commandOptions/globalCooldown.ts (1)

32-32: Simplify timestamp calculation and improve readability

The double Math.floor is unnecessary and makes the code harder to read.

-        .setDescription(`You are currently at cooldown. Please try again in <t:${Math.floor(Math.floor(storedTime + command.globalCooldown) / 1000)}:R>.`),
+        const nextAvailableTime = Math.floor((storedTime + command.globalCooldown) / 1000);
+        .setDescription(`You are currently at cooldown. Please try again in <t:${nextAvailableTime}:R>.`),

apps/discord-bot/README.md (1)

18-20: Fix grammar and style in changelog

Minor grammar issues in the changelog text.

- Added dependency of `simple-json-db` for the cooldown system as i rage quit and can't do it with `fs` myself.
+ Added dependency on `simple-json-db` for the cooldown system as I couldn't implement it with `fs`.

🧰 Tools

🪛 LanguageTool

[uncategorized] ~19-~19: Did you mean “I”?
Context: ...ple-json-dbfor the cooldown system as i rage quit and can't do it withfs` mys...

(I_LOWERCASE_PREMIUM)

---

[misspelling] ~19-~19: This word is normally spelled with a hyphen.
Context: ...e-json-dbfor the cooldown system as i rage quit and can't do it withfs` myself. - Fix...

(EN_COMPOUNDS_RAGE_QUIT)

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

-  if (command.onlyGuilds.includes(message.guild?.id)) {
+  if (command.onlyGuilds.includes(message.guild.id)) {

-  if (command.onlyGuilds.includes(message.guild?.id)) {
+  if (command.onlyGuilds.includes(message.guild.id)) {

#!/bin/bash
# Search for command registration and guild ID validation
ast-grep --pattern 'command.onlyGuilds = $_'

#!/bin/bash
# Let's try a different approach to find guild ID validation patterns
# First, let's look for files that mention onlyGuilds
rg -l "onlyGuilds"

# Then search for any validation patterns related to guild IDs
rg "guild.*id" -A 2 -B 2

# Also search for command registration patterns
ast-grep --pattern 'new Command({
  $$$
})'

#!/bin/bash
# Let's check the Command type definition and onlyGuilds property
cat apps/discord-bot/src/types.ts

# Also check the README for any documentation about onlyGuilds
cat apps/discord-bot/README.md

# And check the command processor to understand the validation flow
cat apps/discord-bot/src/structures/commandOptions/processor.ts

apps/discord-bot/template-server/src/storage.ts (1)

1-1: Consider using persistent storage instead of in-memory Map

Using an in-memory Map for token storage has several limitations:

• Data is lost when the server restarts
• Doesn't scale across multiple instances
• No persistence guarantees

Consider using a persistent storage solution like Redis or a database for token storage in production. This would provide:

• Data persistence across restarts
• Horizontal scalability
• Better security features
• Built-in encryption capabilities

Would you like me to provide an example implementation using Redis or a database?

apps/discord-bot/template-server/src/discord.ts (2)

36-60: Add clearer error-handling strategies.
The error is thrown when the response is not okay, but consider adding fallback logic or retry attempts to mitigate transient failures. This can be helpful if Discord’s API has intermittent issues.

---

119-126: Avoid hardcoding platform_name.
"Example Linked Role Discord Bot" is hardcoded. If you intend to change the bot branding or re-purpose the same code for multiple bots, consider placing this value in configuration.

apps/discord-bot/template-server/src/register.ts (1)

7-54: Check numeric type definitions for metadata.
The numeric type integers (e.g., 2, 7) have domain-specific meanings in Discord’s role-connection metadata schema. To improve maintainability, define constants or an enum referencing official documentation, making the code self-documenting and less prone to mistakes if these values change.

apps/discord-bot/template-server/src/server.ts (2)

59-62: Confirm state verification logic and error responses.
The 403 status code is appropriate for invalid states, but consider returning an explanatory message or a redirect to clarify for a user who might accidentally end up here.

---

64-65: Handle null or malformed OAuth code.
If the user arrives without a valid OAuth code, the request to get tokens will fail with a less specific error. Consider explicitly checking for a missing or invalid code before calling getOAuthTokens.

apps/discord-bot/template-server/README.md (2)

35-104: Add language specifiers to code blocks

For better syntax highlighting and documentation consistency, add language specifiers to the code blocks. For example:

-```
+```bash
 git clone https://github.com/discord/linked-roles-sample.git

This applies to all code blocks in the setup and running sections.

<details>
<summary>🧰 Tools</summary>

<details>
<summary>🪛 Markdownlint (0.37.0)</summary>

74-74: null
Dollar signs used before commands without showing output

(MD014, commands-show-output)

---

80-80: null
Dollar signs used before commands without showing output

(MD014, commands-show-output)

---

90-90: null
Dollar signs used before commands without showing output

(MD014, commands-show-output)

---

35-35: null
Fenced code blocks should have a language specified

(MD040, fenced-code-language)

---

41-41: null
Fenced code blocks should have a language specified

(MD040, fenced-code-language)

---

50-50: null
Fenced code blocks should have a language specified

(MD040, fenced-code-language)

---

60-60: null
Fenced code blocks should have a language specified

(MD040, fenced-code-language)

---

73-73: null
Fenced code blocks should have a language specified

(MD040, fenced-code-language)

---

79-79: null
Fenced code blocks should have a language specified

(MD040, fenced-code-language)

---

89-89: null
Fenced code blocks should have a language specified

(MD040, fenced-code-language)

---

95-95: null
Fenced code blocks should have a language specified

(MD040, fenced-code-language)

</details>

</details>

---

`114-118`: **Format URL as markdown link and add internal documentation references**

Please format the bare URL as a proper markdown link and consider adding references to internal documentation:

```diff
 - Read **[the tutorial](https://discord.com/developers/docs/tutorials/configuring-app-metadata-for-linked-roles)** for in-depth information.
-- Browse https://github.com/JustinBeckwith/fitbit-discord-bot/ for a more in-depth example using the Fitbit API
+- Browse [Fitbit Discord Bot Example](https://github.com/JustinBeckwith/fitbit-discord-bot/) for a more in-depth example using the Fitbit API
 - Join the **[Discord Developers server](https://discord.gg/discord-developers)** to ask questions about the API, attend events hosted by the Discord API team, and interact with other devs.
+- Check our [Internal Bot Development Guide](../docs/bot-development.md) for team-specific guidelines and best practices

🧰 Tools

🪛 Markdownlint (0.37.0)

117-117: null
Bare URL used

(MD034, no-bare-urls)

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

-git clone https://github.com/discord/linked-roles-sample.git
+git clone https://github.com/cuhacking/2025.git

apps/discord-bot/src/structures/commandOptions/onlyGuilds.ts (1)

18-32: ⚠️ Potential issue

Fix error message formatting and grammar issues

The error handling has several issues that need to be addressed:

         .setDescription(
-          `The command you tried to execute cannot be ran in the current guild. Please execute the command in of these authorized guilds:\n${command.onlyGuilds.map((guildID: string) => `↳ <#${guildID}>`).join('\n')}`,
+          `The command you tried to execute cannot be run in the current guild. Please execute the command in one of these authorized guilds:\n${command.onlyGuilds.map((guildID: string) => `↳ ${client.guilds.cache.get(guildID)?.name ?? guildID}`).join('\n')}`,
         )
       ],
     })
-    return false
-  };
+    return false
+  }

Changes:

1. Fixed grammar: "cannot be ran" → "cannot be run"
2. Fixed typo: "in of these" → "in one of these"
3. Replaced channel mentions with guild names
4. Removed unreachable semicolon

🧰 Tools

🪛 Biome (1.9.4)

[error] 31-32: This code is unreachable

... because either this statement, ...

... this statement, ...

... this statement, ...

... this statement, ...

... or this statement will return from the function beforehand

(lint/correctness/noUnreachable)

apps/discord-bot/src/events/errorManager.ts (1)

8-13: ⚠️ Potential issue

Uncomment and enhance error handling implementation

The error handlers are currently commented out, leaving the bot without any error management. This could lead to silent failures or unexpected crashes in production.

Additional enhancement: Consider implementing a custom error handling class to centralize error management and add structured logging:

class ErrorManager {
  private static formatError(error: Error) {
    return {
      name: error.name,
      message: error.message,
      stack: error.stack,
      timestamp: new Date().toISOString()
    };
  }

  static handleUnhandledRejection(error: Error) {
    console.error('[Unhandled Rejection]', this.formatError(error));
    // TODO: Add error reporting service integration
  }

  static handleUncaughtException(error: Error) {
    console.error('[Uncaught Exception]', this.formatError(error));
    // TODO: Add error reporting service integration
    
    // Gracefully shutdown after uncaught exception
    process.exit(1);
  }
}

process.on('unhandledRejection', ErrorManager.handleUnhandledRejection);
process.on('uncaughtException', ErrorManager.handleUncaughtException);

apps/discord-bot/src/structures/managers/events.ts (1)

10-23: ⚠️ Potential issue

Enhance event registration with proper error handling and type safety

Combining previous review suggestions with additional improvements for robust event handling.

-  for (const event of eventFiles) {
+  for (const eventFile of eventFiles) {
+    try {
+      // Validate event file path
+      if (!eventFile.endsWith('.js') && !eventFile.endsWith('.ts')) {
+        console.warn(`Skipping invalid event file: ${eventFile}`);
+        continue;
+      }
+
-      const clientEvent: ClientEvent = (await import(`file:///${event}`))?.Event
+      const clientEvent: ClientEvent = (await import(eventFile))?.Event
+
+      // Validate event structure
+      if (!clientEvent || typeof clientEvent !== 'object') {
+        console.warn(`Invalid event export in ${eventFile}`);
+        continue;
+      }
+
       if (clientEvent.ignore)
         continue
 
       client.events?.set(clientEvent.name, clientEvent)
 
       if (clientEvent.customEvent)
-        clientEvent.run(client)
+        await clientEvent.run(client)
       else if (clientEvent.name && clientEvent.runOnce)
-        client.once(clientEvent.name, (...args: unknown[]) => clientEvent.run(...args, client))
+        client.once(clientEvent.name, async (...args: Parameters<typeof clientEvent.run>) => {
+          try {
+            await clientEvent.run(...args, client);
+          } catch (error) {
+            console.error(`Error in event ${clientEvent.name}:`, error);
+          }
+        })
       else if (clientEvent.name)
-        client.on(clientEvent.name, (...args: unknown[]) => clientEvent.run(...args, client))
+        client.on(clientEvent.name, async (...args: Parameters<typeof clientEvent.run>) => {
+          try {
+            await clientEvent.run(...args, client);
+          } catch (error) {
+            console.error(`Error in event ${clientEvent.name}:`, error);
+          }
+        })
+    } catch (error) {
+      console.error(`Failed to load event from ${eventFile}:`, error);
+    }
   };

apps/discord-bot/src/events/messageCreate.ts (2)

11-28: ⚠️ Potential issue

Replace forEach with for...of for async operations

Using forEach with async operations can lead to race conditions and doesn't properly handle promise rejections.

-    PREFIX.forEach(async (botPrefix: string) => {
+    for (const botPrefix of PREFIX) {
+      try {
         if (!message.content.startsWith(botPrefix))
-          return
+          continue;
         // ... rest of the code ...
         if (processedCommandOptionsChecker)
           await command.run(client, message, args)
+      } catch (error) {
+        console.error('Error processing command:', error);
+        // Consider sending an error message to the channel
+      }
-    })
+    }

---

18-18: ⚠️ Potential issue

Add input validation for command arguments

The current implementation splits arguments without validation, which could lead to security issues.

apps/discord-bot/src/structures/commandOptions/anyUserPermissions.ts (2)

8-10: ⚠️ Potential issue

Improve permission check error handling

The permission check could fail silently if message.member is null.

---

26-26: 🛠️ Refactor suggestion

Enhance permission display in error message

The current implementation shows raw permission bits, which are not user-friendly.

apps/discord-bot/src/structures/commandOptions/anyClientPermissions.ts (1)

8-10: 🛠️ Refactor suggestion

Improve permission check robustness

The permission check could be simplified and made more robust by using optional chaining consistently.

apps/discord-bot/template-server/src/storage.ts (1)

1-1: Consider a more robust storage solution for production use

Using an in-memory Map for token storage has several limitations:

1. Tokens are lost when the server restarts
2. Not scalable across multiple instances
3. No persistence

Consider implementing a storage interface that can be backed by different implementations:

interface TokenStorage {
  set(key: string, value: DiscordTokens): Promise<void>;
  get(key: string): Promise<DiscordTokens | null>;
}

class InMemoryStorage implements TokenStorage {
  private store: Map<string, DiscordTokens> = new Map();
  
  async set(key: string, value: DiscordTokens): Promise<void> {
    this.store.set(key, value);
  }
  
  async get(key: string): Promise<DiscordTokens | null> {
    return this.store.get(key) || null;
  }
}

This allows for easy switching between storage backends (Redis, PostgreSQL, etc.) while maintaining type safety.

apps/discord-bot/src/structures/commandOptions/onlyChannels.ts (2)

5-8: Add additional parameter validation

While the current validation is good, consider adding these safety checks:

• Validate that client is not null
• Ensure command object has required properties

 export function onlyChannelsFN(client: DiscordClient, message: Message | Interaction<'cached'>, command: AnyCommand) {
+  if (!client || !message || !command) return false;
   if (!command.onlyChannels || !Array.isArray(command.onlyChannels) || !message.guild)
     return true

---

18-29: Consider limiting the channel list length

The channel list in the error message could become very long if there are many authorized channels. Consider:

• Limiting the number of channels shown
• Adding a "and X more..." suffix if truncated

-        .setDescription(`The command you tried to execute cannot be ran in the current channel. Please execute the command in of these authorized channels:\n${command.onlyChannels.map(channelId => `↳ <#${channelId}>`).join('\n')}`)
+        .setDescription(`The command you tried to execute cannot be ran in the current channel. Please execute the command in of these authorized channels:\n${command.onlyChannels.slice(0, 5).map(channelId => `↳ <#${channelId}>`).join('\n')}${command.onlyChannels.length > 5 ? `\n...and ${command.onlyChannels.length - 5} more channels` : ''}`)

apps/discord-bot/src/structures/commandOptions/onlyGuilds.ts (3)

5-8: Consider improving readability of the validation condition

The compound condition could be more readable if split into multiple lines.

-  if (!command.onlyGuilds || !Array.isArray(command.onlyGuilds) || !message.guild)
+  if (
+    !command.onlyGuilds ||
+    !Array.isArray(command.onlyGuilds) ||
+    !message.guild
+  )

---

9-12: Remove redundant optional chaining and unnecessary else block

The code can be simplified:

1. Optional chaining on message.guild?.id is redundant since we already checked !message.guild
2. The else block is unnecessary since the previous block returns

-  if (command.onlyGuilds.includes(message.guild?.id)) {
+  if (command.onlyGuilds.includes(message.guild.id)) {
     return true
-  }
-  else {

---

1-32: Consider architectural improvements

1. The error messages should be externalized for localization support.
2. As mentioned in the PR objectives, unit tests should be added to verify the behavior of this function.

Would you like me to:

1. Propose a structure for implementing localization?
2. Generate unit tests for this function?

🧰 Tools

🪛 Biome (1.9.4)

[error] 31-32: This code is unreachable

... because either this statement, ...

... this statement, ...

... this statement, ...

... this statement, ...

... or this statement will return from the function beforehand

(lint/correctness/noUnreachable)

apps/discord-bot/tsconfig.json (3)

3-3: Consider enabling incremental compilation for faster builds

Setting "incremental": true can significantly improve build times in development by reusing results from previous compilations.

-    "incremental": false,
+    "incremental": true,

---

21-21: Enable unused parameters checking

Having noUnusedParameters disabled can lead to confusing code with unused parameters. Consider enabling it to maintain cleaner function signatures.

-    "noUnusedParameters": false,
+    "noUnusedParameters": true,

---

1-33: Add source map support for better debugging

Consider adding source map generation for better debugging experience, especially useful when running the Discord bot in development.

Add the following option to your compiler options:

   "compilerOptions": {
+    "sourceMap": true,
     // ... other options
   }

apps/discord-bot/src/structures/commandOptions/ownerOnly.ts (3)

6-8: Improve readability of the initial command check

The initial check is correct but could be more explicit about its intent.

-  if (!command.ownerOnly || typeof command.ownerOnly !== 'boolean')
+  if (!command.ownerOnly || typeof command.ownerOnly !== 'boolean') {
+    // Command is not restricted to owners
     return true
+  }

---

18-30: Add error handling for embed creation

The embed creation could fail if user data is inaccessible.

-    message.channel.send({
+    try {
+      await message.channel.send({
       embeds: [
         new EmbedBuilder()
           .setColor('DarkRed')
           .setTimestamp()
           .setAuthor({
             name: message.member?.user.globalName ?? message.member?.user.username ?? '',
             iconURL: message.member?.user.displayAvatarURL(),
           })
           .setThumbnail(client.user.displayAvatarURL())
           .setDescription('The command you tried to run is __restricted__ for the developers of this bot and thus the command failed to execute.'),
       ],
-    })
+      })
+    } catch (error) {
+      console.error('Failed to send owner-only error message:', error)
+    }

---

31-33: Remove unnecessary semicolon and fix code structure

The trailing semicolon is unnecessary, and the code structure can be improved.

-    return false
-  };
+  return false
}

🧰 Tools

🪛 Biome (1.9.4)

[error] 32-32: This code is unreachable

... because either this statement, ...

... this statement, ...

... this statement, ...

... this statement, ...

... or this statement will return from the function beforehand

(lint/correctness/noUnreachable)

apps/discord-bot/README.md (1)

82-86: Improve clarity in technical notes

-Guild commands may take time to refresh if there are a large number of different guild commands.
+Guild commands may take time to refresh if there are many different guild commands.

🧰 Tools

🪛 LanguageTool

[style] ~86-~86: Specify a number, remove phrase, or simply use “many” or “numerous”
Context: ...s may take time to refresh if there are a large number of different guild commands. - Collections...

(LARGE_NUMBER_OF)

apps/discord-bot/src/structures/commandOptions/onlyUsers.ts (3)

5-8: Consider adding explicit type guard for onlyUsers array.

While the current check works, it could be more explicit about the expected type.

-  if (!command.onlyUsers || !Array.isArray(command.onlyUsers))
+  if (!Array.isArray(command.onlyUsers) || command.onlyUsers.length === 0)

---

18-31: Enhance error message and add null checks.

A few suggestions to improve the error handling:

1. Add null check for client.user
2. Provide more specific error message
3. Remove unnecessary semicolon

     message.channel.send({
       embeds: [new EmbedBuilder()
         .setColor('DarkRed')
         .setTimestamp()
         .setAuthor({
           name: message.member?.user.globalName ?? message.member?.user.username ?? '',
           iconURL: message.member?.user.displayAvatarURL(),
         })
-        .setThumbnail(client.user.displayAvatarURL())
+        .setThumbnail(client.user?.displayAvatarURL())
         .setDescription('The command you tried to execute couldn\'t be ran as you are not one of the authorized users.'),
       ],
     })
-    return false
-  };
+    return false;

Also consider enhancing the error message to be more specific:

-        .setDescription('The command you tried to execute couldn\'t be ran as you are not one of the authorized users.'),
+        .setDescription(`You don't have permission to use the \`${command.name}\` command. This command is restricted to specific users.`),

🧰 Tools

🪛 Biome (1.9.4)

[error] 31-31: This code is unreachable

... because either this statement, ...

... this statement, ...

... this statement, ...

... this statement, ...

... or this statement will return from the function beforehand

(lint/correctness/noUnreachable)

---

1-32: Consider enhancing the permission system architecture.

A few architectural suggestions:

1. Consider integrating with a broader permission system that can handle role-based access control (RBAC) alongside user-specific permissions
2. Add validation for user ID format to prevent invalid IDs in the onlyUsers array
3. Consider adding an interface for command options to better document the expected structure of onlyUsers, returnErrors, and returnOnlyUsersError

Would you like me to provide an example implementation of these architectural improvements?

🧰 Tools

🪛 Biome (1.9.4)

[error] 31-31: This code is unreachable

... because either this statement, ...

... this statement, ...

... this statement, ...

... this statement, ...

... or this statement will return from the function beforehand

(lint/correctness/noUnreachable)

apps/discord-bot/src/structures/commandOptions/onlyRoles.ts (1)

9-12: Optimize the role checking logic and remove unnecessary else block.

The role checking logic is correct but can be simplified by removing the unnecessary else block.

  if (command.onlyRoles.some((roleID: string) => message.member?.roles.cache.has(roleID))) {
    return true
  }
- else {

apps/discord-bot/src/events/ready.ts (2)

8-15: Add error handling for activity setup.

While the activity setup is correct, it should handle potential errors when setting the activity status.

-    client.user?.setActivity('Humans.', {
-      type: ActivityType.Watching,
-    })
+    try {
+      await client.user?.setActivity('Humans.', {
+        type: ActivityType.Watching,
+      })
+    } catch (error) {
+      console.error('Failed to set activity status:', error)
+    }

---

8-61: Consider architectural improvements for better maintainability.

1. Extract command loading logic into a separate service class for better separation of concerns and testability.
2. Consider implementing dependency injection for the client and configuration.
3. Add interfaces for command loaders to make them pluggable and easier to test.

Example service structure:

interface CommandLoader {
  loadCommands(): Promise<string[]>;
}

class SlashCommandLoader implements CommandLoader {
  constructor(private rootPath: string) {}
  async loadCommands(): Promise<string[]> {
    // Implementation
  }
}

class ReadyEventHandler {
  constructor(
    private client: DiscordClient,
    private slashCommandLoader: CommandLoader,
    private contextMenuLoader: CommandLoader
  ) {}
  
  async handle(): Promise<void> {
    // Implementation
  }
}

apps/discord-bot/template-server/src/register.ts (1)

3-6: Documentation needs enhancement

While the documentation explains the purpose, it should also mention:

• The expected format of the metadata
• The significance of the metadata types
• The impact of re-running this registration

 /**
  * Register the metadata to be stored by Discord. This should be a one time action.
  * Note: uses a Bot token for authentication, not a user token.
+ * 
+ * @see https://discord.com/developers/docs/resources/application-role-connection-metadata
+ * 
+ * @remarks
+ * - This updates the metadata schema for all users
+ * - Re-running will override existing metadata configuration
+ * - Types: number_lt(1), number_gt(2), number_eq(3), number_neq(4),
+ *         datetime_lt(5), datetime_gt(6), boolean_eq(7), boolean_neq(8)
  */

apps/discord-bot/template-server/README.md (1)

117-117: Fix markdown formatting issues

Several markdown formatting issues need to be addressed:

1. Use proper markdown link syntax for bare URLs
2. Add language identifiers to code blocks
3. Remove $ from command examples

-Browse https://github.com/JustinBeckwith/fitbit-discord-bot/ for a more in-depth example
+Browse [fitbit-discord-bot](https://github.com/JustinBeckwith/fitbit-discord-bot/) for a more in-depth example

Also update code blocks to include language identifiers:

-```
+```bash
 $ node server.js

<details>
<summary>🧰 Tools</summary>

<details>
<summary>🪛 Markdownlint (0.37.0)</summary>

117-117: null
Bare URL used

(MD034, no-bare-urls)

</details>

</details>

</blockquote></details>
<details>
<summary>apps/discord-bot/src/structures/managers/modalForms.ts (1)</summary><blockquote>

`5-5`: **Add JSDoc documentation for the ModalManager function**

Consider adding comprehensive JSDoc documentation to describe the function's purpose, parameters, and usage.

```diff
+/**
+ * Initializes and loads modal form handlers for the Discord bot
+ * @param client - The Discord client instance to register modal forms with
+ * @param rootPath - The root directory path where modal form files are located
+ * @throws {Error} When modal form files cannot be loaded or are invalid
+ */
 export async function ModalManager(client: DiscordClient, rootPath: string): Promise<void> {

apps/discord-bot/src/structures/commandOptions/anyClientPermissions.ts (1)

1-31: Consider extracting shared permission checking logic

This file shares significant code with anyUserPermissions.ts. Consider extracting common functionality into a shared utility.

Create a new utility file permissionUtils.ts:

import { DiscordClient, Interaction, Message, EmbedBuilder } from 'discord.js'
import { AnyCommand } from '../../types.js'

export function createPermissionErrorEmbed(
  client: DiscordClient,
  message: Message | Interaction<'cached'>,
  permissions: bigint[],
  errorMessage: string
): EmbedBuilder {
  return new EmbedBuilder()
    .setColor('DarkRed')
    .setTimestamp()
    .setAuthor({
      name: message.member?.user.globalName ?? message.member?.user.username ?? '',
      iconURL: message.member?.user.displayAvatarURL(),
    })
    .setThumbnail(client.user.displayAvatarURL())
    .setDescription(errorMessage)
}

This would reduce code duplication and make maintenance easier.

apps/discord-bot/src/structures/commandOptions/allUserPermissions.ts (2)

8-8: Simplify permission check with optional chaining

The permission check can be simplified while maintaining type safety.

-  const missingPermissions: Array<PermissionsString> | undefined = message.member?.permissions.missing(command.allUserPermissions)
+  const missingPermissions = message.member?.permissions?.missing(command.allUserPermissions)

---

24-27: Enhance user identification robustness

The user identification logic could be more robust by adding a fallback for the display name.

          .setAuthor({
-            name: message.member?.user.globalName ?? message.member?.user.username ?? '',
+            name: message.member?.user.globalName ?? message.member?.user.username ?? message.member?.user.tag ?? 'Unknown User',
            iconURL: message.member?.user.displayAvatarURL(),
          })

apps/discord-bot/src/events/interactionCreate.ts (1)

66-66: Remove unnecessary semicolon

The semicolon after the closing brace of the modal submit block is unnecessary.

    };
-  };
+  }

apps/discord-bot/src/types.ts (5)

5-17: Enhance module augmentation documentation

The comment could be more descriptive about the purpose of extending the Client interface.

Consider replacing the existing comment with:

-}; // Extends Discord.js Client to allow for the Map caches.
+}; // Extends Discord.js Client to add command registries and cooldown management capabilities

---

19-47: Enhance type safety and organization of CommandOptions

The interface could benefit from the following improvements:

1. Use more specific types for permissions
2. Group related properties using nested interfaces

Consider applying these changes:

import { PermissionsBitField } from 'discord.js';

interface CooldownOptions {
  channelCooldown?: number;
  globalCooldown?: number;
  guildCooldown?: number;
}

interface PermissionOptions {
  allClientPermissions?: Array<keyof typeof PermissionsBitField.Flags>;
  allUserPermissions?: Array<keyof typeof PermissionsBitField.Flags>;
  anyClientPermissions?: Array<keyof typeof PermissionsBitField.Flags>;
  anyUserPermissions?: Array<keyof typeof PermissionsBitField.Flags>;
}

interface TargetingOptions {
  allowInDms?: boolean;
  onlyChannels?: Array<string>;
  onlyGuilds?: Array<string>;
  onlyRoles?: Array<string>;
  onlyUsers?: Array<string>;
  ownerOnly?: boolean;
}

export interface CommandOptions extends 
  CooldownOptions,
  PermissionOptions,
  TargetingOptions {
  // Error handling options remain the same
  returnErrors?: boolean;
  // ...
}

---

49-114: Add JSDoc documentation for command interfaces

The command interfaces would benefit from detailed documentation explaining their purpose and usage.

Consider adding JSDoc comments like this:

/**
 * Represents a message-based command that is triggered by a prefix.
 * @example
 * const pingCommand: MessageCommand = {
 *   name: 'ping',
 *   run: (client, message) => {
 *     message.reply('Pong!');
 *   }
 * };
 */
export interface MessageCommand extends CommandOptions {
  // ... existing properties
}

---

115-116: Derive InteractionTypeOptions from AnyCommand type

To maintain consistency and reduce potential errors, consider deriving the interaction type options from the AnyCommand type.

Apply this change:

export type AnyCommand = MessageCommand | ButtonCommand | SelectMenu | ModalForm | SlashCommand | ContextMenu;

// Derive from AnyCommand to ensure consistency
export type InteractionTypeOptions = {
  [K in AnyCommand as K extends any ? K['constructor']['name'] : never]: K;
}[keyof AnyCommand];

---

1-116: Well-structured type system for Discord bot

The overall architecture provides a robust foundation for type-safe Discord bot development. The interfaces are well-designed and extensible, allowing for easy addition of new command types in the future.

Consider creating a separate documentation file (e.g., ARCHITECTURE.md) explaining the type system and providing examples of how to implement each command type.

apps/discord-bot/src/bot.ts (1)

5-5: Consider using a more robust database for cooldown management

Using simple-json-db for cooldown management might lead to scalability issues in production. Consider using Redis or a similar in-memory database for better performance and reliability with cooldowns.

Also applies to: 35-35

apps/discord-bot/src/structures/managers/slashCommands.ts (1)

11-27: Add JSDoc documentation for interfaces

The interfaces are well-structured but lack documentation. Consider adding JSDoc comments to improve maintainability:

+/**
+ * Represents a global Discord application command
+ * @interface GlobalCommandArray
+ */
 interface GlobalCommandArray {
   name: string
   nsfw?: boolean
   type: ApplicationCommandType
   description?: string
   options?: Array<SlashCommandOptions>
 };

+/**
+ * Represents guild-specific Discord application commands
+ * @interface GuildCommandObjects
+ */
 interface GuildCommandObjects {
   [key: string]: Array<{
     name: string
     nsfw?: boolean
     description?: string
     type: ApplicationCommandType
     options?: Array<SlashCommandOptions>
   }>
 };