回答。

問題の歴史

TypeScriptは元々JavaScriptからのスムーズな移行を可能にするように設計されていたため、デフォルトで明示的な型が指定されていない変数やパラメータに対してはany型が与えられました。これによりマイグレーションが簡単になりましたが、静的型付けの利点が損なわれました。信頼性と予測可能性を高めるために、TypeScriptチームはnoImplicitAnyというコンパイラフラグを導入しました。これにより、明示的に型を指定するか、TypeScriptに適切に型を推論する機能を持たせることが求められます。

問題

noImplicitAnyが無効になっている場合、開発者は変数、パラメータ、または関数の戻り値の型を明示的に指定することを見落とす可能性があります。これにより、コードの安全性が低下し、リファクタリングが困難になります。型に関連するエラーはコンパイル時に検出されず、実行時にのみ発生します。

解決策

tsconfig.jsonファイルでnoImplicitAnyを有効にすると、TypeScriptコンパイラは暗黙的なanyの使用があるたびにエラーをスローします。これにより、開発者は型に注意を払う必要があり、リファクタリングプロセスはリスクが少なくなり、コード自体もより信頼できるものになります。

コードの例：

// tsconfig.json
{
  "compilerOptions": {
    "noImplicitAny": true
  }
}

// パラメータの型を指定していない関数の例
function printUser(user) {
  console.log(user.name); // 型が指定されていない場合、コンパイルエラー
}

// 正しく：
function printUser(user: { name: string }) {
  console.log(user.name);
}

主な特徴：

曖昧な場所で型を明示的に指定することを要求します。
コンパイル時に多くの型エラーを発見することを可能にします。
大規模なプロジェクトでのコードの予測可能性と安全性を高めます。

腹の探り質問。

noImplicitAnyを有効にすることで、プロジェクト内のすべての潜在的な型エラーを防ぐことができますか？

いいえ、このフラグは暗黙的なanyを排除するだけです。明示的なanyの使用は依然として許可されています。完全な保護を望む場合は、lintingとレビューを通じて明示的なanyも制限する必要があります。

型が自動的に推論される場合、noImplicitAnyはそれでも警告しますか？

いいえ、TypeScriptが型を正しく推論できた場合（例えば、初期化に基づいて）、エラーは発生しません。例えば：

let n = 123; // 型はnumber、anyではない

strictを有効にすると、自動的にnoImplicitAnyも有効になりますか？

はい、strictフラグは多くの厳格なチェックを有効にし、その中にはnoImplicitAnyも含まれます。ただし、必要に応じて手動で無効にすることもできます。

典型的なエラーとアンチパターン

多くの場所に明示的なanyを残すこと — 厳密な型付けの意味が失われます。
大規模なコードでnoImplicitAnyを無効にして「まあいいや」と考えること — 多くの隠れたエラーがあります。
型を「とりあえずコンパイルできるように」追加し、正確さを考慮しないこと。

実生活の例

ネガティブケース

プロジェクトでnoImplicitAnyが無効になっているため、大多数のAPIハンドラーは明示的な型なしでパラメータを受け取ります。新しいビジネスロジックを導入する際に、開発者はプロパティ名で間違うことが多く、そのエラーは本番環境でのみ発覚します。

利点：

コードの簡単で迅速なスタート。
JavaScriptからの移行が容易。

欠点：

本番環境で静的に発見できたエラーが発生します。
リファクタリングとスケーリングが難しくなります。

ポジティブケース

noImplicitAnyを有効にした後、コード全体が徐々にリファクタリングされ、暗黙のanyは排除されました。型のハイライトと自動補完を備えたエディタを使用し始めました。新たに発生するエラーはビルド時にすぐに修正されます。