rubocopは定期的に新バージョンがリリースされていますが、最新もしくはそれに近いバージョンにきっちり保てているプロジェクトは案外少ないのではないでしょうか。 2023年の3月末でRuby2.7のサポートが終了するのですが、3.0移行のrubyでrubocopを動かすにはrubocopのバージョンを1.0.0以上にあげる必要があります。 上記の都合から慌ててrubocopのバージョンを上げる必要になった方もいると思います。 しかし、一気に全部やろうとすると、チーム開発であれば他のメンバーの開発とコンフリクトしますし、長時間対応している間に新しいバージョンが出て規則が追加されるので全部対応しきるのは難しいです。 この記事では、そんなrubocopで疲弊する未来が見えた読者の方へ愚直に向き合いすぎないrubocopのバージョンアップ方法を授けます。 とりあえずバージョンを上げる まず兎にも角
RuboCop’s motto has always been “The Ruby Linter that Serves and Protects”.1 Now, with the addition of a server mode in RuboCop 1.31 that motto is truer than ever! But first - a bit of background. Most people value speed and we’ve been on a decade-long journey in RuboCop to improve the performance: we’ve started with the Commissioner that triggered all cops during a single parser run for each file
RuboCopをGitHub Actionsで使うならGitHubActionsFormatterが便利。 Workflow commands形式で出力してくれるので、GitHub Actionsが勝手にそれを拾ってPull Requestだと自動的に変更行に注釈を付けてくれるし、Checksの項目にもエラーと警告の一覧が出力される。 但し、この出力形式は主に機械が便利にキャプチャするためのものなので、人間がログを直接見るときには不都合なことが多い。例えばGitHub Actionsのログでは、Workflow commandsが使われたとき、色を付けたりしてくれるもののファイルパスや行番号を隠してしまう。問題のあったファイルパスを知りたいのに、これは問題だ。 rubocop –format progress –format github と複数指定し、人間用と機械用の両方を同時に出力させ
これはなに RuboCop のバージョンアップを行った際に、新しいルール "Style/FetchEnvVar" が追加されており、仕様について調べ適用を行いました 適用した "Style/FetchEnvVar" のルールについて簡単にまとめました Style/FetchEnvVar について 簡単に記載すると、 ENV['FOO'] ではなく ENV.fetch('FOO') を利用しましょうというルールです 通常 ENV['FOO'] とプログラムを記述し、実行した際に環境変数 FOO が未定義だった場合 nil を返却します nil が返ること自体は明らかなため、 nil で返る可能性を考慮しプログラムを組むべきと言われればその通りです しかし、手法は文化や慣習によって対応方法は複数存在することは容易に想像できます 環境変数参照後にエラーを発生させたい人 デフォルト値を定義し何事も
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く