webpackを使ったサイト、極端にデバッグしずらい (外部ライブラリが eval(文字列) の形で埋め込まれる)ので、はっきり言って大キライだったりする

— コラーゲンたっぷりさん (@uupaa)2017年4月19日

見知らぬコードが minifyされ、さらに eval されているのをデバッグしろとか、暴力にも等しい要求なんだよね。そりゃキライになるよ

— コラーゲンたっぷりさん (@uupaa)2017年4月19日

「環境Aの言語Bで書かれたコードを言語Fに変換した、環境C/D/Eで動くと思うのでデバッグしろ」というのも極端にデバッグしづらいという理由から避けるようにしている。

デバッガビリティに問題がある環境は、心がすり減るのでイヤ(時給1万円なら頑張る

— コラーゲンたっぷりさん (@uupaa)2017年4月19日

js minifyあるある

A「パフォーマンスに問題があるのでコードを見てくれませんか?
u「はい
u「minify+evalされているので追えません。生のコードみせてもらっていいですか?
A「今のままでは無理ですか?
u「無限に時間がかかりますがそれでもいいですか?

これな

— コラーゲンたっぷりさん (@uupaa)2017年4月19日

ブレークポイントも貼れないような環境を渡されても、こちらで出来る事は非常に少ないし、スクロールするだけでDevToolsが固まったりする場合は、こちらのストレスは10分で致死量を超えます

— コラーゲンたっぷりさん (@uupaa)2017年4月19日

10分ほどで致死量のストレスを受けるので、時給1万円でも安い(と思う

— コラーゲンたっぷりさん (@uupaa)2017年4月19日

SafariのDevToolsはChromeのように頑強ではないので、すぐに死ぬ。
そしてパフォーマンスが悪いコードほどSafariでうまく動かない。
つまりパフォーマンスが悪くてSafariで動かずminifyされているコードを渡されるとデバッグがそもそも不可能な事がよくある

— コラーゲンたっぷりさん (@uupaa)2017年4月19日

はい、伝わりましたでしょうか。

— コラーゲンたっぷりさん (@uupaa)2017年4月19日

“デバッグしてください”“パフォーマンスチューニングしてもらってもいいですか?” とJavaScriptが難読化された状態のページのURLを渡された場合に、依頼された側は(恐らく)以下の方法で解決を試みます。

• Minify をほどいた状態のJavaScript をローカルに保存し、難読化されたコードの意味的な解読とコードの流れを何となく読み取る
• コードの実際の動作を確認するために、 Charles などの LocalProxy を使い、Minifyされたコードと解読したコードを差し替え、DevTools上で動かしてみる
• DevTools が謎の理由で死亡する場合や、コードを表示するだけでUIの応答性が極端に悪くなるほど巨大なJavaScript の塊(10万行を超えるコード)対しては、まずはコードをDevToolsが耐えられるサイズに分割する
• minify + eval されているコードの一部を差し替える場合は、DevToolsによってはevalの内部に対しブレークポイントが張れない場合があるため、さらにほどき、動く状態にしてからブレークポイントを張ったり、printfデバッグ用のコードを追加する

はい、聡明な諸氏であればお分かりのように、Minify前のコードを提示してくれたら、このような無駄な苦労はそもそも発生しない のです。

時間は有効に活用したいですね。

webpackを使ってて極端にデバッグしづらいサイトが大キライ のとこは、webpackを使ってCSSや画像がBase64化された状態でjsと一緒に埋め込まれている事が多々あり、DevToolsがそれによって悲鳴を上げるから。ですね。

webpack を使って全部一つに混ぜる → 生成された bundle.js が死ぬほどデカくなる → DevToolsで開けない/DevToolsの反応が死ぬ → オマエを殺して俺も死ぬ。 の構図です。