Gemfile styling

Question

I would like to know if there is a generally accepted style on Gemfile.

I generate new rails application, open the Gemifile, and add all the gems I need under appropriate group (test, dev etc.).

When I look at Rails opensource projects, most are not structured this way. They have the standard installed Rails gems left as they are or commented out, and then there is a second list of gems under it for the gems that the app actually needs. For me, this is less readable, but is there a reason why a lot of people seem to do it this way?

score 3 · Accepted Answer · edited May 23 '17 at 12:15

There is no general standard or consensus, exactly like there is no general standard on leaving commented code in a Ruby file.

Generally, the idea of leaving stuff commented out is a bad habit from the days where we were used to code without a version control system.

If you are not using a Gem, there is no need to leave it there commented out. It's fine to comment it out temporarily while testing different behaviours with/without or temporarily for whatever reason, but once you reached a decision to take out the gem it's safe to remove it.

Personally, I generally structure the Gemfiles in the following way:

source 'https://rubygems.org'

# Rails core gems at the top
gem 'rake'
gem 'rails', '4.2.5'
gem 'sass-rails', '~> 5.0'
.
.
.
gem 'responders', '~> 2.0'

# Gems, in alphabetical order
gem 'yajl-ruby', '~> 1.2.0', require: 'yajl'
gem 'bcrypt', '~> 3.1.0', require: 'bcrypt'
.
.
.

# Environment dependent gems, in alphabetical order
group :test do
  gem 'database_cleaner', require: false
  .
  .
end

group :development do
  gem 'letter_opener', '~> 1.4.0'
  .
  .
  .
end

group :production do
  gem 'clockwork', '~> 1.2.0', require: false
  .
  .
  .
end

group :development, :test do
  gem 'byebug', require: false
  .
  .
  .
end

Gemfile styling

1 Answers1