Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Contributing to Rails? Start with the Gems You ...

Contributing to Rails? Start with the Gems You Already Use

Contributing to Ruby on Rails might seem difficult, especially if you’re new to open source. But the first step is ensuring that the gems your application depends on are compatible with new Ruby and Rails versions. Many gems power your Rails app, and improving them is a great way to get comfortable with open-source development.

This session is designed for developers who are interested in open source but don’t know where to begin. We’ll explore why contributing to gems is an ideal first step—it helps ensure compatibility, improves your understanding of Rails, and makes a meaningful impact. You’ll learn how to find issues, interact with maintainers, and submit your first pull request with confidence.

We’ll also discuss best practices for running CI across different Rails and Ruby versions and how to address compatibility issues. By the end of this talk, you’ll have a clear roadmap to start contributing and making an impact in the Rails ecosystem.

Avatar for Yasuo Honda

Yasuo Honda

July 10, 2025
Tweet

More Decks by Yasuo Honda

Other Decks in Technology

Transcript

  1. Contributing To Rails? Start With The Gems You Already Use

    Yasuo Honda RailsConf 2025 - July 10, 2025 1
  2. About Me | Yasuo Honda Rails Committer Maintainer of Active

    Record Oracle enhanced adapter Find me on: GitHub: https://github.com/yahonda Mastodon: https://mastodon.social/@yahonda X: https://x.com/yahonda Bluesky: https://bsky.app/profile/yahonda.bsky.social 2
  3. 3

  4. Why Contributing is Challenging Gem contributions: New features – Need

    domain knowledge and gem architecture Docs – Also need a solid understanding of how the gem works Rails contributions: All the above challenges, plus: Good first issues have intense competition Massive codebase - where do you even begin? 4
  5. My Proposal - Ruby Compatibility and Green CI I propose:

    Focus on two goals for gems you already use 1. Fix Ruby compatibility changes 2. Keep CI green (set up or fix broken CI) The reality: Many people want to contribute but don't know where to begin 5
  6. Why This Approach Works Why Ruby compatibility fixes work: You

    actually use them - Easier to understand problems and test fixes Easy to start - Clear requirements, no guesswork Established patterns - Learn from existing fixes Why CI work is valuable: Some gems have broken or missing CI - Essential infrastructure that needs fixing Proves your fixes work - Maintainers need confidence across Ruby versions Enables future contributions - Good CI helps everyone contribute safely 6
  7. How to Find the Right Gems "But how do I

    find gems I'm using that need help?" Check your app's Gemfile.lock Compare with Rails repository's Gemfile.lock Focus on gems that are NOT in Rails' Gemfile.lock These are your contribution opportunities Why this works: Rails core dependencies are already Ruby 3.4+ compatible Your third-party gems likely need Ruby compatibility updates By fixing these gems, you can confidently upgrade to new Ruby versions 7
  8. Ruby 3.4 Compatibility Fixes You Can Do Right Now Ruby

    3.4 was released December 25, 2024 Common compatibility changes we'll cover: Chilled Strings URI::DEFAULT_PARSER changes Bundled Gems Warnings Hash#inspect format changes Error message quotes: backticks to single quotes 8
  9. Chilled Strings What warnings appear: String mutation warnings when warnings

    -w is enabled % ruby -we "foo = ''; foo << 'bar'" -e:1: warning: literal string will be frozen in the future (run with --debug-frozen-string-literal for more information) How to fix: Add .dup to strings that need mutation % ruby -we "foo = ''.dup; foo << 'bar'" # no warnings Real examples: https://github.com/rails/rails/pull/51357 https://github.com/nahi/httpclient/pull/462 9
  10. URI::DEFAULT_PARSER Changes What warnings appear: URI::DEFAULT_PARSER Changes from URI::RFC2396_Parser to

    URI::RFC3986_Parser URI::RFC3986_PARSER.make_regexp , URI::RFC3986_PARSER.escape , URI::RFC3986_PARSER.unescape and URI::RFC3986_PARSER.extract are obsoleted % ruby -ruri -we "URI::DEFAULT_PARSER.escape('/:controller(/:action)')" -e:1: warning: URI::RFC3986_PARSER.escape is obsolete. Use URI::RFC2396_PARSER.escape explicitly. 10
  11. URI::DEFAULT_PARSER Changes How to fix: If you want the RFC2396

    parser behavior, use URI::RFC2396_PARSER explicitly. % ruby -ruri -we "URI::RFC2396_PARSER.escape('/:controller(/:action)')" # no warnings Real examples: https://github.com/rails/rails/pull/52779 https://github.com/teamcapybara/capybara/pull/2781 11
  12. Bundled Gems Warnings What warnings appear: ostruct , logger will

    be bundled gem in future Warnings about missing gems that were previously part of standard gems ostruct was loaded from the standard library, but will no longer be part of the default gems starting from Ruby 3.5.0. You can add ostruct to your Gemfile or gemspec to silence this warning. Check https://stdgems.org Bundled gems: The behavior of bundled gems is similar to normal gems, but they get automatically installed when you install Ruby. They can be uninstalled and they are maintained outside of Ruby core. 12
  13. Bundled Gems Warnings How to fix: Add these gems to

    gemspec Use Struct instead of OpenStruct when possible Real examples: https://github.com/rails/sprockets/pull/811 https://github.com/rack/rack/pull/2004 https://github.com/rails/rails/pull/52024 13
  14. Hash#inspect Format Changes What changes appear: % ruby -ve "h

    = {a: 1, b: 2}; puts h.inspect" ruby 3.3.8 (2025-04-09 revision b200bad6cd) [arm64-darwin25] {:a=>1, :b=>2} % ruby -ve "h = {a: 1, b: 2}; puts h.inspect" ruby 3.4.4 (2025-05-14 revision a38531fd3f) +PRISM [arm64-darwin24] {a: 1, b: 2} How to fix: Update test expectations to handle new output formats Real examples: https://github.com/rails/rails/pull/53202 14
  15. Error Message Quotes Changes What changed: Error message quotes were

    changed from backticks ( + ) to single quotes (’+’) The error message now includes the class name ( Integer ) % ruby --disable-error_highlight -ve "1 + '1'" ruby 3.3.8 (2025-04-09 revision b200bad6cd) [arm64-darwin25] -e:1: warning: possibly useless use of + in void context -e:1:in `+': String can't be coerced into Integer (TypeError) from -e:1:in `<main>' % ruby --disable-error_highlight -ve "1 + '1'" ruby 3.4.4 (2025-05-14 revision a38531fd3f) +PRISM [arm64-darwin24] -e:1: warning: possibly useless use of + in void context -e:1:in 'Integer#+': String can't be coerced into Integer (TypeError) from -e:1:in '<main>' 15
  16. Error Message Quotes Changes How to fix: Update test expectations

    to handle new quote formats Real example: https://github.com/rails/rails/pull/51101 16
  17. Why CI Matters for Compatibility When fixing Ruby compatibility changes,

    CI becomes essential: Prove your compatibility fixes work across multiple Ruby versions Green CI enables future development - makes adding new features safer and easier Some gems lack proper CI or have failing/outdated CI 17
  18. Two Types of CI Released Ruby CI (Production Ready): Test

    against already released Ruby versions Must pass for pull requests to be merged Ensures gem works as intended on released Ruby versions Development Ruby CI (Future Preparation): Monitor Ruby under development Early warning system for upcoming changes Helps prepare for future Ruby releases 18
  19. Released Ruby CI - Production Ready Purpose: Ensure your gem

    works across all supported Ruby versions name: test on: push: pull_request: jobs: build: runs-on: ubuntu-latest strategy: matrix: ruby: ["3.4", "3.3", "3.2"] env: RUBYOPT: "-W" 19
  20. Released Ruby CI - Production Ready Test configuration for early

    problem detection: Run tests with RUBYOPT='-W' or add --warnings to .rspec file Important: While you may suppress warnings in production apps, actively enable warnings in tests to catch compatibility issues early This test is mandaroty - must pass for pull requests to be merged. 20
  21. Development Ruby CI - Future Preparation Purpose: Monitor Ruby 3.5

    under development for early warning name: ruby_head on: schedule: - cron: "0 0 * * *" workflow_dispatch: jobs: build: name: "ruby-${{ matrix.ruby }}-yjit-enabled: ${{ matrix.yjit-enabled }}" runs-on: ubuntu-latest strategy: matrix: ruby: ["head", "debug", "asan"] yjit-enabled: [0, 1] env: RUBY_YJIT_ENABLE: ${{ matrix.yjit-enabled }} RUBYOPT: "-W --debug-frozen-string-literal" 21
  22. Development Ruby CI - Future Preparation Ruby versions explained: head:

    Latest development Ruby (unstable, cutting-edge features) debug: Debug build with additional runtime checks asan: AddressSanitizer build for memory error detection (requires ubuntu- latest/ubuntu-24.04) --debug-frozen-string-literal Shows where each string literal was originally created These are built daily, so you get the latest Ruby changes. 22
  23. Development Ruby CI - Future Preparation Pro tips: Check ruby

    -v for commit hash (i.e. 65a0f46880) $ ruby -v ruby 3.5.0dev (2025-07-10T07:48:16Z master 65a0f46880) +PRISM [x86_64-linux] Remember git bisect . If only the Ruby commit hash differs between runs and tests fail, the issue might be in recent Ruby changes Consider rm Gemfile.lock and bundle install to use newest gem versions Fat gems (native extensions like nokogiri ) may not be available for development Ruby Red is OK if released Ruby tests are green - this is early warning, not a pull request merge requirement. 23
  24. Working With The Community Note: Some maintainers may not prefer

    CI for development Ruby versions. If you think it’s useful, explain why – and be open to discussion. If you encounter issues while fixing compatibility or CI, express your opinions clearly: Early feedback during preview releases improves future versions Use official channels: bugs.ruby-lang.org, GitHub Issues Responses may take time — that’s completely normal. Healthy communities thrive on mutual support and two-way communication. 24
  25. What You Can Start Today Start small - pick just

    one gem to begin with Step 1: Find your target gems Check your app's Gemfile.lock Focus on gems NOT in Rails repository's Gemfile.lock Step 2: Test for compatibility issues Run tests with RUBYOPT='-W' to find Ruby 3.4 warnings Look for chilled strings, URI parser, bundled gem warnings 25
  26. What You Can Start Today Step 3: Set up or

    fix CI Create CI for released Ruby versions (3.2-3.4) - must pass for merging Optional: Add development Ruby CI for Ruby 3.5 monitoring Step 4: Submit your contributions Fix compatibility issues using examples from Rails PRs Be patient with maintainer responses Remember: Don't aim for perfection - progress step by step 26
  27. Thank You Find me on: GitHub: https://github.com/yahonda Mastodon: https://mastodon.social/@yahonda X:

    https://x.com/yahonda Bluesky: https://bsky.app/profile/yahonda.bsky.social 27