Laravel公式が利用している継続的コードフォーマッター・StyleCIを試してみた
StyleCI とは？
StyleCI は、コード スタイルの設定を自動的に適用する継続的インテグレーション サービスらしいです。
こんな感じで、設定に合わせてコードのフォーマットをしてくれます。
GitHub へコードを push するだけでコードチェックが行われ、適合しないコードがあればこんな感じでエラーになります。
また、StyleCI は Laravel が公式に利用しているサービスです。
これがあることで、各開発者はコーディングスタイルの設定の違いを気にすることなく、コントリビュートにのみ集中できると Laravel は公式ドキュメントで謳っています。
PHP のみのサポートか？
公式ドキュメントによると、サポートしている言語は以下の通りです。(※2023/04/27 21:32 現在)
- PHP
- JavaScript/JSX
- TypeScript
- CSS/SCSS/LESS
- Python
- Vue.js
- Python
ただし、ドキュメントによると無料プランの場合は PHP のみが対象のようです。
料金
以下の通りです。
| サブスクリプション | Solo | Startup | Premium | Open Source |
|---|---|---|---|---|
| 月額 | $10 | $20 | $50 | 無料 |
| 年額（年払い） | $100 | $200 | $500 | 無料 |
| パブリックリポジトリ | 無制限 | 無制限 | 無制限 | 無制限 |
| プライベートリポジトリ | 10 個 | 20 個 | 50 個 | サポートなし |
| 分析回数 | 無制限 | 無制限 | 無制限 | おそらく無制限 |
| ユーザーライセンス | シングルユーザーのみ | 無制限 | 無制限 | ？ |
| コラボレーター数 | 制限なし | 無制限 | 無制限 | ？ |
| Slack 通知 | なし | あり | あり | なし |
| フルオートメーション | あり | あり | あり | なし |
| サポートする言語 | PHP/JS/CSS/Vue.js/Python | PHP/JS/CSS/Vue.js/Python | PHP/JS/CSS/Vue.js/Python | PHP のみ |
Open Source プランについては確定した情報がなく参考程度に、それでいて他のプランについても必ず公式ページを確認するようにしてください。
(当方では責任を負いかねます)
ただし Open Source プランについて以下はある程度確度が高い情報です。
- 料金は無料
- プライベートリポジトリはサポートされていません
- 無料プランの場合、PHP のみ分析対象。有料プランであれば StyleCI のサポートしているすべての言語が対象
- StyleCI CLI で実行をかけるには有料プランでないといけない
今回は無料版で使い勝手を試してみようと思います。
StyleCI を始める
まずはサインアップから始めます。
GitHub, GitLab, Bitbucket のいずれかでサインアップが可能です。
自分は GitHub で開始しました。
構成の設定
構成の設定を行うには.styleci.ymlを用意する必要があり、これを用意する方法には２通りあるようです。
- 自前で用意した
.styleci.ymlをプロジェクトのルートにコミットする - ダッシュボードを開き、リポジトリのすぐ横にある歯車アイコンをクリックして、リポジトリの設定を構成できます。
今回は、2 の方法を取りたいと思います。
2 ではまず、StyleCI のダッシュボードから以下の手順でリポジトリに対して StyleCI を有効化します。
有効化されるとボタンが「SHOW ANALYSES」に切り替わるのでクリック。
以下の画面が表示されるので、設定を行います。歯車ボタンをクリック。
すると Configure Repo の文字とともにエディタが表示されます。
今回は Laravel 公式 と同じ設定で分析をして欲しいので、Laravel 公式の.styleci.ymlの内容を編集して貼り付けます。
元となる Laravel 公式 の.styleci.ymlはこちらから取得します。
編集前の内容は以下の通りです。
ちなみに、以下の内容を見ると PHP 以外の言語に対してもフォーマットがかかるように設定しているので、Laravel が使っているのは StyleCI の有料プランみたいです。
php:
preset: laravel
version: 8.1
finder:
not-name:
- bad-syntax-strategy.php
js:
finder:
not-name:
- webpack.mix.js
css: true
なので、この内容をそのまま貼り付けると、エラーが起こります。
「複数言語の分析は StyleCI Pro の機能じゃボケ」と言ってるみたいですね。
ですので、PHP の設定のみ抜粋して貼り付けます。抜粋する際、元の StyleCI Pro の記法ルールが違うみたいなので、PHP のみの記法を参考に編集します。
preset: laravel
version: 8.1
finder:
not-name:
- bad-syntax-strategy.php
PHP 設定についてだけ簡単に触れると、preset というものが事前に用意された設定で、ここに"laravel"を指定することで Laravel 向けの解析をしてくれるみたいです。
このとき、具体的にどんな設定が用いられているかはこちらに記載があります。
なお、今回は Laravel 公式と同じ設定にしたいという思考停止状態なので問題ありませんでしたが、詳しく設定を行うのであればドキュメントの参照が必要そうです。
こちらに詳しく書かれているので、参照しながら設定するとよいでしょう。
では、保存します。
今度は無事に保存することができました。
そのほか設定
フォーマット以外に StyleCI の分析結果をどうするかといったことを設定するフィールドが先ほどのエディタの下に続きます。
一つずつ見て行きます。
自動化レベルの設定
先ほどの「Configure Repo」の下に、「Automation Level」というものがあります。
どうやらここでは、以下の設定が可能なようです。
- 必要に応じて修正をプルリクエストとして送信する
- 修正を自動的にプルリクエストとして送信する
- 修正を自動的に送信してマージする
- 修正を自動的に送信して、Squash Merge でマージする
- 修正を自動的に同じブランチに直接コミットする
今回は"修正を自動的にプルリクエストとして送信する"を設定しておきます。
元のコミットの作者を保持する
前のコミットの作者を修正コミットの作者として使用します。
可能な場合には、リンクされたユーザーにフォールバックします。これが無効になっている場合、StyleCI Bot がコミットの作者となります。
これを使用しないようにしたい場合は、単に無効にしてください。デフォルトの設定は無効です。
これは StyleCI Bot がコミットの作者でよいでしょう。
修正 PR コミットの CI をスキップ
私たちは、修正のプルリクエストコミットに[ci skip]を追加することができます。
これを有効にすると、Travis CI などのサービスは、私たちのコミットをテストしなくなります。
これを使用しないようにしたい場合は、単に無効にしてください。デフォルトの設定は無効です。
イマイチイメージが掴めないのですが、勝手にソースを修正してくれるのはいいものの、テストコードを通さないのは元の木阿弥なので無効のままにしておきます。(初期値は無効なのでそのままで OK)
直接/マージコミットの CI をスキップ
私たちは、マージまたは直接修正のコミットに[ci skip]を追加することができます。
これを有効にすると、Travis CI などのサービスは、私たちのコミットをテストしなくなります。
これを使用しないようにしたい場合は、単に無効にしてください。デフォルトの設定は無効です。
よくわかりませんがこれも"修正 PR コミットの CI をスキップ"と同じく無効にします。(初期値は無効なのでそのままで OK)
初めての分析
では、構成の設定ができたので、初めての分析を実行したいと思います。
「ANALYZE NOW」をクリック。
なんで"Update README.md"かというと、どうも最新のコミットコメントが抜粋されて表示されるようです。
実行時間は 3 秒ほど。クッソ早いです。
中をみると…
おぉ〜確かに Laravel のコーディングスタイルが当たってますね！
プルリクも確認
来てますな！
ワークフローも走ってますな。
差分についても、Laravel のコーデングスタイルが当たってそうです。
GitHub 側の初期設定はどうなってるの？
初期状態だと、ブランチに対して StyleCI を有効にした時点で push やプルリクだけでなく、ブランチのタグを作ったり消したりその他もろもろ… が発生するたびに StyleCI が動くようになっています。
意図しないところで動かれてはたまったもんじゃないので、GitHub 側 の設定は無効にしておきます。
Settings > Webhooks > Edit を押下
遷移先の Active チェックボックスを OFF にして、"Update webhook"を押下します。
ブランチ戦略はどうしよう
このリポジトリには master と dev ブランチがあり、コントリビュータの方には dev ブランチから feature ブランチを作成していただき、プルリクエストを dev に対して出してもらっていました。
今回 StyleCI を利用するに当たって、各 feature ブランチへの毎 push ごとや、dev へのプルリクごとに StyleCI の分析とその結果を受けてのプルリクが飛んでくるとプルリクエストが溢れかえってしまいそうです。
なので、新たに release ブランチを作ることにします。
そして、dev へマージされたコミットを、release へマージしたタイミングで StyleCI を実行しコードフォーマットをかけてから release ブランチで動作確認 → 確認後 master へマージがという流れがよさそうです。
自動化は有料プランじゃないとできないっぽい
GitHub Actions で push やプルリクをトリガーにして StyleCI の分析が走るように…と思ったのですが先述の通り、StyleCI CLI で自動で実行をかけるには有料プランでないといけないようです。
一応ドキュメントを見た限りではそのことがどこにも書かれていなくてずっと気づかなかったのですが、GitHub Actions では別のエラーが出ていました。
で、そのエラーについて検証しようと、ローカルの Docker 環境でまずは動作を確認しようとしていました。
StyleCI CLI の実行方法についてはこちらのドキュメント通りやっていきました。
Docker での手順としては、あらかじめコンテナに composer と git をインストールしたうえで、
# gitリポジトリをクローン
cd ./tmp
git clone https://github.com/ysknsid25/otaku-tool.git
cd ./otaku-tool/
# StyleCI CLIのインストール
composer require styleci/cli:^1.5 --dev
# StyleCIのAPIキーを設定
./vendor/styleci/cli/bin/styleci config auth.github APIキー
# StyleCIの実行
./vendor/styleci/cli/bin/styleci
すると成功するのかと思いきや、「ysknsid25 は StyleCI Pro を買ってないからプラン上げろボケ」と怒られました。
なので、StyleCI CLI を利用するには有料プランでないとダメらしく、よって無料プランだと GitHub Actions から実行することはできないようです。
というわけで仕方なく StyleCI CLI のダッシュボードから定期的に手動実行することにします。
おわりに
無料プランだと自動化は叶わなかったものの、以前紹介した Larastan と組み合わせることで、より強力に開発支援を受けられそうです。
一方でコードフォーマットを自動でおこなってくれるということは、自動テストが導入されていない場合予期せぬバグを引き起こしそうです。
反面、Larastan や自動テストを導入したうえで StyleCI を導入すれば、DX は爆上がりしそうですね。
世界的に利用されており、コントリビューターも大勢いる OSS プロジェクトの開発手法を知ることは、PHP 以外の言語において自分がプロジェクトを新規立ち上げする際にも大いに役立ちそうです。
メンバー募集中！
サーバーサイド Kotlin コミュニティを作りました！
Kotlin ユーザーはぜひご参加ください！！
また関西在住のソフトウェア開発者を中心に、関西エンジニアコミュニティを一緒に盛り上げてくださる方を募集しています。
よろしければ Conpass からメンバー登録よろしくお願いいたします。
Discussion