Closed kachick closed 2 years ago
steep_expectations.yml の管理が大変。これが厳密に行番号とか文字位置を管理しているので、ちょっとしたコード修正でも常に更新する必要が出てしまう。
# steep:ignore
なる annotation をかけるようになるらしい
https://www.timedia.co.jp/tech/20240502-tech/
ruby code 側への侵食にOKが出たんだなぁ
ruby code 側への侵食にOKが出たんだなぁ
TL;DR
Steepfile 内で configure_code_diagnostics を使えば良い
例: https://github.com/kachick/ruby-ulid/commit/be686d4a049f655dbdbe8674fcb312eecae0e141
経緯 / History
steep check
に--severity-level
を渡すと、どの基準でエラーレポートを吐くか決められる。個人的には warning ぐらいが丁度良く使える感じなんだけど、case の 到達し得ない else 節に入った時に ElseOnExhaustiveCase が出てしまう。 これ自体は便利というか、個人的にも TypeScript で default に入ったときには一時変数に never を代入する事で分岐漏れを防ぐ様な感じにしているので本来欲しい機能な気がする。 ただ rbs の場合は別ファイルに annotation を切り出す事もあってか、この手の時に処理を変えずに型チェック側だけチューニングするのがちょっと難しい。 else 節にraise 'should not reach here'
的なおまじないを入れるのが好きなのだけど、デフォルトのままだとsteep_expectations.yml
の管理が大変。これが厳密に行番号とか文字位置を管理しているので、ちょっとしたコード修正でも常に更新する必要が出てしまう。 ref: https://github.com/soutaro/steep/issues/562 また、このファイルを更新しても https://github.com/soutaro/steep-vscode での挙動には変わりがないっぽいのでそこもちょっと厳しい。 vscode が真っ黄色や真っ赤になったままだと精神衛生上良くない。 なので今のところはなるべくsteep_expectations.yml
を空に保つようにした方が良いと思い、止む無く severity-level を error level 以上だけ見るようにしてた。でもまぁ一部だけ無視できると便利だよなぁと、 steep のリポジトリを見に行ったらそれっぽいのが合った。
Steepfile に configure_code_diagnostics を書く。こいつに Hash かブロックを渡すと、検出されたエラーに対する severity-level の扱いをチューニング出来るっぽい。 実際これ使うと、
steep check
の挙動も vscode での検出レベルも変わった⬇️
という事で解消した。あんまぐぐったりドキュメント探しても出てこない感じの機能なのでメモしておく。