ソースマップとは何ですか?

ソースマップは、最新のウェブ開発においてデバッグを可能にする重要なツール 大幅に簡素化されます。このページでは、ソースマップの基本と使い方について説明します。 それらを使用してデバッグ エクスペリエンスを改善する方法について学びます。

ソースマップの必要性

初期のウェブアプリは複雑さが低い状態で構築されていました。デベロッパーは HTML、CSS、 直接ウェブにアップロードできます。

最新の複雑なウェブアプリでは、 開発ワークフローについて説明します。例:

で確認できます。 <ph type="x-smartling-placeholder">
</ph> さまざまなツールの概要。
一般的なウェブアプリ開発ツールの一部。

これらのツールでは、コードを標準 HTML にトランスパイルするビルドプロセスが必要です。 ブラウザが理解できる JavaScript、CSS です。また、一般的な手法で、 などのツールを使用して、これらのファイルを圧縮、結合し、パフォーマンスを最適化します。 Terser

たとえば、ビルドツールを使用して、次のものをトランスパイルして圧縮できます。 TypeScript ファイルを 1 行の JavaScript に変換します。Google Cloud の GitHub のデモをご覧ください。

/* A TypeScript demo: example.ts */

document.querySelector('button')?.addEventListener('click', () => {
  const num: number = Math.floor(Math.random() * 101);
  const greet: string = 'Hello';
  (document.querySelector('p') as HTMLParagraphElement).innerText = `${greet}, you are no. ${num}!`;
  console.log(num);
});

圧縮バージョンは次のようになります。

/* A compressed JavaScript version of the TypeScript demo: example.min.js  */

document.querySelector("button")?.addEventListener("click",(()=>{const e=Math.floor(101*Math.random());document.querySelector("p").innerText=`Hello, you are no. ${e}!`,console.log(e)}));

ただし、コードを圧縮するとデバッグが難しくなることがあります。ソースマップ この問題を解消できます。コンパイル済みのコードを元のコードにマッピングすることで、 エラーの原因を素早く突き止めることができます。

ソースマップを生成する

ソースマップは、名前が .map で終わるファイルです(例: example.min.js.mapstyles.css.map)。ほとんどのビルドで生成できる ツール(VitewebpackRollupParcelesbuild

一部のツールには、デフォルトでソースマップが含まれています。その他のインスタンスでは、 作成する必要があります。

/* Example configuration: vite.config.js */
/* https://vitejs.dev/config/ */

export default defineConfig({
  build: {
    sourcemap: true, // enable production source maps
  },
  css: {
    devSourcemap: true // enable CSS source maps during development
  }
})

ソースマップについて

これらのソースマップ ファイルには、デバッグに役立つ重要な情報が含まれています。 コンパイルされたコードが元のコードにどのようにマッピングされるかについて学習しました。これが ソースマップ:

{
  "mappings": "AAAAA,SAASC,cAAc,WAAWC, ...",
  "sources": ["src/script.ts"],
  "sourcesContent": ["document.querySelector('button')..."],
  "names": ["document","querySelector", ...],
  "version": 3,
  "file": "example.min.js.map"
}

これらの各フィールドについては、 ソースマップの仕様または ソースマップの構造

ソースマップで最も重要な部分は、mappings フィールドです。使用される VLQ Base 64 でエンコードされた文字列 : コンパイル済みファイル内の行や場所を、対応する元の行、 表示されます。このマッピングは、次のようなソースマップ ビジュアライザを使用して表示できます。 source-map-visualization または ソースマップの可視化

<ph type="x-smartling-placeholder">
</ph> ソースマップのビジュアリゼーション。 <ph type="x-smartling-placeholder">
</ph> ビジュアライザで生成された、前のコードサンプルの可視化。

左側の [generated] 列には圧縮されたコンテンツが表示され、 original 列に元のソースが表示されます。

ビジュアライザは、元の列の各行を、 対応するコードを generated 列に配置します。

[mappings] セクションには、コードのデコードされたマッピングが表示されます。たとえば、 エントリ 65 -> 2:2 の意味:

  • 生成されたコード: 単語 const は、圧縮されたコンテンツの 65 番目から始まります。
  • 元のコード: const という単語は、元のコンテンツの行 2 と列 2 で始まります。
で確認できます。 <ph type="x-smartling-placeholder">
</ph> マッピング エントリ。
65 -> 2:2 エントリに焦点を当てたマッピングの可視化。

これにより、開発者は圧縮されたコード間の関係をすばやく特定できます。 デバッグ プロセスがスムーズになります。

ブラウザ デベロッパー ツールは、これらのソースマップを適用して、 ブラウザで問題を迅速にデバッグできます

<ph type="x-smartling-placeholder">
</ph> ソースマップを適用するデベロッパー ツール。
ブラウザ デベロッパー ツールの適用例 ファイル間のマッピングが示されています。

ソースマップ拡張機能

ソースマップは、x_ 接頭辞で始まるカスタム拡張フィールドをサポートしています。1 本 例: Chrome が提案する x_google_ignoreList 拡張フィールド DevTools。x_google_ignoreList を参照 をご覧ください。

ソースマップの欠点

残念ながら、ソース マッピングは必ずしも必要とするほど完全ではありません。 最初の例では、ビルド中に変数 greet が最適化されました。 その値は最終的な文字列出力に直接埋め込まれています。

<ph type="x-smartling-placeholder">
</ph> 変数の greet がマッピングされていません。
元の変数の greet 変数は、 マッピングにコードがありません。

この場合、コードをデバッグする際に、デベロッパー ツールが 実際の値を推測して表示します。このようなエラーにより、コードが モニタリングと分析が困難になります

<ph type="x-smartling-placeholder">
</ph> 変数 greet が定義されていません。
デベロッパー ツールで greet の値が見つかりません。

これは、ソースマップの設計内で解決する必要がある問題です。1 本 考えられる解決策は、API のソースマップにスコープ情報を 他のプログラミング言語で行われるデバッグ情報と同じです。

しかしこれにはエコシステム全体が協力して ソースマップの仕様と実装。このコースの ソースマップでデバッグ可能性を改善する方法については、 ソースマップ v4 ご覧ください。