chore(deps): bump @slack/bolt from 3.22.0 to 4.0.0

[dependabot]

Bumps @slack/bolt from 3.22.0 to 4.0.0.

Release notes

Sourced from @​slack/bolt's releases.

@​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 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.

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 public socketModeClient 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 the client within listeners is affected by
• removed exported type: KnownKeys
• @slack/types now exist under a named export types.
• removed the SocketModeFunctions class that had a single static method on it and instead directly exposed the defaultProcessEventErrorHandler method from it.
• the built-in middleware functions 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.
• 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 interface

... (truncated)

Commits

• 1555975 Publish @slack/[email protected] (#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)
• See full diff in compare view

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 <dependency name> 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)