shakacode/react_on_rails v17.2.0.rc.1

on GitHub

Fixed

• [Pro] Streamed useId hydration: Client components now hydrate with the server's useId prefix even when
  they are not wrapped by the default RSC provider. This prevents hydration mismatches and keeps
  generated IDs consistent with accessible references. Fixes #5146.
  #5148 by justin808.

• [Pro] Node Renderer no longer drops multipart files that follow a large file over HTTP/1.1: With
  fastifyServerOptions: { http2: false }, file parts uploaded after a large file part were silently discarded
  while the request still returned 200. With RSC enabled, a large assets_to_copy file such as
  loadable-stats.json caused the RSC manifests behind it to go missing, so the first RSC render failed with
  ENOENT ... react-client-manifest.json. The renderer now keeps every file part, and requests over the
  aggregate upload limit still return 413. HTTP/2 (the default transport) was not affected. Fixes
  #5144.
  #5147 by justin808.

• Published JavaScript no longer ships dangling sourceMappingURL pointers: Every published lib/**/*.js file
  in react-on-rails and react-on-rails-pro ended with a //# sourceMappingURL=<name>.js.map comment, but the
  packages never published the .map files, so each pointer referenced a missing file. Besides devtools warnings,
  the dangling pointers crashed RSC bundle builds (SyntaxError: ... is not valid JSON from
  react-on-rails-rsc/WebpackLoader) whenever server-component code imported one of the Pro package's own
  'use client' components such as react-on-rails-pro/RSCRoute. The packages' tsc builds no longer emit
  JavaScript sourcemaps, removing the pointer comments without changing the emitted JavaScript. (TypeScript
  declarationMap pointers in published .d.ts files are unaffected — cosmetic, tracked as a follow-up.) Part of
  #5079.
  #5099 by
  AbanoubGhadban.

• [Pro] RSC client-reference resolution now registers the Pro package's own 'use client' components:
  Client-reference discovery only scans app source directories (node_modules is excluded), so the 'use client'
  components the react-on-rails-pro npm package itself ships — react-on-rails-pro/RSCRoute,
  react-on-rails-pro/RSCProvider, and react-on-rails-pro/registerDefaultRSCProvider/client — could never appear
  in react-client-manifest.json. A server component rendering one of them (for example a nested <RSCRoute> used
  for section-level refetching) then failed the render-time manifest lookup even when the RSC bundle compiled. The
  client-reference resolver emitted by the react_on_rails:rsc generator now appends these components as explicit
  clientReferences entries (via require.resolve) to every resolution branch, on both the client and server
  manifest plugins. Action required for existing RSC apps: a resolver emitted by a previous generator version is
  never rewritten — re-running rails g react_on_rails:rsc warns and leaves it unchanged. Add the require.resolve
  entries for the three components to your clientReferences manually, or remove the generated resolver block and
  re-run the generator (see the
  RSC setup docs). Part of
  #5079.
  #5100 by
  AbanoubGhadban.