slackapi / slackapi/bolt-js

Removing support for Node 18 and other upcoming breaking changes

Open
#2,644 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

discussion semver:major
Dominant language
TypeScript
Stars
2.9k
Forks
445
Avg merge
1d 3h
Merged PRs (30d)
28

Description

👋 Hello! This issue announces support for Node 18 is being removed within a few months to add support and develop with changes from more recent Node versions. Ongoing changes and discussion can be followed along here!

📆 Timeline

As overview for what's ahead, the following timeline might be useful:

  • Upstream Node 18 reaches EOL: 2025-03-27.
  • Notice of removing support: 2025-09-03.
  • Development releases shared: 2025-10-03 or sooner.
  • Public release of new package versions: 2025-12-02 or later.
  • Previous versions become unsupported: 2026-01-01 or later.

References

👾 Planned changes

Breaking changes planned for this next major version follow.

Supported Node version

The Node 18 release will no longer be supported or used in testing. Future development will use features from the latest releases for the following versions:

  • Node 20 - "Maintenace": What we use in testing.
  • Node 22 - "Active": What we use in testing.
  • Node 24 - "Current": What we will recommend applications use.
Using the fetch API to send requests

The axios package has been used to send various responses as requests. We'll look to replace this with the undici package to align with the Node implementation.

Converting code samples and examples to ECMAScript modules

Examples documented for these packages will use ECMAScript modules. For: #2565.

Removing deprecated features

The next major version will remove deprecated features.

Using updated upstream packages

The @slack/logger, @slack/oauth, @slack/socket-mode, @slack/types, and @slack/web-api packages are used with planned breaking changes happening. We should use these updates for this release! From: https://github.com/slackapi/node-slack-sdk/issues/2359.

Converting test runners to default scaffoldings

Recent Node updates introduced a test runner for setting up and asserting cases. We can perhaps use this to reduce updates from test dependencies.

👁️‍🗨️ Future changes

Multiple open issues discuss improvements and breaking changes around typescript development that might not be included in this set of changes and can involve coordinating changes with @slack/types in upcoming releases. Follows: #1432.

📝 Notes

Super open to discussing the scope of these changes and considerations of all kind!

For sometime soon I'm hoping we can start developing against supported Node versions in sample apps and begin testing in CI 🚀

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

No files, tests, or entry points are named. Start by reviewing the timeline and planned changes, then follow #2565, #2359, and #1432 to establish scope; done would require an agreed implementation of the selected breaking changes and a release plan.

Written by the indexing model from the issue text.

Assessment

Tech stack
nodejs, typescript
Domain
build-system, ci-cd, release
Issue type
Refactor
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
20/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.