オブジェクトの型をそのオブジェクトが持つメソッドやプロパティの集まりによって決定する方式。「もしそれがカモのように歩き、カモのように鳴くなら、それはカモである」という古い格言に由来する。つまり、オブジェクトが特定のインターフェースや契約を満たすメソッドやプロパティを持っていれば、そのオブジェクトの具体的な型に関係なく、特定の型として扱うことができる。

この概念は、特に動的型付け言語やいくつかの静的型付け言語において、柔軟で直感的なコーディングスタイルを可能にする。

TypeScriptの文脈では、ダックタイピングは構造的型付けの一形態として現れる。
TypeScriptでは、型はその構造（つまり、持っているメンバー）によって決定される。例えば、ある関数が特定のプロパティを持つオブジェクトを引数に取る場合、そのプロパティを持つ任意のオブジェクトをその関数に渡すことができる。これにより、TypeScriptはJavaScriptの柔軟性を保ちつつ、型安全性を提供する。

いくつかのプログラミング言語では、静的型付けが「名目的（nominally typed）」。これは、型がコードの構造ではなく名前に基づいていることを意味する。その結果、コードが問題なく動作することが分かっていても、言語のルールに従って、不必要にコードをコピーしたり、調整したりする必要がある。
（例えば、C#においては、異なる型間でのデータの移動を自動化する「AutoMapper」のようなツールが重要になる。）

しかし、TypeScriptでは「構造的（structural）」型付けが採用されている。これは、オブジェクトが期待されるプロパティ（この場合はxとy）を持っていれば、そのオブジェクトの具体的な型は問われない、というもの。これを「ダックタイピング」と呼ぶ。
例えば、iTakePoint2Dという関数がある場合、この関数はxとyプロパティを持つ任意のオブジェクトを受け入れることができる。

具体的な例として、Point2Dインターフェースと完全に一致するオブジェクト（point2D）、Point2Dの条件を満たしつつ追加のプロパティ（z）を持つオブジェクト（point3D）を受け入れることができる。しかし、必要なプロパティ（この場合はy）が足りないオブジェクトを渡すと、エラーが起きる。

interface Point2D {
    x: number;
    y: number;
}
interface Point3D {
    x: number;
    y: number;
    z: number;
}
var point2D: Point2D = { x: 0, y: 10 }
var point3D: Point3D = { x: 0, y: 10, z: 20 }
function iTakePoint2D(point: Point2D) { /* do something */ }

iTakePoint2D(point2D); // exact match okay
iTakePoint2D(point3D); // extra information okay
iTakePoint2D({ x: 0 }); // Error: missing information `y`

TypeScriptがどのようにして既存のJavaScriptコードやライブラリと連携できるように設計されているかを説明する。このアプローチにより、TypeScriptはJavaScriptのエコシステムの豊富なリソースを活用しつつ、型の安全性と開発者の生産性を向上させることができる。

アンビエント型とは、TypeScriptでの宣言の概念を指し、既存のJavaScriptコードやライブラリがTypeScriptの型システム内でどのように動作するかを定義するものである。これにより、TypeScriptを使用している開発者は、任意のJavaScriptライブラリをTypeScriptの型チェックの恩恵を受けながら使用できる。

ここでの「アンビエント」という用語は、周囲の環境やコンテキストを指す言葉で、この文脈では既存のJavaScriptコードやライブラリをTypeScriptのコード内で「周囲の環境」として取り込み、それらをTypeScriptの型システムで認識できるようにすることを意味している。
宣言ファイル（通常.d.tsファイルとして拡張子がつけられる）を通じて、TypeScriptは既存のJavaScriptライブラリのAPIを型情報として認識できるようになる。これにより、開発者はライブラリを使いながらも、TypeScriptの型安全性とコード補完などの利点を享受できる。

たとえば、jQueryのようなJavaScriptライブラリをTypeScriptプロジェクトで使いたい場合、declare var $: any;のように記述することで、$変数が任意の型を持つと宣言できる。より詳細な型定義を提供することで、$(selector: string): any;のように特定のAPI呼び出しに対して型安全性を向上させることが可能になる。

TypeScriptが現在のJavaScriptエンジンで将来のECMAScriptのバージョン（具体的にはES6やそれ以降）で計画されている機能を利用可能にするという概念。
つまり、TypeScriptを使用することで、現行のJavaScriptエンジンが直接サポートしていない最新のJavaScriptの機能やシンタックスをコードに組み込むことができ、それらのコードはTypeScriptコンパイラによって現行のJavaScriptエンジンでも動作するようにトランスパイル（変換）されるということ。

ES6（ECMAScript 2015とも呼ばれる）は、JavaScriptの言語仕様の一つであり、クラス、モジュール、アロー関数、プロミスなど多くの新機能を導入した。
しかし、すべてのブラウザやJavaScript環境がこれらの新機能をサポートしているわけではない。
TypeScriptを使用すると、これらの新しい機能を使って開発を行いながらも、より広範な互換性を持つJavaScriptにコンパイルすることができるので、開発者は新しいシンタックスや機能を安心して利用することができる。

例えば、TypeScriptではES6のクラスやアロー関数などの構文を使用してコーディングすることができ、TypeScriptコンパイラはそれを現行のJavaScript環境でも動作するコードに変換する。
このようにして、TypeScriptは未来のJavaScriptの機能を「今」、つまり現在の開発環境で利用できるように橋渡しをしている。

はい、ポリモーフィックthisの型について説明します。

一般的に、JavaScriptのthisは実行時の値が決まり、その値はクラスのインスタンスである場合とそうでない場合があります。TypeScriptではこの両方の場合に対応するため、ポリモーフィックthisという特別な型が用意されています。

ポリモーフィックthisの型は、メソッドの中でthisを使用する際に、thisの型がそのメソッドが属するクラスの型になるよう保証する機能です。つまり、クラスのサブクラスでもthisの型が正しくなります。

例えば、以下のようなコードを考えてみましょう:

class BasicCircle {
  radius = 1;

  scale(factor: number) {
    this.radius *= factor; // thisの型はBasicCircleのインスタンス
  }
}

let c = new BasicCircle();
c.scale(2); // radius は 2

ここではscaleメソッドの中で、thisの型がBasicCircleのインスタンスとして扱われています。

さらに、サブクラスを作った場合でも適切にthisの型が決まります:

class Circle extends BasicCircle {
  area() {
    return Math.PI * this.radius ** 2; // thisの型はCircleのインスタンス
  }
}

let c = new Circle();
c.scale(2); // radius は 2
console.log(c.area()); // 12.566...

Circleクラスのareaメソッドにおいて、thisの型がCircleのインスタンスと推論されています。

このポリモーフィックthisの仕組みにより、サブクラスでもthisが適切に処理され、安全でDRYなコードを書くことができます。メソッドチェーンのように、this経由でメソッドを連鎖させる場合に特に役立ちます。

TypeScriptがDOM要素のような場合に自動的に正確な型を推論できない主な理由は、実行時の状況に依存するからです。TypeScriptは静的型付け言語であり、コンパイル時に型の検査を行います。しかし、DOM要素に関しては、その型が実行時によって変わる可能性があり、HTMLの構造やJavaScriptによる動的な変更によって、異なる型の要素が同じIDやクラス名で参照されることがあります。

例えば、document.getElementByIdやdocument.querySelectorのようなメソッドは、特定のIDやセレクタにマッチするDOM要素を返しますが、その要素が具体的にどのような型（HTMLDivElement、HTMLButtonElementなど）かは、HTMLのマークアップに依存します。TypeScriptはこのHTMLマークアップを解析しないため、これらのメソッドから返される要素の具体的な型を推論することができません。

<button id="myButton">Click me</button>

const button = document.getElementById('myButton');

上記のコードでは、button変数がHTMLButtonElement型であることは明らかですが、TypeScriptはgetElementByIdがHTMLElement型を返すことしか知りません。そのため、HTMLButtonElementに固有のプロパティやメソッド（例えばdisabledプロパティ）を使用する場合、開発者は型アサーションを使用してTypeScriptに型情報を「教える」必要があります。

const button = document.getElementById('myButton') as HTMLButtonElement;
button.disabled = true; // 型アサーションにより、`disabled` プロパティの使用が可能に

このように、DOM操作では実行時の状況に依存するため、TypeScriptが自動で正確な型を推論することは困難です。その結果、型安全性を確保するために型アサーションが必要になるケースがあります。

共変性(Covariance)

ある型が別の型のサブタイプである場合、その型のコンテナや関数の戻り値も同様にサブタイプ関係を保持すること。

例えば、DogがAnimalのサブタイプである場合、Dog[]はAnimal[]のサブタイプになる。
この性質は、型の代入が「同じ方向」で行われることを示す。

class Animal {
    name: string
    constructor(name: string) {
        this.name = name
    }
}

class Dog extends Animal {
    breed: string
    constructor(name: string, breed: string) {
        super(name)
        this.breed = breed
    }
}

let animals: Animal[] = []
let dogs: Dog[] = []

// Covariance allows assigning subtype (Dog) array to supertype (Animal) array
animals = dogs
dogs = animals // Invalid: Type 'Animal[]' is not assignable to type 'Dog[]'

反変性(Contravariance)

ある型の関数の引数が別の型のサブタイプである場合に、その関数自体が逆のサブタイプ関係を持つこと。

例えば、Animalを引数に取る関数があるとき、Dogを引数に取る関数はAnimalを引数に取る関数のサブタイプになる。（→Animal型の引数受け取ってもDog型のプロパティbreedは存在しないですもんね）
これは、関数の引数に関しては「逆方向」のサブタイプ関係が成立することを意味する。

type Feed<in T> = (animal: T) => void

let feedAnimal: Feed<Animal> = (animal: Animal) => {
    console.log(`Animal name: ${animal.name}`)
};

let feedDog: Feed<Dog> = (dog: Dog) => {
    console.log(`Dog name: ${dog.name}, Breed: ${dog.breed}`)
}

// Contravariance allows assigning supertype (Animal) callback to subtype (Dog) callback
feedDog = feedAnimal
feedAnimal = feedDog // Invalid: Type 'Feed<Dog>' is not assignable to type 'Feed<Animal>'