Nuxt + TypeScript 構成のプロジェクトに関わることがあり、主にバグ中心のリファクタリング・構造化を実施した際
Any が許容されていたり、何故か型が使用されていないモジュールがあり大変でした。

そのため、できるだけ TypeScript の使用を強制したいとき、どれくらいの手段が必要かをまとめました。

具体的な方針の検討

最初から TypeScript のプロジェクトとして始める場合

eslint のルールを TypeScript 用に変更する

eslint のルールについてはマネージャー層が決めてしまっている可能性が高いのでその場合は難しいけど、
自分がその立場になったり、意見を通せる場合は TypeScript が導入されていない.vue モジュールについては
ビルド不可になるよう lint で弾いてあげるルールを追加することでビルド前に気付けるようにします。

参考：TypeScript のプロジェクトで ESLint+Prettier を活用する

bulld 用の module を TypeScript のみに設定(nuxt.config.js)

nuxt.config.js の設定でビルドするバージョン・言語を指定できるため、TypeScript 用のビルドツールを通してしかビルドできないようにします。
ただ型定義がない場合そのままビルドされてしまうと思われるので、lint でビルド前に弾いてしまうのが一番現実的だと思います。

プロジェクトの途中から TypeScript に移行した場合

技術負債としてチケットを切る

途中から TypeScript を導入した場合、以前に作成したモジュールについては当然動的型になっており型推論・チェックが効きません。
ここについては素直にチケットとして切り、別作業と同時に行うことがないようにしたほうが良いです。 動的型付け志向の実装になっていると治すだけで意外と詰まるところも出てくると思うので、並行作業となった場合に無駄な時間を食ったりバグの原因となる可能性が出てきます。
単体でビルド・テストがきちんと通るよう集中して作業するようにしたいです

調査ツールを作って定期的に回す

lint に追加してしまうと膨大な警告が毎回表示される様になってしまうので、実行した際に型が実装されているかを
モジュールごとに判断して一覧として出力するような CLI ツールなりを作成し使用するようにします。
自分でも作ってみたいけどまだ Nuxt+TS の開発をいくつも経験したというわけではないので、
経験しつつプロジェクトごとの差異が吸収できるようなものを作って npm で取れるようにしたい。

共通

レビューで TS になっているかちゃんと見る

一番労力が少ない方法としてはレビュー時に型がきちんと使用されているかを確認することをルール化し、使われていない場合指摘をしてあげることで
TypeScript が使えていないメンバーへのキャッチアップも可能になり全体として型使用を強制することが可能となります。

マイナスポイントとして完成してしまっている型が導入されていないモジュールにあたった際、型導入により書き方をかなり変える必要があったり、
別の手段で実装する必要がある場合、リファクタリングに多くの時間を使ってしまう可能性があります。

正直この状態になっている時点でオペレーションがあまり良くないので、バグ対応からの派生作業であるときは別作業としてチケットを切る、
もしくは JavaScript のファイルとして許容してしまうしかないのかなと思います。

まとめ

・極力 TypeScript はプロジェクトの走り段階で追加し、esLint の設定はきちんと書く
・自分がレビューするときは最低限型が正常に設定されているかを見る
・バグを避けることと正常な修正期間を担保するため、タスクとしてチケットを切るようにする