Ruby Next lets a gem use new Ruby syntax and still run on 2.5

Two gems, two jobs

Ruby Next has two halves and they are distributed differently. The core part provides polyfills for Ruby core class APIs, delivered through Refinements by default or through core extensions if you prefer or if you are in a refinement-less environment. The language part is responsible for transpiling edge Ruby syntax into older versions, and it can be done programmatically, through a CLI, or at runtime. The distribution split is deliberate and the README explains it. There is a separate gem for distribution, `ruby-next-core`, which gives a zero-dependency, polyfills-only version, and the full `ruby-next` gem is the one that includes the language rewriting. A gem that only wants the API backports can depend on the smaller artefact and not drag the transpiler into its dependency tree.

Refinements by default, core extensions on purpose

How the polyfills are activated is a decision, not a detail. The default strategy is Refinements, and the alternative is core extensions, which are described as optionally available or for refinement-less environments. The README gives a rule of thumb for choosing. Use refinements for library development, to avoid conflicts with other people's code, while using core extensions could be considered for application development, where you do not need to think about the surrounding code. The activation itself is one line, `using RubyNext`, and the README notes it only refines core classes if necessary, so the line has no effect in edge Ruby. There is also a deliberate wrinkle: even if the runtime already contains a monkey patch with the backported functionality, the method is considered dirty and the refinement is activated for it anyway, so behaviour is predictable rather than depending on load order.

What the transpiler actually rewrites

The language half takes syntax that the target interpreter does not understand and turns it into something it does. The quick start in the README makes the point with a pattern matching example, run through the `ruby -ruby-next` flag:

# Install Ruby Next globally
$ gem install ruby-next

The example defines a proc that matches a `hello:` key in a case expression and prints an emoji depending on whether the value looks human, and the result is the Martian emoji, which is the point: the pattern matching worked on a runtime that does not support it natively. The repository also tracks what is supported in a file called `SUPPORTED_FEATURES.md`, and the project describes itself as a way to help the community assess new, experimental MRI features by making it easier to play with them, which is why it implements the `master` features as fast as possible. The Makefile has a target that transpiles the library's own source to a minimum version of 2.0, and another that does the same for the language specs, so the project eats its own cooking.

Three ways to run the transpiler

The README's table of contents lists a modes section, a CLI section, integrating into a gem development section, a runtime usage section, the `ruby -ruby-next` entry, and a logging and debugging section, and those are the three practical shapes. The CLI is `bin/ruby-next` with a `nextify` subcommand, as the Makefile shows:

bundle exec bin/ruby-next nextify --transpile-mode=rewrite --min-version=2.0 lib/ -V

The flag names carry the two decisions that matter. The transpile mode decides what rewriting strategy is used, and the minimum version tells the tool which target to rewrite down to. Integration into a gem development means running that as part of your build so the published gem contains code the oldest supported Ruby can parse, and runtime usage means the transformation happens as the code is loaded. The logging and debugging section is the one to look at when a rewrite does not do what you expected, since a silent mis-rewrite in a gem is much harder to diagnose than an error in a build script.

Supported versions, and the caveat for end of life Rubies

The support statement is specific. Ruby Next currently supports Ruby versions 2.3 and later, including JRuby 9.2.8 and later and TruffleRuby 20.1 and later, with some limitations. Support for older versions below 2.5 differs slightly, and the README has a separate section on using it with end of life Rubies. Versions between 2.0 and 2.3 may work but are no longer tested against. That distinction between may work and is tested is the one to hold on to, since the whole value of the project is that the output is predictable on a runtime you do not control. The README also asks readers to open an issue or join the discussion if they need support for older Ruby versions, which is how the floor moves over time.

Who uses it, and the project around the gem

The README lists real users, and they span several kinds of project. Ruby gems in the list include action_policy, anyway_config and graphql-fragment_cache, Rails applications include the anycable_rails_demo, and mruby projects include ACLI. The gem is built by Evil Martians, described as an American design and engineering consultancy for developer tools, AI and cybersecurity startups, and there is a Fukuoka Ruby award badge in the header, along with a linked post explaining the motivation, Make all Rubies quack alike. A companion library extracted from Ruby Next provides code loading hooks under the name require-hooks, which is the piece you would reach for if your problem is controlling when files are loaded rather than what syntax they contain.

Licence, release line and the shape of the repository

The licence is MIT, in a `LICENSE.txt` at the root, which for a tool that rewrites other people's code is the permissive choice that lets it sit inside any gem. The release history shows a project that moved from 1.0.0 in December 2023 to 1.1.0 in January 2025 and 1.2.0 on 2026-01-13, and the last push to the repository was on 2026-07-25, so the work is current. The repository itself is two gemspecs, `ruby-next-core.gemspec` and `ruby-next.gemspec`, over a shared `lib/` directory, with `bin/` holding the executables, `spec/` the specs driven by the `default.mspec` file, `benchmarks/`, `gemfiles/` for testing against multiple Ruby versions, and a `Makefile` whose default target is `lint test`. The `lint` target runs RuboCop with `RUBY_NEXT_PROPOSED=true`, which is how the codebase is checked against the proposed syntax the transpiler itself supports.

Editorial conclusion

Adopt Ruby Next when you maintain a gem or an application that has to run on an older Ruby or a non-MRI implementation, since it rewrites new syntax down to something the older interpreter understands and backports the core class APIs. Do not adopt it as a way to avoid upgrading, since a transpiler cannot express every new feature and the README points to a section on limitations and on using it with end of life Rubies. Verify first which interpreter versions your users actually run, because the supported range is Ruby 2.3 and later with JRuby 9.2.8 and TruffleRuby 20.1, and check the transpiler modes before you commit to a pipeline, since the rewriting behaviour differs by mode and by target version.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. ruby-next/ruby-next on GitHub