Rails Developers Meetup 2018 Day 3 Extreme で『RuboCop Headquarters 2018』というタイトルで登壇した。
Rails Developers Meetup では 2018 Day 1 から4ヶ月ぶり4度目の登壇となる発表資料は以下 (もしかすると登壇回数最多?) 。
今回は秒速 284km さんから RubyKaigi 2018 で話していた Part 3: Cross over OSS communities みたいな感じで「衝突してしまった RuboCop Rails の Gem 名を譲ってもらうにあたる話をしてもらいたい」とのオファーを Asakusa.rb でもらったのがきっかけ。あまり同じ話はしないタイプだけれど、これまで RuboCop で活動してきた話を RubyKaigi 2018 で話したので、これから RuboCop で行う話としてまとめることで違いを出してみたつもり。
前半は RuboCop Headquarters の話。後半は RuboCop 1.0 に向けたマイルストーンと実現に向けた活動の話の2パート構成になっている。
RuboCop 1.0 について3行でざっくりまとめる。
- 設計どおりに振る舞う Cop に限定する
safeと、設計どおり自動修正されるsafe-auto-correctなどのメタデータと実行オプションが導入される - バージョンアップで導入される新たな (枯れていない) Cop を利用する/しないを選択できるようにして、アップグレードのハードルを下げる
- Rails cops と Performance cops はコアから外れる
safe な Cop かどうかだけれど、まず safe が前提になる。そのうえで unsafe であるかどうかの判断は、Issue が元になるとおもうので問題があれば Issue を開いてもらいたい。
このあたりを基準に safe がまずそうであれば、unsafe な Cop としていくと思うので、もし false positive などの問題に遭遇したときは RuboCop 1.0 への参加方法のひとつとしてもらいたい。
あるいは私が所属している https://github.com/esminc という企業 organization に参加して伝えてもらえれば、うまいことやりたいと思っている (ステマ) 。
もう少し詳しい情報はスライド参照。現時点で見えている RuboCop 1.0 の姿がまとまった唯一無二のスライドだと思う。
質問の余地を残すためあえて記さなかったけれど、RuboCop 1.0 にいつなるかについては年内か年明けくらいには条件は整えておきたいという目標。
その他、個人的には金子さんが開発を進めている Ruby 2.6.0 で試験導入される RubyVM::AST の静的解析ツールなどへの実用性などに興味があって、金子さんと話せたのは良かった。いまのところ複数の Ruby バージョンを梱包している Parser gem と異なり、実行処理系の AST に依存するというあたり、マルチプラットフォームが必要な Gem ではない何らかの用途を前提での利用検討となりそうという所感。
また 2019 年にも開催されるということで、次回の Railsdm も楽しみにしています。スタッフのみなさんありがとうございました。
