Files, Binary & Compression
.mapファイル（またはインラインmap付きのJS）を貼り付け、行:列かスタックトレースを入力すると、元のファイル・行番号・コードが表示されます。
このタブ内で解析します。リモートのソースや外部のsourceMappingURLは取得しません。
入力が変わりました。自動で解析します…
本番のエラー監視に「app.3f2a.js:1:20931」とだけ出ている。圧縮されたバンドルの1行目、2万列目です。一緒にビルドされた.mapファイルには、それが元のどの.tsや.vueの何行目かが書かれていますが、mappingsはBase64 VLQで符号化されていて目では読めません。このソースマップ解析ツールがデコードと検索を代わりに行うので、エラー1件のためにsource-mapライブラリを入れたスクリプトを書く必要はありません。
エラー監視にソースマップをアップロードしていないとき、CIの成果物しか手元にないとき、あるいはmapが本番のバンドルと同じビルドのものか確認したいときに使えます。ファイル自体の確認にも向いています。sourcesに何が並び、どれがsourcesContentを持ち、どれがignoreListに入っていて、mappingsが壊れていないか。サーバーにmapを送って解析するサービスと違い、何もアップロードせず、リモートのURLにも一切アクセスしません。
知りたいのは「元のコードの何行目か」。スタックトレース全体をまとめて調べ、結果が近似のときはそう表示します。
:行:列で終わる行はすべてmapで検索され、元のファイル・行番号・列番号・元の変数名と前後数行のコードが表示されます。mapのfileと違うファイルのフレームには警告が付くので、vendorバンドルのフレームをアプリのmapで誤って解決することはありません。
「ソース」ビューはsourcesの各エントリーをsourceRoot適用後のパスで一覧し、sourcesContentの有無とignoreListかどうかを示し、行番号付きでコードを表示します。1ファイルずつ保存するほか、埋め込まれた全ソースをフォルダ構成のままzipで保存でき、sourcesContent復元の手段になります。
.mapのJSONを貼る、「.mapファイルを開く」かドロップする、あるいはビルド後のJS/CSSファイルそのものを貼っても構いません。末尾に//# sourceMappingURL=data:…があれば、インラインmapを取り出してデコードします（Base64とURLエンコードの両方に対応）。通常のURLを指している場合はURLを表示するだけで取得しないので、その.mapファイルを直接開いてください。
位置は12:345、「12 345」、またはat n (https://example.com/app.js:1:177)のようなフレームそのままでも入力できます。Chrome・Firefox・Nodeのスタックトレースに合わせ、列番号は既定で1から数えます。mozilla/source-mapの結果など0始まりの列番号を使うときは「列番号を1から数える」をオフにしてください。そうしないと結果が1文字ずれます。
「完全一致」はその列からセグメントが始まっていることを意味します。そうでなければ左側で最も近いセグメントを使い、その旨を表示します。これはブラウザやsource-mapライブラリの既定と同じ規則です。「ソースで表示」を押すと元の行に移動し、元の行番号欄がその行に対応する生成位置をすべて逆引きします。
「マッピング」ビューはVLQ文字列を「生成行:列 → ソース・元の行:列・名前」の行に分解して100件ずつ表示し、全件をTSVで書き出せます。表計算ソフトやdiffでの比較に使えます。
ソースと元の行番号を選ぶと、そこを指す生成位置を一覧します。ある行がインライン化されたのか、複製されたのか、ミニファイで消えたのかを確かめられます。
インラインのdata: URL、sectionsとoffsetを持つインデックスマップ、sourceRootの連結、ignoreListと旧来のx_google_ignoreListに対応し、フレームワークのコードと自分のコードを見分けられます。
JSONの構文エラーは行と列で、不正なVLQ文字、フィールド数の合わないセグメント、範囲外のsourceやnameのインデックスは、生成コードの何行目の何番目のセグメントかで報告します。
mapにsourcesContentが含まれていれば復元できます。このフィールドには各ソースファイルの全文が入っています。「ソース」ビューで1ファイルずつ表示・保存するか、全ファイルをフォルダ構成のままzipで保存してください。sourcesContentがないmapにはパスと位置しかなく、コードは復元できません。
そのエントリーのコードはmapに含まれていないため、このツールでは「ソースなし」と表示されます。行番号と列番号、ファイルパスはmappingsとsourcesから分かるので、リポジトリの同じコミットを開いてその位置を確認するのが確実です。ビルド設定でsourcesContentを有効にすれば次回から埋め込まれます。
なります。位置欄に行:列かスタックトレースを貼ると、source-mapライブラリのoriginalPositionForと同じく左側で最も近いセグメントから元の位置を求めます。違いは列番号の数え方で、originalPositionForは0始まり、このツールは既定でスタックトレースと同じ1始まりです。
mappingsはセミコロンで生成コードの行を、カンマでセグメントを区切り、各セグメントは1・4・5個の値をBase64 VLQで符号化したものです。値は前のセグメントからの差分です。「マッピング」ビューでこれを行:列の対応表に展開したソースマップ解析の結果を確認できます。
見られます。公開されたmapにsourcesContentがあれば、誰でも元のコードとコメントを読めます。そのため多くのチームはmapをエラー監視サービスにだけアップロードするか、認証付きの場所に置いています。ここでの確認はすべてブラウザ内で完結し、貼り付けた内容は外部に送信されません。
解決しませんでしたか？
直近のビルドの.mapファイルをドロップし、バグ報告のスタックトレースを貼れば、元のコードの何行目かがすぐに分かります。ソースマップ解析はすべてブラウザ内で行われます。
処理はすべてブラウザ内のローカルで完結します。