search

shakacode / react_on_rails

Integration of React + Webpack + Rails + rails/webpacker including server-side rendering of React, enabling a better developer experience and faster client performance.
https://www.shakacode.com/react-on-rails/docs/
MIT License
5.12k stars 630 forks source link

Bump Rescript in examples due to build-time errors #1612

Closed LuigiPiucco closed 6 months ago

LuigiPiucco commented 7 months ago

The title alone makes this sound like a feature request, but since the reason is compilation errors/build-time breakage, I've chosen to mark as bug report. Skipping to the last section is advised for quickness, the template's required information isn't of much use in this particular case.

Environment

  1. Ruby version: 3.1.4
  2. Rails version: 7.1.3.2
  3. Shakapacker/Webpacker version: locally built from master commit
  4. React on Rails version: locally cloned from master commit

Note: The above shouldn't matter, as it's a very low-level issue described in the section "Details". Below is a piece of information that does matter, or rather, it is an instance of a system where the problem occurs.

  1. OS and version: NixOS master, which uses Glibc 2.39 and (due to specifics of its purpose) cannot run the pre-compiled binaries downloaded by default.

Expected behavior

The command below should prepare JavaScript dependencies successfully.

cd react_on_rails/spec/dummy && yarn

Actual behavior

The command above fails due to being unable to build Rescript. It checks the bundled binaries (which don't work due to the system it's running on) and, upon failing that, tries to build everything (Ninja -> OCaml -> Rescript). It errors out somewhere between the OCaml and Rescript steps.

Small, reproducible repo

Not relevant, it's an interaction between a dependency and the OS of the user. Always happens on affected OSs.

Details

Some of the external examples and, most notably, the spec/dummy example for testing, depend on Rescript version 9, which cannot be built on systems with Glibc >=2.34. This may go unnoticed if the platform supports binaries pre-compiled on other distributions, since these are cached and preferred by their build system when available. However, this can still be considered a bug, prevents potential contributors (myself included) from being able to develop react_on_rails, and may even cause other issues for end-users who happen to be on the affected systems.

The fix is bumping the causing package to at least version 10, possibly 11. I can open a PR to do that, but thought that a discussion here should happen first. I propose upgrading to Rescript 11 everywhere, to advance something that would probably happen later anyway, but since 10 may require a smaller set of changes perhaps the owners would prefer that. There's also the possibility of leaving as-is, but I don't see a reason for that.

justin808 commented 6 months ago

@LuigiPiucco why is this a react_on_rails issue?

LuigiPiucco commented 6 months ago

@LuigiPiucco why is this a react_on_rails issue?

You mean the part about the Glibc incompatibility? That is more of a Rescript issue, yes. The point of this issue thread is that react_on_rails depends on the version of Rescript that's affected, meaning users on systems with newer Glibc can't build react_on_rails. This can be solved by updating the Rescript dependency to 10 or newer.

I guess it may seem like the problem is the OS, but rather, it is a bug in Rescript (which has been solved in newer versions). It only happens in some distributions because those are the ones where pre-built binaries are generally discouraged, requiring the user to built it themselves; and they use the newer versions of Glibc that Rescript doesn't build on.

Also, that is just one reason to update Rescript. Even without this incompatibility, keeping dependencies up to date is generally a good thing.