Article by: Abhijeet Prasad
数か月前、Sentry は Debug ID 用の新しい NPM 組織（名前空間）を作成し、その配下に複数のパッケージを公開しました。https://www.npmjs.com/org/debugids
これは、JavaScript Debug ID がエコシステム全体で正式に認知されるための大きな一歩です。同時に、Sentry がオープンスタンダードを牽引し、合意形成に取り組む成熟度を示しています。
———————————————————————————–
💡 要点まとめ
Debug ID は JavaScript ファイルとそのソースマップを結びつける決定論的かつグローバルに一意な値です。
Sentry は Debug ID を Sentry 独自の機能にとどまらず、JavaScript エコシステム全体で広く利用される概念にしようとしています。
Debug ID をソースマップ仕様に追加するため、tc39 に公式提案を提出し、ブラウザ API も含めた標準化を推進しています。
誰でもツールやアプリに Debug ID 機能を追加できるよう、各種プラグイン・ツール・ポリフィルを公開済みです。また、バンドラーやソースマップツールへの対応を JavaScript コミュニティと協力して進めています。
詳しく知りたい方は、ぜひ読み進めてください。
Debug ID とは何か
現代のウェブサイト開発者は、JavaScript をサイトに追加する際に、何らかのビルドプロセスを使用するのが一般的です。このビルドプロセスは、入力された JavaScript を何らかの形で変換し、Web サイトとともに配信される JavaScript を出力します。たとえば、JavaScript コードを縮小して読み込み速度を向上させたり、TypeScript の型を削除したりといった変換が行われます。（ブラウザで動作するのは JavaScript のみであるため）
つまり、99% の場合において、実行される JavaScript はエディタで書いたものそのままではありません。変換され、トランスパイルされ、ダウングレードされ、ポリフィルされるなど、さまざまな処理が施されています。
Sentry が収集するエラーのデバッグにはスタックトレースが不可欠ですが、変換後の JavaScript から得られるスタックトレースは、読みにくく、役に立たない場合が多くあります。書いたコードとはまったく違う見た目になり、ソースコードリポジトリと結びつけることもできません。さらに、変数名や関数名が縮小されているため、何が起きているのかの文脈が失われてしまいます。
Sentry（や他のツール）がスタックトレースを読みやすく、役立つものにするためには、ソースマップを生成し活用する必要があります。ソースマップは、変換後の JavaScript ファイルと元のファイルとの対応関係を記述したファイルです。Sentry はこのソースマップを用いて、変換後のファイルから元のソースを特定できます。つまり、実際に書いたコードのようなスタックフレームを表示することができるのです。
ソースマップを JavaScript ファイルに結びつけるために、従来はファイル名を用いていましたが、これは信頼性に欠けることが多々ありました。たとえば、同じファイル名のまま新しいソースマップをデプロイすると、誤ったソースマッピングが適用されてしまうことがあります。
このように URL ベースのファイル名では信頼性に欠けるため、私たちは Debug ID という仕組みを考案しました。これはネイティブ言語のエコシステムに着想を得たもので、変換済みの JavaScript ファイルとその対応するソースマップを識別する、決定論的かつグローバルに一意な ID です。
Sentry における Debug ID の活用
Sentry のソースマッピング基盤において Debug ID を使用することで、ユーザーがソースマップ付きのエラーを簡単に扱えるようになり、JavaScript のスタックトレースの有用性が大幅に向上しました。
さらに、Debug ID を使うことで、ソースマップの利用をリリースと切り離すことができるため、Sentry 上でのソースマップ導入のハードルが下がりました。
直近 1 か月間だけでも、25,000 を超える組織が Debug ID を使ってソースマップをアップロードしており、その総数は 790 万件にのぼります。
総じて、Debug ID の活用は Sentry にとってもユーザーにとっても非常に成功した取り組みとなっています。
Sentry の外での Debug ID
Sentry ではソースマップ用途に Debug ID を導入しましたが、それにとどまらず、JavaScript の標準化委員会である tc39 に対して、Debug ID をソースマップ仕様の正式な一部として追加する提案も行いました。
この提案は、2023年4月に Armin によって最初に提出され、その後 Luca によって改訂されました。（彼は tc39 ソースマップ作業部会の会合にも参加し、前進に貢献しています）
現在では、Debug ID をソースマップ仕様に加える tc39 提案がステージ2に進んでいます。
私たちは今後も tc39 での議論を進め、正式な仕様として実現されるまでこの取り組みを継続していきます。
tc39 での標準化とは別に、JavaScript のツール群やブラウザ本体にも Debug ID をサポートしてほしいと考えています。そのため、採用しやすくする目的で、@debugids 名前空間のもとに複数の JavaScript ライブラリを公開しました。
以下に一覧を示します。
Polyfills（ポリフィル）
@debugids/browser — ブラウザ向け Debug ID 機能ポリフィル
@debugids/node — Node.js 向け Debug ID 機能ポリフィル
Tools（ツール）
@debugids/cli — 変換済みファイルと対応するソースマップに Debug ID を追加する CLI ツール
Bundler Plugins（バンドラープラグイン）
@debugids/esbuild — Debug ID 対応を追加する Esbuild プラグイン
@debugids/parcel-optimizer-debugids — Debug ID 対応を追加する Parcel プラグイン
@debugids/rolldown — Debug ID 対応を追加する Rolldown プラグイン
@debugids/rollup — Debug ID 対応を追加する Rollup プラグイン
@debugids/rspack — Debug ID 対応を追加する Rspack プラグイン
@debugids/vite — Debug ID 対応を追加する Vite プラグイン
@debugids/webpack — Debug ID 対応を追加する Webpack プラグイン
これらのパッケージを通じて、他の開発者が自分たちのツールやアプリに Debug ID を取り入れる方法を紹介できるようになりました。バンドラーや JavaScript 本体への上流統合には、主に次の 3 つの利点があります。
- 自社のバンドラープラグインや Sentry CLI における Debug ID サポートの保守負担を軽減できる
- JavaScript やブラウザ API として Debug ID 機能が公開されれば、SDK のロジックやバンドルサイズの複雑さも軽減できる
- 標準化を推進し、他組織・企業と合意形成を行う存在として、Sentry を Web コミュニティ内で重要な立場に確立できる（ブランド的な意味でも？）
当初はライブラリやツール制作者に向けてパッケージを提供し、自ら Debug ID を組み込んでもらうことを想定していましたが、実際には多くの JavaScript ライブラリ開発者が私たちの PR を快く受け入れてくれたのは嬉しい驚きでした。
JavaScript ツールへの Debug ID 統合
私たちが @debugids 名前空間でライブラリを公開する以前から、Bun バンドラーはすでに Debug ID をサポートしていました。
まず、Rust 製のバンドラーであり将来的に Vite の中核となる Rolldown にアプローチしたのですが、Debug ID サポートの PR を出してから、わずか数日でマージされました！
さらに、Rolldown に加え、以下のプロジェクトにも PR を送り、Debug ID 機能を追加しました。
- Rollup（プルリクエスト）
- Webpack（プルリクエスト）
- Vite（プルリクエスト）
- Rspack（Issue と複数のプルリクエスト）
Esbuild や v8（Chrome）にも Debug ID のサポートを提案しましたが、現在 TC39 における提案はまだステージ 2 にとどまっており、具体的な進展はありません。
Debug ID に関するバンドラーや JavaScript ツールへの対応を推進してくれた Tim Fish に深く感謝いたします！
Rollup、Rolldown、Rspack、Vite、Webpack といった主要ツールでの対応により、JavaScript エコシステムは Debug ID を十分に活用できる体制が整ってきています。
今後の展望
主要なバンドラーがすべて Debug ID に対応した今、あとは TC39 における提案をさらに前進させるのみです。この提案がステージ3以降に進み、最終的に JavaScript の正式仕様の一部となることを期待しています。
Sentry の社内では JavaScript の Debug ID によって多くの価値を得てきましたが、それがより広く利用可能になった今、コミュニティ全体がその恩恵を受けるのを楽しみにしています。
JavaScript に Debug ID は必要です。そして現在、それは誰もが利用できる状態になっています！
Original Page: JavaScript needs Debug IDs
IchizokuはSentryと提携し、日本でSentry製品の導入支援、テクニカルサポート、ベストプラクティスの共有を行なっています。Ichizokuが提供するSentryの日本語サイトについてはこちらをご覧ください。またご導入についての相談はこちらのフォームからお気軽にお問い合わせください。
