@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 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!
Other Breaking Changes
- drops node v14 and v16 (are now EOL'ed)
expressto v4->v5;ExpressReceiverusers will be exposed to express v4 -> v5 breaking changes- fixes #2242
- upgrades to
@slack/socket-modev2;SocketModeReceiverusers who have attached custom event listeners to the publicsocketModeClientdirectly should read the v1 -> v2 migration guide in case the major upgrade could affect them- fixes #2225
- upgrades
@slack/web-apiv7; all users should read the web-api v6->v7 migration guide to see what the scope of breaking changes theclientwithin listeners is affected by - removed exported type:
KnownKeys @slack/typesnow exist under a named exporttypes.- removed the
SocketModeFunctionsclass that had a single static method on it and instead directly exposed thedefaultProcessEventErrorHandlermethod from it. - the built-in middleware functions
ignoreSelfanddirectMentionnow 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
AwsEventinterface 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:
OptionsRequestinterfaceauthed_usersandauthed_teamsfrom event payload enveloperender-html-for-install-pathmoduleverifyandVerifyOptionsfrom theverify-requestmodulesrc/receivers/http-utils.tsmodule
Non-breaking Changes
- expose the bundled
@slack/web-apidependency under thewebApinamed export - fixed an issue in
AwsLambdaReceiverwhere 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-bodyto v3 - upgrades
@slack/oauthto v3 - removes
promise.allsettledsince that is natively supported in node since v14 - moves
@types/tsscmpto dev dependencies since that is not exposed to developers
- upgrades
Fetched April 3, 2026
