Skip to content

Test: add packaged Pro smokes for React 16 and 17 - #4652

Merged
justin808 merged 3 commits into
mainfrom
jg-codex/4644-pro-react-16-17-smokes
Jul 14, 2026
Merged

Test: add packaged Pro smokes for React 16 and 17#4652
justin808 merged 3 commits into
mainfrom
jg-codex/4644-pro-react-16-17-smokes

Conversation

@justin808

@justin808 justin808 commented Jul 14, 2026

Copy link
Copy Markdown
Member

Summary

React on Rails Pro releases now prove that plain, non-RSC server rendering still installs, bundles, and runs with React 16.14 and React 17.0. Each matrix case consumes packed core and Pro tarballs in an isolated project, selects the Pro Node export, confirms react-on-rails-rsc is absent from both the installed dependency tree and webpack module graph, then executes the generated SSR bundle.

The compatibility smoke is part of the standard Pro package test command so future packaging or export regressions fail the normal Pro test lane.

Fixes #4644.

Validation

  • pnpm --filter react-on-rails-pro test — 620 existing tests passed; packed React 16.14.0 and 17.0.2 webpack/SSR smokes passed.
  • pnpm run nps check-typescript — core, Pro, and Node renderer TypeScript checks passed.
  • Syntax, ESLint, Prettier, and script/check-pro-license-headers passed; all 857 in-scope Pro files have current headers.
  • script/ci-changes-detector origin/main selected the expected Pro lint, unit, dummy-app, Node-renderer, and benchmark lanes.

Decision log

  • The matrix installs tarballs rather than resolving workspace packages, because the claim under test is published-package compatibility.
  • React and React DOM are exact-pinned per case so a permissive peer range cannot silently upgrade the runtime being proven.
  • .agents/bin/validate --changed could not complete because its unchanged Pro JavaScript step invokes pnpm run nps test from the package directory, where the root-only nps script is unavailable. The exact package test and workspace TypeScript gates above were run directly and passed.
  • Changelog classification: not user-visible; this adds regression evidence without changing released behavior or support claims.

Merge qualification

  • Release gate: main beta phase with release tracker Release gate: react_on_rails 17.0.0 #3823 in development mode; the standard merge qualification applies.
  • Merge authority: auto_merge_when_gates_pass from the active maintainer batch.
  • Current head: edcdba5527db19e66423f6b20b9312e0065ee105.
  • Exact-head QA: PASS with no findings, including packed Pro-to-core realpath identity for both React versions.
  • Hosted CI: all nine optimized workflows explicitly dispatched for the current head passed, including Pro package tests, Pro integration tests, and lint.
  • Review threads: zero unresolved on the current head; repeated non-blocking suggestions were triaged with recorded rationale.
  • Review-system coverage: three working systems on the current head — Claude review, CodeRabbit's successful current-head check, and a clean app-bundled Codex review.
  • Degraded review coverage: Greptile produced a review only for the initial head and no artifact for the final head. Its earlier finding was fixed and replayed; it is not cited as a current-head gate.
  • Labels: ready-for-hosted-ci because packaged Pro compatibility needs remote installation/build/runtime confirmation.

Confidence note:

  • Validated: full Pro package tests, focused packed React 16/17 matrix, workspace TypeScript, lint/format, Pro RuboCop/RBS, license headers, CI routing, exact-head QA, nine hosted workflows, and two independent current-head code reviews.
  • Evidence: QA, hosted CI, address-review, and Codex review links above; strict merge ledger reports CI READY, zero unresolved threads, no violations or unknown fields.
  • UNKNOWN: the aggregate .agents/bin/validate --changed wrapper remains unavailable because of the unchanged package-local nps lookup defect described above; every intended underlying gate was run directly and passed. Greptile final-head liveness is degraded as recorded above.
  • Residual risk: the smoke intentionally depends on registry installation because published-package consumption is the behavior under test; the hosted workflow supplies the execution bound and pnpm reuses its content-addressable store.

Compound Engineering
GPT-5

@coderabbitai

coderabbitai Bot commented Jul 14, 2026

Copy link
Copy Markdown
Contributor

Review Change Stack

Walkthrough

Adds a packed-package smoke test for React on Rails Pro against React 16.14.0 and 17.0.2. It installs isolated consumers, verifies non-RSC package resolution, bundles the Node entry with webpack, and executes SSR output.

Changes

Packed React compatibility

Layer / File(s) Summary
Smoke-test command and package setup
packages/react-on-rails-pro/package.json, packages/react-on-rails-pro/scripts/packed-react-compatibility-smoke.mjs
Adds a runnable command, React version matrix, package path resolution, deterministic pnpm execution, and packed tarball discovery.
Isolated consumer generation
packages/react-on-rails-pro/scripts/packed-react-compatibility-smoke.mjs
Creates per-version consumer projects with packed React on Rails packages, an SSR entry point, and a Node-target webpack configuration.
Build and runtime validation
packages/react-on-rails-pro/scripts/packed-react-compatibility-smoke.mjs
Checks package isolation and absence of RSC modules, builds and executes the server bundle, validates SSR output, and cleans up temporary files.

Estimated code review effort: 3 (Moderate) | ~20 minutes

Sequence Diagram(s)

sequenceDiagram
  participant pnpm
  participant ConsumerProject
  participant webpack
  participant Node
  pnpm->>ConsumerProject: Install packed packages with React 16 or React 17
  ConsumerProject->>webpack: Build the Node-target server bundle
  webpack-->>ConsumerProject: Return module graph and bundle
  ConsumerProject->>Node: Execute the generated server bundle
  Node-->>ConsumerProject: Return SSR output
Loading
🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check name Status Explanation
Linked Issues check ✅ Passed The PR adds packed-package React 16.14.0/17.0.2 smokes, keeps RSC disabled, bundles the Pro node entry, and runs SSR checks.
Out of Scope Changes check ✅ Passed The changes stay within the compatibility-smoke objective and only add the needed test script and smoke runner.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title clearly reflects the main change: adding packaged Pro smoke tests for React 16 and 17.
✨ Finishing Touches
📝 Generate docstrings
  • Create stacked PR
  • Commit on current branch
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch jg-codex/4644-pro-react-16-17-smokes

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.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@greptile-apps

greptile-apps Bot commented Jul 14, 2026

Copy link
Copy Markdown

Greptile Summary

This PR adds packaged React compatibility smokes for the Pro package. The main changes are:

  • Adds the packed compatibility smoke to the Pro test script.
  • Packs core and Pro tarballs into an isolated temp workspace.
  • Installs React 16.14.0 and 17.0.2 consumers and runs webpack SSR bundles.
  • Checks that the non-RSC path does not pull in react-on-rails-rsc.

Confidence Score: 5/5

This looks safe to merge after a small smoke-test hardening cleanup.

  • No blocking issues found in the changed code.
  • The new network-backed install path can hang without a local timeout when registry access stalls.

packages/react-on-rails-pro/scripts/packed-react-compatibility-smoke.mjs

Important Files Changed

Filename Overview
packages/react-on-rails-pro/package.json Adds the packaged React compatibility smoke to the standard Pro package test command.
packages/react-on-rails-pro/scripts/packed-react-compatibility-smoke.mjs Adds the isolated pack/install/build/runtime smoke for React 16 and 17, with one non-blocking timeout hardening issue.

Reviews (1): Last reviewed commit: "Test packaged Pro compatibility on React..." | Re-trigger Greptile

Comment thread packages/react-on-rails-pro/package.json
@github-actions

github-actions Bot commented Jul 14, 2026

Copy link
Copy Markdown
Contributor

size-limit report 📦

Path Size
react-on-rails/client bundled (gzip) 63.51 KB (0%)
react-on-rails/client bundled (gzip) (time) 63.51 KB (0%)
react-on-rails/client bundled (brotli) 54.46 KB (0%)
react-on-rails/client bundled (brotli) (time) 54.46 KB (0%)
react-on-rails-pro/client bundled (gzip) 64.87 KB (0%)
react-on-rails-pro/client bundled (gzip) (time) 64.87 KB (0%)
react-on-rails-pro/client bundled (brotli) 55.81 KB (0%)
react-on-rails-pro/client bundled (brotli) (time) 55.81 KB (0%)
registerServerComponent/client bundled (gzip) 135.37 KB (0%)
registerServerComponent/client bundled (gzip) (time) 135.37 KB (0%)
registerServerComponent/client bundled (brotli) 81.66 KB (0%)
registerServerComponent/client bundled (brotli) (time) 81.66 KB (0%)
wrapServerComponentRenderer/client bundled (gzip) 127.84 KB (0%)
wrapServerComponentRenderer/client bundled (gzip) (time) 127.84 KB (0%)
wrapServerComponentRenderer/client bundled (brotli) 74.96 KB (0%)
wrapServerComponentRenderer/client bundled (brotli) (time) 74.96 KB (0%)

@claude

claude Bot commented Jul 14, 2026

Copy link
Copy Markdown
Contributor

Review

Overview

This adds test:packed-react-compatibility (packages/react-on-rails-pro/scripts/packed-react-compatibility-smoke.mjs) to the Pro package's default test script. For React 16.14.0 and 17.0.2, it: packs the core and Pro packages into tarballs, installs them into an isolated temp consumer project alongside the pinned React version and webpack, verifies the Pro package's Node export resolves to ReactOnRails.node.js, asserts react-on-rails-rsc is absent from both the dependency tree and the webpack module graph, builds a small entry with webpack, and runs the resulting bundle to confirm SSR actually works.

Strengths

  • Genuinely exercises the published-package surface (tarball install + webpack + runtime), not just source-level unit tests — a good gap to close for a "does the Pro export tree-shake/resolve correctly for non-RSC consumers" claim.
  • Exact-pinning React/React DOM versions per case is a deliberate, well-reasoned choice (documented in the PR description) so a permissive peer range can't mask a runtime mismatch.
  • Isolated temp directories via os.tmpdir() avoid pnpm workspace resolution surprises, and cleanup happens in a finally block.
  • execFileSync is used with array args throughout (no shell interpolation), and CI: 'true' is set to avoid interactive pnpm prompts — no command-injection or hang-on-prompt concerns.
  • License header is present and matches the Pro file convention.

Concerns

  1. CI cost/flakiness from uncached network installs (see inline comment on package.json): wiring this into the default test script means every pnpm --filter react-on-rails-pro test run now does two full, network-bound pnpm installs pulling webpack + two React version pairs from the registry. These temp-directory installs aren't covered by the workspace's pnpm-lock.yaml-keyed store cache, so they're fetched fresh essentially every run — a recurring time cost and a new failure mode (registry hiccup) for what's otherwise a required gate.
  2. Build freshness assumption (see inline comment on the pnpm pack calls): packing relies on lib/ already being up to date, and the Pro package's prepare script only rebuilds when lib/ is absent, not when it's stale. Explicitly running pnpm run build before packing in this script would make the smoke test self-contained and immune to stale local build state.
  3. No timeout on execFileSync calls (minor): network-bound pack/install calls could hang silently until the outer CI job timeout kicks in, rather than failing fast with a clear cause.

Other notes

  • API usage (ReactOnRails.register, serverRenderReactComponent options) matches the current RenderParams/Params types — no signature mismatches spotted.
  • The Node package-resolution assertion (react-on-rails-rsc export ordering: react-servernodedefault) lines up correctly with how require()-based resolution behaves, so that assertion should be reliable.
  • No security issues found — all subprocess calls use array-form args, no untrusted input flows into shell strings or regexes unescaped (reactVersion.replaceAll('.', '\\.') correctly escapes for the RegExp constructor).

@justin808

Copy link
Copy Markdown
Member Author

+ci-status

@github-actions

Copy link
Copy Markdown
Contributor

CI Status

Head SHA: 3db219a728e7
Changed files: 2
Docs-only heuristic (matches ci-changes-detector metadata paths): no
ready-for-hosted-ci label: absent
force-full-hosted-ci label: absent
Current hosted-CI waiver: not present for this SHA

Only the required gate is active unless hosted CI is requested.

@justin808

Copy link
Copy Markdown
Member Author

+ci-run-hosted

@github-actions github-actions Bot added the ready-for-hosted-ci Run optimized hosted GitHub CI for this PR label Jul 14, 2026
@github-actions

Copy link
Copy Markdown
Contributor

Hosted CI Requested

Triggered 9 workflow(s) for 3db219a728e7.
Mode: optimized hosted CI (path-selected by script/ci-changes-detector).
Added ready-for-hosted-ci, so future commits will keep running optimized hosted CI until +ci-stop-hosted is used.

View progress in the Actions tab.

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 3db219a728

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

@justin808

Copy link
Copy Markdown
Member Author

Address-review summary

Scan scope: full review history; no previous address-review cutoff.

Mattered

  • Fixed the stale compiled-output risk in 3b44ce50f359f7439b40a94d452b013b6cb4df78 by rebuilding core and Pro immediately before packing. Both duplicate threads were answered and resolved after the focused and full Pro suites passed.

Optional

  • Declined the duplicate inner-timeout suggestions: the hosted job already bounds execution, and an arbitrary command timeout would add environment-dependent failures without strengthening compatibility evidence.
  • Declined moving the smoke to a non-blocking lane: this evidence is intended to gate Pro package changes, and temporary consumers still reuse pnpm's shared content-addressable store.

Skipped

  • The Codex review summary was status-only boilerplate; its single actionable inline finding was fixed above.

Deferred-work tracking: dropped as not worth tracking; the declined items are non-blocking test-harness policy choices with rationale recorded in their original threads.

Next default scan starts after this comment. Say check all reviews to rescan the full PR.

@justin808

Copy link
Copy Markdown
Member Author

+ci-status

@justin808

Copy link
Copy Markdown
Member Author

+ci-run-hosted

@github-actions

Copy link
Copy Markdown
Contributor

CI Status

Head SHA: 3b44ce50f359
Changed files: 2
Docs-only heuristic (matches ci-changes-detector metadata paths): no
ready-for-hosted-ci label: present
force-full-hosted-ci label: absent
Current hosted-CI waiver: not present for this SHA

Optimized hosted CI is enabled for this PR.

@github-actions

Copy link
Copy Markdown
Contributor

Hosted CI Requested

Triggered 9 workflow(s) for 3b44ce50f359.
Mode: optimized hosted CI (path-selected by script/ci-changes-detector).
Added ready-for-hosted-ci, so future commits will keep running optimized hosted CI until +ci-stop-hosted is used.

View progress in the Actions tab.

@justin808

Copy link
Copy Markdown
Member Author

Independent QA — PASS

Exact head: 3b44ce50f359f7439b40a94d452b013b6cb4df78

  • Fresh core and Pro builds occurred before packing; artifact timestamps changed during the smoke.
  • Isolated tarball consumers passed on React 16.14.0 and 17.0.2.
  • Both webpack production builds executed successfully under Node SSR.
  • react-on-rails-rsc was absent from direct resolution, the installed dependency tree, and the webpack module graph.
  • Full Pro package suite passed: 620 Jest tests plus both packed compatibility smokes.
  • ESLint, Prettier, all workspace TypeScript checks, Pro RuboCop (241 files), Pro RBS, syntax, diff checks, the Pro license self-test, and all 857 in-scope headers passed.
  • Final-head routing selected the expected Pro lint, package, integration, Node-renderer, and benchmark-related coverage.

Findings: none. Confidence: high.

Known limitation: .agents/bin/validate --changed remains UNKNOWN because its unchanged Pro JavaScript step invokes the root-only NPS command from the package directory. Every direct intended gate above passed. Hosted Pro jobs were running at QA completion and remain a merge gate.

Environment: macOS arm64, Node 22.12.0, pnpm 10.33.4.

@claude

claude Bot commented Jul 14, 2026

Copy link
Copy Markdown
Contributor

Review: Test: add packaged Pro smokes for React 16 and 17

Overview

Adds packages/react-on-rails-pro/scripts/packed-react-compatibility-smoke.mjs, wired into the Pro package's test script as test:packed-react-compatibility. For React 16.14.0 and 17.0.2, it: builds and pnpm packs the core and Pro packages, installs the tarballs into an isolated temp consumer project alongside a pinned React/React-DOM, verifies Node resolution selects the Pro node export (ReactOnRails.node.js) and that react-on-rails-rsc is absent from both the dependency tree and the webpack module graph, then bundles and executes a small SSR entrypoint to confirm the packed artifacts actually render. This is a solid, well-targeted regression test for issue #4644 (published-package compatibility, not just workspace-resolved compatibility).

Strengths

  • Tests against packed tarballs rather than workspace-linked packages, which is the right approach for validating what actually ships to consumers.
  • Exact-pins React/React-DOM per case so the peer range can't silently mask a runtime upgrade.
  • Verifies compatibility at three independent layers (Node require.resolve, pnpm list dependency tree, webpack module graph) instead of relying on just one signal that react-on-rails-rsc isn't pulled in.
  • Uses --ignore-scripts on the consumer install, which is a good default for installing freshly-packed local tarballs.
  • Proper try/finally cleanup of the temp sandbox even on assertion failure.
  • License header matches the project's Pro-file convention.

Issues / suggestions (posted inline)

  1. Side effect on the real package lib/ output (runPnpm(['run', 'build'], corePackageDirectory) / proPackageDirectory): both packages' build script does rm -rf ./lib && tsc, so running this smoke rebuilds the actual packages/react-on-rails/lib and packages/react-on-rails-pro/lib directories in place rather than in the temp sandbox. This is a non-hermetic side effect of pnpm test that could race with anything else reading those directories concurrently, and is a bit surprising for a "test" script to do.
  2. New hard network dependency + hardcoded webpack: '5.104.1' pin: this test now requires npm registry access to install two React versions and webpack on every Pro test run. A registry hiccup will fail this smoke (and therefore the whole test script) for reasons unrelated to the code under test. The webpack version is also a second, independent hardcoded pin that can drift from whatever the workspace actually uses.
  3. No timeout on execFileSync: every pnpm install/pnpm pack/pnpm run build call goes through the runPnpm helper with no timeout, so a hung network call blocks indefinitely instead of failing fast (only the outer CI job timeout would eventually catch it).

None of these are correctness bugs in the assertions themselves — the verification logic (Node export resolution, dependency-tree/webpack-graph absence checks, SSR runtime output matching) looks correct and I didn't find false-positive/false-negative risks in it. The concerns above are about CI reliability/hermeticity and are worth considering before merge, but aren't blocking if the team is comfortable with the current tradeoffs (e.g., CI already has reliable registry access).

Security

No concerns — this only installs public npm packages and locally-built tarballs in an isolated temp directory, with --ignore-scripts on the consumer install, and cleans up after itself.

@justin808

Copy link
Copy Markdown
Member Author

Address-review summary

Scan scope: activity after the previous address-review summary at 2026-07-14T02:33:42Z.

Mattered

  • None. No current-head correctness, security, or compatibility defect was identified.

Optional

  • Declined moving fresh builds into a separate output tree: rebuilding ignored package output is necessary to prove the tarballs reflect the current checkout, and the package test is serial in an isolated CI worktree.
  • Declined separating registry-backed installs from the gating suite: packed-consumer installation is the compatibility contract and still uses pnpm's shared store.
  • Retained webpack 5.104.1 as an intentional fixed control dimension for the legacy React matrix instead of coupling it to incidental workspace resolution.
  • Declined an inner command timeout because the hosted job already bounds execution and an arbitrary per-command limit would add environment-dependent failures.

Skipped

  • None.

Deferred-work tracking: dropped as not worth tracking; each non-blocking design decision is recorded in its original thread.

Next default scan starts after this comment. Say check all reviews to rescan the full PR.

@claude

claude Bot commented Jul 14, 2026

Copy link
Copy Markdown
Contributor

Review: Test: add packaged Pro smokes for React 16 and 17 (#4652)

Overview
Adds scripts/packed-react-compatibility-smoke.mjs, wired into the Pro package's test script. For React 16.14.0 and 17.0.2 it builds and pnpm packs the core and Pro packages, installs them (with pinned React/React-DOM/webpack) into an isolated temp-dir consumer project, asserts module resolution stays inside that isolated node_modules and that react-on-rails-rsc is absent from both the dependency tree and the webpack module graph, then runs a production webpack build and executes the bundled SSR output. Good use of execFileSync with argument arrays throughout (no shell interpolation / injection risk), try/finally cleanup of the temp dir, and correct Pro license headers.

Findings

  1. Perf/CI risk - network-dependent smoke wired into the default test script (package.json line 11, scripts/packed-react-compatibility-smoke.mjs lines 204-216). Every pnpm --filter react-on-rails-pro test (local dev and the package-js-tests.yml CI lane, on both Node 20 and 22) now performs two full pnpm installs against the real npm registry plus two production webpack builds, in addition to rebuilding core and Pro (runPnpm(['run', 'build'], ...)) even though the CI workflow already runs pnpm build for both packages one step earlier (root build script builds react-on-rails and react-on-rails-pro). That is redundant compilation on every run, and a hard new network dependency for what was previously an offline-capable unit-test suite - it will fail or hang in network-restricted/offline environments. Worth considering a separate opt-in script/CI job rather than folding it into the default test chain that runs on every PR touching JS.

  2. Reliability - no timeout on the network install step (scripts/packed-react-compatibility-smoke.mjs line 216, runPnpm at lines 31-37). execFileSync calls have no timeout option, and the CI job that runs this (package-js-tests.yml build job) has no timeout-minutes set, so a stalled registry fetch could hang for the GitHub Actions default of 6 hours instead of failing fast. Suggest adding an explicit timeout (and maybe fetch-retry/registry-timeout flags) to the pnpm install call in particular.

  3. Minor - hardcoded webpack version (scripts/packed-react-compatibility-smoke.mjs line 63). webpack: '5.104.1' is not sourced from any existing devDependency pin elsewhere in the repo, so it will silently drift out of date and need manual bumps. Consider reading it from the root/workspace webpack version instead.

  4. Minor/edge case - isolation assumption on os.tmpdir(). The isolated-dependency-tree assertions (module resolution startsWith(installedRoot), absence of react-on-rails-rsc in the dep tree/module graph) implicitly rely on os.tmpdir() resolving outside the monorepo. If TMPDIR were ever configured to a workspace-relative path in some CI environment, Node's upward node_modules resolution could pick up the monorepo's hoisted packages and mask a real regression. A cheap assert(!temporaryRoot.startsWith(repoRoot)) up front would make that invariant explicit.

Nothing here is a correctness blocker - the script's assertions themselves (module resolution, RSC absence, webpack graph, SSR runtime output) are well constructed. The main concern is scope: baking a two-version network install plus webpack build into the default test command for the package.

Comment thread packages/react-on-rails-pro/package.json
@justin808

Copy link
Copy Markdown
Member Author

QA evidence — exact final head

Head: edcdba5527db19e66423f6b20b9312e0065ee105
Verdict: PASS (high confidence, no findings)

Fresh independent QA replayed the packaged compatibility path on the exact PR head:

  • pnpm --filter react-on-rails-pro run test:packed-react-compatibility passed for React 16.14.0 and 17.0.2.
  • Each case rebuilt core and Pro before packing, installed the tarballs in an isolated consumer, built with webpack in production mode, and completed Node SSR.
  • react-on-rails-rsc was absent from direct resolution, the installed dependency tree, and the webpack graph.
  • In both cases, createRequire(proEntry).resolve('react-on-rails') resolved to the same realpath as the top-level packed core tarball, proving Pro did not silently load a registry copy.
  • The full Pro package test suite passed: 620 Jest tests, suite-selection checks, and both packed smokes.
  • Repository lint and formatting, TypeScript checks across core/Pro/Pro Node renderer, Pro RuboCop, Pro RBS validation, all 857 Pro license-header checks, syntax/diff checks, and CI routing detection passed.
  • The QA worktree remained clean and detached at the exact head; strict PR security preflight passed before GitHub state was read.

Hosted checks and current-head review/audit gates remain separate merge requirements.

@justin808

Copy link
Copy Markdown
Member Author

+ci-status

@github-actions

Copy link
Copy Markdown
Contributor

CI Status

Head SHA: edcdba5527db
Changed files: 2
Docs-only heuristic (matches ci-changes-detector metadata paths): no
ready-for-hosted-ci label: present
force-full-hosted-ci label: absent
Current hosted-CI waiver: not present for this SHA

Optimized hosted CI is enabled for this PR.

@justin808

Copy link
Copy Markdown
Member Author

+ci-run-hosted

@github-actions

Copy link
Copy Markdown
Contributor

Hosted CI Requested

Triggered 9 workflow(s) for edcdba5527db.
Mode: optimized hosted CI (path-selected by script/ci-changes-detector).
Added ready-for-hosted-ci, so future commits will keep running optimized hosted CI until +ci-stop-hosted is used.

View progress in the Actions tab.

@justin808

Copy link
Copy Markdown
Member Author

Address-review summary

Scan scope: review activity after 2026-07-14T02:39:44Z on head edcdba5527db19e66423f6b20b9312e0065ee105.

Mattered

  • None. The current-head review introduced no new correctness, regression, security, or coverage finding.

Optional

  • Default-test/network cost: autonomously declined at the final-candidate debounce point. The required packed evidence intentionally gates Pro package changes and uses pnpm's shared store plus the hosted workflow's execution bound.
  • Inner command timeout: autonomously declined. The hosted workflow already bounds execution; an arbitrary inner timeout would add environment-dependent failures without strengthening the compatibility claim.
  • Fixed webpack version: autonomously declined. Webpack 5.104.1 is a deliberate fixed matrix control, so deriving it from incidental workspace resolution would reduce reproducibility.

Skipped

  • All three items duplicate earlier resolved review threads and added no new evidence. Each received the required [auto-deferred] rationale before resolution.

All review threads are resolved. Future default scans should start after this comment unless check all reviews is requested.

@justin808

Copy link
Copy Markdown
Member Author

Current-head Codex review

Verdict: clean — no accepted/actionable findings.

  • Source: app-bundled codex review (codex-cli 0.144.2, gpt-5.6-sol, xhigh)
  • Target: committed PR branch diff against origin/main
  • Base: main at b7e55795237a688b6b3ab196a1bb7986ddb4c02d
  • Head: edcdba5527db19e66423f6b20b9312e0065ee105
  • Invocation: codex review --base origin/main
  • Included paths: packages/react-on-rails-pro/package.json and packages/react-on-rails-pro/scripts/packed-react-compatibility-smoke.mjs
  • Lenses: correctness, security, React 16/17 compatibility, packaged-artifact identity, Pro-to-core resolution, RSC absence, webpack/SSR runtime, CI/test integration, and reliability
  • Proof replayed by the reviewer: pnpm --filter react-on-rails-pro run test:packed-react-compatibility passed for React 16.14.0 and 17.0.2.
  • Excluded/not applicable: runtime production changes, migrations, public API changes, and performance benchmarking.
  • Limitation: this is a branch-diff review plus focused runtime proof; the separate exact-head QA and hosted CI records remain the broader validation evidence.

Review result: the smoke builds and packs current artifacts, installs isolated consumers, proves dependency/RSC isolation and Pro-to-core package identity, and executes bundled SSR without an identified correctness regression.

@justin808

Copy link
Copy Markdown
Member Author

Independent pre-merge audit

AUDIT_PREMERGE_VERDICT: PASS

Exact head: edcdba5527db19e66423f6b20b9312e0065ee105

  • Blocking findings: none.
  • Discuss items: none.
  • Follow-ups: none.
  • CI: add React 16/17 compatibility smokes for React on Rails Pro #4644 acceptance coverage: complete. The audit independently confirmed exact React/ReactDOM 16.14.0 and 17.0.2 consumers, freshly built packed core/Pro tarballs, Pro-to-core realpath identity, the Pro Node export, absence of react-on-rails-rsc from resolution/tree/webpack graph, production webpack builds, and executed SSR.
  • Exact-head QA: PASS.
  • Hosted CI: all explicitly dispatched final-head workflows complete and green, including Pro package, Pro integration, and lint.
  • Reviews: zero unresolved threads; Claude, CodeRabbit, and app-bundled Codex provide three working current-head systems. Greptile final-head degradation is recorded in the PR body and is not cited as a gate.
  • Fresh strict merge ledger at 2026-07-14T03:15:42Z: complete_allowed: true, CI READY, no violations, and no unknown fields.
  • Release gate: main beta with tracker Release gate: react_on_rails 17.0.0 #3823 in development mode; standard qualification is satisfied.
  • Audit-local replay: exact detached SHA/clean tree, full diff inspection, Node syntax, package wiring, diff checks, all 857 Pro headers, and CI routing passed.

The documented registry dependence and unchanged aggregate-validator wrapper defect are non-blocking because the intended underlying checks, exact-head QA, and hosted workflows passed. The coordinator may merge under the batch's auto_merge_when_gates_pass authority.

@justin808
justin808 added this pull request to the merge queue Jul 14, 2026
Merged via the queue into main with commit c74239f Jul 14, 2026
83 checks passed
@justin808
justin808 deleted the jg-codex/4644-pro-react-16-17-smokes branch July 14, 2026 03:21
@justin808

Copy link
Copy Markdown
Member Author

Final replayable QA evidence

This record makes the already-completed exact-head QA and priority-finding disposition mechanically replayable for the completed-batch audit.

justin808 added a commit that referenced this pull request Jul 15, 2026
Backports #4652 to the 17.0.0 release train with release-specific package metadata preserved.
justin808 added a commit that referenced this pull request Jul 16, 2026
…t-policy

* origin/main: (33 commits)
  Release: add auditable accelerated RC async gates (#4669)
  Release: handle optional required-check metadata (#4685)
  Release: forward-port post-pull prerelease guard (#4680)
  Forward-port stable RSC 19.2.1 to main (#4672)
  Forward-port Pro license metadata to main (#4668)
  Docs: clarify local benchmark workflow (#4665)
  Fix Hacker News demo-fleet smoke path (#4664)
  Release: reuse verified ShakaPerf pre-run evidence (#4662)
  Release: require strict HEAD evidence before retry guidance (#4661)
  Fix: support React 18 non-RSC streaming (#4658)
  Docs: compare Next.js with Rails async-props streaming (#4651)
  Docs: add reusable demo fleet RC update prompt (#4649)
  CI: run Pro compatibility smokes in hosted tests (#4656)
  Fix ambiguous prerelease retries (#4654)
  Test: add packaged Pro smokes for React 16 and 17 (#4652)
  docs: clarify release version ownership and RSC promotion (#4650)
  [Pro] Keep react-on-rails-rsc out of non-RSC entry graphs (fixes React 18 builds on rc.9) (#4641)
  ci: make benchmark proof gates replayable (#4626)
  Test: keep React 19 coverage out of the React 18 lane (#4635)
  Redact prerender secrets and harden service checks (#4624)
  ...

# Conflicts:
#	internal/contributor-info/release-train-runbook.md
justin808 added a commit that referenced this pull request Jul 16, 2026
…taller

* origin/main: (33 commits)
  Release: add auditable accelerated RC async gates (#4669)
  Release: handle optional required-check metadata (#4685)
  Release: forward-port post-pull prerelease guard (#4680)
  Forward-port stable RSC 19.2.1 to main (#4672)
  Forward-port Pro license metadata to main (#4668)
  Docs: clarify local benchmark workflow (#4665)
  Fix Hacker News demo-fleet smoke path (#4664)
  Release: reuse verified ShakaPerf pre-run evidence (#4662)
  Release: require strict HEAD evidence before retry guidance (#4661)
  Fix: support React 18 non-RSC streaming (#4658)
  Docs: compare Next.js with Rails async-props streaming (#4651)
  Docs: add reusable demo fleet RC update prompt (#4649)
  CI: run Pro compatibility smokes in hosted tests (#4656)
  Fix ambiguous prerelease retries (#4654)
  Test: add packaged Pro smokes for React 16 and 17 (#4652)
  docs: clarify release version ownership and RSC promotion (#4650)
  [Pro] Keep react-on-rails-rsc out of non-RSC entry graphs (fixes React 18 builds on rc.9) (#4641)
  ci: make benchmark proof gates replayable (#4626)
  Test: keep React 19 coverage out of the React 18 lane (#4635)
  Redact prerender secrets and harden service checks (#4624)
  ...
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

ready-for-hosted-ci Run optimized hosted GitHub CI for this PR

Projects

None yet

Development

Successfully merging this pull request may close these issues.

CI: add React 16/17 compatibility smokes for React on Rails Pro

1 participant