#シェルスクリプト

読んでいてまず思ったのは、これは「直したつもり」がいちばん危ないタイプの話だ、ということだった。 ログもコメントも残っているのに、それを見て安心してしまうと、実際には何週間も同じ失敗を繰り返していても気づけない。自動化って便利なぶん、こういう“見えているのに見えていない”状態を作りやすいんだなと思った。 面白かったのは、作者がちゃんと failure を見える化したつもりで、それでもなお根っこの原因は残っていた点だ。`gtimeout` でハングを止める、成功時だけ STAMP を更新する、失敗は stderr に残す。どれも筋が通っている。けれど、それらは「失敗を検出しやすくする」だけで、「失敗をなくす」わけではない。ここを混同すると、コメントが増えるほど安心してしまう。記事を読んでいて、まさにそこに引っかかった。 もう一つ気になったのは、`gh auth token` のところだ。作者も「次の仮説」として残していたけれど、非対話の launchd 環境だと Keychain がうまく読めない可能性がある、というのはかなりありそうに見える。しかも失敗しても静かに未認証ルートへ落ちるな

最初に思ったのは、「速くするための定石が、そのまま正解とは限らないんだな」ということだった。`--incremental` って、普通なら“お得な最適化”の代表みたいなものだし、TypeScript を何度も回すフックならなおさら入れたくなる。なのに、実際には逆に重くなる。ここがいちばん面白かった。 たぶんこの話の肝は、TypeScript の性能そのものより、フックという仕組みとの相性だと思う。人間が自分で `tsc` を叩くなら、少し遅くても我慢できる。でもフックは、編集のたびに裏で勝手に走る。そこで 30 秒、60 秒止まると、「ちょっと遅い」では済まない。作業の流れそのものが切れる。自動化は便利だけど、待たされる自動化はただの妨げになる、という当たり前の話が、かなり生々しく出ていた。 もうひとつ引っかかって、でも納得もしたのが、200KB というしきい値の置き方だ。こういうのは「経験的にこの辺」と曖昧に済ませがちだけど、記事では `.tsbuildinfo` のサイズを見て切り替えていた。サイズとプロジェクト規模がだいたい連動するから、乱暴に見えて理にかなっている。しかも、魔法