Move from webpack to esbuild bundler

[martinpitt]

This speeds up the bundle build considerably, from about 26 s with
webpack to about 6s with esbuild.

Drop babel. esbuild understands JSX natively, and we don't need the
"transpile to ES5" any more -- all recent browsers understand ES6.

esbuild also creates LEGAL.txt files in development mode (unlike webpack
terser), so we can drop this hack as well.

Co-Authored-By: Martin Pitt mpitt@redhat.com

TODO:

• Builds on top of PR build: Move to a webpack module, generalize bundler language/variable names #1209
• move plugins to cockpit.git and if possible, make them compatible with both webpack and esbuild: lib: Make PO and rsync bundler plugins work for webpack and esbuild cockpit#18372 → PR Update cockpit repo to hybrid webpack/esbuild plugins #1211
• Bundle CSS sizes are much bigger: CSS is wrongly present in bundle when the CSS import is done in an unused nested JS import evanw/esbuild#2933; devel: 1.3 → 1.9 MB, prod: 97 → 146 kB (when gzipped)
• Bundle JS size are also a bit bigger: 429 → 473 kB in production with gzip
• Update to new pf-react-table which fixes the bundle size: PR Bump pkg/lib and bring in new @patternfly/react-table #1214; rebase afterwards
• fail on eslint/stylelint warnings: watch mode aborts loop on plugin errors evanw/esbuild#2939; fixed
• (not a blocker, but ugly) sass plugin pulls in older/duplicate esbuild compiler: Pulls in duplicate esbuild compiler glromeo/esbuild-sass-plugin#122
• give some "building"/progress feedback in watch mode
• bring back file gzipping for NODE_ENV=production
• Move our custom plugins to cockpit.git lib: Add esbuild plugins for eslint, stylelint, and compression cockpit#18404 and import from there
• Decide what to do about the esbuild binary. Bundling in node_modules works for machines/podman/cockpit where we just rpm the pre-built dist/. But not for starter-kit and certificates where rpm build rebuilds the webpack (which is the cleaner approach); so let's restrict that to these projects for now.
• Wait with landing until RHEL translation updates are done, and new point release: https://bugzilla.redhat.com/show_bug.cgi?id=2139647
• clean up dist/ in between runs

All credit for this goes to @KKoukiou . I am mostly sending this PR to give it a trial run on CI, and collect a TODO list

Development: Cockpit now supports the esbuild bundler

esbuild is a much faster bundler alternative for webpack. It also natively understands JSX, so that it is not necessary any more to use babel. Cockpit's shared components and bundler plugins in pkg/lib/ now support both eslint and webpack, so that projects can pick either. cockpit-podman moved to esbuild in this commit. You may choose to do the same for your project.

[martinpitt]

@KKoukiou : I updated esbuild-rsync-plugin.js here to be usable with webpack and esbuild. I tested the unchanged file with both bundlers, with and without $RSYNC. Next step is to do the same for the po plugin, then update both of them in cockpit, then we can use them from the shared code import. WDYT?

[garrett]

Note: Switching from our breakpoint SCSS import dance to rewriting the CSS breakpoints will help detangle our SCSS and will probably make it smaller in the resulting size too. And it'll also fix our breakpoints further (as it's still broken in some places). So it'd probably help here too.

Details @

• Breakpoint redfinition at compiled CSS "optimization" time cockpit#17629

[martinpitt]

This branch is somehow out of date. But when I rebase to main and rebuild node_modules, the bundle sizes are now as we had with webpack. Amazing work! :clap 💯

[martinpitt]

@KKoukiou : So AFAICS: Land #1214 ✔️ , rebase/rebuild this ✔️ , add plugins to cockpit pkg/lib/, pull this in here, and collect trophy, right? 🏆

[jelly]

The analyzer is cool:

Interesting... docker-names is 53 kB I guess it's all the comments which aren't getting stripped?

https://github.com/bearjaws/docker-names/blob/master/index.js#L141

Local changes. also requires some dropping of the npm run build output out of the logged json.

diff --git a/build.js b/build.js
index e8a6cec7..c0eb3512 100644
--- a/build.js
+++ b/build.js
@@ -31,6 +31,7 @@ const context = await esbuild.context({
     // show "build started/finished" messages in watch mode
     logLevel: 'info',
     minify: production,
+    metafile: true,
     nodePaths,
     outdir: "./dist",
     target: ['es2020'],
@@ -67,6 +68,6 @@ const context = await esbuild.context({
 if (watchMode)
     await context.watch();
 else {
-    await context.rebuild();
+    await context.rebuild().then(result => console.log(JSON.stringify(result.metafile)));
     context.dispose();
 }

[jelly]

I found one minor bug when I run NODE_ENV=production npm run build twice.

[jelle@t14s][~/projects/cockpit-podman]%NODE_ENV=production npm run build > metafile.json
node:internal/errors:867
  const err = new Error(message);
              ^

Error: Command failed: gzip -9 dist/po.ko.js
gzip: dist/po.ko.js.gz already exists;  not overwritten

    at ChildProcess.exithandler (node:child_process:419:12)
    at ChildProcess.emit (node:events:512:28)
    at maybeClose (node:internal/child_process:1098:16)
    at Socket.<anonymous> (node:internal/child_process:456:11)
    at Socket.emit (node:events:512:28)
    at Pipe.<anonymous> (node:net:316:12) {
  code: 2,
  killed: false,
  signal: null,
  cmd: 'gzip -9 dist/po.ko.js',
  stdout: '',
  stderr: 'gzip: dist/po.ko.js.gz already exists;\tnot overwritten\n'
}

[martinpitt]

@jelly Thanks, well spotted! This needs to be fixed in the plugin in cockpit.git, I'm happy to do that.

[jelly]

Now with a production build!

[martinpitt]

@jelly 's issue is actually much worse.. It also happens with NODE_ENV=production npm run watch on the second build.

These are both a symptom of a deeper problem: The dist/ directory does not get cleaned between the builds. Do this:

rm -rf dist; NODE_ENV=production npm run build; npm run build

Now dist/ has both the compressed (production) and uncompressed (devel) files. This has already annoyed me a lot with webpack, that does the same. So the use case is to start with a prod build (from e.g. make vm or make check), then wanting to fix something, running make watch and wondering why the changes don't apply -- it's because cockpit-ws prefers serving .gz files.

So we need to clean up old files, or possibly all files, in dist/ on each round. webpack has a clean: true option, we should check if esbuild has something similar, and if not, build it somehow.

[martinpitt]

https://esbuild.github.io/api/#outdir documents this behaviour, and basically says "do it yourself". So I added a trivial cleanPlugin, all of the cases above work now (building twice, switching between prod and dev, watch mode). @KKoukiou , @jelly , PTAL?

[martinpitt]

Wah, node_modules/ changes every two hours, rebuilt for the 128th time.

[martinpitt]

After some discussion with @KKoukiou , I cleaned up how we handle the linters. Pushing with an extra committ which should fail in CI. After this proves to works as intended, I'll take it out again.

Update: Failed as intended

[martinpitt]

I suppose this should also eventually move to cockpit's pkg/lib/, but at this point my gut feeling is that we can land this PR, and do that separately. @KKoukiou is already working on esbuild-ifying cockpit.git, and she will most certainly add the clean plugin there as well.