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 slackapi/bolt-js#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.
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!
upgrades to @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
Most Recent Ignore Conditions Applied to This Pull Request
| Dependency Name | Ignore Conditions |
| --- | --- |
| @slack/bolt | [< 3.18, > 3.17.1-customFunctionBeta.0] |
| @slack/bolt | [>= 3.19.a, < 3.20] |
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.
Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
- `@dependabot show ignore conditions` will show all of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
Bumps @slack/bolt from 3.22.0 to 4.0.1.
Release notes
Sourced from
@slack/bolt
's releases.... (truncated)
Commits
198d7c3
Publish@slack/bolt@4.0.1
(#2299)a382238
fix: bug where parsing assistant thread message event fails for beta feature ...840a26b
chore(deps-dev): bump@types/node
from 22.7.5 to 22.7.7 (#2297)1555975
Publish@slack/bolt@v4.0.0
(#2294)91750c2
bolt v4 (#2254)1ebd657
Add support for Agents/Assistants (#2286)70debca
chore(deps): bump cookie and express in /docs (#2291)864978d
chore(deps-dev): bump@types/node
from 22.7.4 to 22.7.5 (#2289)cd662ed
chore(deps-dev): bump@types/node
from 22.5.5 to 22.7.4 (#2276)Most Recent Ignore Conditions Applied to This Pull Request
| Dependency Name | Ignore Conditions | | --- | --- | | @slack/bolt | [< 3.18, > 3.17.1-customFunctionBeta.0] | | @slack/bolt | [>= 3.19.a, < 3.20] |Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase
.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot show