トランスパイル結果に一切の影響を及ぼさず、TypeScriptのチェックレイヤを通過するだけのものでした。ように表面上でだけエラーを隠すわけではないため、ランタイムエラーを引き起こすような心配はありません。提供有無」の優先順位で選ぶアプリケーションを開発する上でライブラリの選定は重要な要素の1つで、似たようなライブラリの中からどのライブラリを選定するかは、個人の些細な差はあれど、その多くはGitHubリポジトリのスター数やnpmのダウンロード数、コミュニティの活発度、ドキュメントの豊富さなどが共通することでしょう。スター数などの他の指標が似たりよったりするライブラリが複数ある場合、僕は以下のような優先度で最終的にライブラリを選定します。型定義が提供されているライブラリか?「どれも型定義が提供されているのならば問題ないのでは」と思う人もいるかもしれませんが、ライブラリ本体がTypeScriptで記述されていないということは、本体の型と型定義ファイルの型に乖離が存在する可能性が高くなります。よって自動的に生成されたものが多く、最も信頼性の高い型定義ファイルを提供してくれます。Assertionsを多用していなければ、型定義と実際のAPIに乖離が生まれることはほとんどありません。型定義ファイルがリポジトリに同梱されているライブラリか?本体がJavaScriptで記述されていても、型定義ファイルがリポジトリに同梱されている場合、新バージョンリリース時に型定義ファイルも一緒に更新される可能性が高くなります。ミスとして型定義と実際のAPIに乖離が生まれることがあっても、「型定義が実際のAPIに追いついていない」という可能性は低くなります。よる型定義が提供されているライブラリの場合、型定義ファイルとライブラリ本体は別々のリポジトリに存在するため、基本的に型定義ファイルの更新が本体よりも遅れます。したがって最新のライブラリを利用する際に、型定義ファイルだけ古いAPIで記述されている......なんてこともあり得ます。独立した1つのパッケージとして提供されているため、ライブラリ本体のバージョンと一致しないことがほとんどです。かけ離れた場合もよくあり、本体のバージョンに対応した型定義ファイルのバージョンが何かを把握しなければいけません。型定義ファイルの利用も本来ならば避けておきたいところです。APIの型定義を参照できてしまう事態になっていました。よる型チェックではエラーが一切発生しないのに、ランタイムではエラーが発生してしまうという悲しい事件です。2つの値が存在します。この2つの値をどう使い分けるか、そもそも使い分けずにどちらかの値で統一するか、はプロジェクトによって方針が異なり、大手企業やライブラリの中でも揺れています。両者の大きな違いは、以下が挙げられると思います。統一派と使い分ける派の2つに別れますが、やはりどちらもメリット・デメリットが存在します。使い分けることが多いです。型を提供していません。この理由がまさに上述したとおりで、プロジェクトによって方針が異なるからです5。利用しなければならない”と記述されています6。このスタイルガイドはTypeScriptという言語を開発する際においてのガイドであり、TypeScript利用者へそれを強制/推奨するものでもありません。この点を勘違いしてIssueをたてる人が多かったせいか、TypeScript開発チームはブチギレて、当該ドキュメントのページ最上部には、恐ろしい数の注意文言が記載されています。Wiki「注意文言なし→1行だけ注意文言が記載される→画像のように大量の注意文言が記載される」という変遷を見てきた僕からすると、ちょっとした恐怖を感じます。利用を明確に分けています。返さなければいけません。オブジェクト型のプロパティや関数の引数に対して利用できるものです。