この記事ははてなエンジニア Advent Calendar 2021 の 22 日目の記事です。
昨日の記事は id:shimobayashi さんの アジャイル推進活動にここ1年で吉兆がみえてきた要因について - 下林明正のブログ でした。
Chrome の DevTools の UI 部分は Web 技術でできています。Web 技術でできているので、DevTools を DevTools で inspect することもできます。
このことを知ったのは、10MB くらいある JavaScript ファイルにブレークポイントを貼りつつデバッグしていたら DevTools が固まるようになってしまい、ブレークポイントを解除しようにもその前に DevTools がフリーズしてしまうので詰んだ……、という出来事に遭遇したのがきっかけでした。なんとかならないかと思ってごちゃごちゃ検索していたところ、次の Stack Overflow のページにたどり着きました。
DevTools の設定や Console の入力履歴 (JavaScript の REPL のアレ)、ブレークポイントの設定などは DevTools の localStorage に永続化されています。したがって、DevTools を DevTools で inspect して、localStorage を適当に書き換えることで、そのあたりを自由に改変できます。……というわけで、Chrome の DevTools の UI 部分は Web 技術でできていることに改めて気づきます。
ソースコードはこのあたり。
- https://source.chromium.org/chromium/chromium/src/+/main:third_party/devtools-frontend/src/
- ミラー: https://github.com/ChromeDevTools/devtools-frontend
- 以下ではこっちを参照しています。手癖で操作できて楽なので……
- npm パッケージとしても配信されている: https://www.npmjs.com/package/chrome-devtools-frontend
- どうでもいいんですが
node_modules
以下が完全に vendoring されていて面白い。徹底している
リポジトリルートに ARCHITECTURE.md というファイルがありそうなので眺めてみると、
- Guiding principles
- Web Platform Design Principles というドキュメントがあるらしく度々言及されている
- DevTools はでかいから Load only what is necessary しようね、という話
- DevTools ships every single day in Canary builds of Chromium-based browsers. It is therefore risky to halt development during a migration (even for a couple of weeks), as DevTools can cause Canary builds to break and effect not just end-users, but also engineers working on the web platform itself であることに気を遣おうという話
- それはそうって感じもありますが、それ以上に尊さを感じます。実際 stable に降りてきてない機能を試すには Canary 使うしかないわけなので……
- 闘うプログラマー的なエピソード感もありますね
- 一方で Use flexible third_party libraries whenever necessary という話もあって柔軟
- 実際 package-lock.json を見るとかなり賑やか
- Startup process overview
while implementations of features is lazily loaded using dynamic imports
- これ (機能ごとの実際の実装が dynamic imports で遅延ロードされていること) が守られていることを ESLint のカスタムルールでチェックしてるっぽい!めっちゃ面白い
- 実際のフォルダ構造 (とビルドシステムとの連携) の説明
- DevTools application entrypoints 以下に細かく書いてある
README から Chrome DevTools Contribution Guide というドキュメントが参照されていたのでこれも眺めてみます。これは Google ドキュメント
"How DevTools Works" という見出し以下の箇所 に良いことが書いてありました:
DevTools is a web app that talks the DevTools Protocol over a WebSocket to a backend within Blink's C++. The devtools-frontend github wiki is the best current documentation on the various components of DevTools, including architecture, testing, etc
WebSocket! と思いコードベースを wss
で検索してみたところ、いかにもそれらしいコードがありました
- ES Class の private なフィールド (
#
始まりのアレ) がめちゃくちゃ使われているのも目を引きます- TypeScript の private フィールドから移行するのが細切れに実施されているようでした https://crbug.com/1222126
- というのを見ているあたりで Node.js のデバッガに DevTools を使うことができるという話を思い出した
- Debugging - Getting Started | Node.js
When started with the
--inspect
switch, a Node.js process listens for a debugging client
- これ WebSocket で実際にやり取りされてるメッセージを見たいよな〜と思ったんですが、ひとまず Remote Debugging の仕組みを使いつつパケットキャプチャを走らせると普通に確認できました。おもしろい
最初の話に戻ると、ブレークポイントの情報が localStorage に保存されている、というのはこのあたりでの出来事でした。
- devtools-frontend/BreakpointManager.ts at 5404c44e77b29e97c604ff0305397b24a9a51ced · ChromeDevTools/devtools-frontend · GitHub
- devtools-frontend/Settings.ts at 445f84c23e4e6196207ac3463577d949fd7eb804 · ChromeDevTools/devtools-frontend · GitHub
- 近くに永続化層のマイグレーション実装が並んでてときめきますね
という感じで、普段 Web アプリケーションエンジニアとして仕事をしているうちの相応の時間は DevTools とともにあるわけですが、そんな DevTools も Web アプリケーションの一つの姿であることが垣間見れて面白かった、という話でした。
余談ですが、どうやら他のブラウザも似た感じの構造になっていそうな雰囲気を感じるので、次はこっちも眺めてみるか〜という気持ちになっています。
- WebKit: WebKit/Source/WebInspectorUI at c08ec39abeacc368eed435e9979786a57e46b6ab · WebKit/WebKit · GitHub
- Gecko: gecko-dev/devtools at beb8961e1298f3a09f443ebd7374353d684923d2 · mozilla/gecko-dev · GitHub
はてなでは、普段から Web ブラウジングをしているときに手癖で DevTools を起動してしまう Web アプリケーションエンジニアを募集しています。