Software

SprocketsからPropshaftへの移行に関する注意点

21 Dec, 2025 06:00 +00:00

Propshaftへの移行に際して、tailwindcss-railsまたはdartsass-railsを選ぶのもあり

Propshaftの公式移行手順では、CSS関連の処理が必要な場合の選択肢として cssbundling-rails のみ紹介されていますが、 tailwindcss-rails と dartsass-rails という選択肢もあります。cssbundling-railsのREADMEには、選び方のヒントが掲載されています。

SprocketsからPropshaftへの移行に関する注意点

@wakairo

21 Dec, 2025 05:54 +00:00

SprocketsからPropshaftへの移行手順は、以下のPropshaftの公式手順で基本的には問題ないと思いますが、この公式手順に記載されていないものを中心に、移行における注意点をこのTopicで集約できればと思います。

https://github.com/rails/propshaft/blob/main/UPGRADING.md

OmniAuthを利用したログインのボタンやリンクではTurboをオフにした方が無難

@wakairo

21 Dec, 2025 05:24 +00:00

Last edited

21 Dec, 2025 05:24 +00:00

OmniAuthを利用すると外部サービスの認証情報を用いたログインが可能となりますが、そのログインのボタンやリンクでは、以下のようにdata: {turbo: false}を付けてTurboをオフにしないと、ログインが機能しない場合があります。

<%= button_to "Login with GitHub", "/auth/github", data: {turbo: false} %>

なお、公式のREADMEにあるRails向けサンプルでもdata: {turbo: false}が用いられています。

また、Rails 7からは、Turboがデフォルト構成に組み込まれ有効になっているため、OmniAuthを利用する際は本件への注意が必要です。

setup-rubyにおける.ruby-versionを用いたバージョン指定

@wakairo

19 Dec, 2025 05:37 +00:00

ruby-version:が無いときのデフォルト動作では、まず.ruby-versionを読みに行くのですね。知りませんでした。

ちなみに少し調べてみたら、2020年のv1.3.0のときから既にそういう仕様のようですね。

それから、railsの新規アプリのGitHub Actionsの設定も現在はruby-version:を省略するようになっていますね。

setup-rubyにおける.ruby-versionを用いたバージョン指定

Takuma @takuma_tech

18 Dec, 2025 11:14 +00:00

setup-rubyのREADMEに以下の記述がありますので、 ruby-version:を設定ファイルにあえて書かないことで、.ruby-versionに設定することも可能です。

If the ruby-version input is not specified, .ruby-version is tried first, followed by .tool-versions, followed by mise.toml

設定ファイルをできるだけ簡潔にしたいなら書かない選択もありですし、逆に分かりやすさを重視するなら明示的に書くのも一案です。どちらを取るかは悩ましいところですね。

Podmanのreplaceオプションを使ってワンコマンドでPodを作り直す

@wakairo

17 Dec, 2025 05:53 +00:00

Last edited

17 Dec, 2025 08:01 +00:00

以下のコマンドの実行などで、Podに対応するKubernetes YAMLファイルを一度用意しておけば、

podman generate kube mypod -f=mypod.yaml

replaceオプションを利用した以下のコマンドで1つで、PodとそのContainerの停止から削除、再生成までを一度に行えます。

podman play kube mypod.yaml --replace

Imageの更新について

Kubernetes YAMLファイル内でimagePullPolicy:を指定していないlatestタグのImageは、 replaceを利用した前述のコマンドの実行により、Imageの更新（pull）も併せて行われます。

latest以外のタグのImageが更新された形でPodを再生成したい場合は、以下のコマンドでImageを更新してから、replaceを利用した前述のコマンドを実行します。

podman pull example/image:tag

参考情報

`yield :foo`と`content_for :foo`の使い分け

@wakairo

17 May, 2025 03:26 +00:00

動機

Rails 8.0.2でrails newをして生成されたapp/views/layouts/application.html.erbでは、以下のようにyield :fooとcontent_for :fooが混在していました。

<html>
  <head>
    <title><%= content_for(:title) || "Sample" %></title>
（中略）
    <%= yield :head %>

content_forのAPIドキュメントによれば yield :fooとcontent_for :fooの働きが等価となる場合もあるのですが、このapplication.html.erbの例のように、片方に統一されず両方を利用しているケースがあったので、 yield :fooとcontent_for :fooの使い分けについて調べる事にしました。

結論

基本的には、yield :fooを使う。ただし、以下の2つのケースではcontent_for :fooを使う。
ケース1：ヘルパーメソッドの中では、yieldは利用できないので、content_for :fooを使う。
ケース2：ビュー側で設定されているかどうかに応じて挙動を切り替えるコードを短く書くときにはcontent_for :fooを使う。

詳細

yieldはヘルパーメソッドの中では利用できない

content_forのAPIドキュメントに書かれている通り、 content_forは以下の例のようにヘルパーメソッド内で利用可能ですが、yieldは利用できません。

module StorageHelper
  def stored_content
    content_for(:storage) || "Your storage is empty"
  end
end

yieldとcontent_forでは、設定されていないときの戻り値が異なる

ビュー側で以下のように:fooに対して設定が行われていた場合、

<% content_for :foo do %>
  Foo
<% end %>

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する

@wakairo

07 Apr, 2025 01:42 +00:00

Rais8から標準となったPropshaftを使っている場合でのbootstrap-rubygemのインストールについてです。

結論としましては、公式GitHubレポジトリのインストール方法にある「Sprockets」のところより前はPropshaftでも同様に作業を進め、その後はPropshaftの場合は以下の2行をapp/javascript/application.jsに追加すればインストール完了です。

import "@popperjs/core"
import "bootstrap"

なお、Propshaftの場合のインストール作業全体の例は、こちらのページで紹介されています。ご参考まで。

params.expectで配列のパラメータを許可するには明示的に二重の角括弧（[[ :属性名 ]]）が必要

@wakairo

25 Feb, 2025 06:59 +00:00

Last edited

25 Feb, 2025 07:00 +00:00

ちなみに、RuboCopにrequireとpermitの組み合わせからexpectへの書き換えを自動でやってもらうことは可能ですが、配列パラメータの許可に関してはRuboCopが自動書き換えに失敗する場合があります。

その理由は以下の記述は、配列のパラメータも配列でないパラメータも許可してしまうため、RuboCopとしては配列なのかそうでないのかの判定が機械的に行えないためであると考えられます。

permit(user: [:name])

より詳しくは、前述の記事のこちらの箇所を参照ください。

params.expectで配列のパラメータを許可するには明示的に二重の角括弧（[[ :属性名 ]]）が必要

@wakairo

25 Feb, 2025 06:43 +00:00

Rails8では、requireとpermitに代わるより安全な新しいメソッドとして、strong parametersへexpectが導入されました。

expectでは、安全面への配慮から、配列のパラメータを指定する方法がpermitに比べ厳格化されています。具体的には、配列のパラメータを許可するには明示的に二重の角括弧（[[ :属性名 ]]）が必要となりました。

配列のパラメータを許可する具体的な方法（引用元: expectのAPIドキュメント）は以下の通りです。

params = ActionController::Parameters.new(comments: [{ text: "hello" }, { text: "world" }])
params.expect(comments: [[:text]])
# => [#<ActionController::Parameters { "text" => "hello" } permitted: true>,
#     #<ActionController::Parameters { "text" => "world" } permitted: true>]

なお、安全のためにexpectがこの二重の括弧の記法を採用した背景については、Rails 8: strong parametersの新しいparams.expectの使い方（翻訳）を参照ください。

Software

Latest comments

Propshaftへの移行に際して、tailwindcss-railsまたはdartsass-railsを選ぶのもあり

Imageの更新について

参考情報

動機

結論

詳細

yieldはヘルパーメソッドの中では利用できない

yieldとcontent_forでは、設定されていないときの戻り値が異なる