app.message() does not expose all message properties in TS

[danthegoodman1]

(Filling out the following with as much detail as you can provide will help us solve your issue sooner.)

Reproducible in: 3.12.2

The Slack SDK version 3.12.2

(Paste the output of)

npm ls | grep -o "\S\+@\S\+$" | tr @ ' ' | awk -v q='"' '{print q$1q": "q"^"$2q","}' | grep slack

"slack/bolt": "^3.12.2",
"slack/web-api": "^6.8.1",
"slack-block-builder": "^2.7.2",

or refer to your package.json

Node.js runtime version v18.12.1

(Paste the output of node --version)

OS info

(Paste the output of sw_vers && uname -v on macOS/Linux or ver on Windows OS)

ProductName:		macOS
ProductVersion:		13.2.1
BuildVersion:		22D68
Darwin Kernel Version 22.3.0: Mon Jan 30 20:42:11 PST 2023; root:xnu-8792.81.3~2/RELEASE_X86_64

Steps to reproduce:

What's available in the type:

Expected result:

What I can log:

I should be able to see all of those types. I don't see them in req.event, req.message, req.payload, or any child of req.body for typescript.

These are very useful keys

[seratch]

Hi @danthegoodman1, thanks for writing in!

This could be confusing but the message object is typed as union type of 10 patterns in app.message listeners. So, at the top-level, only the most common properties are available in TS types while all properties exist at runtime.

To deal with that, you can have if/else statements to determine what payload pattern is. The code block inside the if/else statements can safely access more specific message payload data type. Usually, checking the value of "subtype" of message events is the way to go. Refer to #796 (comment) for more details.

We know this is not ideal developer experience, and we are still exploring the way to improve it without any breaking changes. However, we are unable to tell when and how it may come in the future.

I hope this helps.

[danthegoodman1]

gotcha, makes sense. I made my own overriding type any way