ビルドが「Unexpected token in JSON at position 4,821」というエラーで失敗します。ご丁寧にどうも。さあ、4000文字の設定ファイルをスクロールしながら、頭の中で括弧を数えて、どれが不一致なのかを突き止める作業の始まりです。これはソフトウェア開発で最も避けられる時間の浪費の1つであり、JSONが小さなミスに対して一切の寛容さを持たないため、常に起こり続けます。
配列の最後の要素の後の末尾のカンマ。キーを囲むクォートの欠落。どこかからコピーしてきた余分な閉じ括弧。これらのどれもが解析を完全に壊してしまい、エラーメッセージが実際の問題を指し示すことはほとんどありません——パーサーが諦めた場所を指しており、それは本当の間違いから数行離れていることがよくあります。
位置番号が役に立たない理由
ほとんどのJSONパーサーは、エディタでジャンプできる行と列ではなく、文字オフセットとしてエラーを報告します。位置4,821を「3番目のオブジェクトのあたり、112行目」に変換するには、手動で数えるか、使い捨てのスクリプトを書く必要があります。どちらもあなたの午後を有効に使う方法とは言えません。
一部のエディタはJSONの構文エラーをインラインでハイライトしてくれますが、これは今まさに書いているファイルには役立ちます。しかし、APIや同僚、あるいは受け継いだレガシーな設定から受け取ったJSONについては、生のテキストを受け取って、何が、どこで間違っているのかを正確に教えてくれるツールが必要です。
Macを離れずにJSONを検証
検証も行うJSONフォーマッターがあれば、当て推量が不要になります。JSONを貼り付けて、不正な形式であれば、生のバイトオフセットではなく、具体的な行と文字を指し示す明確なエラーが表示されます。有効であれば、適切なインデントできれいにレンダリングされ、構造を視覚的に確認できます。Bellowsは同じツールでこの両方のケースを処理します——JSONが壊れているかどうかを事前に知っている必要はありません。
出荷前にミスを発見する
設定ファイル、APIリクエストボディ、フィクスチャデータはすべて、有効なJSONによって成り立っています。設定変更をコミットしたり、テストリクエストを送信したりする前に素早く検証を行うことで、そうでなければパイプラインのずっと後の段階で紛らわしいランタイムエラーとして表面化するようなタイプミスを捕まえられます。
信頼できない入力を扱う
同僚がSlackでJSONの塊を貼り付けてきたとき、あるいは完全には信頼していないサードパーティAPIから取得したとき、それをローカルで検証すれば、解析できるかどうかを確認するためだけに外部のウェブサイトにデータを送信する必要が一切なくなります。