A robust settings library for Ruby. Access your settings by calling methods on a safe immutable object.

• 🚀 Light and Performant: settings are eagerly loaded, no method_missing tricks, no dependencies.
• 💬 Useful Error Messages: when trying to access a setting that does not exist.
• 💎 Immutability: once created settings can't be modified.
• 🗂 Multiple Files: useful to create multiple environment-specific source files.
• ❕ No Optional Setings: since it encourages unsafe access patterns.

You can read more about it in the blog announcement.

Add this line to your application's Gemfile:

gem 'better_settings'

And then execute:

$ bundle

Or install it yourself as:

$ gem install better_settings

Create a class in your application that extends BetterSettings:

# app/models/settings.rb
class Settings < BetterSettings
  source Rails.root.join('config', 'application.yml'), namespace: Rails.env
end

We use Rails.root in this example to obtain an absolute path to a plain YML file, but when using other Ruby frameworks you can use File.expand_path with __dir__ instead.

Also, we specified a namespace with the current environment. You can provide any value that corresponds to a key in the YAML file that you want to use. This allows to target different environments with the same file.

Now, create a YAML file that contains all the possible namespaces:

# config/application.yml
defaults: &defaults
  port: 80
  mailer:
    root: www.example.com
  dynamic: <%= "Did you know you can use ERB inside the YML file? Env is #{ Rails.env }." %>

development:
  <<: *defaults
  port: 3000

test:
  <<: *defaults

production:
  <<: *defaults

The defaults group in this example won't be used directly, we are using YAML's syntax to reuse those values when we use <<: *defaults, allowing us to share these values across environments.

You can use these settings anywhere, for example in a model:

class Post < ActiveRecord::Base
  self.per_page = Settings.pagination.posts_per_page
end

or in the console:

>> Rails.env
=> "development"

>> Settings.mailer
=> "#<Settings ... >"

>> Settings.mailer.root
=> "www.example.com

>> Settings.port
=> 3000

>> Settings.dynamic
=> "Did you know you can use ERB inside the YML file? Env is development."

You can create as many setting classes as you need, and name them in different ways, and read from as many files as necessary (nested keys will be merged).

The way I like to use it, is by reading a few optional files for the development and test environments, which allows each developer to override some settings in their own local environment (and git ignoring development.yml and test.yml).

# app/models/settings.rb
class Settings < BetterSettings
  source Rails.root.join('config/application.yml'), namespace: Rails.env
  source Rails.root.join('config/development.yml'), namespace: Rails.env, optional: true if Rails.env.development?
  source Rails.root.join('config/test.yml'), namespace: Rails.env, optional: true if Rails.env.test?
end

Then application.yml looks like this:

# application.yml
defaults: &defaults
  auto_logout: false
  secret_key_base: 'fake_secret_key_base'

server_defaults: &server_defaults
  <<: *defaults
  auto_logout: true
  secret_key: <%= ENV['SECRET_KEY'] %>

development:
  <<: *defaults
  host: 'localhost'

test:
  <<: *defaults
  host: '127.0.0.1'

staging:
  <<: *server_defaults
  host: 'staging.example.com'

production:
  <<: *server_defaults
  host: 'example.com'

A developer might want to override some settings by defining a development.yml such as:

development:
  auto_logout: true

The main advantage is that those changes won't be tracked in source control 😃