Summary
PR #2785 added several new docs pages covering ExecJS limitations, performance benchmarks, debugging, and client-vs-server rendering. Bot reviewers raised several valid concerns about ExecJS technical accuracy that require research to resolve properly. These were deferred from #2785 to avoid an endless review cycle on a docs PR.
Items to investigate
-
ExecJS runtime auto-detection — Multiple docs state "By default, ExecJS uses the Node.js runtime." However, ExecJS auto-detects via best_available and picks mini_racer/Bun before Node if installed. Verify and clarify across:
docs/oss/core-concepts/execjs-limitations.md:9
docs/oss/core-concepts/client-vs-server-rendering.md:7
-
ExecJS-on-Node process model — docs/oss/core-concepts/performance-benchmarks.md:13 describes ExecJS-on-Node as "Persistent subprocess via IPC" but ExecJS's ExternalRuntime may shell out per evaluation. Verify the actual architecture.
-
Timer polyfill behavior — docs/oss/building-features/debugging.md:68 says users will see setTimeout is not defined errors, but RubyEmbeddedJavaScript#execjs_timer_polyfills stubs these as silent no-ops. Clarify the actual failure mode.
-
SSR timing logging claim — docs/oss/core-concepts/performance-benchmarks.md:110 says "Server render time" is "logged by React on Rails when logging_on_server is enabled." But logging_on_server replays console messages, not render durations. Clarify what metrics are actually available.
-
pool_size constraint scope — docs/oss/core-concepts/execjs-limitations.md:108 says pool_size=1 is required on MRI for all ExecJS runtimes. This may only apply to mini_racer (V8 holds the GVL). With Node.js ExternalRuntime, rendering runs in a subprocess. Narrow the claim if appropriate.
Context
🤖 Generated with Claude Code
Summary
PR #2785 added several new docs pages covering ExecJS limitations, performance benchmarks, debugging, and client-vs-server rendering. Bot reviewers raised several valid concerns about ExecJS technical accuracy that require research to resolve properly. These were deferred from #2785 to avoid an endless review cycle on a docs PR.
Items to investigate
ExecJS runtime auto-detection — Multiple docs state "By default, ExecJS uses the Node.js runtime." However, ExecJS auto-detects via
best_availableand picks mini_racer/Bun before Node if installed. Verify and clarify across:docs/oss/core-concepts/execjs-limitations.md:9docs/oss/core-concepts/client-vs-server-rendering.md:7ExecJS-on-Node process model —
docs/oss/core-concepts/performance-benchmarks.md:13describes ExecJS-on-Node as "Persistent subprocess via IPC" but ExecJS'sExternalRuntimemay shell out per evaluation. Verify the actual architecture.Timer polyfill behavior —
docs/oss/building-features/debugging.md:68says users will seesetTimeout is not definederrors, butRubyEmbeddedJavaScript#execjs_timer_polyfillsstubs these as silent no-ops. Clarify the actual failure mode.SSR timing logging claim —
docs/oss/core-concepts/performance-benchmarks.md:110says "Server render time" is "logged by React on Rails whenlogging_on_serveris enabled." Butlogging_on_serverreplays console messages, not render durations. Clarify what metrics are actually available.pool_size constraint scope —
docs/oss/core-concepts/execjs-limitations.md:108says pool_size=1 is required on MRI for all ExecJS runtimes. This may only apply to mini_racer (V8 holds the GVL). With Node.js ExternalRuntime, rendering runs in a subprocess. Narrow the claim if appropriate.Context
claude[bot],chatgpt-codex-connector[bot]RubyEmbeddedJavaScriptto verify claims🤖 Generated with Claude Code