fix: eval (#383)

## Summary                                                
                                                           
Previously, `react-server` and `react-server build` would silently treat
piped stdin as the server entrypoint whenever `fd 0` happened to be a
pipe, file redirect, or (in production) any non-TTY context outside CI.
That made the CLI's behavior
depend on invisible environmental state: the same command could behave
differently depending on whether it was invoked from a shell, an editor
task runner, a process manager, or a subprocess whose parent happened to
close stdin. It also meant
stdin could be read without the user ever asking for it, which is
surprising at best and unsafe at worst.
                                                           
This change makes `--eval` the single, explicit opt-in. Stdin is now
**only** consulted when the user passes `--eval`, and nothing else
changes the CLI's entrypoint resolution.
  ## Behavior                                            
`--eval "<code>"` passes the inline string as the virtualized server
entrypoint, the same as before. `--eval` with no value reads the full
entrypoint from stdin — this is the new, explicit way to pipe code in.
With no `--eval` at all, stdin is
never touched, even if it is a pipe or a file redirect; the CLI falls
back to the positional root or the file-router as it always did.
                                                         
The JS-level signal is that the plugin's `options.eval` is now
tri-valued: `string` for inline code, `true` for "read stdin", and
anything else (undefined / `false`) for "don't use eval at all". The CLI
option definition changed from `-e,
--eval <code>` (required value) to `-e, --eval [code]` (optional value)
in both `dev` and `build` commands to support the bare form.
  ## Why                                             
The previous auto-detection had three concrete problems. It could
consume stdin from an unrelated parent process that happened to leave fd
0 open as a pipe, producing confusing "Root module not provided" errors
or worse, running
attacker-controlled code. It was non-deterministic across environments:
the production path additionally gated on `!process.env.CI`, so the same
invocation would take different branches in CI vs. local. And it made
the `--eval` flag's contract
ambiguous, because stdin could be the entrypoint even when `--eval` was
absent, so users couldn't reason about the CLI from the flags alone.
Making stdin opt-in via `--eval` collapses these three cases into one
rule that is trivial to explain and impossible to trigger by accident.
  ## Changes                                             
`lib/plugins/react-server-eval.mjs` drops the `fstatSync`-based
`isStdinPiped` probe entirely. The load handler now branches cleanly on
`options.eval`: string → return it verbatim, `true` → read stdin,
otherwise → return the "Root module not
provided" stub. `lib/dev/action.mjs` no longer runs its own `fstat` on
fd 0 to pick the virtual entrypoint; it selects the virtual module only
when `options.eval != null && options.eval !== false`.
`lib/build/server.mjs` drops the
`!process.stdin.isTTY && !process.env.CI` heuristic at the production
root-module decision and uses the same explicit check.
`bin/commands/dev.mjs` and `bin/commands/build.mjs` change the cac
option shape to `-e, --eval [code]` with clarified
  help text describing both forms.                      
                                               
## Docs
                                            
Both the English and Japanese `features/cli.mdx` have been updated for
the dev and build `--eval` sections. The prose explicitly calls out that
stdin is never auto-consumed, and each section now carries three
runnable examples: inline code,
bare `--eval` with a pipe, and bare `--eval` with a shell file redirect.
  ## Tests                                           
Two new specs guard the contract at complementary levels.
`test/__test__/react-server-eval.spec.mjs` is a fast unit spec that
imports the `react-server:eval` plugin directly and exercises its load
hook with a *poisoned* `process.stdin` that
throws on read. It verifies that the "no `--eval`", "`eval: false`", and
"`--eval "<inline>"`" paths all return the expected result without ever
touching stdin, and that `eval: true` correctly reads both single-chunk
and multi-chunk stdin
payloads. The poisoned-stdin trick is what lets the test make a positive
assertion about the *absence* of stdin reads, which a black-box HTTP
test cannot observe.
`test/__test__/cli-eval.spec.mjs` is an end-to-end spec that spawns the
real CLI binary as a subprocess. In dev mode it covers three cases:
`--eval "<inline>"` serves the inline marker, bare `--eval` + piped
stdin serves the stdin marker, and
a positional root file + piped *invalid* JavaScript serves the
positional marker (the critical regression guard — if auto-eval ever
comes back, the bogus stdin would either crash the server or be rendered
instead of the positional root). In
production mode it runs `build --eval "<inline>"` with bogus stdin piped
in and asserts the build exits successfully, covering the
`build/server.mjs` code path. The subprocess helper forces `NO_COLOR=1`
and strips ANSI defensively so readiness
   detection isn't broken by colored log output.        
  ## Compatibility                                   
This is a behavior change that could in principle affect users who were
relying on the undocumented auto-stdin path. In practice, the documented
way to pipe code was always `--eval`, and the auto path was an
implementation detail of the
plugin. Users who were piping code without `--eval` need to add the
flag. No API surface outside the CLI is affected.

Author: lazarv

docs/src/pages/en/(pages)/features/cli.mdx

@@ -140,7 +140,18 @@ When set, the development server will not validate your `react-server.config.*`
 ### --eval
 </Link>
 
-Evaluate the server entrypoint from the argument, like `node -e`. You can also use _stdin_ as the entrypoint. This type of entrypoint becomes a virtualized entrypoint and is not written to the file system.
+Evaluate the server entrypoint from the argument, like `node -e`. Pass `--eval` without a value to read the entrypoint from _stdin_ instead. Stdin is **never** auto-consumed — it is only read when `--eval` is explicitly passed. This type of entrypoint becomes a virtualized entrypoint and is not written to the file system.
+
+```sh
+# Inline code
+pnpm exec react-server --eval "export default () => <h1>Hello</h1>;"
+
+# From stdin (note the bare --eval, with no value)
+echo 'export default () => <h1>Hello from stdin</h1>;' | pnpm exec react-server --eval
+
+# From a file via shell redirect
+pnpm exec react-server --eval < ./entry.jsx
+```
 
 <Link name="dev-version">
 ### --version
@@ -259,7 +270,18 @@ This is useful when you want to override or provide adapter options without modi
 ### --eval
 </Link>
 
-Evaluate the server entrypoint from the argument, like `node -e`. You can also use _stdin_ as the entrypoint. This type of entrypoint becomes a virtualized entrypoint and is not written to the file system.
+Evaluate the server entrypoint from the argument, like `node -e`. Pass `--eval` without a value to read the entrypoint from _stdin_ instead. Stdin is **never** auto-consumed — it is only read when `--eval` is explicitly passed. This type of entrypoint becomes a virtualized entrypoint and is not written to the file system.
+
+```sh
+# Inline code
+pnpm exec react-server build --eval "export default () => <h1>Hello</h1>;"
+
+# From stdin
+echo 'export default () => <h1>Hi</h1>;' | pnpm exec react-server build --eval
+
+# From a file via shell redirect
+pnpm exec react-server build --eval < ./entry.jsx
+```
 
 <Link name="build-outdir">
 ### --outDir

docs/src/pages/ja/(pages)/features/cli.mdx

@@ -140,7 +140,18 @@ export default {
 ### --eval
 </Link>
 
-`node -e`と同じように引数からサーバーのエントリーポイントを評価します。または標準入力も指定することが出来ます。このエントリーポイントは仮想化エントリーポイントとなり、ファイルシステムには書き込まれません。
+`node -e`と同じように引数からサーバーのエントリーポイントを評価します。値を指定せずに `--eval` だけを渡すと、エントリーポイントを _標準入力_ から読み込みます。標準入力は **自動的には消費されません** — `--eval` が明示的に指定された場合にのみ読み込まれます。このエントリーポイントは仮想化エントリーポイントとなり、ファイルシステムには書き込まれません。
+
+```sh
+# インラインコード
+pnpm exec react-server --eval "export default () => <h1>Hello</h1>;"
+
+# 標準入力から（値を指定しない `--eval` に注意）
+echo 'export default () => <h1>Hello from stdin</h1>;' | pnpm exec react-server --eval
+
+# シェルのリダイレクトでファイルから
+pnpm exec react-server --eval < ./entry.jsx
+```
 
 <Link name="dev-version">
 ### --version
@@ -259,7 +270,18 @@ pnpm react-server build --deploy '{"project": "my-project"}'
 ### --eval
 </Link>
 
-`node -e`と同じように引数に指定したエントリーポイントを評価します。または標準入力も指定することが出来ます。このエントリーポイントはファイルシステムに書き込んだものではなく仮想的なエントリーポイントです。
+`node -e`と同じように引数に指定したエントリーポイントを評価します。値を指定せずに `--eval` だけを渡すと、エントリーポイントを _標準入力_ から読み込みます。標準入力は **自動的には消費されません** — `--eval` が明示的に指定された場合にのみ読み込まれます。このエントリーポイントはファイルシステムに書き込んだものではなく仮想的なエントリーポイントです。
+
+```sh
+# インラインコード
+pnpm exec react-server build --eval "export default () => <h1>Hello</h1>;"
+
+# 標準入力から
+echo 'export default () => <h1>Hi</h1>;' | pnpm exec react-server build --eval
+
+# シェルのリダイレクトでファイルから
+pnpm exec react-server build --eval < ./entry.jsx
+```
 
 <Link name="build-outdir">
 ### --outDir

packages/react-server/bin/commands/build.mjs

@@ -25,7 +25,10 @@ export default (cli) =>
       "[boolean|json] deploy using adapter, optionally pass JSON adapter options",
       { default: false }
     )
-    .option("-e, --eval <code>", "evaluate code", { type: "string" })
+    .option(
+      "-e, --eval [code]",
+      "evaluate code as the server entrypoint; pass without a value to read from stdin"
+    )
     .option("--outDir <dir>", "[string] output directory", {
       default: ".react-server",
     })

packages/react-server/bin/commands/dev.mjs

@@ -24,7 +24,10 @@ export default (cli) =>
     .option("--no-color", "disable color output", { default: false })
     .option("--no-check", "skip dependency checks", { default: false })
     .option("--no-validation", "skip config validation", { default: false })
-    .option("-e, --eval <code>", "evaluate code", { type: "string" })
+    .option(
+      "-e, --eval [code]",
+      "evaluate code as the server entrypoint; pass without a value to read from stdin"
+    )
     .option("-o, --outDir <dir>", "[string] output directory", {
       default: ".react-server",
     })

packages/react-server/lib/build/server.mjs

@@ -344,7 +344,7 @@ export default async function serverBuild(root, options, clientManifestBus) {
     { paths: [cwd] }
   );
   const rootModulePath =
-    !root && (options.eval || (!process.stdin.isTTY && !process.env.CI))
+    !root && options.eval != null && options.eval !== false
       ? "virtual:react-server-eval.jsx"
       : root?.startsWith("virtual:")
         ? root

packages/react-server/lib/dev/action.mjs

@@ -1,4 +1,3 @@
-import { fstatSync } from "node:fs";
 import { isIPv6 } from "node:net";
 
 import open from "open";
@@ -132,25 +131,11 @@ export default async function dev(root, options) {
             await import("../../server/action-crypto.mjs");
           await initSecretFromConfig(configRoot);
 
-          // Detect whether the user is piping code via stdin.
-          // Use fstat on fd 0 to distinguish a real pipe/file redirect
-          // from a non-TTY background process, Docker, or CI runner
-          // where stdin is /dev/null or closed.
-          // Only relevant when no explicit root module was provided —
-          // if the user passed `react-server ./app.jsx`, use that even
-          // when stdin happens to be piped (e.g. via npm-run-all/run-p).
-          let isStdinPiped = false;
-          if (!root) {
-            try {
-              const stat = fstatSync(0);
-              isStdinPiped = stat.isFIFO() || stat.isFile();
-            } catch {
-              // fd 0 not available — not piped
-            }
-          }
-
+          // Stdin is never auto-detected as the entrypoint — the user must
+          // explicitly opt in by passing `--eval` (with a string value, or
+          // bare to read the entrypoint from stdin).
           server = await createServer(
-            options.eval || isStdinPiped
+            options.eval != null && options.eval !== false
               ? "virtual:react-server-eval.jsx"
               : root,
             options

packages/react-server/lib/plugins/react-server-eval.mjs

@@ -1,19 +1,3 @@
-import { fstatSync } from "node:fs";
-
-// Check whether stdin is an actual pipe or file redirect (i.e. the user
-// is piping code into react-server), as opposed to a TTY, /dev/null
-// (background process), or a closed fd (spawned subprocess).
-// `isFIFO()` catches `echo "code" | react-server`
-// `isFile()` catches `react-server < file.jsx`
-function isStdinPiped() {
-  try {
-    const stat = fstatSync(0);
-    return stat.isFIFO() || stat.isFile();
-  } catch {
-    return false;
-  }
-}
-
 export default function reactServerEval(options) {
   return {
     name: "react-server:eval",
@@ -30,9 +14,13 @@ export default function reactServerEval(options) {
         id: /^virtual:react-server-eval\.jsx$/,
       },
       async handler() {
-        if (options.eval) {
+        // `--eval <code>` → use the literal code string.
+        // `--eval` (no value) → read the entrypoint from stdin.
+        // Stdin is never consulted unless `--eval` was explicitly passed.
+        if (typeof options.eval === "string") {
           return options.eval;
-        } else if (isStdinPiped()) {
+        }
+        if (options.eval === true) {
           let code = "";
           process.stdin.setEncoding("utf8");
           for await (const chunk of process.stdin) {