Open slifty opened 7 months ago
I agree this would be a fantastic enhancement. The issue is that perfect typing for Slack payload events is challenging, as the payloads can be quite contextual. For example, depending on the Slack workspace type (enterprise vs. standalone), the payloads might differ. Additionally, some payloads may or may not contain properties depending on the context, for example
a block_actions
payload contains a container
property, which might be a View
object or might be a containing message.
That said, at least some baseline form of event typing should be doable. I will leave this as an enhancement issue open but can make no promises on a delivery timeline.
I suppose this would technically be a breaking change, yes? Going from any
to something more specific may possibly break existing apps, so this would be a major version change - but would be a great one!
This issue comment in the EventEmitter3
package that powers socket-mode has some great examples of using its generics support to provide nice type completion. I think this would be worthwhile doing!
First, though, what needs to happen:
@slack/types
repo.@slack/types
Once these are in place, we can consume the new @slack/types@3.0+
package and leverage EventEmitter3
generics to provide a much better experience for socket-mode consumers.
I'm using
@slack/socket-mode
in a TypeScript project and would love to be able to benefit from type definitions when defining event handlers -- e.g. when I invoke something along the lines ofI'd like
event
to not be of theany
type but instead to reflect the expected type for the event in question.It looks like there are libraries that might support this, for your consideration.
Packages:
Select all that apply:
@slack/web-api
@slack/rtm-api
@slack/webhooks
@slack/oauth
@slack/socket-mode
@slack/types
Requirements
Please read the Contributing guidelines and Code of Conduct before creating this issue or pull request. By submitting, you are agreeing to those rules.