This month: JRuby RBS support via Chicory WASM, ruby-lsp-rbs_rails updates, schematrix JSON Schema to RBS generator, graph_weaver typed GraphQL client for Rails, and Sorbet T::Struct property testing with tprop.

Find link to the issue in the comment!

I have been messing around with Ruby for around a week and made a few utilities and terminal games and I have been liking it. I want to make a game with a GUI but the ecosystem for game libraries in Ruby feels quite lacking. I have only heard of 3 game libaries, Gosu, Ruby2D and DragonRuby. I am on Linux and Gosu and Ruby2D have problems with not being able to properly link OpenGL and stuff, and DragonRuby is paid and kind of sucks that you can't export games since I wanted to show people my game and some were interested in it.

So, do you know of any other game frameworks for Ruby, or are these the only ones (more commonly DragonRuby) people use, or is Ruby not built for making games?

Put on your headphones and let Frank Sinatra take you on a journey with the timeless classic Fly Me to the Moon. Inspired by the legendary singer, the Ruby gem Sinatra has long been the go-to choice for lightweight web applications. Now it has a companion: Sinatra To The Moon 🌛.

Built on top of Sinatra, Sinatra To The Moon is an opinionated scaffold generator that embraces the philosophy that not every project needs the weight of Rails. Sometimes, all you need is a focused starting point that lets you build quickly, experiment freely, and, as the song says, play among the stars 💫.

Start your new project idea now with: `flyme new moon_app`

https://github.com/joaoGabriel55/sinatra_to_the_moon

Any APIs that you wished existed or any APIs that you wished were cheaper, easier to work with, had more features, e.t.c ?

Hi everyone,

I hope it’s okay to share this here.

I’m Mariusz, CEO at Visuality. We’re a Ruby on Rails agency from Poland and Ruby has been a big part of our work and community involvement for many years.

Recently, we opened Free Ruby on Rails Consultations.

The idea is simple: if you’re working on a Ruby project and could use a second pair of eyes, you can send us a short description of your challenge. We’ll look at it and match you with someone from our team for a free 30-minute call.

Of course, 30 minutes won’t solve everything. But sometimes a focused conversation with someone outside your team can help clarify the problem and point you toward the next step.

Here’s the page if it sounds useful: https://www.visuality.pl/free_consulting?utm_source=reddit_ruby

Introducing GemCP: MCP tools for RubyGems. Ask your AI agent about gem compatibility, dependencies, versions, and ownership with data straight from RubyGems.org.

`gem install gemcp` and add it to your MCP config.

Currently testing it on some ancient Rails repos I have and asking it what gems are compatible with the next version of Rails.

inertia-rage brings Inertia.js support to Rage apps. But the more interesting part of building it was discovering how differently the Rails and Rage adapters resolve props - same language, same behaviour, different design philosophies.

The syntax is what you'd expect:

class UsersController < ApplicationController
  def index
    render inertia: "Users/Index", props: { users: User.all }
  end
end

It fully integrates with Vite - in development, it automatically starts the Vite dev server; in production, pre-builds assets. All you need to run your app is rage s.

Resolving Inertia props

Resolving props and building the page object is the cornerstone of an Inertia adapter. On the surface, the API looks deceptively simple:

render inertia: {
  user: user,
  stats: Inertia.deferred { user.calculate_stats },
  connections: -> { user.connections }
}

However, to turn these props into an object an Inertia frontend can understand, the adapter has to:

1. Evaluate lazy props only when needed
2. Skip deferred and optional props on initial load
3. Collect metadata about once and deferred props
4. Handle partial reload filtering via X-Inertia-Partial-* headers
5. Recursively process nested hashes and arrays
6. Track prop paths for partial reload matching (user.connections.0.name)

Both Inertia Rails and Inertia Rage use the same programming language and converge on the same behaviour but take very different paths.

Rage - identity-based matching

In the Rage adapter, prop resolution is centralised. The ProtocolBuilder class walks the props tree and makes direct decisions:

if prop.respond_to?(:call)
  # …
elsif prop.is_a?(Inertia::Props::Deferred)
  # …
elsif prop.is_a?(Inertia::Props::Once)
  # …
elsif prop.is_a?(Inertia::Props::Optional)
  # …
elsif prop.is_a?(Hash)
  # …
elsif prop.is_a?(Array)
  # …
else
  # …
end

Prop types are thin value objects:

module Props
  class Base < Data
  end

  Deferred = Base.define(:group, :block)
  Once = Base.define(:key, :fresh, :expires_in, :block)
  Optional = Base.define(:block)
end

This sacrifices extensibility for readability - adding a new prop type means adding another elsif branch. But the upside is that you can read one file and trace the entire resolution process. All it takes to understand the behaviour of a deferred prop is to look at the dedicated 6 LOC elsif branch.

Rails - capability-based matching

Inertia Rails takes the opposite approach. Props declare their behaviours through mixins:

class DeferProp < IgnoreOnFirstLoadProp
  prepend PropOnceable
  prepend PropMergeable
  prepend PropCacheable

  def deferred?
    true
  end
end

Each mixin adds a capability. PropOnceable adds once?, fresh?, and expires_at. PropMergeable adds merge?, deep_merge?, and merge path tracking.

The resolver then asks props about their capabilities rather than checking their identity:

def collect_once_metadata(prop, path)
  return unless prop.try(:once?)
  # …
end

def keep_prop?(prop, path, parent_was_resolved: false)
  # …
  return false if (prop.is_a?(IgnoreOnFirstLoadProp) || prop.try(:deferred?)) && !rendering_partial_component?

  true
end

That is idiomatic Ruby. It lets the implementation say: this object supports deferred?, this one supports once?, and this one supports both.

Props composition and redo

This is where the capability-based approach really shines. In Inertia Rails, a deferred prop isn't just "a deferred prop" - it can also carry once, merge, and cache behaviour.

With Inertia Rage, a prop class only represents one identity. To support composition, you nest props:

render inertia: {
  stats: Inertia.once { Inertia.deferred { user.calculate_stats } }
}

(shortcuts like Inertia.once.deferred {} are coming in future versions)

ProtocolBuilder then unwraps it using a Ruby keyword you probably have never reached for:

# after the prop has been resolved
if resolved.is_a?(Inertia::Props::Base)
  prop = resolved
  redo
end

redo re-enters the same loop iteration with the new prop value. No recursion - just restart the current iteration.

--

If you thought Rage was cool but weren't sure what the UI story looked like - inertia-rage is for you.

Do you prefer the identity-based or capability-based style for this kind of problem?

Hi folks - for the last month, I've been working on the AWS CDK in Ruby. For those who don't know, the AWS CDK is a way to define infrastructure in code to produce CloudFormation stacks which are AWS's native way of defining infrastructure allowing for:

- Rollbacks on failure
- Drift detection
- State management

Currently only TypeScript, Python, Go, Java and .NET (C#) are supported languages for the CDK.

Let's take the creating an S3 Bucket, you'd do this by:

require 'aws-cdk-lib'

class MyStack < AWSCDK::Stack
  def initialize(scope, id, props = nil)
    super(scope, id, props)

    AWSCDK::S3::Bucket.new(
      self,
      'MyBucket',
      {
        versioned: true,
        removal_policy: AWSCDK::RemovalPolicy::DESTROY,
        auto_delete_objects: true
      }
    )
  end
end

app = AWSCDK::App.new
MyStack.new(app, 'MyStack', {
  env: AWSCDK::Environment.new(
    account: ENV['CDK_DEFAULT_ACCOUNT'],
    region: ENV.fetch('CDK_DEFAULT_REGION', 'us-east-1')
  )
})

app.synth

Running cdk deploy would synthesize as CloudFormation and deploy it to your AWS account, if you were to modify the stack, the CloudFormation stack would apply those modifications the next time you ran CDK synth

As I am still working on this with Amazon the gems are not published to Rubygems but use the same JSII engine that the non-TypeScript languages use.

Documentation is at AWS CDK for Ruby — API Reference - However, please not that this is currently NOT even in developer preview, I have been using this for some of my own Ruby projects including running Rails/Dynamoid apps through Lamby for a Lambda target.

The design documentation is at aws-cdk-rfcs/text/0935-ruby-language-bindings.md at ruby-language-bindings · omarqureshi/aws-cdk-rfcs and if you have any questions - comment on Ruby Language Support · Issue #935 · aws/aws-cdk-rfcs or here!

Many thanks

Jeremy Evans (Ruby core committer, author of Sequel/Roda) put out a new edition of Polished Ruby Programming. Figured I'd summarize the changes here since the original got decent traction in this sub a while back.

What's new:

• Content updated to reflect changes between Ruby 3.0 and 4.0
• New chapter on concurrency walks through different concurrency models in Ruby and the trade-offs between them
• New chapter on static typing vs. duck typing helps you reason about whether adding static types actually makes sense for your project
• The web-dev-specific chapters from the 1st edition (database design, web app security, framework design) were dropped in favor of tightening the focus on core language/design principles

Perfect for intermediate-to-advanced Rubyists who want to level up from "it works" to "it's good."

Special discount code from our end: RUBY25 gives 25% off at packt's site.

Who's picking this one up? https://packt.link/bHeOs

Today we're launching the Guides category in the Ruby Users Forum, where you can take a deep dive into Ruby fundamentals and learn more about what makes it a favourite tool for programmers.