esbuild, part 2: Practical implementation of JavaScript bundling

Share your love

In browser-based front-end projects, the transpilation and bundling of JavaScript will sooner or later be essential. With esbuild, almost all common web front-end requirements can be implemented without using additional plug-ins. Developers can add everything they need themselves with surprisingly little effort using “Configuration as Code”.

esbuild is a JavaScript transpiler / bundler written in Go, which in addition to its enormous speed – compared to webpack, sucrase or rollup – brings with it a few other conveniences that are used in the following example project. This includes the standard integrated support for TypeScript, JSX, and CSS imports as well as an interface, via which esbuild can be expanded to include individual functionalities using both Go and JavaScript.

The API is to be used in a sample project to enable esbuild to work with per import referenced Sass CSS files without additional plug-ins. Furthermore, esbuild should be able to obtain certain imported modules from a global (browser) variable.

With a WordPress has a market share of over 65 percent the most widely used content management software in the world. Their standard editor Gutenberg is a complex JavaScript world that can be expanded at all corners and ends via interfaces and uses React as a substructure.

In the following, the focus will be on developing JavaScript as an ECMAScript module that fits smoothly into the Gutenberg editor’s ecosystem.

The sample source code to be transpiled replaces the Gutenberg editor from WordPress with a button from the WordPress UI library. To do this, it is necessary to open a WordPress page or post in the WordPress editor and execute the transpiled JavaScript code via the browser JavaScript console. The purpose of the rather short sample source code is to illustrate the correct transpilation into the environment provided by the Gutenberg editor.

Read Also   Chrome will protect your tabs incognito using iPhone biometric recognition

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"),
  );
});

The ones with the namespace @wordpress/ prefixed import-Instructions import the Gutenberg JavaScript packages from WordPress. The debug-Package is a widespread classic npm logging library that is used here as a representative of any other libraries.

the import-Instruction for the (Sass-) CSS file looks unusual at first glance, but is standard in almost all larger JavaScript front-end libraries – not only at Gutenberg. The statement only serves to inform the bundler that this Sass CSS file must also be transpiled, although the result ends up in a separate CSS file and not in the JavaScript file.

wordpress/element such as @wordpress/dom-ready are Gutenberg-specific wrappers around React, respectively that dom-ready-Event. This is one DOMContentLoaded-DOM event wrapper, where the term dom-ready has established itself as a quasi-standard in the JavaScript world.

The line mydebug("environment : %s", process.env.NODE_ENV); may make one or the other puzzled, because there is a global variable in the browser process not – it is only available in Node.js – but this practice is also common in many open source libraries.

Usually the environment variable divides NODE_ENV a Node.js JavaScript program with which mode it should run. Typical values ​​are development, production or test. This can be used to influence the mode-specific behavior or outputs of a program. It is common practice to set this variable for the bundler that is responsible for the Expression process.env.NODE_ENV replaced by the actual value, for example development.

Read Also   Amazon AWS: It's now even easier to monitor calls with cloud AI

Article Source

Share your love