^4.4.0 => TypeError: lazyWebStreams(...).newReadableStreamFromStreamReadable is not a function #521

Activity

1. arschmitz commented on Jun 7, 2023

   

   arschmitz

   on Jun 7, 2023

   More actions

   the code for this is just clearly wrong / missing

   readable-stream/lib/internal/streams/readable.js

   Lines 1220 to 1227 in ba27fd8

   	// Lazy to avoid circular references
   	function lazyWebStreams() {
   	if (webStreamsAdapters === undefined) webStreamsAdapters = {}
   	return webStreamsAdapters
   	}
   	Readable.fromWeb = function (readableStream, options) {
   	return lazyWebStreams().newStreamReadableFromReadableStream(readableStream, options)
   	}

   👍React with 👍1Reacted by David Halls
2. tpluscode commented on Jun 23, 2026

   

   tpluscode

   on Jun 23, 2026

   More actions

   Can this be fixed?
3. MattiasBuelens commented on Jun 23, 2026

   

   MattiasBuelens

   on Jun 23, 2026

   Contributor

   More actions

   I don't have a lot of context here, but it looks like we intentionally do not attempt to support the web streams adapter methods. We stub those out entirely:

   readable-stream/build/replacements.mjs

   Line 80 in 88df210

   const internalStreamsRequireWebStream = ["require\\('internal/webstreams/adapters'\\)", '{}']

   That said, if you're trying to use a new API like Readable.toWeb()... why are you using readable-stream in the first place? Wouldn't it make more sense to just use node:stream? 🤷‍♂️
4. tpluscode commented on Jun 23, 2026

   

   tpluscode

   on Jun 23, 2026

   More actions

   Because node:stream is problematic in web environment, where I'm forced to use libraries which depend on node streams. readable-stream usually is a good drop-in replacement
5. gowy222 commented on Jun 24, 2026

   

   gowy222

   on Jun 24, 2026

   Author

   More actions

   Thanks for the context. I understand that internal/webstreams/adapters is intentionally stubbed out in the current build.

   However, I do not think “just use node:stream” addresses the actual use case here.

   I originally ran into this while working on pure zip.js cross-platform consistency, specifically trying to keep behavior consistent between Node.js and browser Workers. In that kind of library/runtime-agnostic code, Web Streams are often the common denominator, and the Node.js stream ↔ Web Stream adapter methods are exactly the boundary where consistency matters.

   Using node:stream directly works only if the code is Node-only. But for a package that is intended to run consistently across Node.js, browsers, and Workers, replacing readable-stream with node:stream forces a Node-specific code path and defeats the purpose of having a portable stream abstraction in the first place.

   The issue is not that readable-stream must necessarily support the Web Streams adapter implementation. The issue is that the API appears to exist, but fails at runtime with an internal TypeError because the dependency was stubbed out:

   Readable.toWeb(...)
   Readable.fromWeb(...)

   From a userland perspective, if these methods are intentionally unsupported, then it would be much clearer and safer to either:

   1. remove them from the distributed build,
   2. exclude them from the documented/type-level API surface, or
   3. make them throw an explicit “Web Streams adapters are not supported by readable-stream” error.

   Leaving the methods present but wired to a stubbed internal adapter creates a misleading API surface and makes the failure mode look like a bug rather than an intentional unsupported feature.

   So the reason for using readable-stream here is not because this is Node-only code that should have used node:stream; it is because this is cross-platform code where consistent behavior between Node.js and browser/Worker environments is the primary goal.
6. arschmitz commented on Jun 24, 2026

   

   arschmitz

   on Jun 24, 2026

   More actions

   I don't remember the context or even the project i ran into this on before but I completely agree with @gowy222 assessment of the appearance of support while there is not. Which is also completely inline with my original comment that it appeared to be wrong or missing.