Skip to content

Only support native ReadableStream streams #4293

Closed

Description

@kanongil

Support plan

  • is this issue currently blocking your project? (yes/no): no
  • is this issue affecting a production system? (yes/no): no

Context

  • node version: 14+
  • module version: 20.x
  • environment (e.g. node, browser, native):
  • used with (e.g. hapi application, another framework, standalone, ...):
  • any other relevant information:

Handlers currently support returning any ReadableStream, even v1 streams from the readable-stream module. However using such legacy streams is incompatible with modern streams and requires very careful integration to support.

What problem are you trying to solve?

Simpler, more robust internal stream handling. Eg. we can rely on all streams having the .destroy() method and remove tests like:

it('close() stream when no destroy() method', async () => {

Do you have a new or modified API suggestion to solve the problem?

Drop node v12 support (#4279) and fail when the returned stream matches value instanceof Stream && !(value instanceof ReadableStream). The current detection logic relies on duck typing.

One drawback is that we increase the reliance on the node runtime, which means that the Chrome "support" as introduced in #3946 will be gone (unless they find a way to properly polyfill ReadableStream). I don't know why this was patched in, since we don't do any kind of testing on that platform.

For a more graceful approach, we could pipe() legacy streams through a Passthrough stream when returned from a handler. Then internal processing could still rely on the stream being native.

Activity

  1. added
    featureNew functionality or improvement
    breaking changesChange that can breaking existing code
    on Oct 1, 2021
  2. Nargonath commented on Oct 1, 2021

    @Nargonath
    Contributor

    Thanks @kanongil for bringing this up. Overall this seems like a good idea, I'm not sure though regarding breaking the support for the Chrome use case. Reading through the PR you mentioned their use case seemed legitimate. FWIU if we pipe the legacy streams through a Passthrough stream we'd be able to keep the Chrome support?

  3. kanongil commented on Oct 1, 2021

    @kanongil
    ContributorAuthor

    This will still break this specific Chrome support, since it most likely polyfills the internal ReadableStream using the readable-stream module, which is outdated and does not expose all modern APIs. We would likely query properties that aren't there.

  4. hueniverse commented on Feb 17, 2022

    @hueniverse
    Contributor

    This smells like the kind of change I would have made. Not sure what's the "Chrome support" use case...

  5. devinivy commented on Nov 7, 2022

    @devinivy
    Member

    Resolved with v21 #4386

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

    breaking changesChange that can breaking existing codefeatureNew functionality or improvement

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions