esbuild, Teil 2: JavaScript-Bundling praktisch umsetzen

In browserbasierten Frontend-Projekten sind die Transpilation und das Bundlen von JavaScript früher oder später unerlässlich. Mit esbuild lassen sich fast alle gängigen Web-Frontend-Anforderungen umsetzen, ohne zusätzliche Plug-ins zu bemühen. Alles Nötige können Entwicklerinnen und Entwickler per "Configuration as Code" mit erstaunlich wenig Aufwand selbst hinzufügen.

esbuild ist ein in Go geschriebener JavaScript-Transpiler/-Bundler, der neben seiner – gegenüber webpack, Sucrase oder Rollup – enormen Geschwindigkeit einige weitere Annehmlichkeiten mit sich bringt, die im nachfolgenden Beispielprojekt zum Einsatz kommen. Dazu zählen der standardmäßig integrierte Support für TypeScript, JSX, und CSS-Imports sowie eine Schnittstelle, worüber sich esbuild sowohl mittels Go als auch JavaScript um individuelle Funktionalitäten erweitern lässt.

Die API soll in einem Beispielprojekt zum Einsatz kommen, um esbuild den Umgang mit per import referenzierten Sass-CSS-Dateien ohne zusätzliche Plug-ins zu ermöglichen. Weiterhin soll esbuild die Fähigkeit erhalten, bestimmte importierte Module von einer globalen (Browser-)Variable zu beziehen.

Ans Eingemachte

Mit einem Marktanteil von über 65 Prozent ist WordPress die am weitesten verbreitete Content-Management-Software der Welt. Deren Standard-Editor Gutenberg ist eine komplexe JavaScript-Welt, die sich an allen Ecken und Enden per Schnittstellen erweitern lässt und React als Unterbau verwendet.

Nachfolgend soll der Fokus darauf liegen, JavaScript als ein ECMAScript-Modul zu entwickeln, das sich geschmeidig in das Ökosystem des Gutenberg-Editors einfügt.

Der zu transpilierende Beispielquellcode ersetzt den Gutenberg-Editor von WordPress durch einen Button aus der WordPress UI Library. Dazu ist es nötig, eine WordPress-Seite oder einen Post im WordPress-Editor zu öffnen und den transpilierten JavaScript-Code über die Browser-JavaScript-Konsole auszuführen. Der Zweck des recht kurzen Beispielquelltextes ist die Veranschaulichung der korrekten Transpilation in die vom Gutenberg-Editor bereitgestellte Umgebung.

import element from "@wordpress/element";
import domReady from "@wordpress/dom-ready";
import components from "@wordpress/components";
import { Icon, download } from "@wordpress/icons";

import Debug from "debug";

import "./example.scss";

import Component1 from "./components/component1.mjs";
import Component2 from "./components/component2.mjs";

// enable debug messages in js console
Debug.enable("*");
const mydebug = Debug("mydebug");

function MyButton({ label }) {
  mydebug("environment : %s", process.env.NODE_ENV);

  return (
    <components.Button isPrimary>
      <Icon icon={download}></Icon>
      {label}
    </components.Button>
  );
}

domReady(() => {
  element.render(
    <div>
      <MyButton label="hello world" />
      <Component1 text="c1" />
      <Component1 text="c2" />
    </div>,
    document.getElementById("editor"),
  );
});

Die mit dem Namespace @wordpress/ geprefixten import-Anweisungen importieren die von WordPress stammenden Gutenberg-JavaScript-Pakete. Das debug-Paket ist eine weitverbreitete klassische npm-Logging-Bibliothek, die hier als Vertreter beliebiger weiterer Bibliotheken zum Einsatz kommt.

Die import-Anweisung für die (Sass-)CSS-Datei sieht auf den ersten Blick ungewöhnlich aus, ist aber Standard in nahezu allen größeren JavaScript-Frontend-Bibliotheken – nicht nur bei Gutenberg. Das Statement dient lediglich dazu, dem Bundler mitzuteilen, dass diese Sass-CSS-Datei ebenfalls zu transpilieren ist, obwohl das Resultat in einer separaten CSS-Datei mündet und nicht in der JavaScript-Datei.

wordpress/element sowie @wordpress/dom-ready sind Gutenberg-spezifische Wrapper um React, respektive das dom-ready-Event. Dieses ist ein DOMContentLoaded-DOM-Event-Wrapper, wobei sich der Begriff dom-ready als Quasi-Standard in der JavaScript-Welt etabliert hat.

Die Zeile mydebug("environment : %s", process.env.NODE_ENV); macht den einen oder anderen vielleicht stutzig, denn im Browser gibt es die globale Variable process nicht – sie ist nur in Node.js verfügbar –, aber auch diese Praxis ist in vielen Open-Source-Bibliotheken gängig.

Üblicherweise teilt die Environment-Variable NODE_ENV einem Node.js-JavaScript-Programm mit, in welchem Modus es laufen soll. Typische Werte sind development, production oder test. Darüber lassen sich Modus-spezifische Verhaltensweisen oder Ausgaben eines Programms beeinflussen. Es ist gängig, diese Variable für den Bundler zu setzen, der die Expression process.env.NODE_ENV durch den eigentlichen Wert ersetzt, zum Beispiel development.