/command support

[JasonEtco]

It'd be great to provide a /command abstraction - something like:

// In an issue/PR comment, `/pizza dominos pepperoni`
toolkit.command('pizza', async args => {
  // args -> ['dominos', 'pepperoni']
})

Or maybe...

// on instead of command
toolkit.on('pizza', async args => console.log(args))

---

Memorializing a conversation in this tweet:

---

I think that @mscoutermarsh should work on this 😎😈

[JasonEtco]

Hi @mscoutermarsh cc this tweet

[JasonEtco]

Random thought - this'd be a weird API, because we'd need to ensure that its only triggered by issue_comment events, and that thats clear in the docs. Internally, that might be:

class Toolkit {
  public command (name: string, handler: () => void) {
    if (this.context.event !== 'issue_comment') return
    // ...
  }
}

Folks can use the events options in the Toolkit constructor, but that's probably not enough.

[macklinu]

// In an issue/PR comment, `/pizza dominos pepperoni`
toolkit.command('pizza', async args => {
  // args -> ['dominos', 'pepperoni']
})

+1 to this API. I feel like registering a command like this would be more explicit than a generic event emitter/subscription API (e.g. toolkit.on('pizza')).

To clarify #17 (comment), are you stating that the only event a command can respond to is the issue_comment event and that the docs should explicitly state that? I think that makes sense as a potential user of this feature - can't think of another use case right now where a slash command handler would respond to a different GitHub event type.

[JasonEtco]

@macklinu thanks for sharing your thoughts!

To clarify #17 (comment), are you stating that the only event a command can respond to is the issue_comment event and that the docs should explicitly state that?

Yeah, it'd be to avoid a "gotcha" where folks use the API in an action that cannot, by definition, trigger the command. I'd want to avoid people accidentally thinking that a push might trigger a /command 😁

It might be worth building up a list of what those events are - issues, issue_comment, pull_request, commit_comment, pull_request_review_comment, pull_request_review I think? Basically anything that can have a "body" 🤔

[tcbyrd]

@JasonEtco We should also ensure it doesn't respond to bots, to prevent infinite loop situations (helpful when a Bot responds with a list of commands you can use)

We do this in the jira middleware:

if (context.payload.sender.type === 'Bot') {
  return
}