This would be a follow-up issue to tackle once slackapi/bolt-js#1395 is addressed; slackapi/bolt-js#1395 simply adds the existing, likely lacking, types for Events API payloads to the types package. This issue would be about breaking those payloads and include that in a new 3.0 release of @slack/types.
Summary
Improvements to MessageEvent
Today, MessageEvent is a big union of different events Slack may send to apps, presumably that include some message information. Because it is a union, when using it as a type both in applications as well as frameworks (like bolt), only the common properties across all types in this union can be used. Some properties that would be expected to be present on messages are not common in this union today: text and blocks, for instance. We should study how this type is used in bolt and elsewhere, and consider a different approach to modeling message events. For example, perhaps a generics-based approach could better serve?
Another problem when working with MessageEvent in TypeScript is the fact that one member of the union, the GenericMessageEvent, has subtype: undefined. This causes major problems when trying to match against the union of all different kinds of messages, since many message subtype events have a defined string literal subtype. subtype: undefined needs to get the 🔪 .
TODO
Review Issues to Identify Pain Points
The following should be studied to determine the scope of what these breaking changes should include, in order to address developer pain points, and folded into the Summary section above in order to plan the changes:
This would be a follow-up issue to tackle once slackapi/bolt-js#1395 is addressed; slackapi/bolt-js#1395 simply adds the existing, likely lacking, types for Events API payloads to the
typespackage. This issue would be about breaking those payloads and include that in a new 3.0 release of@slack/types.Summary
Improvements to
MessageEventToday,
MessageEventis a big union of different events Slack may send to apps, presumably that include some message information. Because it is a union, when using it as a type both in applications as well as frameworks (like bolt), only the common properties across all types in this union can be used. Some properties that would be expected to be present on messages are not common in this union today:textandblocks, for instance. We should study how this type is used in bolt and elsewhere, and consider a different approach to modeling message events. For example, perhaps a generics-based approach could better serve?Another problem when working with
MessageEventin TypeScript is the fact that one member of the union, theGenericMessageEvent, hassubtype: undefined. This causes major problems when trying to match against the union of all different kinds of messages, since many message subtype events have a defined string literalsubtype.subtype: undefinedneeds to get the 🔪 .TODO
Review Issues to Identify Pain Points
The following should be studied to determine the scope of what these breaking changes should include, in order to address developer pain points, and folded into the Summary section above in order to plan the changes:
subtypemessage pattern filter formessagehandlers bolt-js#796message_repliedevent missing text property in typescript #2025