The holy grail for my local development efforts on new Rails projects has been to Dockerize the experience so I don't run into the usual dependency hells of RVM / rbenv and all the various issues along the way of Rails + Ruby versioning that will eventually rear their heads when doing one-off experiments.

I have used a whole suite of third-party gems in the past like rspec for testing, pundit for authorization, etc. For this latest project, I want to use as much of the out of the box tooling that comes with Rails 8, including the new authorization scaffolding.

I believe the latest rails application tools allow this to become more of a reality. The efforts of tracking down the various Dockerfile configs will hopefully be somewhat more standardized. Let's document the process as I attempt it:

  • Install Docker (if not done already)
  • Install VSCode + the VS Code Dev Containers extension
  • Install rails-new (and uncompress)
  • mv ~/Downloads/rails-new /usr/local/bin 
  • rails-new <app-name> --devcontainer
  • cd <app-name>
  • open VSCode
    • Install the Dev Containers plugin
    • Install SQLite Viewer plugin
    • it should magically inform you it found a container, click the prompt and watch it do its thing
  • in the VSCode Terminal, you can just run rails s and the local dev server is ready to go
  • I'm going to add tailwindcss functionality to the .erb templates, so we need to install that in the Gemfile:
# tailwind for our css
gem "tailwindcss-ruby", "~> 4.0"
gem "tailwindcss-rails", "~> 4.0"
  • Then run the built-in installer for tailwindcss-rails:
    • ./bin/bundle add tailwindcss-rails
    • ./bin/rails tailwindcss:install
  • Then add a Procfile so tailwind will listen out to changes and update the templates on style class changes while testing on local dev server
    • First a Procfile.dev file at the root level of the project with the following:
web: bin/rails server
css: bin/rails tailwindcss
    • Then use the overmind gem to allow for better debugging across multiple services
    • Start the services via:
      • overmind s

Unexpected benefits of using the generic rails-new --devcontainer include:

  • the ci.yml file that's generated in the /.github/workflows/ci.yml area.
    • this gives us a default build pipeline each time we push our commits up to the GitHub remote with the following 4 steps:
      • brakeman i.e. audit security vulnerabilities in rails code
      • importmap audit scan for js dependency issues
      • rubocop i.e. ruby linter for ensuring baseline code styling
      • bin/rails db:test:prepare test test:system
        • test the specs along with the functional tests
  • the dependabot.yml config that is setup to scan for latest gem file updates.
    • we can choose to ignore them after reviewing on GitHub.com, or use the automagically generated PRs and test them with our existing suite to try and stay up to date with all the latest gems.