Skip to content

Fix type usage on interaction.options.get{type} #31

Open
@MathyouMB

Description

@MathyouMB

As a developer, I want to properly type Discord interactions so that we don’t rely on @ts-ignore and can catch type errors at compile time.


🧠 Context

Currently, we are using @ts-ignore in multiple places when accessing properties from Discord interactions. This is a temporary workaround to avoid TypeScript errors, but it bypasses static type checking and can lead to runtime issues.

Examples of this can be found in:

  • src/infrastructure/discord/commands/unassignedIssues.ts
  • src/infrastructure/discord/commands/myIssues.ts

For instance:

Example @ts-ignore usage


🛠️ Implementation Plan

  1. Identify All @ts-ignore Usages

    • Scan the codebase for all usages of @ts-ignore related to Discord interaction data access
    • Focus on the two known files, but check others for consistency
  2. Correctly Type Interactions

    • Use the correct types from discord.js (e.g., ChatInputCommandInteraction)
    • Narrow interaction types using type guards where necessary (e.g., checking .isChatInputCommand() before accessing .options)

    Example:

    if (interaction.isChatInputCommand()) {
      const username = interaction.options.getString("username");
      // Use with confidence now
    }
  3. Remove All @ts-ignore Statements

    • After correcting the types, remove the corresponding @ts-ignore comments
  4. Add Type-Safe Wrappers or Helpers (Optional)

    • If access patterns repeat frequently, consider writing typed utility functions for common operations like .options.getString(...)
  5. Verify with Lint + Type Check

    • Run tsc and your linter to ensure no errors remain

✅ Acceptance Criteria

  • All @ts-ignore statements related to Discord interactions are removed from the codebase
  • interaction objects are correctly typed using discord.js types
  • Commands in unassignedIssues.ts and myIssues.ts access interaction data safely without type suppression
  • TypeScript compiles without error, and ESLint reports no type-ignorant code
  • Optional: Utility functions are introduced if repetitive interaction access patterns are observed

Metadata

Metadata

Assignees

Labels

Type

No type

Projects

Status

Ready

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions