Skip to content

Use built-in AbortController #552

Open

Description

@james-pre

AbortController is available as a built-in on all platforms. readable-stream currently uses the abort-controller dependency. Since AbortController already exists, this dependency can be removed, which decreases the size of readable-stream while increasing supply chain security. Furthermore, native implementations are likely faster.

I'm willing to do a PR for this.

Activity

  1. MattiasBuelens commented on Feb 13, 2025

    @MattiasBuelens
    Contributor

    AbortController was added in Node 14.17.0. However, readable-stream supports Node 12 and higher (see README). So I'm afraid we can't remove this dependency just yet.

    Note that if globalThis.AbortController exists, readable-stream will use it and not load abort-controller:

    const AbortSignal = globalThis.AbortSignal || require('abort-controller').AbortSignal
    const AbortController = globalThis.AbortController || require('abort-controller').AbortController

    So if you don't need to support Node 12 in your app and can assume that globalThis.AbortController will always exist, you can configure your package manager or bundler to remove that dependency while building.

  2. james-pre commented on Feb 13, 2025

    @james-pre
    Author

    If that's the case, a conditional dependency should be used. This would allow abort-controller to not be installed when using a new enough version of Node.

  3. MichaelDeBoey commented on Aug 7, 2025

    @MichaelDeBoey

    @james-pre Unfortunately that would be a breaking change for existing consumers as well 😢
    So next breaking change would either drop v12 support (which means we could use native AbortController) or add abort-controller in optionalPeerDependencies.

    If I can choose, I would choose for option number 1 and just go native

    @mcollina It seems this package drops older versions of Node with every major, so I'm wondering if you'd be willing to accept a PR for dropping Node 12 support?
    I can even drop Node 14 & 16 support if you want to, but I would understand if that would be way too much at once.

  4. james-pre commented on Aug 7, 2025

    @james-pre
    Author

    Hey @MichaelDeBoey,

    Thanks for the reply. I agree with uping the major Node.js version. It might be worth going all the way to Node 20, since that is the current maintenance release (still older than LTS).

  5. james-pre commented on Apr 3, 2026

    @james-pre
    Author

    Hey maintainers! It's been over a year since this issue was opened, any chance we could see a new version to clean up the rotting dependency tree?

  6. mcollina commented on Apr 5, 2026

    @mcollina
    SponsorMember

    The only way this is solved is by releasing a new major. I would say it's in the Roadmap, maybe from the code in Node 26. This means it would target 22+ or 20+. But... most Node.js users are better off in using node:stream directly. There are still valid cases to use this, but every single time we ship a new major, the downloads of the previous majors do not decrease.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions