[WIP] Rethink frontend bundles

[jackdbd]

This PR tries to address #770 by generating CSS/JS bundles at build time instead of at runtime.

Warning

At the moment this PR should be considered a work in progress.

Both bundles are generated by esbuild instead of Rollup + Lightning CSS. I have nothing against those tools, but I have more experience with esbuild and I wanted to use esbuild-plugin-manifest to generate a manifest.json to get a mapping of non-hashed asset name => hashed asset name for cache busting.

{
  "public/entries/app.css.map": "public/entries/app-EHISVF66.css.map",
  "public/entries/app.css": "public/entries/app-EHISVF66.css",
  "public/entries/app.js.map": "public/entries/app-VDPQZHVH.js.map",
  "public/entries/app.js": "public/entries/app-VDPQZHVH.js"
}

Also, esbuild can produce a metafile that can be uploaded to Bundle Buddy to visualize the JS bundle.

You can run the following command (from the monorepo root) to generate all bundles and sourcemaps, and compile all nunjucks templates:

npx lerna run build --scope @indiekit/frontend

Then you can launch the "standalone" frontend by serving the public directory using any local web server. For example:

python3 -m http.server --directory packages/frontend/public 8080

[paulrobertlloyd]

Interesting approach. I was hoping having cached assets would prevent the need to compile assets, but I can see from your issue that this is not the case.

That said, given assets only change between each release, we could:

• Use a pre-publish script to compile assets and include these in the distributed frontend package,
• Use Indiekit’s version number for cache-busting.

Ideally the solution would mean we could continue to run a dev server with live asset compilation, while in production pre-built assets would be served instead.