Comments in Gemfile, round 2

A May Of WTFs
1

I agree Flag to not leave so many comments in the default Gemfile wasn’t a very constructive thread, but I think there is some merit in reviewing these comments. You can see the current base Gemfile in that thread. Here’s what I’m proposing:

source 'https://rubygems.org'
git_source(:github) { |repo| "https://github.com/#{repo}.git" }

ruby '2.6.4'

# The base Rails gem, where most of the magic happens!
# https://guides.rubyonrails.org/getting_started.html
gem 'rails', '~> 6.0.3'
# Puma is the app server Rails runs on. Learn about Puma: https://puma.io
gem 'puma', '~> 4.1'

# Most Rails apps will use these gems, but you can change or remove them if needed:

# Use SQLite as the database. PostgreSQL and MySQL are also supported.
# To change database, read https://guides.rubyonrails.org/configuring.html#configuring-a-database
gem 'sqlite3', '~> 1.4'
# Use SCSS for easy to write CSS: https://sass-lang.com/guide
gem 'sass-rails', '>= 6'
# Transpile app-like JavaScript. Read more: https://github.com/rails/webpacker
gem 'webpacker', '~> 4.0'
# Turbolinks makes navigating your web application faster. Read more: https://github.com/turbolinks/turbolinks
gem 'turbolinks', '~> 5'
# Build JSON APIs with ease. Read more: https://github.com/rails/jbuilder
gem 'jbuilder', '~> 2.7'

# Optional gems needed by specific Rails features:

# If using ActionCable, use the Redis adapter. https://guides.rubyonrails.org/action_cable_overview.html
# gem 'redis', '~> 4.0'
# Use bcrypt to encrypt passwords securely. Works with https://guides.rubyonrails.org/active_model_basics.html#securepassword
# gem 'bcrypt', '~> 3.1.7'

# The gems below will make development easier, but if they cause problems it's OK to remove them

group :development, :test do
  # Call 'byebug' anywhere in the code to stop execution and get a debugger console
  gem 'byebug', platforms: [:mri, :mingw, :x64_mingw]
end

group :development do
  # Access an interactive console on exception pages or by calling 'console' anywhere in the code.
  gem 'web-console', '>= 3.3.0'
  gem 'listen', '~> 3.2'
  # Spring speeds up development by keeping your application running in the background. Read more: https://github.com/rails/spring
  gem 'spring'
  gem 'spring-watcher-listen', '~> 2.0.0'
end

group :test do
  # These gems are needed for https://guides.rubyonrails.org/testing.html#system-testing

  # Adds support for Capybara system testing and selenium driver
  gem 'capybara', '>= 2.15'
  gem 'selenium-webdriver'
  # Easy installation and use of web drivers to run system tests with browsers
  gem 'webdrivers'
end

# Reduces boot times through caching; required in config/boot.rb
gem 'bootsnap', '>= 1.4.2', require: false

# Windows does not include zoneinfo files, so bundle the tzinfo-data gem
# If you don't use Windows you can remove this gem
gem 'tzinfo-data', platforms: [:mingw, :mswin, :x64_mingw, :jruby]

Principles:

  • For each gem there is a link or a solid explanation of what the gem does.
  • Gems that you can change are called out. Gems that you shouldn’t change are not.
  • It’s better to have multi-line comments or extra spacing than it is to have confusing comments.

Questions:

  • I don’t know much about jbuilder. I’ve never used it. Does every single Rails user need it on by default?

Changes:

  • Removed note about bundling edge rails as it’s only useful for power users.
  • Explained how to change your DB + added a link to Configuring Rails Applications — Ruby on Rails Guides (which could probably be better but that’s another story)
  • If you google has_secure_password you don’t get any great results. I imagine this confuses lots of people when it’s mentioned in the Gemfile. I’ve removed it and made the comment around bcrypt more generic for this reason.
  • I removed image_processing entirely. Active Storage Overview — Ruby on Rails Guides introduces it, but I don’t see why every single user needs to be told about it.
  • Moved bootsnap to the bottom. It’s not something new users should think about.

Thoughts?

7 Likes
2

This feels like it’s something you could break up into a series of PRs without too much effort. I think improved documentation is basically always welcome. :slight_smile:

1 Like
3

I’d love to put it all in one PR unless anything seems particularly controversial.

Do you have any thoughts on the jbuilder question? / can you suggest who the best person to ask about that is?

4

I know that jbuilder is used for JSON APIs by people who don’t write serializer classes. In spirit it’s “ERB for JSON” (though that’s not at all what jbuilder files look like.)

I think that the gem removal is likely to be controversial in ways that would benefit from a separate PR, but on further thought I agree that the reorganization is likely to be easy to review as a block otherwise.

5

I don’t use it either, but I can see myself reaching for it if I’m building an app which only needs structured JSON sprinkles here and there

6

We are off the topic of comments in the gemfile. Removing jbuilder by default would be a good new topic though!

1 Like
7

https://github.com/rails/rails/pull/39440

4 Likes
8

I love gemfile/gemspecs discussions since most people just ignore their features and usually they don’t care about others using their projects (“just let the file grows wild as we add things that nobody check”).

About the post, I would clarify that it’s covering a Gemfil usage for a RoR app. The scenario does not really apply for more “static” ruby projects/gems krogerfeedback