Not clear where to import Slack types from

[geoguide]

Description

Unless I'm missing something I can't seem to get the types out of the projects, I'd like to do things like

import { App, Member } from '@slack/bolt'

So I can type other parts of my application, such as results from queries. I don't see an easy way to do this and there aren't types available elsewhere.

What type of issue is this? (place an x in one of the [ ])

• bug
• enhancement (feature request)
• question
• documentation related
• example code related
• testing related
• discussion

Requirements (place an x in each of the [ ])

• I've read and understood the Contributing guidelines and have done my best effort to follow them.
• I've read and agree to the Code of Conduct.
• I've searched for any related issues and avoided creating a duplicate issue.

---

Bug Report

Filling out the following details about bugs will help us solve your issue sooner.

Reproducible in:

package version:

node version:

OS version(s):

Steps to reproduce:

Expected result:

What you expected to happen

Actual result:

What actually happened

Attachments:

Logs, screenshots, screencast, sample project, funny gif, etc.

[srajiang]

@geoguide - Not sure whether you meant to include something like,

import { App } from "@slack/bolt"

But that syntax should work. If it helps as well, @misscoded's just added a complete bolt typescript starter template you can play around with as well 🎉

[geoguide]

No, I want to actually get the types also because I want to type other things. for example

import { App, Member } from '@slack/bolt'

...
const { members } = await client.users.list()

function findMember(member: Member, members: Member[]): Member | undefined {
  ....
}

const member = findMember(userObject, members)

type CustomObjectType = {
  members: Member[],
  category: string,
}

const gamersCategory: CustomObjectType = { members: [member], category 'gamers' }

There are other cases where I want to type objects that I am creating with the slack types.

[srajiang]

import { App, Member } from '@slack/bolt'
const { members } = await client.users.list()

I see, thanks for the clarification. Wasn't sure if it was just an issue with the import syntax.

It's not at all obvious where to go if you're looking for types for Slack Web API calls, which might be the issue here. The users.list response is typed here: https://github.com/slackapi/node-slack-sdk/blob/main/packages/web-api/src/response/UsersListResponse.ts and you can import it like this

import { UsersListResponse } from '@slack/web-api'

If you're looking for the types for either arguments or responses from Slack API calls, you'll want to check out the other types in the web-api package.

We're also considering overhauling the organization of our types across node-slack-sdk bolt-js and other repos to a separate package entirely, making a bit more of a centralized place for most all slack types in the future. Let us know if that would be useful!

[geoguide]

import { App, Member } from '@slack/bolt'
const { members } = await client.users.list()

I see, thanks for the clarification. Wasn't sure if it was just an issue with the import syntax.

It's not at all obvious where to go if you're looking for types for Slack Web API calls, which might be the issue here. The users.list response is typed here: https://github.com/slackapi/node-slack-sdk/blob/main/packages/web-api/src/response/UsersListResponse.ts and you can import it like this

import { UsersListResponse } from '@slack/web-api'

If you're looking for the types for either arguments or responses from Slack API calls, you'll want to check out the other types in the web-api package.

We're also considering overhauling the organization of our types across node-slack-sdk bolt-js and other repos to a separate package entirely, making a bit more of a centralized place for most all slack types in the future. Let us know if that would be useful!

That would b super useful! No offense, but it's hard to be confident that the types are the same across bolt and the web API library, and it seems bad to install the web-api library just to get the types. If the types were in their own package, then I'd be confident they were uniform!

[srajiang]

@geoguide - No offense taken! The location of types across our repos has evolved organically (which is a very nice way of saying, we never got around to fully consolidating them). You might have already noticed that we do actually have a standalone package called types published from within our node-slack-sdk, so clearly there have been efforts before, just incomplete ones).

There's lots of opportunity for us to rethink this experience for TS developers, so I'll take your feedback back to the other maintainers as well.

@filmaj @stevengill relevant to the types repo thinkings as of late.

[geoguide]

Also I'm noticing things like the type of a message from the event listener KnownEventFromType<"message"> should have user? on it so I have to disable typescript for it, similarly it should have thread_s so I'm having to do this: (message as any).thread_ts

[seratch]

@geoguide The message event data types are a bit tricky. The type is a union type of these message event interface so that only the common properties are available unless the event subtype is determined. Please refer to #904 and the other issues linked from the issue.

[geoguide]

I see. Thanks! I'm not a typescript expert, but this seems like another use case for the types so I could do this when I know what kind of message event it is.

message as GenericMessageEvent

Maybe I'm just looking for a more specific event or handler? For now my workaround will do it :)

By the way I'm loving the bolt library in general!

[seratch]

@geoguide As you can see here, there are many subtpes. If you would like to do something only with a newly posted message by humans, you can do the same with this suggestion. In this way, you can access GenericMessageEvent data without casting the type inside the if statement block.

app.message(keyword, async ({ message, say }) => {
  if (!message.subtype) {
    // the `message` is no longer a union type here
    await say(`Hi, <@${message.user}>!`);
  }
});

If you need to handle messages posted by either humans or other apps' bot users, message.subtype can be either undefined or bot_message. I hope this helps.

By the way I'm loving the bolt library in general!

So glad to hear this! Thank you ❤️

[geoguide]

Hm, I have to use the suggestion below it which is messier and probably won't continue to work.

        message.subtype !== "message_deleted" &&
        message.subtype !== "message_replied" &&
        message.subtype !== "message_changed"

Also this doesn't fix the object not having thread_ts, optionally so I still have to cast it to any.

Is there a handler that only fires on user messages?

[seratch]

Is there a handler that only fires on user messages?

Unfortunately, no. I do understand that this is not so easy to handle. However, it is the nature of message events on the platform and we have to ask you to deal with the complexity due to the event delivery design. Please consider picking up the necessary subtype events for your app. It'd be appreciated if you could understand this.