ドミノソフト公式ブログ

合同会社ドミノソフトの公式ブログです。

トップ > Polyfillが効いてない問題の対処方法

Polyfillが効いてない問題の対処方法

はじめに

いよいよ2025年も終わりですね！　CEOのuenoyamaです。
この記事は、開発中のQuasar Frameworkアプリケーション（Vue3ベース）で起きた、Polyfillが効いてないから起動しないよ問題を解決した話です。
会社の若い人向けに、どういう手順で解決に到達したか、参考になればと思って書きました。

何が起きたのか

当社で開発中のQuasar Frameworkアプリケーション（SPA）では、古いChromeでも動作する必要があるため、@vitejs/plugin-legacyにて、polyfills: trueの設定を入れて対応しています。
これで古いブラウザでも問題なく動作していたのですが、ある日、古いブラウザでの動作確認をしたところ、Array.at解決できず、起動に失敗していることが発覚しました。
（開発メンバーは、ふだんは最新ブラウザで確認していたので気付くのが遅れた）

その後、開発メンバーの1人が「なんでArray.atが解決できない？」を生成AIと相談して、modernPolyfills: trueを入れてpolyfills: ['es.array.at', 'es.typed-array.at']に直したら問題なく動作しました！ というPull Requestを発行しました。
その時、私の中のコナンが疼きました。
「あれれー？　それって設定が不足していたということだよねー？　だとしたら、以前は動作していたことと合わないんじゃない？」

ステップ1 問題発生コミットを探す

とりえあず1ヶ月ぐらい前には動作していたような記憶があったので、まずはgitの1ヶ月ぐらい前のcommitをcheckoutしてresearchブランチとし、起動してみます。
そしたら何の問題もなく動作したので、あとは当該commitから最新commitまで（全部で50 commitぐらい）を、適当に3-5個ずつぐらいcherry-pickして起動を試します。
これを繰り返すと、見事に現象が発生する特定のコミットがわかりました。

ステップ2 問題発生箇所を探す

この該当コミット、修正量が少なければ良いのですが……変更したファイルは35、変更ステップは+582 -327。
グヘえ。チマチマとTry & Errorをしては時間がかかりすぎます。
なので、己のバグ嗅覚をたよりに、ざーっとコードを流して見ていきます。
ん？　におう？　なんだかクサイ変更があるぞ？
見つけたのは、とある設定の初期値を、グローバルオブジェクトとして持つようにしたコードでした。

const initialValue = {
  ....
}
const useXXXX = () => {
  const value = ref(structuredClone(initialValue));
}

という感じのコードです。
におう気がしたので、さらに各フィールドの修正を確認したところ、Array.atを使っている箇所を発見し、これを添え字アクセスに変更したところ、現象が起きなくなりました。

ステップ3 仮説を立てる

事件は……終わったのか……？
いや、これではmodernPolyfills: true、polyfills: ['es.array.at', 'es.typed-array.at']を入れたら現象が起きなくなった、という疑問が解消していない。
今回、Array.atを使っている部分を置換することで現象は起きなくなったが、また違う形で問題が再燃するかもしれない。

とりあえず、modernPolyfills: true、polyfills: ['es.array.at', 'es.typed-array.at']を入れたらどうなるのかを、quasar buildが出力する結果を並べて比較してみました。
polyfill関連なので、polyfillという言葉を含む出力と、問題が発生していたindex-xxxx.jsを見てみます。

（入れる前の抜粋）

Asset Size Gzipped
assets/index-xxxx.js 396.29 KB 133.09 KB
assets/polyfill-legacy-xxxx.js 209.41 KB 75.63 KB
assets/polyfill-xxxx.js 222.49 KB 81.74KB
assets/polyfills-legacy-xxxx.js 96.34KB 35.47KB

（入れた後の抜粋）

Asset Size Gzipped
assets/index-xxxx.js 396.29 KB 133.09 KB
assets/polyfill-legacy-xxxx.js 209.41 KB 75.63 KB
assets/polyfill-xxxx.js 222.49 KB 81.74KB
assets/polyfills-xxxx.js 138.41 KB 51.96KB
assets/polyfills-legacy-xxxx.js 96.34KB 35.47KB

なんか増えとるな……
polyfill-xxxx.jsよりもサイズが小さいな……
きっとこれがmodernPolyfills: trueで生成されたファイルなんだろう……
と思った瞬間、仮説が思い付きました。
index-xxxx.jsの前にpolyfill-xxxx.jsは読み込まれてないけどpolyfills-xxxx.jsなら読み込まれるのでは！

ステップ4 仮説検証

Chrome Developer Toolのネットワークタブで、ThrottlingをSlow 3Gにして、リロードした時の読み込み順を確認します。

（入れる前の処理順）

（入れた後の処理順）

ビンゴ！
index-xxxx.jsのDOMContentLoadedの前に、polyfills-xxxx.jsのDOMContentLoadedが終わっている！
というか、index-xxxx.jsと同時にpolyfills-xxxx.jsの取得が始まっている！

追加でindex.htmlの比較をしてみたところ、入れた後のファイルには、<head>に以下が増えてました。
<script type="module" crossorigin src="/assets/polyfills-xxxx.js"></script>

なるほどね……

ステップ5 結論付ける

Vueアプリケーションでは、最初にアプリケーションのメインコードであるindex-xxxx.jsのロードを開始します。
が、modernPolyfills: trueが指定されていると、index-xxxx.jsと同じタイミングでロードを開始するようです。

つまり、modernPolyfills: trueを指定したので、index-xxxx.jsと同じタイミングでロードが始まり、ファイルサイズが小さいこともあって先にDOMContentLoadedが終わる。
index-xxxx.jsのDOMContentLoaded後にスクリプト処理が始まった時には、すでにArray.atは使える状態になっているので問題にならなかった、ということなのでしょう。

ということは、modernPolyfills: trueの対策でも問題ないように思いますが、先にDOMContentLoadedが終わっているのは、ファイルが小さいことなどが要因であり、プログラムとして保証された動作ではありません。
なので、本当の対策は以下だと結論付けて、本事件は解決となりました。

  • 短期的には、グローバルオブジェクトの初期化は、Polyfillが必要なメソッドを使用しないようにする。
  • 長期的には、そもそもグローバルオブジェクトを使用しない設計にする。

「真実はいつもひとつ！」

さいごに

あとから気付いたのですが、トランスパイルしたファイルが難読化されていてもJSONのフィールド名は変化しないので、そっから調査を開始したらもっと早く問題となっているArray.atの場所が特定できて、事件解決は早かったかなーと思いました。修行修行。

We're Hiring

こんな感じで、私は今でもバグハンターとしてデバッグの最前線に立ってたりします！ そんな泥臭いCEOと一緒に働いてみたいなー、と興味を持ってくれた方は、HPのCONTACTからお気軽にご連絡ください！ ドミノソフトでは一緒に働く仲間を募集中です！

www.dominosoft.co.jp