ソースマップは、最新のウェブ開発においてデバッグを可能にする重要なツール 大幅に簡素化されます。このページでは、ソースマップの基本と使い方について説明します。 それらを使用してデバッグ エクスペリエンスを改善する方法について学びます。
ソースマップの必要性
初期のウェブアプリは複雑さが低い状態で構築されていました。デベロッパーは HTML、CSS、 直接ウェブにアップロードできます。
最新の複雑なウェブアプリでは、 開発ワークフローについて説明します。例:
- テンプレート言語と HTML プリプロセッサ: Pug、 Nunjucks マークダウン。
- CSS プリプロセッサ: SCSS LESS、PostCSS。
- JavaScript フレームワーク: Angular、React、 Vue、Svelte。
- JavaScript メタ フレームワーク: Next.js Nuxt、Astro。
- 高水準プログラミング言語: TypeScript Dart CoffeeScript。
これらのツールでは、コードを標準 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.map
、styles.css.map
)。ほとんどのビルドで生成できる
ツール(Vite、webpack、
Rollup、Parcel、
esbuild。
一部のツールには、デフォルトでソースマップが含まれています。その他のインスタンスでは、 作成する必要があります。
/* 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 または
ソースマップの可視化。
左側の [generated] 列には圧縮されたコンテンツが表示され、 original 列に元のソースが表示されます。
ビジュアライザは、元の列の各行を、 対応するコードを generated 列に配置します。
[mappings] セクションには、コードのデコードされたマッピングが表示されます。たとえば、
エントリ 65 -> 2:2
の意味:
- 生成されたコード: 単語
const
は、圧縮されたコンテンツの 65 番目から始まります。 - 元のコード:
const
という単語は、元のコンテンツの行 2 と列 2 で始まります。
これにより、開発者は圧縮されたコード間の関係をすばやく特定できます。 デバッグ プロセスがスムーズになります。
ブラウザ デベロッパー ツールは、これらのソースマップを適用して、 ブラウザで問題を迅速にデバッグできます
<ph type="x-smartling-placeholder">ソースマップ拡張機能
ソースマップは、x_
接頭辞で始まるカスタム拡張フィールドをサポートしています。1 本
例: Chrome が提案する x_google_ignoreList
拡張フィールド
DevTools。x_google_ignoreList を参照
をご覧ください。
ソースマップの欠点
残念ながら、ソース マッピングは必ずしも必要とするほど完全ではありません。
最初の例では、ビルド中に変数 greet
が最適化されました。
その値は最終的な文字列出力に直接埋め込まれています。
この場合、コードをデバッグする際に、デベロッパー ツールが 実際の値を推測して表示します。このようなエラーにより、コードが モニタリングと分析が困難になります
<ph type="x-smartling-placeholder">これは、ソースマップの設計内で解決する必要がある問題です。1 本 考えられる解決策は、API のソースマップにスコープ情報を 他のプログラミング言語で行われるデバッグ情報と同じです。
しかしこれにはエコシステム全体が協力して ソースマップの仕様と実装。このコースの ソースマップでデバッグ可能性を改善する方法については、 ソースマップ v4 ご覧ください。