Running 1 tests in a single process (parallelization threshold is 50)
Run options: --seed 32547
# Running:
/x/vendor/bundle/ruby/3.4.0/gems/railties-8.0.4/lib/rails/test_unit/line_filtering.rb:7:in 'run': wrong number of arguments (given 3, expected 1..2) (ArgumentError)
from /x/vendor/bundle/ruby/3.4.0/gems/minitest-6.0.0/lib/minitest.rb:467:in 'block (2 levels) in Minitest::Runnable.run_suite'
from /x/vendor/bundle/ruby/3.4.0/gems/minitest-6.0.0/lib/minitest.rb:463:in 'Array#each'
from /x/vendor/bundle/ruby/3.4.0/gems/minitest-6.0.0/lib/minitest.rb:463:in 'block in Minitest::Runnable.run_suite'
from /x/vendor/bundle/ruby/3.4.0/gems/minitest-6.0.0/lib/minitest.rb:505:in 'Minitest::Runnable.on_signal'
from /x/vendor/bundle/ruby/3.4.0/gems/minitest-6.0.0/lib/minitest.rb:492:in 'Minitest::Runnable.with_info_handler'
from /x/vendor/bundle/ruby/3.4.0/gems/minitest-6.0.0/lib/minitest.rb:462:in 'Minitest::Runnable.run_suite'
from /x/vendor/bundle/ruby/3.4.0/gems/minitest-6.0.0/lib/minitest.rb:355:in 'block in Minitest.run_all_suites'
from /x/vendor/bundle/ruby/3.4.0/gems/minitest-6.0.0/lib/minitest.rb:355:in 'Array#map'
from /x/vendor/bundle/ruby/3.4.0/gems/minitest-6.0.0/lib/minitest.rb:355:in 'Minitest.run_all_suites'
from /x/vendor/bundle/ruby/3.4.0/gems/minitest-6.0.0/lib/minitest.rb:310:in 'Minitest.run'
from /x/vendor/bundle/ruby/3.4.0/gems/minitest-6.0.0/lib/minitest.rb:84:in 'block in Minitest.autorun'
minitest6にアップデートするとrails testがエラーになる
現象
2025/12/18にリリースされたminitest 6.0.0のgemにアップデートしたところ、
bin/rails testの実行で以下のエラーが発生して止まりました。ちなみに、テストが1つも無い状態ではこのエラーは発生しませんでした。とりあえずの回避策
Gemfileの
group :testのところに以下の記述を追加してminitestのバージョンを6よりも下に設定したところエラーは出なくなりました。SprocketsからPropshaftへの移行に関する注意点
Propshaftへ移行したらSprockets用の設定は削除可能
config/environments/production.rbにある以下の設定はSprocketsの設定なので、 Propshaftへ移行したら、削除可能です。参考情報
https://www.techtips.page/ja/comments/658
SprocketsからPropshaftへの移行に関する注意点
Propshaftは.erbを処理しない
Sprocketsは拡張子が
.erbのファイル(例:foo.scss.erb)を処理しますが、Propshaftは処理しません。 そのため、Sprockets で.erbを処理している場合、Propshaftへ移行するには次のいずれかの対応が必要になります。.erbの利用をやめ、プレーンなCSS/SCSSなどに書き換える.erbの処理を、Propshaftに渡す前の前処理として別途組み込むSprocketsからPropshaftへの移行に関する注意点
Propshaftへの移行に際して、tailwindcss-railsまたはdartsass-railsを選ぶのもあり
Propshaftの公式移行手順では、CSS関連の処理が必要な場合の選択肢として cssbundling-rails のみ紹介されていますが、 tailwindcss-rails と dartsass-rails という選択肢もあります。cssbundling-railsのREADMEには、選び方のヒントが掲載されています。
SprocketsからPropshaftへの移行に関する注意点
SprocketsからPropshaftへの移行手順は、 以下のPropshaftの公式手順で基本的には問題ないと思いますが、 この公式手順に記載されていないものを中心に、 移行における注意点をこのTopicで集約できればと思います。
https://github.com/rails/propshaft/blob/main/UPGRADING.md
OmniAuthを利用したログインのボタンやリンクではTurboをオフにした方が無難
OmniAuthを利用すると外部サービスの認証情報を用いたログインが可能となりますが、 そのログインのボタンやリンクでは、以下のように
data: {turbo: false}を付けてTurboをオフにしないと、ログインが機能しない場合があります。なお、公式のREADMEにあるRails向けサンプルでも
data: {turbo: false}が用いられています。また、Rails 7からは、Turboがデフォルト構成に組み込まれ有効になっているため、OmniAuthを利用する際は本件への注意が必要です。
`yield :foo`と`content_for :foo`の使い分け
動機
Rails 8.0.2でrails newをして生成されたapp/views/layouts/application.html.erbでは、 以下のように
yield :fooとcontent_for :fooが混在していました。content_forのAPIドキュメントによれば
yield :fooとcontent_for :fooの働きが等価となる場合もあるのですが、 このapplication.html.erbの例のように、片方に統一されず両方を利用しているケースがあったので、yield :fooとcontent_for :fooの使い分けについて調べる事にしました。結論
yield :fooを使う。ただし、以下の2つのケースではcontent_for :fooを使う。content_for :fooを使う。content_for :fooを使う。詳細
yieldはヘルパーメソッドの中では利用できない
content_forのAPIドキュメントに書かれている通り、 content_forは以下の例のようにヘルパーメソッド内で利用可能ですが、yieldは利用できません。
yieldとcontent_forでは、設定されていないときの戻り値が異なる
ビュー側で以下のように:fooに対して設定が行われていた場合、
yield :fooとcontent_for :fooの戻り値は、この例ではどちらも" Foo\n"であり、同じになります。しかし、ビュー側で前述のような記述がなく:fooに対して設定が行われていなかった場合、
yield :fooの戻り値が空文字列("")であるのに対し、content_for :fooの戻り値はnilであり、 戻り値が異なります。設定されていない場合に
content_for :fooがnilを戻す性質を利用することで、<title><%= content_for(:title) || "Sample" %></title>のような設定されているかどうかに応じて挙動を切り替えるコードを短く書くことができます。Rais8でPropshaftを使う環境ではapplication.jsでbootstrapをimportする
Rais8から標準となったPropshaftを使っている場合でのbootstrap-rubygemのインストールについてです。
結論としましては、公式GitHubレポジトリのインストール方法にある「Sprockets」のところより前はPropshaftでも同様に作業を進め、その後はPropshaftの場合は以下の2行をapp/javascript/application.jsに追加すればインストール完了です。
なお、Propshaftの場合のインストール作業全体の例は、こちらのページで紹介されています。ご参考まで。
params.expectで配列のパラメータを許可するには明示的に二重の角括弧([[ :属性名 ]])が必要
ちなみに、RuboCopに
requireとpermitの組み合わせからexpectへの書き換えを自動でやってもらうことは可能ですが、配列パラメータの許可に関してはRuboCopが自動書き換えに失敗する場合があります。その理由は以下の記述は、配列のパラメータも配列でないパラメータも許可してしまうため、RuboCopとしては配列なのかそうでないのかの判定が機械的に行えないためであると考えられます。
より詳しくは、前述の記事のこちらの箇所を参照ください。
params.expectで配列のパラメータを許可するには明示的に二重の角括弧([[ :属性名 ]])が必要
Rails8では、
requireとpermitに代わるより安全な新しいメソッドとして、strong parametersへexpectが導入されました。expectでは、安全面への配慮から、配列のパラメータを指定する方法がpermitに比べ厳格化されています。 具体的には、配列のパラメータを許可するには明示的に二重の角括弧([[ :属性名 ]])が必要となりました。配列のパラメータを許可する具体的な方法(引用元:
expectのAPIドキュメント)は以下の通りです。なお、安全のためにexpectがこの二重の括弧の記法を採用した背景については、Rails 8: strong parametersの新しいparams.expectの使い方(翻訳)を参照ください。