irb install was broken on JRuby 10+ for 6 weeks due to broken rdoc/rbs

Right now, an off-the-shelf irb install is entirely broken on jruby 10+, due to https://github.com/ruby/rdoc/issues/1746 and (arguably) the lack of constraints on irb’s dependencies. Yes, perhaps it will install again soon when/if a WASM jruby variant of rdoc/rbs is released, but that seems partly besides the point of whether irb should break like this in ways that pushes effort to users or other library maintainers.

Upstream

In lieu of implementing #1211 or some variant, my observation is that the dependency tree for irb (which is still on 1.x theoretically, yet is seeing a surprising amount of dependency churn) is getting increasingly complex and “chunky” over time, especially in ways that affect jruby, or any application that needs to keep its CRuby extensions under control (for which there are a number of reasons to do so, including build time, use of uncommon architectures, lack of precompiled extensions for a given CRuby version and architecture, security concerns etc). Earlier it was issues with psych or erb and their Java extensions (also via rdoc) causing compatibility issues with various jruby versions - now it’s rbs (also via rdoc).

Downstresm

While it is not irb’s “fault”, irb is also now an unconstrained runtime dependency of railties, meaning every rails installation is now getting it (in production environments despite it being an “interactive” library, no less) and rdoc…plus rdoc’s entire dependency tree which now includes rbs… which includes erb, tsort and… you get the idea. (For reference rdoc was zero dependencies at 6.3.0 in 2021)

Bundler challenges

This increasingly forces users to keep digging into their transitive trees to debug problems disconnected from what they are actually using (which might be rails or something else further up the stack). Given bundler’s inability to express optional dependencies or transitive constraints (I think?) this makes lives of library maintainers even tougher when testing across versions and implementations, and trying to keep compatible sets of versions in ways bundler should be able to express for them, or which libraries should possibly be more conservative with.

Next steps

I understand jruby might not be a priority, and that this may be ignored or closed as “won’t fix” - however I also think some more consideration could go into how heavy the dependency tree is and what risk and version interoperability problems it brings. Mainly rdoc.

In the short term, to directly resolve this issue, with such a dependency tree, it doesn’t seem good practice to me to have an unconstrained rdoc dependency that isn’t specifically validated with irb across impls important to the ecosystem. Medium term, I’d ask to consider whether irb is appropriately modularised in ways that are sufficiently easy to work with via bundler.

Start by reproducing an off-the-shelf irb install on JRuby 10+ and inspect the dependency tree involving rdoc and rbs. Compare the current unconstrained rdoc dependency with the compatibility requirements across Ruby implementations; done means the installation works on JRuby 10+ and the dependency approach is validated.