Move Node Renderer entry point to renderer/ directory#3165
Conversation
Establishes `renderer/node-renderer.js` as the canonical location for the Pro Node Renderer entry point. Previously the path was inconsistent across docs (`node-renderer.js`, `client/node-renderer.js`, or `react-on-rails-pro-node-renderer.js`). Using a dedicated top-level `renderer/` directory makes it trivial to exclude from production Docker builds that strip JS sources after bundling — the Node Renderer process still needs its entry file at runtime. Changes: - Generator (`pro_setup.rb`, `base_generator.rb`, `demo_page_config.rb`, USAGE, initializer template) now creates the entry at `renderer/node-renderer.js` - Template file moved to `templates/pro/base/renderer/node-renderer.js` - Pro `spec/dummy` renderer file, Procfile.dev, Procfile.prod, package.json scripts, .controlplane/rails.yml, and benchmark reference updated - All 13 docs now use `renderer/node-renderer.js` consistently - Container deployment doc explains the rationale for the dedicated directory - Generator specs updated; 13 renderer-related specs pass Existing apps are unaffected — the generator skips files that already exist, so upgrades keep their current `client/node-renderer.js`. Fixes #3073 Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The previous link to main-branch GitHub URL fails link-check on the PR branch because the file path has changed. Relative link works across all branches and avoids the chicken-and-egg check on the renamed path. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
WalkthroughChange the canonical Node renderer entrypoint to Changes
Sequence Diagram(s)sequenceDiagram
participant Dev as Developer
participant Gen as Pro Generator
participant FS as Filesystem
participant Proc as Procfile
rect rgba(100,149,237,0.5)
Dev->>Gen: run generator (--pro / --force)
Gen->>FS: check `renderer/node-renderer.js`
alt renderer exists
FS-->>Gen: exists -> return (noop)
else
Gen->>FS: check `client/node-renderer.js` (legacy)
alt legacy exists
FS-->>Gen: legacy found -> log hint
Gen->>Proc: do NOT add node-renderer entry
else
Gen->>FS: create `renderer/` and copy template -> `renderer/node-renderer.js`
Gen->>Proc: add `node-renderer:` entry to Procfile.dev
end
end
end
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
coderabbitai
Bot
added
review-needed
documentation
docs-cleanup
Greptile SummaryThis PR establishes Confidence Score: 5/5Safe to merge — path rename is contained, legacy path detection is correct, and add_pro_to_procfile already guards against duplicate Procfile entries. All 30 changed files are consistent path substitutions or the new legacy-detection logic, which is correctly implemented and thoroughly tested (79 generator examples + 3 new legacy-context examples). No P0 or P1 findings. No files require special attention. Important Files Changed
Flowchart%%{init: {'theme': 'neutral'}}%%
flowchart TD
A([run pro generator]) --> B[create_pro_initializer]
B --> C[create_node_renderer]
C --> D{renderer/node-renderer.js already exists?}
D -- yes --> E[skip, return false]
D -- no --> F{client/node-renderer.js legacy exists?}
F -- yes --> G[preserve legacy, return true]
F -- no --> H[empty_directory renderer/ / copy template / return false]
E --> I{legacy_renderer_detected?}
G --> I
H --> I
I -- false --> J[add_pro_to_procfile / check for duplicate entry]
I -- true --> K[skip Procfile update]
J --> L[update_webpack_config_for_pro]
K --> L
Reviews (2): Last reviewed commit: "Guard Procfile update when legacy render..." | Re-trigger Greptile |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
Code ReviewOverviewClean, well-scoped PR. Moving the Node Renderer entrypoint to a dedicated Issues1. Upgrade behavior gap — existing
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
docs/oss/building-features/node-renderer/basics.md (1)
68-81:⚠️ Potential issue | 🟡 MinorConvert the launcher example to CommonJS to match the documented approach.
Line 81 instructs users to run
node renderer/node-renderer.js, but the snippet uses ESMimportsyntax with__dirname, which will fail in a default Node.js configuration. Perjs-configuration.md, this file should use CommonJS: "The generator uses this filename and CommonJS syntax so the file runs directly withnode renderer/node-renderer.jswithout extra ESM configuration."📘 Proposed docs fix
- import path from 'path'; - import reactOnRailsProNodeRenderer from 'react-on-rails-pro-node-renderer'; + const path = require('path'); + const { reactOnRailsProNodeRenderer } = require('react-on-rails-pro-node-renderer'); const config = { serverBundleCachePath: path.resolve(__dirname, '../.node-renderer-bundles'), };🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/oss/building-features/node-renderer/basics.md` around lines 68 - 81, The example launcher uses ESM import syntax which will fail when run with `node renderer/node-renderer.js`; change the snippet to CommonJS by replacing the ESM import with require (use require('path') and require('react-on-rails-pro-node-renderer')), keep the config object with serverBundleCachePath and __dirname, and invoke reactOnRailsProNodeRenderer(config) directly (or export nothing); update the snippet around the symbols reactOnRailsProNodeRenderer, config, and serverBundleCachePath so it runs with plain `node renderer/node-renderer.js`.
🧹 Nitpick comments (1)
react_on_rails/spec/react_on_rails/support/shared_examples/pro_generator_examples.rb (1)
17-21: Consider asserting the Procfile command path too.Since the PR standardizes the runnable entry point, this shared example would catch regressions if
Procfile.devpointed back tonode-renderer.jsorclient/node-renderer.js.Proposed test strengthening
it "adds node-renderer process to Procfile.dev" do assert_file "Procfile.dev" do |content| expect(content).to include("node-renderer:") expect(content).to include("RENDERER_PORT=3800") + expect(content).to include("node renderer/node-renderer.js") end end🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@react_on_rails/spec/react_on_rails/support/shared_examples/pro_generator_examples.rb` around lines 17 - 21, Update the shared example in pro_generator_examples.rb (the "adds node-renderer process to Procfile.dev" test) to also assert that Procfile.dev uses the standardized runnable entry point (for example contains the exact command path "bin/node-renderer" or whatever the project-standard entry is) and to fail if legacy paths like "node-renderer.js" or "client/node-renderer.js" are present; keep the existing checks for "node-renderer:" and "RENDERER_PORT=3800" and add assertions inside the same assert_file block that include the canonical command path and exclude the old paths.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@CHANGELOG.md`:
- Line 29: Update the CHANGELOG entry for the Pro generator so the tag is the
standalone prefix "**[Pro]**" and append the PR attribution using the required
format; locate the line containing "Pro generator now creates the Node Renderer
at `renderer/node-renderer.js`" and change its header to start with "**[Pro]**"
and add the PR link and author as `[PR
1818](https://github.com/shakacode/react_on_rails/pull/1818) by
[username](https://github.com/username)` (replace PR number and username with
the actual values).
---
Outside diff comments:
In `@docs/oss/building-features/node-renderer/basics.md`:
- Around line 68-81: The example launcher uses ESM import syntax which will fail
when run with `node renderer/node-renderer.js`; change the snippet to CommonJS
by replacing the ESM import with require (use require('path') and
require('react-on-rails-pro-node-renderer')), keep the config object with
serverBundleCachePath and __dirname, and invoke
reactOnRailsProNodeRenderer(config) directly (or export nothing); update the
snippet around the symbols reactOnRailsProNodeRenderer, config, and
serverBundleCachePath so it runs with plain `node renderer/node-renderer.js`.
---
Nitpick comments:
In
`@react_on_rails/spec/react_on_rails/support/shared_examples/pro_generator_examples.rb`:
- Around line 17-21: Update the shared example in pro_generator_examples.rb (the
"adds node-renderer process to Procfile.dev" test) to also assert that
Procfile.dev uses the standardized runnable entry point (for example contains
the exact command path "bin/node-renderer" or whatever the project-standard
entry is) and to fail if legacy paths like "node-renderer.js" or
"client/node-renderer.js" are present; keep the existing checks for
"node-renderer:" and "RENDERER_PORT=3800" and add assertions inside the same
assert_file block that include the canonical command path and exclude the old
paths.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: b050f35b-1cc0-4d9e-9c6c-a02974a90339
📒 Files selected for processing (28)
CHANGELOG.mdbenchmarks/bench-node-renderer.rbdocs/oss/api-reference/generator-details.mddocs/oss/building-features/code-splitting.mddocs/oss/building-features/node-renderer/basics.mddocs/oss/building-features/node-renderer/container-deployment.mddocs/oss/building-features/node-renderer/debugging.mddocs/oss/building-features/node-renderer/heroku.mddocs/oss/building-features/node-renderer/js-configuration.mddocs/oss/deployment/docker-deployment.mddocs/oss/migrating/rsc-preparing-app.mddocs/oss/migrating/rsc-troubleshooting.mddocs/pro/installation.mddocs/pro/js-memory-leaks.mddocs/pro/profiling-server-side-rendering-code.mdreact_on_rails/lib/generators/react_on_rails/base_generator.rbreact_on_rails/lib/generators/react_on_rails/demo_page_config.rbreact_on_rails/lib/generators/react_on_rails/pro/USAGEreact_on_rails/lib/generators/react_on_rails/pro_setup.rbreact_on_rails/lib/generators/react_on_rails/templates/pro/base/config/initializers/react_on_rails_pro.rb.ttreact_on_rails/lib/generators/react_on_rails/templates/pro/base/renderer/node-renderer.jsreact_on_rails/spec/react_on_rails/generators/install_generator_spec.rbreact_on_rails/spec/react_on_rails/support/shared_examples/pro_generator_examples.rbreact_on_rails_pro/.controlplane/rails.ymlreact_on_rails_pro/spec/dummy/Procfile.devreact_on_rails_pro/spec/dummy/Procfile.prodreact_on_rails_pro/spec/dummy/package.jsonreact_on_rails_pro/spec/dummy/renderer/node-renderer.js
- pro_setup.rb: skip `create_node_renderer` when the legacy `client/node-renderer.js` exists, emitting a migration hint so existing Pro users don't silently end up with two renderer files after rerunning the generator. Added a spec covering the legacy-path case. - docs/oss/.../js-configuration.md: revert the testing-example link to the absolute GitHub URL so hosted docs platforms don't 404 on a relative path that leaves the docs tree. - CHANGELOG.md: split `**[Pro]**` from the entry title and add the PR attribution to match the project's changelog guidelines. - packages/.../react-on-rails-pro-node-renderer/README.md: update the quickstart to reference `renderer/node-renderer.js` so the README matches the new generator default. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The absolute URL 404s on main until this PR merges, so the pre-push lychee check rejects it. Keep the relative link which resolves correctly on GitHub file browsing; hosted docs are served via GitHub, so the reviewer's concern about Docusaurus-style resolution does not apply. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Review response summaryI (Claude Code) addressed the review feedback in two commits on this branch: 54c71c2 – Address PR #3165 review: legacy renderer check, docs/changelog polish
3eaef8c – Revert docs link back to relative path for lychee compatibility
Local checks: |
|
Tip For best results, initiate chat on the files or code changes. 🧩 Analysis chain🏁 Script executed: Length of output: 7237
CHANGELOG.md ✅
Relative link in All the review threads have been addressed. The PR looks ready to merge. 🐇 🧠 Learnings used |
There was a problem hiding this comment.
🧹 Nitpick comments (1)
react_on_rails/spec/react_on_rails/generators/pro_generator_spec.rb (1)
1226-1255: Consider asserting the migration hint is emitted.The PR description notes the generator "emits migration hint" when it detects
client/node-renderer.js. This spec verifies the two file-system outcomes (renderer not created, legacy preserved) but does not verify the user-facing migration message, which is arguably the most important signal to the developer in this skip path. Adding a third expectation would guard against the hint silently regressing.♻️ Suggested addition
it "preserves the legacy client/node-renderer.js" do expect(File.read(File.join(destination_root, "client/node-renderer.js"))).to eq(legacy_renderer_content) end + + it "emits a migration hint referencing the new renderer path" do + expect(GeneratorMessages.messages.join("\n")).to include("renderer/node-renderer.js") + end endAdjust the substring to match the exact hint wording used by the generator.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@react_on_rails/spec/react_on_rails/generators/pro_generator_spec.rb` around lines 1226 - 1255, Add an expectation in this spec block to assert the generator emitted the user-facing migration hint when it detects the legacy client/node-renderer.js: after the Dir.chdir { run_generator(["--force"]) } invocation, assert that the captured generator output (from run_generator) includes the exact migration hint string the generator prints; locate the spec context using the existing example (the context block and run_generator call) and match the substring to the exact wording used by the generator to avoid false negatives.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In `@react_on_rails/spec/react_on_rails/generators/pro_generator_spec.rb`:
- Around line 1226-1255: Add an expectation in this spec block to assert the
generator emitted the user-facing migration hint when it detects the legacy
client/node-renderer.js: after the Dir.chdir { run_generator(["--force"]) }
invocation, assert that the captured generator output (from run_generator)
includes the exact migration hint string the generator prints; locate the spec
context using the existing example (the context block and run_generator call)
and match the substring to the exact wording used by the generator to avoid
false negatives.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 47afa30b-d9df-408d-aa50-e74d69f6bb30
📒 Files selected for processing (4)
CHANGELOG.mdpackages/react-on-rails-pro-node-renderer/README.mdreact_on_rails/lib/generators/react_on_rails/pro_setup.rbreact_on_rails/spec/react_on_rails/generators/pro_generator_spec.rb
✅ Files skipped from review due to trivial changes (2)
- packages/react-on-rails-pro-node-renderer/README.md
- CHANGELOG.md
🚧 Files skipped from review as they are similar to previous changes (1)
- react_on_rails/lib/generators/react_on_rails/pro_setup.rb
Code ReviewOverall: Clean, well-scoped PR. The path migration is consistent across generators, docs, specs, and the dummy app, and the backward-compatibility guard for Bug (medium) — wrong Procfile.dev entry written for legacy apps
create_node_renderer # may return early when legacy file detected
add_pro_to_procfile # still runsWhen ...pointing to a file that was deliberately not created. The app would fail to start. See inline comment on The legacy-detection test in Minor —
|
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
Bugbot Autofix is ON, but it could not run because on-demand usage is turned off. To enable Bugbot Autofix, turn on on-demand usage and set a spend limit in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 3eaef8c. Configure here.
size-limit report 📦
|
…irectory Addresses PR #3165 review (claude[bot]): - setup_pro now captures the return value of create_node_renderer. When a legacy client/node-renderer.js is present, create_node_renderer returns true, and setup_pro skips add_pro_to_procfile. Previously, legacy-renderer users could end up with a Procfile.dev entry pointing at renderer/node-renderer.js (a file deliberately not created), leaving the renderer process unable to start. - create_node_renderer now uses Thor's empty_directory instead of FileUtils.mkdir_p, so it participates in --pretend / verbose output like the rest of the generator. - Added a Procfile.dev assertion to the legacy-renderer spec to lock in the correct behavior. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Review response summaryI (Claude Code) addressed the follow-up review in commit 7f35de0:
Already-replied threads resolved
Verified locally: |
Review response summaryI (Claude Code) addressed the three remaining review threads in commit 4e8263473.
Declined (and resolved as duplicate):
Verification
|
Code ReviewOverviewThis PR cleanly establishes Strengths
Issues / Suggestions1. Idempotency check is too narrow ( The check 2. No Procfile stale-entry check when legacy renderer is detected When 3. Minor: relative doc link may break in rendered documentation
SummaryThe core change is solid and the test matrix covers the important upgrade combinations well. Items 1 and 2 are minor edge-case gaps in the generator UX rather than correctness bugs — nothing that would break a fresh install. Item 3 is cosmetic. |
- Match renderer command with regex so `node ./renderer/node-renderer.js` is recognized as already present (idempotency was too strict). - When a legacy `client/node-renderer.js` is detected and Procfile.dev still launches it, surface a pointed warning pinpointing the stale line instead of leaving users to diff the generic migration hint. - Add specs for both the `./`-prefixed command and the stale legacy Procfile entry. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Review response summaryI (Claude Code) addressed the two OPTIONAL items from this review in commit 7f11f1b8d.
Item 3 — relative doc link in
|
Code ReviewOverviewClean, well-scoped PR that establishes Potential bugsRegex matches commented-out Procfile lines (see inline comment on
…would cause the generator to think the entry is already present and skip adding the live entry. The same issue applies to Design / UX concernsMixed concern in The method issues a Missing guidance for "legacy file exists, no Procfile entry" (see inline) When Minor observations
Test coverageThe new spec contexts in Overall this is in good shape. The regex anchor issue is the one concrete bug worth fixing before merge; the rest are polish. |
|
Review sweep completed at 2026-04-18T19:51:39Z. Mattered
Skipped
No follow-up issue was created. Future full-PR scans should start after this comment unless I say |
Code ReviewOverviewGood, well-scoped PR. The path standardization is clear and the upgrade safety logic (preserving Issues1. Documentation link regression — The link was changed from an absolute GitHub URL to a relative local path ( 2. Missing edge-case test: both files exist + legacy Procfile entry The "when both renderer/node-renderer.js and legacy client/node-renderer.js exist" context (line 1493 of In that scenario the code path differs from the "legacy only" case:
The user gets less-specific guidance than if only the legacy file were present. Worth adding a test and deciding whether the more detailed migration hint should surface here too. 3. Public module constants
Positive notes
|
|
Follow-up review sweep completed at 2026-04-18T20:21:28Z. Mattered
Skipped
No follow-up issue was created. Future full-PR scans should start after this comment unless I say |
Now that PR #3165 has merged and `react_on_rails_pro/spec/dummy/renderer/node-renderer.js` exists on `main`, switch the testing-example link in `js-configuration.md` from a cross-package relative path back to an absolute GitHub URL. The relative path was a temporary workaround so the lychee link check would pass before the file existed at its new location; absolute URLs render correctly on the published documentation site, where relative cross-package links may not resolve. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
## Summary Follow-up to #3165. Now that `react_on_rails_pro/spec/dummy/renderer/node-renderer.js` exists on `main`, switches the testing-example link in `docs/oss/building-features/node-renderer/js-configuration.md` from a cross-package relative path back to an absolute GitHub URL. The relative path was a temporary workaround so the lychee link check would pass before the file existed at its new location. Absolute URLs render correctly on the published documentation site (Docusaurus / `reactonrails.com/docs`), where cross-package relative links may not resolve. ## Test plan - [x] Lychee pre-commit hook passes on the changed file - [x] Prettier passes - [x] `curl https://github.com/shakacode/react_on_rails/blob/main/react_on_rails_pro/spec/dummy/renderer/node-renderer.js` returns 200 🤖 Generated with [Claude Code](https://claude.com/claude-code) <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Low Risk** > Low risk documentation-only change that updates a single link target with no runtime or API impact. > > **Overview** > Restores the **testing example** link in `docs/oss/building-features/node-renderer/js-configuration.md` to an absolute GitHub URL (instead of a cross-package relative path), so the link resolves correctly on the published documentation site. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 10da4a9. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY --> <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Updated a testing example reference link to point to an external GitHub repository, enhancing documentation accessibility while preserving the reference material. <!-- end of auto-generated comment: release notes by coderabbit.ai --> Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…ons-docs * origin/main: chore: remove redundant --rsc-pro install generator flag (#3105) ci: warn (don't fail) on Bencher main regression (#3168) test: enable RSpec --profile to surface slowest package tests (#3176) fix(node-renderer): expose performance in VM context when supportModules (#3158) docs: remove stale immediate_hydration references (#3139) (#3159) docs: restore absolute URL for node-renderer testing example (#3179) Bump Rspack dependencies to v2 (^2.0.0-0) (#3084) chore: remove obsolete webpack <5.106.0 pin (#3175) Move Node Renderer entry point to renderer/ directory (#3165) docs: address RSC pitfalls review follow-ups (#3155) (#3156) docs: remove fabricated DevConsole reference, link verified RSC tools (#2527) (#3163) # Conflicts: # docs/oss/building-features/node-renderer/js-configuration.md
…ging' into jg/3122-rolling-deploy-adapter * origin/jg/3122-unify-renderer-cache-staging: (39 commits) fix(specs): boot dummy specs without readline and drop redundant pnpm workspace (#3190) docs: add RSC migration success stories page (#1985) (#3162) Fix Bencher reporting permanently broken on pushes to main (#3148) docs: add example migrations guide (#3126) docs: remove defunct guavapass.com reference (#3199) chore: remove redundant --rsc-pro install generator flag (#3105) ci: warn (don't fail) on Bencher main regression (#3168) test: enable RSpec --profile to surface slowest package tests (#3176) fix(node-renderer): expose performance in VM context when supportModules (#3158) docs: remove stale immediate_hydration references (#3139) (#3159) docs: restore absolute URL for node-renderer testing example (#3179) Bump Rspack dependencies to v2 (^2.0.0-0) (#3084) chore: remove obsolete webpack <5.106.0 pin (#3175) Move Node Renderer entry point to renderer/ directory (#3165) docs: address RSC pitfalls review follow-ups (#3155) (#3156) docs: remove fabricated DevConsole reference, link verified RSC tools (#2527) (#3163) Scaffold CI workflow and build scripts for first-run consistency (#3097) Add OPTIONAL triage tier and fix recommendations to /address-review (#3161) chore: sync Gemfile.lock with term-ansicolor 1.11.3 (#3164) Simplify the docs sidebar and Pro landing pages (#3119) ...
* origin/main: fix(specs): boot dummy specs without readline and drop redundant pnpm workspace (#3190) docs: add RSC migration success stories page (#1985) (#3162) Fix Bencher reporting permanently broken on pushes to main (#3148) docs: add example migrations guide (#3126) docs: remove defunct guavapass.com reference (#3199) chore: remove redundant --rsc-pro install generator flag (#3105) ci: warn (don't fail) on Bencher main regression (#3168) test: enable RSpec --profile to surface slowest package tests (#3176) fix(node-renderer): expose performance in VM context when supportModules (#3158) docs: remove stale immediate_hydration references (#3139) (#3159) docs: restore absolute URL for node-renderer testing example (#3179) Bump Rspack dependencies to v2 (^2.0.0-0) (#3084) chore: remove obsolete webpack <5.106.0 pin (#3175) Move Node Renderer entry point to renderer/ directory (#3165) docs: address RSC pitfalls review follow-ups (#3155) (#3156) # Conflicts: # CHANGELOG.md
1 participant
Summary
Establishes
renderer/node-renderer.jsas the canonical location for the Pro Node Renderer entry point. Previously the path was inconsistent across docs (node-renderer.js,client/node-renderer.js, orreact-on-rails-pro-node-renderer.js).Using a dedicated top-level
renderer/directory also makes it trivial to exclude from production Docker builds that strip JS sources after bundling — the Node Renderer process still needs its entry file at runtime.Changes
pro_setup.rb,base_generator.rb,demo_page_config.rb,USAGE, initializer template) now creates the entry atrenderer/node-renderer.jstemplates/pro/base/renderer/node-renderer.jsspec/dummy— renderer file,Procfile.dev,Procfile.prod,package.jsonscripts,.controlplane/rails.yml, andbenchmarks/bench-node-renderer.rbupdatedrenderer/node-renderer.jsconsistently; the Docker-cleanup rationale is added to the container deployment guideExisting apps are unaffected — the generator skips files that already exist, so upgrades keep their current
client/node-renderer.js.Test plan
rubocoppasses on all changed Ruby filesprettier --checkpasses on all changed docs + JSrspec ... --example "creates node-renderer" --example "adds node-renderer process" --example "does not overwrite existing", 13 examples)pro_generator_spec.rbpasses (79 examples)lychee) passes on all modified docsFixes #3073
Note
Medium Risk
Moderate risk because it changes the Pro generator’s output paths and Procfile wiring for SSR, which could break dev/prod startup if projects rely on the old
client/node-renderer.jslocation or have customized Procfiles.Overview
Pro installs now standardize the Node Renderer entrypoint at
renderer/node-renderer.js(instead ofclient/node-renderer.js), including updated generator hints, initializer comments, and a new template undertemplates/pro/base/renderer/.The Pro generator adds safer upgrade behavior: it detects an existing legacy
client/node-renderer.js, avoids overwriting it, conditionally skips/avoids duplicatingProcfile.deventries, and emits targeted warnings when a Procfile still points at the legacy path.Docs, dummy app scripts/Procfiles, deployment examples (Docker/K8s/Heroku), benchmarks, and generator specs are updated to reference the new
renderer/path consistently, with added documentation explaining the Docker build rationale.Reviewed by Cursor Bugbot for commit 20633e7. Bugbot is set up for automated code reviews on this repo. Configure here.
Summary by CodeRabbit