onlinetools.dev

JSON → TypeScript型

JSON サンプルから TypeScript インターフェースを即座に推論

ローカル実行
loading…
このツールについて

JSON のサンプル — API レスポンスや設定ファイル — を貼り付けると、そこから推論された TypeScript インターフェースが得られます。ネストしたオブジェクトはネストした型になり、配列には要素型が付き(内容が混在するならユニオン型で)、有効な識別子でないキーは正しくクォートされます。

生成された型は出発点であって契約ではありません。推論が見るのは 1 つのサンプルだけなので、サンプルでたまたま null だったフィールドは null と型付けされ、欠けていたオプショナルなフィールドは推論には知りようがありません。出力は意図的にプレーンです — デコレーターも実行時バリデーションもなし — なので、どこにでも貼り付けて磨き上げられます。

リクエストごとに変わるフィールドには、2 つ目のサンプルを通して手でマージするか、形が安定したらスキーマファーストのツール(OpenAPI、zod)に卒業してください。日常の「このレスポンスの型がとにかく欲しい」という瞬間には、1 回の貼り付けで十分です。

よくある質問

なぜ nullable なフィールドが単なる null と型付けされるのですか?
推論はあなたが貼り付けたサンプルしか見ません。そこでフィールドが null なら、null しか知りようがないのです。生成後に string | null(あるいは本当の型)に変更するか、フィールドに値が入ったサンプルを貼り付けてください。
オプショナルなフィールドはどう扱われますか?
検出されません — 1 つのサンプルでは「常に存在する」と「今回はたまたま存在した」を区別できません。サンプルに欠けているフィールドは型からも欠けます。API が省略すると分かっているフィールドは、手動でオプショナル(name?:)としてマークしてください。
型が混在した配列は何を生成しますか?
ユニオンです。[1, "a"] は (number | string)[] と推論されます。空の配列は調べる要素がないため unknown[] と推論されます — 本当の要素型が分かったら置き換えてください。
推論した型と zod のようなスキーマライブラリ、どちらを使うべきですか?
推論されたインターフェースはコンパイル時だけのものです — 実行時には何も検証しません。社内ツールやさっと型を付ける用途には最適です。実行時の信頼できない入力には、zod/valibot のスキーマを定義し、そこから静的型を導出してください。
関連ツール