はじめに
こんにちは、2024年3月から CAMPFIRE でバックエンドエンジニアしている @snaka です。
Advent Calendar としてブログ記事を書くのも、Qiita に記事を書くのも久しぶりになります。
数週間前に Omotesando.rb でLTする機会をいただいたので、そのときの発表内容について記事の形にまとめておこうと思います。
資料は以下です。
rails_new_flags
リポジトリの紹介
リポジトリは以下で公開しています。
このリポジトリでは、Rails の直近のバージョン(6.1.x 〜 8.0.x)について rails new
のフラグ(オプション)の有無でどのような差分が出てくるかを GitHub 上で Diff 表示できます。
たとえば、Rails 7.0.x 系で追加になった --javascript=esbuild
を指定すると importmap 関係の設定ファイルが削除されて、 package.json に依存関係および build スクリプトとして esbuild が追加されているのがわかります。
表の基本的な使い方は、差分を確認したいフラグ/バージョンの ↔️ アイコンをクリックして
差分(フラグなしで実行した場合との差分)を確認する。という使い方になります。
この記事の内容
この記事では、前述のリポジトリを参考として、「近年 Rails を構成するコンポーネントにどのような変化があったのか」というのを rails new
のフラグの増減という側面から眺めて見るというものです。
Rails 6.1.x ⇒ 7.0.x
Rails 7.0.x で導入されたものを見ていきます。
asset pipeline で propshaft が選択可能に
flag | 🔎 6.1.7.8 | 🔎 7.0.8.4 |
---|---|---|
--asset-pipeline=propshaft | - | ↔️ 🔎 |
--asset-pipeline=sprockets | - | ↔️ 🔎 |
- デフォルトは sproket ですが、
--asset-pipeline=propshaft
を指定することで propshaft を利用することができるようになっています - propshaft は sprockets に代わる次世代のアセットパイプラインで、HTTP/2 の普及やインターネットの高速化など現代の状況に合わせて、複雑難解だった sprockets よりシンプルな仕組みになっているようで、 Rails 8 からアセットパイプラインのデフォルトになっているようです
jsbundling-rails / cssbundling-rails gem によって JavaScript バンドラや CSS フレームワーク(?) を選択できるように
flag | 🔎 6.1.7.8 | 🔎 7.0.8.4 |
---|---|---|
--css=bootstrap | - | ↔️ 🔎 |
--css=bulma | - | ↔️ 🔎 |
--css=postcss | - | ↔️ 🔎 |
--css=sass | - | ↔️ 🔎 |
--css=tailwind | - | ↔️ 🔎 |
--javascript=esbuild | - | ↔️ 🔎 |
--javascript=importmap | - | ↔️ 🔎 |
--javascript=rollup | - | ↔️ 🔎 |
--javascript=webpack | - | ↔️ 🔎 |
- Rails 7.0.x のデフォルトでは importmap ですが、プロダクトの状況によっては従来どおり Webpack のような JS バンドラや Sass のような CSS プリプロセッサが必要なケースもあり、そのような状況にも対応できるようになっているようです
- jsbundling-rails 自体は bun, esbuild, rollup.js, webpack などに対応しているようです
- cssbundling-rails は bootstrap, bulma, postcss, sass, tailwind などに対応しているようです
Turbolinks の後継として Hotwire が導入された
flag | 🔎 6.1.7.8 | 🔎 7.0.8.4 |
---|---|---|
--skip-hotwire | - | ↔️ 🔎 |
--skip-turbolinks | ↔️ 🔎 | - |
- Rails 7.0.x から Hotwire がデフォルトで導入されるようになって、それを除外するための
--skip-hotwire
フラグが追加されています - Hotwire を構成する gem は turbo-rails と stimlus です
- turbo-rails を構成する要素は Turbo Drive, Turbo Frames, Turbo Streams です
- (Hotwire まだ良くわかっていないので使い所を探っていきたいです)
listen, spring, webpacker などの gem がデフォルトから外れた
flag | 🔎 6.1.7.8 | 🔎 7.0.8.4 |
---|---|---|
--skip-listen | ↔️ 🔎 | - |
--skip-spring | ↔️ 🔎 | - |
--webpacker | ↔️ 🔎 | - |
- webpacker は importmap-rails がデフォルトになったことで外れているようです
- spring を導入するかどうかはオプションになったようです (一応 Gemfile にはコメントとして残されているようです)
- listen が外された経緯としては以下の PR にあるようですが... その主張の背景などは調べきれませんでした
あとで読む:
Rails 7.0.x ⇒ 7.1.x
デフォルトで Docker に対応した
flag | 🔎 7.0.8.4 | 🔎 7.1.4 |
---|---|---|
--skip-docker | - | ↔️ 🔎 |
-
rails new
するとデフォルトでDockerfile
,.dockerignore
などが作られるようになっています
JS バンドラとして bun が利用可能になった
flag | 🔎 7.0.8.4 | 🔎 7.1.4 |
---|---|---|
--javascript=bun | - | ↔️ 🔎 |
- 7.0.x 系でも jsbundling-rails のバージョンが上げれば bun を利用可能だと思います(要検証)が、
rails new
のオプションとして利用可能になったのは 7.1.x 以降のようです
Rails 7.1.x ⇒ 7.2.x
Devcontainer に対応した
flag | 🔎 7.1.4 | 🔎 7.2.1 |
---|---|---|
--devcontainer | - | ↔️ 🔎 |
-
--devcontainer
で.devcontainer/
配下に以下のファイルが作成されるようになっていますDockerfile
compose.yaml
devcontainer.json
- (個人的には Devcontainer の開発は便利だと思う点もありながら、制限が多くてあまり積極的に活用していないのが実情ですが... )
Rubocop, Brakeman がデフォルトで入るようになった
flag | 🔎 7.1.4 | 🔎 7.2.1 |
---|---|---|
--skip-brakeman | - | ↔️ 🔎 |
--skip-rubocop | - | ↔️ 🔎 |
- デフォルトで rubocop, brakeman が導入されるようになっていて、
--skip-*
オプションでそれぞれ外せるようになっています - Rubocop はほぼ必須なのでデフォルトで入るようになったのは個人的には嬉しいポイントです
- 実際に導入されるのは rubocop-rails-omakase という gem のようです
- Omakase の設定内容をまだ把握していないので、後でじっくり見ておきたいと考えています
- Brakeman はコードを静的解析してセキュリティな問題を洗い出してくれる gem です
- まだ実践導入したことがないのですが、機会を見つけて手元のプロダクトコードで動かしてみて、良さそうであれば導入していきたいと考えています
GitHub Action 用の workflow 設定 yaml ファイルが用意されるようになった
flag | 🔎 7.1.4 | 🔎 7.2.1 |
---|---|---|
--skip-ci | - | ↔️ 🔎 |
- GitHub Actions でワークフローを実行するための雛形 (
.github/workflows/ci.yml
,.github/dependabot.yml
) がデフォルトで 作成されるようになっています -
--skip-ci
でこれらの出力を抑制できます
Rails 7.2.x ⇒ 8.0.x
Rails 8 についてはあまり知識が無く、コメントが感想ベースになりますが... そのうち触っていきたいとは思ってます... (そのうち)
デプロイツールの kamal に対応した
flag | 🔎 7.2.1 | 🔎 8.0.0.beta1 |
---|---|---|
--skip-kamal | - | ↔️ 🔎 |
- 名前は「古代アラブの航海用具」に由来しているようです
- Kbernetes がギリシャ語の「舵取り」「水先案内人」を指す語句を由来としているのと同様に、Ship(「船」そのもの以外に、商品などを「出荷する」という意味もある) に由来するものなのかな?と思ったりしました
solid シリーズ (solid_cache, solid_queue, solid_cable) がデフォルトで導入される
flag | 🔎 7.2.1 | 🔎 8.0.0.beta1 |
---|---|---|
--skip-solid | - | ↔️ 🔎 |
- 従来 Redis をバックエンドとして利用することの多かった Cache, Job Queue, Pub/Sub を RDBMS という触れ込み(?) の Solid シリーズが標準で導入されます
- インフラ構成要素として Redis が不要になることで、管理コストやホスティング先の自由度も上がったりするので良さそう、と思ってたりします
デフォルトで Thruster に対応している
flag | 🔎 7.2.1 | 🔎 8.0.0.beta1 |
---|---|---|
--skip-thruster | - | ↔️ 🔎 |
- Thruster は、これまでプロダクション環境などで Nginx が担っていた SSL termination や static asset の配信などの Puma の負荷を軽減するものという認識です
-
./bin/thrust ./bin/rails server
のように Rails の起動をthrust
コマンドを経由することで設定なしでそのまま使えるのが魅力だと思いました- Nginx 用の設定ファイルやコンテナイメージのメンテナンスが結構面倒なので、その負担がなくなるのは単純に嬉しい
- プロダクションにそのまま導入するのは難しいとは思うので、何かの機会に Thruster 試してみたいとは思っています
おわりに
ざっと rails new
のフラグの変遷を追いかけて、そこから Rails を構成するコンポーネントの変化をざっと見ていきました。
後半(直近のバージョン)は実際に触れていないため、コメントが雑な感じになってしまいましたが... 今回確認できなかった部分はそのうち検証してみて、良さそうなものはプロダクション環境に取り入れたいなと、考えています。