Bring magic to a conversation with sayStream for streaming messages and show loading status with setStatus. Now available for app.event and app.message listeners:
app.event('app_mention', async ({ sayStream, setStatus }) => {
setStatus({
status: 'Thinking...',
loading_messages: ['Waking up...', 'Loading a witty response...'],
});
const stream = sayStream({ buffer_size: 100 });
await stream.append({ markdown_text: 'Thinking... :thinking_face:\n\n' });
await stream.append({ markdown_text: 'Here is my response!' });
await stream.stop();
});The respond function now accepts thread_ts to publish responses in a thread:
app.action('my_action', async ({ ack, respond }) => {
await ack();
await respond({ text: 'Replying in thread!', thread_ts: '1234567890.123456' });
});Configure ping timeouts, reconnect behavior, and other Socket Mode settings directly through App options:
const app = new App({
socketMode: true,
appToken: process.env.SLACK_APP_TOKEN,
token: process.env.SLACK_BOT_TOKEN,
clientPingTimeout: 15000,
serverPingTimeout: 60000,
pingPongLoggingEnabled: true,
});Full Changelog: https://github.com/slackapi/bolt-js/compare/@slack/bolt@4.6.0...@slack/bolt@4.7.0 Milestone: https://github.com/slackapi/bolt-js/milestone/61 Package: https://www.npmjs.com/package/@slack/bolt/v/4.7.0
Milestone: https://github.com/slackapi/bolt-js/milestone/60?closed=1 Full Changelog: https://github.com/slackapi/bolt-js/compare/@slack/bolt@4.5.0...@slack/bolt@4.6.0 Package: https://www.npmjs.com/package/@slack/bolt/v/4.6.0
https://github.com/user-attachments/assets/bc16597b-1632-46bb-b7aa-fe22330daf84
Try the AI Agent Sample app to explore the AI-enabled features and existing Assistant helper:
# Create a new AI Agent app
$ slack create slack-ai-agent-app --template slack-samples/bolt-js-assistant-template
$ cd slack-ai-agent-app/
# Add your OPENAI_API_KEY
$ export OPENAI_API_KEY=sk-proj-ahM...
# Run the local dev server
$ slack runAfter the app starts, send a message to the "slack-ai-agent-app" bot for a unique response.
Loading states allows you to not only set the status (e.g. "My app is typing...") but also sprinkle some personality by cycling through a collection of loading messages:
app.event('message', async ({ client, context, event, logger }) => {
// ...
await client.assistant.threads.setStatus({
channel_id: channelId,
thread_ts: threadTs,
status: 'thinking...',
loading_messages: [
'Teaching the hamsters to type faster…',
'Untangling the internet cables…',
'Consulting the office goldfish…',
'Polishing up the response just for you…',
'Convincing the AI to stop overthinking…',
],
});
// Start a new message stream
});const assistant = new Assistant({
threadStarted: assistantThreadStarted,
threadContextChanged: assistantThreadContextChanged,
userMessage: async ({ client, context, logger, message, getThreadContext, say, setTitle, setStatus }) => {
await setStatus({
status: 'thinking...',
loading_messages: [
'Teaching the hamsters to type faster…',
'Untangling the internet cables…',
'Consulting the office goldfish…',
'Polishing up the response just for you…',
'Convincing the AI to stop overthinking…',
],
});
},
});The client.chatStream() helper utility can be used to streamline calling the 3 text streaming methods:
app.event('message', async ({ client, context, event, logger }) => {
// ...
// Start a new message stream
const streamer = client.chatStream({
channel: channelId,
recipient_team_id: teamId,
recipient_user_id: userId,
thread_ts: threadTs,
});
// Loop over OpenAI response stream
// https://platform.openai.com/docs/api-reference/responses/create
for await (const chunk of llmResponse) {
if (chunk.type === 'response.output_text.delta') {
await streamer.append({
markdown_text: chunk.delta,
});
}
}
// Stop the stream and attach feedback buttons
await streamer.stop({ blocks: [feedbackBlock] });
});Alternative to the Text Streaming Helper is to call the individual methods.
client.chat.startStreamFirst, start a chat text stream to stream a response to any message:
app.event('message', async ({ client, context, event, logger }) => {
// ...
const streamResponse = await client.chat.startStream({
channel: channelId,
recipient_team_id: teamId,
recipient_user_id: userId,
thread_ts: threadTs,
});
const streamTs = streamResponse.tsclient.chat.appendStreamAfter starting a chat text stream, you can then append text to it in chunks (often from your favourite LLM SDK) to convey a streaming effect:
for await (const chunk of llmResponse) {
if (chunk.type === 'response.output_text.delta') {
await client.chat.appendSteam({
channel: channelId,
markdown_text: chunk.delta,
ts: streamTs,
});
}
}client.chat.stopStreamLastly, you can stop the chat text stream to finalize your message:
await client.chat.stopStream({
blocks: [feedbackBlock],
channel: channelId,
ts: streamTs,
});Add feedback buttons to the bottom of a message, after stopping a text stream, to gather user feedback:
const feedbackBlock = {
type: 'context_actions',
elements: [{
type: 'feedback_buttons',
action_id: 'feedback',
positive_button: {
text: { type: 'plain_text', text: 'Good Response' },
accessibility_label: 'Submit positive feedback on this response',
value: 'good-feedback',
},
negative_button: {
text: { type: 'plain_text', text: 'Bad Response' },
accessibility_label: 'Submit negative feedback on this response',
value: 'bad-feedback',
},
}],
};
// Using the Text Streaming Helper
await streamer.stop({ blocks: [feedbackBlock] });// Or, using the Text Streaming Method
await client.chat.stopStream({
blocks: [feedbackBlock],
channel: channelId,
ts: streamTs,
});Milestone: https://github.com/slackapi/bolt-js/milestone/59?closed=1 Full Changelog: https://github.com/slackapi/bolt-js/compare/@slack/bolt@4.4.0...@slack/bolt@4.5.0 Package: https://www.npmjs.com/package/@slack/bolt/v/4.5.0
Full Changelog: https://github.com/slackapi/bolt-js/compare/@slack/bolt@4.3.0...@slack/bolt@4.4.0 Milstone: https://github.com/slackapi/bolt-js/milestone/58?closed=1
Thank you to all our lovely contributors ✨
Full Changelog: https://github.com/slackapi/bolt-js/compare/@slack/bolt@4.2.1...@slack/bolt@4.3.0
@types/express an optional peer dependency by @WilliamBergamin in https://github.com/slackapi/bolt-js/pull/2421Full Changelog: https://github.com/slackapi/bolt-js/compare/@slack/bolt@4.2.0...@slack/bolt@4.2.1
Hello! 👋 This release updates dependencies to keep packages secure and makes the logger of your app public for use outside of event listeners when using TypeScript! 🔐 🌲
const app = new App({ ... });
(async () => {
await app.start(process.env.PORT || 3000);
app.logger.info('⚡️ Bolt app is running!'); // The app logger can now be used here!
})();Full Changelog: https://github.com/slackapi/bolt-js/compare/@slack/bolt@4.1.1...@slack/bolt@4.2.0
This pre-release contains the proposed socket-mode library fix addressing runaway connection spawning spiral behaviour observed in https://github.com/slackapi/node-slack-sdk/issues/2094 and fixed in https://github.com/slackapi/node-slack-sdk/issues/2099.
Developers wishing to evaluate the fix for their app may try out this pre-release.
Full Changelog: https://github.com/slackapi/bolt-js/compare/@slack/bolt@4.1.1...@slack/bolt@4.1.2-rc.1
Full Changelog: https://github.com/slackapi/bolt-js/compare/@slack/bolt@4.1.0...@slack/bolt@4.1.1
say util by @misscoded in https://github.com/slackapi/bolt-js/pull/2300title to setSuggestedPrompts utility by @misscoded in https://github.com/slackapi/bolt-js/pull/2308Full Changelog: https://github.com/slackapi/bolt-js/compare/@slack/bolt@4.0.1...@slack/bolt@4.1.0
Full Changelog: https://github.com/slackapi/bolt-js/compare/@slack/bolt@4.0.0...@slack/bolt@4.0.1
Support for Agents & Assistants is now available!
Bolt now offers a simple and intuitive way to create an Agent/Assistant using the new Assistant class. Simply include the required callbacks and add the assistant to your App instance. Get up and running even quicker with a working, out-of-the-box example that utilizes OpenAI here.
We have prepared a migration guide to help BoltJS consumers migrate their Bolt v3 apps to v4.
While a few breaking changes were introduced, we don't expect a majority of bolt v3 users to require changing their apps to upgrade to v4. More complex apps may need a few tweaks. TL;DR is: if your bolt v3 app is built with TypeScript, or uses the ExpressReceiver or the AwsLambdaReceiver, or your app used previously-deprecated types or functions, best to read the migration guide.
In bolt we have a set of Slack*MiddlewareArgs types: for events, shortcuts, commands, and so on. They 'wrap' the underlying event payloads with additional middleware-relevant bits like a next() method, a context object for devs to augment, and so on.
Many of these types, for example the SlackEventMiddlewareArgs type, previously used a conditional to sometimes define particular additional helper utilities on the middleware arguments. For example, the say utility, or tacking on a convenience message property for message-event-related payloads. This was problematic in practice in TypeScript situations, not just internally (this change fixes https://github.com/slackapi/bolt-js/issues/2135) within the bolt codebase but for developers as well: when the payload was not of a type that required the extra utility, these properties would be required to exist on the middleware arguments but have a value of undefined. Those of us trying to build generic middleware utilities would have to deal with TS compilation errors and needing to liberally type-cast to avoid these conditional mismatches with undefined.
Instead, these MiddlewareArgs types now conditionally create a type intersection when appropriate in order to provide this conditional-utility-extension mechanism. In practice that looks something like:
type SomeMiddlewareArgs<EventType extends string = string> = {
// some type in here
} & (EventType extends 'message'
// If this is a message event, add a `message` property
? { message: EventFromType<EventType> }
: unknown
)With the above, now when a message payload is wrapped up into middleware arguments, it will contain an appropriate message property, whereas a non-message payload will be intersected with unknown - effectively a type "noop." No more e.g. say: undefined or message: undefined to deal with!
express to v4->v5; ExpressReceiver users will be exposed to express v4 -> v5 breaking changes - fixes #2242@slack/socket-mode v2; SocketModeReceiver users who have attached custom event listeners to the public socketModeClient directly should read the v1 -> v2 migration guide in case the major upgrade could affect them - fixes #2225@slack/web-api v7; all users should read the web-api v6->v7 migration guide to see what the scope of breaking changes the client within listeners is affected byKnownKeys@slack/types now exist under a named export types.SocketModeFunctions class that had a single static method on it and instead directly exposed the defaultProcessEventErrorHandler method from it.ignoreSelf and directMention now no longer must be invoked as a method in order to return middleware; instead they are middleware to be used directly. this lines up the API for these built-in middlewares to match the other builtins.AwsEvent interface now models event payloads a bit differently; we now properly model AWS API Gateway v1 and v2 payloads separately - fixes #2272OptionsRequest interfaceauthed_users and authed_teams from event payload enveloperender-html-for-install-path moduleverify and VerifyOptions from the verify-request modulesrc/receivers/http-utils.ts module@slack/web-api dependency under the webApi named exportAwsLambdaReceiver where apps with no registered handlers that processed an incoming event would still log out an error related to not acknowledging the request in time - fixes #2284raw-body to v3@slack/oauth to v3promise.allsettled since that is natively supported in node since v14@types/tsscmp to dev dependencies since that is not exposed to developers@slack/bolt@v4.0.0 by @filmaj in https://github.com/slackapi/bolt-js/pull/2294Full Changelog: https://github.com/slackapi/bolt-js/compare/@slack/bolt@3.22.0...@slack/bolt@4.0.0
A lot! We have prepared a migration guide to help bolt-js consumers migrate their bolt v3 apps to v4.
In bolt we have a set of Slack*MiddlewareArgs types: for events, shortcuts, commands, and so on. They 'wrap' the underlying event payloads with additional middleware-relevant bits like a next() method, a context object for devs to augment, and so on.
Many of these types, for example the SlackEventMiddlewareArgs type, previously used a conditional to sometimes define particular additional helper utilities on the middleware arguments. For example, the say utility, or tacking on a convenience message property for message-event-related payloads. This was problematic in practice in TypeScript situations, not just internally (this change fixes https://github.com/slackapi/bolt-js/issues/2135) within the bolt codebase but for developers as well: when the payload was not of a type that required the extra utility, these properties would be required to exist on the middleware arguments but have a value of undefined. Those of us trying to build generic middleware utilities would have to deal with TS compilation errors and needing to liberally type-cast to avoid these conditional mismatches with undefined.
Instead, these MiddlewareArgs types now conditionally create a type intersection when appropriate in order to provide this conditional-utility-extension mechanism. In practice that looks something like:
type SomeMiddlewareArgs<EventType extends string = string> = {
// some type in here
} & (EventType extends 'message'
// If this is a message event, add a `message` property
? { message: EventFromType<EventType> }
: unknown
)With the above, now when a message payload is wrapped up into middleware arguments, it will contain an appropriate message property, whereas a non-message payload will be intersected with unknown - effectively a type "noop." No more e.g. say: undefined or message: undefined to deal with!
express to v4->v5; ExpressReceiver users will be exposed to express v4 -> v5 breaking changes
@slack/socket-mode v2; SocketModeReceiver users who have attached custom event listeners to the public socketModeClient directly should read the v1 -> v2 migration guide in case the major upgrade could affect them
@slack/web-api v7; all users should read the web-api v6->v7 migration guide to see what the scope of breaking changes the client within listeners is affected byKnownKeys@slack/types now exist under a named export types.SocketModeFunctions class that had a single static method on it and instead directly exposed the defaultProcessEventErrorHandler method from it.ignoreSelf and directMention now no longer must be invoked as a method in order to return middleware; instead they are middleware to be used directly. this lines up the API for these built-in middlewares to match the other builtins.AwsEvent interface now models event payloads a bit differently; we now properly model AWS API Gateway v1 and v2 payloads separately.
OptionsRequest interfaceauthed_users and authed_teams from event payload enveloperender-html-for-install-path moduleverify and VerifyOptions from the verify-request modulesrc/receivers/http-utils.ts module@slack/web-api dependency under the webApi named exportAwsLambdaReceiver where apps with no registered handlers that processed an incoming event would still log out an error related to not acknowledging the request in time. Resolves #2284raw-body to v3@slack/oauth to v3promise.allsettled since that is natively supported in node since v14@types/tsscmp to dev dependencies since that is not exposed to developersA lot! We have prepared a migration guide to help bolt-js consumers migrate their bolt v3 apps to v4.
In bolt we have a set of Slack*MiddlewareArgs types: for events, shortcuts, commands, and so on. They 'wrap' the underlying event payloads with additional middleware-relevant bits like a next() method, a context object for devs to augment, and so on.
Many of these types, for example the SlackEventMiddlewareArgs type, previously used a conditional to sometimes define particular additional helper utilities on the middleware arguments. For example, the say utility, or tacking on a convenience message property for message-event-related payloads. This was problematic in practice in TypeScript situations, not just internally (this change fixes https://github.com/slackapi/bolt-js/issues/2135) within the bolt codebase but for developers as well: when the payload was not of a type that required the extra utility, these properties would be required to exist on the middleware arguments but have a value of undefined. Those of us trying to build generic middleware utilities would have to deal with TS compilation errors and needing to liberally type-cast to avoid these conditional mismatches with undefined.
Instead, these MiddlewareArgs types now conditionally create a type intersection when appropriate in order to provide this conditional-utility-extension mechanism. In practice that looks something like:
type SomeMiddlewareArgs<EventType extends string = string> = {
// some type in here
} & (EventType extends 'message'
// If this is a message event, add a `message` property
? { message: EventFromType<EventType> }
: unknown
)With the above, now when a message payload is wrapped up into middleware arguments, it will contain an appropriate message property, whereas a non-message payload will be intersected with unknown - effectively a type "noop." No more e.g. say: undefined or message: undefined to deal with!
express to v4->v5; ExpressReceiver users will be exposed to express v4 -> v5 breaking changes
@slack/socket-mode v2; SocketModeReceiver users who have attached custom event listeners to the public socketModeClient directly should read the v1 -> v2 migration guide in case the major upgrade could affect them
@slack/web-api v7; all users should read the web-api v6->v7 migration guide to see what the scope of breaking changes the client within listeners is affected byKnownKeys@slack/types now exist under a named export types.SocketModeFunctions class that had a single static method on it and instead directly exposed the defaultProcessEventErrorHandler method from it.ignoreSelf and directMention now no longer must be invoked as a method in order to return middleware; instead they are middleware to be used directly. this lines up the API for these built-in middlewares to match the other builtins.AwsEvent interface now models event payloads a bit differently; we now properly model AWS API Gateway v1 and v2 payloads separately.
OptionsRequest interfaceauthed_users and authed_teams from event payload enveloperender-html-for-install-path moduleverify and VerifyOptions from the verify-request modulesrc/receivers/http-utils.ts module@slack/web-api dependency under the webApi named exportraw-body to v3@slack/oauth to v3promise.allsettled since that is natively supported in node since v14@types/tsscmp to dev dependencies since that is not exposed to developersThis release adds support for the assistant.threads.* API methods introduced in @slack/web-api@6.13.0 🤖 as well as improvements to documentation at the new https://tools.slack.dev/bolt-js site and patches to dependencies 🔒
More details about these endpoints can be discovered in the documentation, and listeners can be added to code to respond to incoming events like so:
app.event('assistant_thread_started', async ({ client, event, logger }) => {
logger.info('A new thread started');
logger.debug(event);
const now = new Date();
const title = await client.assistant.threads.setTitle({
title: `Chats from ${now.toISOString()}`,
channel_id: event.assistant_thread.channel_id,
thread_ts: event.assistant_thread.thread_ts,
});
logger.debug(title);
const suggestions = await client.assistant.threads.setSuggestedPrompts({
channel_id: event.assistant_thread.channel_id,
thread_ts: event.assistant_thread.thread_ts,
title: 'Ask the computer for answers',
prompts: [
{
title: 'Find the time',
message: `What happens at ${Math.floor(now.getTime() / 1000)}`,
},
],
});
logger.debug(suggestions);
});
app.event('assistant_thread_context_changed', async ({ client, event, logger }) => {
logger.info('The channel of focus changed');
logger.debug(event);
const response = client.chat.postMessage({
thread_ts: event.assistant_thread.thread_ts,
channel: event.assistant_thread.channel_id,
text: `Now visiting <#${event.assistant_thread.context.channel_id}>`,
});
logger.debug(response);
});
app.message(async ({ client, message, logger }) => {
logger.info('A new message was received');
logger.debug(message);
if (message.subtype === 'message_changed' || message.subtype === 'message_deleted') {
return;
}
const status = await client.assistant.threads.setStatus({
channel_id: message.channel,
thread_ts: message.thread_ts,
status: 'is thinking...',
});
logger.debug(status);
/**
* Actual response generation could happen here!
*/
setTimeout(async () => {
const response = await client.chat.postMessage({
channel: message.channel,
thread_ts: message.thread_ts,
text: 'How insightful!',
});
logger.debug(response);
}, 3000);
});Full Changelog: https://github.com/slackapi/bolt-js/compare/@slack/bolt@3.21.4...@slack/bolt@3.22.0
path-to-regexp to partially address a security vulnerability (#2242) by @filmaj in https://github.com/slackapi/bolt-js/pull/2251Full Changelog: https://github.com/slackapi/bolt-js/compare/@slack/bolt@3.21.3...@slack/bolt@3.21.4
Woops! We (coughfilmajcough) removed the EnvelopedEvent export in a recent change. We are adding it back in in this patch release. Please accept our sincere apologies for this temporary breaking change in bolt 3.21.2.
Full Changelog: https://github.com/slackapi/bolt-js/compare/@slack/bolt@3.21.2...@slack/bolt@3.21.3
The main change in this patch release is creating an npm release for the change in #2223, where exported event payload types were moved from bolt-js to @slack/types. If you see errors compiling your TypeScript-based application that look like:
Module './types' has already exported a member
.. then upgrading to this release should address the issue (see #2233 and #2234 for issue details).
next function to the last listener middleware by @filmaj in https://github.com/slackapi/bolt-js/pull/2214 (fixes #1457)@slack/types and consume event payloads from it by @filmaj in https://github.com/slackapi/bolt-js/pull/2223Full Changelog: https://github.com/slackapi/bolt-js/compare/@slack/bolt@3.21.1...@slack/bolt@3.21.2
This patch release brings improvements to documentation and sureness in our CI, as well as security updates to certain @slack packages - see CVE-2024-39338 and axios@1.7.4 for more details!
Full Changelog: https://github.com/slackapi/bolt-js/compare/@slack/bolt@3.21.0...@slack/bolt@3.21.1
Bolt-JS now supports Custom Steps! That's right, your trusty Bolt app now let's you expose Custom Steps in Bolt, allowing you to provide steps for use in Workflow Builder.
You can now use the new function() method to register handlers for the function_executed event. Check out our API docs on the topic to get started.
Full Changelog: https://github.com/slackapi/bolt-js/compare/@slack/bolt@3.20.0...@slack/bolt@3.21.0