Stream options are null using basic setup

[damassi]

Hi! I'm trying out this lib in our app, and right away things seem to throw errors. Not sure why. Using regular React 18 renderToPipeableStream things work fine.

Using out of the box vanilla setup config:

stream = await renderToStream(jsx)

I see this error:

Error: [react-streaming@0.3.43][Bug] You stumbled upon a bug in react-streaming's source code. Reach out at https://github.com/brillout/react-streaming/issues/new and include this error stack (the error stack is usually enough to fix the problem). A maintainer will fix the bug (usually under 24 hours). Do not hesitate to reach out as it makes react-streaming more robust. at renderToStream (/Users/cn/Sites/artsy/force/node_modules/react-streaming/dist/cjs/server/renderToStream.js:113:28)

Which points at this line of code:

(0, utils_1.assert)(globalObject.renderToWebStream);

As a test, if I set webStream: false I now get this error:

TypeError: globalObject.renderToNodeStream is not a function
    at renderToStream (/Users/cn/Sites/artsy/force/node_modules/react-streaming/dist/cjs/server/renderToStream.js:110:79)

If I go into the source code and log out globalObject, this is what's returned:

 { renderToNodeStream: null, renderToWebStream: null }

Why would both of these be null? Am I missing some setup somewhere?

FWIW, our app is running on Node 18, but I've also tried things under Node 20 and 22, and still the same error.

[brillout]

Minimal reproduction welcome. I'll re-open then. (If you want don't want to create a minimal reproduction you can also further dig into the source code, the problematic part is fairly easy to understand.)

[damassi]

Created a minimal repo setup with a new app and all worked good, so i'll continue digging inside of our app to see if anything else is up. Thanks 👍

[damassi]

@brillout - reporting back (and for others that might encounter this issue), I was able to track down the problem in our express app.

For whatever reason, importing the lib from

import { renderToStream } from "react-streaming/server"

does not seem to correctly resolve to a node-only environment, where things are being used.

To get things to work, I had to explicitly import it from dist like so:

import { renderToStream } from "react-streaming/dist/cjs/server/index.node-only"

[brillout]

does not seem to correctly resolve to a node-only environment, where things are being used.

Why does your environment resolves the wrong package.json#exports? Or can the exports list be improved?

To get things to work, I had to explicitly import it from dist like so:

It's a brittle workaround prone to break at any time, e.g. upon internal refactors such as when react-streaming will move to ESM only.

The best would be to get to the bottom of this.

[damassi]

Right. And in fact we've already run into two issues trying to import directly from this path on CircleCI. Jest cannot resolve it.

And then later, when mocking out said path (to get the test to green) and deploying our app via a docker container, the app fails to launch for the same reason, but there it seems to hint at an attempt to resolve an incorrect path via ESM, which we don't use. Importing the long dist path works fine during local dev on OSX, but on linux, no go (seemingly). Still, the bigger question is why I can't import from react-streaming/server.

Here's that error message:

Running command: node --max_old_space_size=2048 --heapsnapshot-signal=SIGUSR2 --no-experimental-fetch ./server.dist.js
Error [ERR_PACKAGE_PATH_NOT_EXPORTED]: Package subpath './dist/cjs/server/index.node-only' is not defined by "exports" in /app/node_modules/react-streaming/package.json
    at new NodeError (node:internal/errors:399:5)
    at exportsNotFound (node:internal/modules/esm/resolve:361:10)
    at packageExportsResolve (node:internal/modules/esm/resolve:697:9)
    at resolveExports (node:internal/modules/cjs/loader:565:36)
    at Module._findPath (node:internal/modules/cjs/loader:634:31)
    at Module._resolveFilename (node:internal/modules/cjs/loader:1061:27)
    at Hook.Module.require (/app/node_modules/dd-trace/packages/dd-trace/src/ritm.js:54:29)
    at Module.patchedRequire (/app/node_modules/require-in-the-middle/index.js:194:34)
    at Hook._require.Module.require (/app/node_modules/require-in-the-middle/index.js:142:27)
    at require (node:internal/modules/cjs/helpers:110:18) {
  code: 'ERR_PACKAGE_PATH_NOT_EXPORTED'

Will look at the exports in the lib to see whats up. We're not doing anything particularly special in our app. Node 18, express, webpack and babel compiled down to cjs.

Upon internal refactors such as when react-streaming will move to ESM only.

(Not to side-track the discussion, but moving to ESM only would be unfortunate. For large apps, its very non-trivial to migrate, and this library is incredibly useful (it solved many edge-cases for us, compared to vanilla renderToPipeableStream). ESM-only would lock out many consumers and companies who aren't in a position to switch, either because of node version or a large compiled codebase, or otherwise.)

Update:

I tried all manner of changes to react-streaming's exports config in addition to various changes to our webpack config, but nothing budged. Was able to get things to work by patch-packaging the CJS exports into server/index, but obviously this isn't an ideal solution. Feels like there's a missing condition on the lib side exports somewhere, but I can't put my finger on it.

[brillout]

I've refactored the exports fields. Try import { renderToStream } from 'react-streaming/server' with 0.3.43-commit-af1be3b and let me know if that works.

[damassi]

Amazing! Will do. Let me try.

[damassi]

Unfortunately still same error:

Error: [react-streaming@0.3.43-commit-af1be3b][Bug] You stumbled upon a bug in react-streaming's source code. Reach out at https://github.com/brillout/react-streaming/issues/new and include this error stack (the error stack is usually enough to fix the problem). A maintainer will fix the bug (usually under 24 hours). Do not hesitate to reach out as it makes react-streaming more robust. 
    at renderToStream (/Users/cn/Sites/artsy/force/node_modules/react-streaming/dist/cjs/server/renderToStream.js:113:28)

Though command clicking into the path I do see an update on the TS side:

https://github.com/user-attachments/assets/7b1720ec-d567-4c0d-812b-5b04a38e686d

Worth noting that we're not compiling with TSC; we use babel + babel-preset-typescript to compile down.

[brillout]

This is the rationale of the new "./server" exports: https://gist.github.com/brillout/553253e27a43ccfc01ec6c38880d1360.

To which path is "./server" being resolved? Which tool is doing the resolving?

[damassi]

We use webpack to build our server code with target: "node" for prod, however, during development we don't invoke any bundler at all, and run everything through babel-register at runtime. So in instances like this, babel would be doing the compiling down into cjs, and node would be doing the resolving. I'm unsure of how that might work, as this is the first time I've run across this issue!

[brillout]

Then I guess you don't get the error at dev and you only get it at prod, correct?

It seems that Babel is picking the "worker" field. Why is that?

[damassi]

Unfortunately get the error during dev, but I suspect we wouldn't get it in prod (because of target: "node", which, via webpack, would likely resolve the correct package when bundling.)

We don't have any worker setup in our app at the moment, but I'll investigate a bit.

[brillout]

Ah, yeah, that makes sense. I meant the other way around (working in prod but failing in dev).

I'll investigate a bit.

:+1: