kachick / times_kachick

`#times_kachick channel in chat` as a public repository. Personal Note and TODOs
https://github.com/kachick/times_kachick/issues?q=is%3Aissue+is%3Aclosed
6 stars 0 forks source link

2022-06-23 - steep(rbs) の severity をエラー種別毎に変える #169

Closed kachick closed 2 years ago

kachick commented 2 years ago

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 での検出レベルも変わった

before-info

⬇️

after-info

という事で解消した。あんまぐぐったりドキュメント探しても出てこない感じの機能なのでメモしておく。

kachick commented 4 months ago

steep_expectations.yml の管理が大変。これが厳密に行番号とか文字位置を管理しているので、ちょっとしたコード修正でも常に更新する必要が出てしまう。

# steep:ignore なる annotation をかけるようになるらしい

https://www.timedia.co.jp/tech/20240502-tech/

ruby code 側への侵食にOKが出たんだなぁ

kachick commented 4 months ago

ruby code 側への侵食にOKが出たんだなぁ

https://github.com/soutaro/rbs-inline