Managing Gems in Your Rails Application

Screening a new gem

A good gem can cut your build time hugely. A bad one adds maintenance and cost.

Before adopting one, check that it actually fits your need. Skip gems that pile on features you will never use, they just bloat the app.

Check the repo

• Commit frequency: frequent updates suggest active maintenance.
• Issue resolution: quick, useful fixes indicate strong support.
• Stars and forks: high numbers hint at reliability and trust.

Check the code

• Clarity: well-structured, commented code is easier to integrate and maintain.
• Test coverage: real tests reflect stability and safer updates.

Then search for blog posts or tutorials from people who have used it. Good docs and positive write-ups are a green light. A pile of unresolved issues is a red flag.

The TAM method

When picking a gem, run it through TAM.

T: Tests. Confirm the gem ships its own automated test suite. No tests means your app’s reliability rides on someone else’s hope.

A: Activity. Look for recent commits, issues, and pull requests. Active maintenance means it keeps up with new Rails versions.

M: Maturity. Check the age and version history. Stability usually tracks maturity, and a mature gem is less likely to surprise you in production.

Modifying a gem

Sometimes you need to change third-party code. Two clean ways to do it.

Monkey patching

Reopen the class or module and change its behavior at runtime, without touching the original source.

# lib/validatable_extensions.rb
module Validatable
  class ValidatesNumericalityOf < ValidationBase
    def valid?(instance)
      # 1. Copy paste original code from the git repo
      # 2. Modify the lines that you need

      value = value_for(instance)
      return true if allow_nil && value.nil?

      return true if allow_blank && value.blank?

      value = value.to_s
      # EXAMPLE: modify the regexp for our use case.
      regex = self.only_integer ? /\A[+-]?\d+\Z/ : /\A[+-]?\d*\.{0,1}\d+$/
      not (value =~ regex).nil?
    end
  end
end

Forking

If the patch fixes something real or improves the library sensibly, fork it on GitHub and point your Gemfile at the fork.

# Gemfile
gem 'validatable', git: 'git://github.com/yourusername/validatable.git'

Keeping your Gemfile lean

A tidy Gemfile is part of app health.

Find unused gems. Cross-reference usage with tools like bundler-audit or gem_unused, and periodically ask “why is this here?”

Update and prune. Keep gems current and drop the ones you no longer use, for security and performance.

bundle update
bundle install

Gem OCD

Not critical for the bottom line, but I have strong OCD about Gemfiles. I always add:

• A description
• Consistent quotes
• Explicit versions

# Gemfile

# Ruby on Rails is a full-stack web framework optimized for programmer happiness and sustainable productivity.
gem 'rails', '~> 7.1', '>= 7.1.3.2'

Share your gems

We are not the JS community, we love our gems.

Share yours in r/rails, on Twitter, on YouTube. You will be surprised how much love and good advice comes back.

The more you build, the faster you know which gem to reach for. That is the level of expertise to aim for.