Polyfills－填充物還是縫隙？ （第 1 部分）

幾天前，我們在組織的 Teams 聊天中收到一條優先訊息，內容如下：發現安全漏洞 - 偵測到 Polyfill JavaScript - 高。
舉個例子，我在一家大型銀行公司工作，你必須知道，銀行和安全漏洞就像主要的敵人。因此，我們開始深入研究這個問題，並在幾個小時內解決了這個問題，我將在下面討論。但好的（或最糟糕的？）部分是當我最初用谷歌搜尋這個問題時，彈出的搜尋結果讓我在一天剩下的時間裡都著迷！

讓我們強調一下現代瀏覽器和舊版瀏覽器之間的差異。以下是最新 Chrome 版本與 Internet Explorer (IE) 9 的比較。現代瀏覽器支援大量 ES6 功能，同時，許多公司仍在使用的 IE9 和 IE11 幾乎不支援任何 ES6 功能。
這裡有一個轉譯的概念，在JavaScript的上下文中，指的是將以現代JavaScript（ES6/ES2015及更高版本）編寫的源代碼轉換為舊版本（如ES5） ，較舊的瀏覽器廣泛支援。一個非常流行的轉譯器是 Babel，它提供了一系列功能，例如語法轉換、代碼捆綁（以及 Webpack）和對 JSX 的支持（獻給我們親愛的朋友，React！）。

現在，在有大量現代語法的地方，轉譯器的使用非常普遍，並且必須確保不同環境之間的兼容性。請注意，將整個程式碼庫轉換為不同的版本需要大量時間，並且還需要為 Babel 等設定建置過程和附加配置。不言而喻的是，除了轉換語法功能之外，還涵蓋了在舊瀏覽器中擴展相同功能複製的 API 功能。

來到 Babel 的參考，它構成了許多包，提供了不同類型功能的插件，例如將 ES6 類、箭頭函數等轉換為等效的 JS 程式碼。其中，它還提供了自己的“polyfill”包。

Polyfills 是一些程式碼片段，使舊瀏覽器能夠提供相同/幾乎相同的JS 功能，這些功能在較新的瀏覽器版本中顯示，而它們本身並不提供這些功能。 這是一個快速視訊範例和非常簡單的實現。

現在有人可能會想，那麼轉譯器和 Polyfill 之間有什麼差別呢？嗯，polyfills 專注於模擬缺少的特定 API，而不是將整個程式碼庫更改為由轉譯器完成的舊瀏覽器友善版本。這允許更精細的方法，當然，也使其更加高效和性能。

這應該給我們足夠的背景知識來說明為什麼我對 Polyfills 著迷了一天，直到我寫這篇文章的那一刻。

現在，Babel 有一個名為 babel/polyfill 的包，它由 2 個函式庫組成：core-js 和 regenerator-runtime。最初，導入此套件將使所有的 polyfill 生效。

import '@babel/polyfill';

但是引入所有內容（無論您的專案是否會使用它們）、增加套件大小以及全域注入 polyfill 可能會導致物件衝突。
這導致棄用該套件，Babel 建議直接使用 core-js 函式庫
第1步：修改babel配置

{
  "presets": [
    ["@babel/preset-env", {
      "useBuiltIns": "usage",
      "corejs": 3
    }]
  ]
}

第 2 步：手動匯入您要在專案中使用的 Polyfill

import "core-js/es/array/includes";
import "core-js/es/promise";

因此，節省記憶體並減少不必要的程式碼。

現在，這是一個部分的結束，本身並不那麼重要，但對於專案來說絕對重要，了解依賴項的最新變化，為客戶提供更好的體驗。

但是。這還不是全部。

我們即將討論最近發生的一次重大攻擊，該攻擊震動了整個互聯網並讓他們搜索了他們的程式碼庫。
而且，它包括我們在這裡討論的內容。那就敬請期待第二部吧！

以上是Polyfills－填充物還是縫隙？ （第 1 部分）的詳細內容。更多資訊請關注PHP中文網其他相關文章！