Source Mapが実際に記録しているもの
.mapファイルには元のソースコードそのものは入っていません。ほとんどの場合、記録されているのはただ一つ、位置の対応表だけです——「生成後の2行目4110列目はapp.jsの88行目12列目に由来し、そこにあった識別子の名前はtotalだった」というように。マップによっては元ファイルの全文まで埋め込むもの(sourcesContent)もありますが、このフィールドは任意項目であり、jQuery自身のマップを含め、本番環境の多くのマップはこれを含まずに公開されています。
このツールはブラウザ内でその対応表を直接読み取り、ビルドツールの主張を鵜呑みにするのではなく、実際の内容と突き合わせて確認できるようにします。
ここでできること
.mapファイルを読み込む。 そこに列挙されている元のソースパスがすべて即座にツリー表示され、マッピング数も確認できます。- 対応する生成後の
.jsファイルを追加する(任意項目ですが、追加する価値があります)。 これがあると、行・列の検索で照会した位置の周辺の生成コードそのものも表示され、そのコードスニペット内の行をクリックすると行番号欄が自動的に入力されます。 - 任意の生成位置を検索する。 行は1始まり、列は0始まりで、これはsource map仕様そのものの定義であり、Chrome DevToolsをはじめとするあらゆるJSツールが内部的に用いている慣習と同じです。バンドル内のすべてのバイトがマッピングされているわけではありません——ランタイムのつなぎコード、モジュールラッパーの定型コード、トークン間の圧縮出力には、しばしばマッピングが全く存在せず、このツールは推測ではなくその旨をはっきり示します。
- 埋め込まれていれば元のソースを読む。 ツリー内の任意のファイルをクリックすると、埋め込まれた
sourcesContentを表示します。あるソースに埋め込みテキストがない場合——マッピングはあってもテキストがない場合——何も表示すべきものがないふりをする空のパネルではなく、明示的な通知が表示されます。
なぜこれが重要か
Source mapは、bundle.min.js:2:184031を指すエラースタックをsrc/components/Cart.jsx:41を指すものへと変換してくれる仕組みです。この変換がおかしいと感じたとき——意味の通らない行でエラーが報告される、デバッガが間違ったファイルに入ってしまう——マップ自体が壊れているのか、自分の理解が誤っているのかを最も速く見極める方法は、マップに直接尋ねることです。それこそが、このツールの役割です。
プライバシー
両方のファイルはすべてブラウザ内で解析されます。どこにもアップロードされません。
Tiny Online Tools







