Vor ein paar Tagen erhielten wir im Teams-Chat unserer Organisation eine Prioritätsnachricht mit der Aufschrift: Sicherheitslücke gefunden – Polyfill-JavaScript erkannt – HOCH.
Um einen Kontext zu geben: Ich arbeite für ein großes Bankunternehmen und wie Sie wissen, sind Bank- und Sicherheitslücken wie große Feinde. Also begannen wir, uns eingehend mit der Angelegenheit zu befassen, und konnten das Problem innerhalb weniger Stunden lösen, worauf ich im Folgenden eingehen werde. Aber das Gute (oder das Schlimmste?) daran ist, dass ich, als ich anfangs über das Problem gegoogelt habe, von den angezeigten Suchergebnissen für den Rest des Tages gefesselt war!

Lassen Sie uns eine Diskrepanz zwischen einem modernen und einem älteren Browser hervorheben. Hier ist ein Vergleich der neuesten Chrome-Version mit Internet Explorer (IE) 9. Moderne Browser unterstützen eine ganze Reihe von ES6-Funktionen und gleichzeitig unterstützen IE9 und auch IE11, die immer noch von vielen Unternehmen verwendet werden, kaum ES6-Funktionen .
Hier hilft das Konzept des Transpiling, das sich im Kontext von JavaScript auf die Konvertierung von in modernem JavaScript (ES6/ES2015 und höher) geschriebenem Quellcode in eine ältere Version wie ES5 bezieht , das von älteren Browsern weitgehend unterstützt wird. Ein sehr beliebter Transpiler ist Babel, der eine Reihe von Funktionen wie Syntaxtransformation, Code-Bündelung (zusammen mit Webpack) und Unterstützung für JSX (für unseren lieben Freund React!) bietet.

Der Einsatz von Transpilern ist mittlerweile weit verbreitet an Orten, an denen es viel moderne Syntax gibt, und man muss die Kompatibilität zwischen verschiedenen Umgebungen sicherstellen. Beachten Sie, dass das Konvertieren einer gesamten Codebasis in eine andere Version sehr viel Zeit erfordert und auch das Einrichten eines Build-Prozesses und zusätzlicher Konfigurationen für Dinge wie Babel erfordert. Es wird nicht erwähnt, dass neben der Konvertierung syntaktischer Funktionen auch die API-Funktionalität zur Erweiterung der Replikation derselben Funktionen in alten Browsern abgedeckt wird.

Was die Referenz von Babel betrifft, so besteht es aus vielen Paketen, die Plugins für verschiedene Arten von Funktionen bereitstellen, wie z. B. die Umwandlung von ES6-Klassen, Pfeilfunktionen usw. in äquivalenten JS-Code. Darunter bietet es auch ein eigenes „Polyfill“-Paket an.

Polyfills sind Codeteile, die es alten Browsern ermöglichen, dieselbe/fast dieselbe JS-Funktionalität bereitzustellen, die sie nicht nativ bereitstellen, die in neueren Browserversionen angezeigt wird. Hier ist ein kurzes Videobeispiel und eine sehr einfache Implementierung.

Nun könnte man denken: Was ist dann der Unterschied zwischen Transpilern und Polyfillern? Nun, Polyfills konzentrieren sich auf die Emulation spezifischer APIs, die fehlen, anstatt die gesamte Codebasis in eine alte, browserfreundliche Version zu ändern, die von Transpilern erstellt wird. Dies ermöglicht einen detaillierteren Ansatz und macht ihn natürlich effizienter und leistungsfähiger.

Das sollte uns genug Hintergrundwissen liefern, um auf den Punkt zu kommen, warum ich einen Tag lang süchtig danach war, bis ich dies über Polyfills schreibe.

Jetzt hat Babel ein Paket namens babel/polyfill, das aus zwei Bibliotheken besteht: core-js und regenerator-runtime. Der Import dieses Pakets würde zunächst alle Polyfills in Aktion setzen.

import '@babel/polyfill';

Aber wenn Sie alles einbeziehen, unabhängig davon, ob Ihr Projekt es verwenden würde oder nicht, erhöht sich die Paketgröße und das globale Einfügen von Polyfills kann zu Konflikten in Objekten führen.
Dies führte dazu, dass das Paket nicht mehr unterstützt wurde und Babel empfiehlt, die core-js-Bibliothek direkt von
zu verwenden. Schritt 1: Ändern der Babel-Konfiguration

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

Schritt 2: Importieren Sie manuell die Polyfüllungen, die Sie in Ihrem Projekt verwenden würden

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

Dadurch wird Speicher gespart und unnötiger Code reduziert.

Dies ist nun das Ende eines Teils, der an sich nicht so besorgniserregend ist, aber im Hinblick auf ein Projekt auf jeden Fall wichtig ist, um über die Änderungen in den Abhängigkeiten auf dem Laufenden zu bleiben und seinen Kunden ein besseres Erlebnis zu bieten.

ABER. Das ist noch nicht alles.

Wir sind dabei, über einen großen Angriff zu sprechen, der vor Kurzem stattfand und das gesamte Internet erschütterte und sie dazu brachte, ihre Codebasis zu durchsuchen.
Und dazu gehört auch das, was wir hier besprochen haben. Seien Sie also gespannt auf den zweiten Teil!