Releases: slackapi/bolt-js
@slack/bolt@4.2.0
What's Changed
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!
})();
🎁 Enhancements
🔐 Security
- chore(deps): bump slack and axios dependencies to latest secure versions in #2360 - thanks @hello-ashleyintech!
📚 Documentation
- docs: show descriptions of function listener arguments in #2364 - thanks @zimeg!
- docs: replace redirected or missing links to bolt documentation in #2367 - thanks @zimeg!
🧰 Maintenance
- build: install @types/express@^v5 as a dev dependency for express@^5 in #2355 - thanks @zimeg!
- ci: check for linting errors without writing required changes in #2357 - thanks @zimeg!
- build: find the biome config schema from the installed path in #2363 - thanks @zimeg!
- build: ignore autogenerated docusaurus files when running the formatter in #2362 - thanks @zimeg!
- build: update the redirected repo homepage url to postfix js in #2370 - thanks @zimeg!
🤖 Dependencies
- chore(deps): bump codecov/codecov-action from 4 to 5 in #2349 - thanks @dependabot!
- chore(deps): bump the docusaurus group in /docs with 5 updates in #2350 - thanks @dependabot!
- chore(deps): bump path-to-regexp from 1.8.0 to 1.9.0 in /docs in #2352 - thanks @dependabot!
- chore(deps-dev): bump stylelint from 16.10.0 to 16.11.0 in /docs in #2351 - thanks @dependabot!
- chore(deps): bump path-to-regexp and express in /docs in #2358 - thanks @dependabot!
- chore(deps-dev): @types/node from 22.9.3 to 22.10.1 in #2359 - thanks @dependabot!
- chore(deps): bump nanoid from 3.3.7 to 3.3.8 in /docs in #2368 - thanks @dependabot!
- chore(deps-dev): @types/node from 22.10.1 to 22.10.2 in #2369 - thanks @dependabot!
Full Changelog: https://github.com/slackapi/bolt-js/compare/@slack/bolt@4.1.1...@slack/bolt@4.2.0
@slack/bolt@4.1.1
What's Changed
- 🏭 A fix related to the TypeScript types for the Assistant handler utilities. Fixes #2319 in #2325, thanks @misscoded!
- 📚 Our bolt-js online documentation at https://tools.slack.dev/bolt-js/ received many updates. Thanks to @lukegalbraithrussell, @haleychaas and @kuredev!
Changelog
- Docs: agents and assistants by @lukegalbraithrussell in #2295
- fix: Assistant utility types by @misscoded in #2325
- Docs: Tutorial for assistant app by @haleychaas in #2331
- docs: Changed "App Token" to "App-Level Tokens" by @kuredev in #2336
- docs: add xapp section by @kuredev in #2339
New Contributors
- @haleychaas made their first contribution in #2331
- @kuredev made their first contribution in #2336
Full Changelog: https://github.com/slackapi/bolt-js/compare/@slack/bolt@4.1.0...@slack/bolt@4.1.1
@slack/bolt@4.1.2-rc.1
What's Changed
This pre-release contains the proposed socket-mode
library fix addressing runaway connection spawning spiral behaviour observed in slackapi/node-slack-sdk#2094 and fixed in slackapi/node-slack-sdk#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
@slack/bolt@4.1.0
What's Changed
- fix: Include metadata with Assistant
say
util by @misscoded in #2300 - docs: concept focused nav by @lukegalbraithrussell in #2302
- feat: Add
title
to setSuggestedPrompts utility by @misscoded in #2308
Full Changelog: https://github.com/slackapi/bolt-js/compare/@slack/bolt@4.0.1...@slack/bolt@4.1.0
@slack/bolt@4.0.1
What's Changed
- Fix a bug where parsing assistant thread message event fails for beta feature enabled apps by @seratch in #2298
Full Changelog: https://github.com/slackapi/bolt-js/compare/@slack/bolt@4.0.0...@slack/bolt@4.0.1
@slack/bolt@4.0.0
Bolt v4
What's Changed
New Features
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.
Breaking Changes
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.
Middleware Type Changes
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 #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!
Other Breaking Changes
- drops node v14 and v16 (are now EOL'ed)
express
to v4->v5;ExpressReceiver
users will be exposed to express v4 -> v5 breaking changes - fixes #2242- upgrades to
@slack/socket-mode
v2;SocketModeReceiver
users who have attached custom event listeners to the publicsocketModeClient
directly should read the v1 -> v2 migration guide in case the major upgrade could affect them - fixes #2225 - upgrades
@slack/web-api
v7; all users should read the web-api v6->v7 migration guide to see what the scope of breaking changes theclient
within listeners is affected by - removed exported type:
KnownKeys
@slack/types
now exist under a named exporttypes
.- removed the
SocketModeFunctions
class that had a single static method on it and instead directly exposed thedefaultProcessEventErrorHandler
method from it. - the built-in middleware functions
ignoreSelf
anddirectMention
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. - AWSReceiver's
AwsEvent
interface now models event payloads a bit differently; we now properly model AWS API Gateway v1 and v2 payloads separately - fixes #2272 - remove deprecated methods/modules/properties:
OptionsRequest
interfaceauthed_users
andauthed_teams
from event payload enveloperender-html-for-install-path
moduleverify
andVerifyOptions
from theverify-request
modulesrc/receivers/http-utils.ts
module
Non-breaking Changes
- expose the bundled
@slack/web-api
dependency under thewebApi
named export - fixed an issue in
AwsLambdaReceiver
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 #2284 - dependency updates:
- upgrades
raw-body
to v3 - upgrades
@slack/oauth
to v3 - removes
promise.allsettled
since that is natively supported in node since v14 - moves
@types/tsscmp
to dev dependencies since that is not exposed to developers
- upgrades
Changelog
- chore(deps-dev): bump @types/node from 22.5.5 to 22.7.4 by @dependabot in #2276
- chore(deps-dev): bump @types/node from 22.7.4 to 22.7.5 by @dependabot in #2289
- chore(deps): bump cookie and express in /docs by @dependabot in #2291
- Add support for Agents/Assistants by @misscoded in #2286
- bolt v4 by @filmaj in #2254
- Publish
@slack/bolt@v4.0.0
by @filmaj in #2294
Full Changelog: https://github.com/slackapi/bolt-js/compare/@slack/bolt@3.22.0...@slack/bolt@4.0.0
@slack/bolt@4.0.0-rc.4
Bolt v4 Release Candidate 4
A lot! We have prepared a migration guide to help bolt-js consumers migrate their bolt v3 apps to v4.
What's Changed
Breaking Changes
Middleware Type Changes
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 #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!
Other Breaking Changes
- drops node v14 and v16 (are now EOL'ed)
express
to v4->v5;ExpressReceiver
users will be exposed to express v4 -> v5 breaking changes- fixes #2242
- upgrades to
@slack/socket-mode
v2;SocketModeReceiver
users who have attached custom event listeners to the publicsocketModeClient
directly should read the v1 -> v2 migration guide in case the major upgrade could affect them- fixes #2225
- upgrades
@slack/web-api
v7; all users should read the web-api v6->v7 migration guide to see what the scope of breaking changes theclient
within listeners is affected by - removed exported type:
KnownKeys
@slack/types
now exist under a named exporttypes
.- removed the
SocketModeFunctions
class that had a single static method on it and instead directly exposed thedefaultProcessEventErrorHandler
method from it. - the built-in middleware functions
ignoreSelf
anddirectMention
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. - AWSReceiver's
AwsEvent
interface now models event payloads a bit differently; we now properly model AWS API Gateway v1 and v2 payloads separately.- This resolves #2272
- remove deprecated methods/modules/properties:
OptionsRequest
interfaceauthed_users
andauthed_teams
from event payload enveloperender-html-for-install-path
moduleverify
andVerifyOptions
from theverify-request
modulesrc/receivers/http-utils.ts
module
Non-breaking Changes
- expose the bundled
@slack/web-api
dependency under thewebApi
named export - fixed an issue in
AwsLambdaReceiver
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 #2284 - dependency updates:
- upgrades
raw-body
to v3 - upgrades
@slack/oauth
to v3 - removes
promise.allsettled
since that is natively supported in node since v14 - moves
@types/tsscmp
to dev dependencies since that is not exposed to developers
- upgrades
@slack/bolt@4.0.0-rc.3
Bolt v4 Release Candidate 3
A lot! We have prepared a migration guide to help bolt-js consumers migrate their bolt v3 apps to v4.
What's Changed
Breaking Changes
Middleware Type Changes
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 #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!
Other Breaking Changes
- drops node v14 and v16 (are now EOL'ed)
express
to v4->v5;ExpressReceiver
users will be exposed to express v4 -> v5 breaking changes- fixes #2242
- upgrades to
@slack/socket-mode
v2;SocketModeReceiver
users who have attached custom event listeners to the publicsocketModeClient
directly should read the v1 -> v2 migration guide in case the major upgrade could affect them- fixes #2225
- upgrades
@slack/web-api
v7; all users should read the web-api v6->v7 migration guide to see what the scope of breaking changes theclient
within listeners is affected by - removed exported type:
KnownKeys
@slack/types
now exist under a named exporttypes
.- removed the
SocketModeFunctions
class that had a single static method on it and instead directly exposed thedefaultProcessEventErrorHandler
method from it. - the built-in middleware functions
ignoreSelf
anddirectMention
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. - AWSReceiver's
AwsEvent
interface now models event payloads a bit differently; we now properly model AWS API Gateway v1 and v2 payloads separately.- This resolves #2272
- remove deprecated methods/modules/properties:
OptionsRequest
interfaceauthed_users
andauthed_teams
from event payload enveloperender-html-for-install-path
moduleverify
andVerifyOptions
from theverify-request
modulesrc/receivers/http-utils.ts
module
Non-breaking Changes
- expose the bundled
@slack/web-api
dependency under thewebApi
named export - dependency updates:
- upgrades
raw-body
to v3 - upgrades
@slack/oauth
to v3 - removes
promise.allsettled
since that is natively supported in node since v14 - moves
@types/tsscmp
to dev dependencies since that is not exposed to developers
- upgrades
@slack/bolt@3.22.0
What's new
This 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 🔒
Example usage
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);
});
Changes
📚 Documentation
- typo: update error link in App.ts - Thanks @ChinoUkaegbu! #2260
- docs: new URL (HOLD) - Thanks @lukegalbraithrussell! #2253
📦 Dependencies
- chore(deps-dev): bump @types/node from 22.5.4 to 22.5.5 - Thanks @dependabot! #2263
- Upgrade express version - Thanks @helzahalim! #2270
- chore(deps): bump @slack/web-api from 6.12.1 to 6.13.0 - Thanks @zimeg! #2273
🎉 New contributors
- @ChinoUkaegbu made their first contribution in #2260
Full Changelog: https://github.com/slackapi/bolt-js/compare/@slack/bolt@3.21.4...@slack/bolt@3.22.0
@slack/bolt@3.21.4
What's Changed
- chore(deps): upgrade
path-to-regexp
to partially address a security vulnerability (#2242) by @filmaj in #2251
Full Changelog: https://github.com/slackapi/bolt-js/compare/@slack/bolt@3.21.3...@slack/bolt@3.21.4