Add JavaScript build artifacts to tagged releases

longwave → credited balintbrews → .

longwave → credited larowlan → .

longwave → credited wim leers → .

Adding credits for discussion in Slack.

MR!515 contains a first attempt at a Docker-based build step that can be run locally or on CI.

$ rm -rf dist

$ docker build --output dist .
...
 => exporting to client directory
 => => copying files 1.62MB

$ ls dist/ dist/assets/
dist/:
assets  index.html

dist/assets/:
index.css  index.js

This is critical for the 0.2 tag needed for Drupal CMS next week.

I'm not sure how to review this. 😅 (But spotted one problem 🙈)

1. Why would I build this using Docker if I can just do npm ci && npm run build locally and commit that?
2. This is not yet running on Drupal CI. Do you intend to do that? And if so, is it worth figuring that out for the handful of tags we'll make prior to starting a 1.0-stable? (I suspect that at that point we will have to always commit the build artifacts? Because people might run the dev snapshot then. Or we might just say that we don't support that.)

I can see how this is useful to be able to build it without having to install npm, but anybody tagging a release would also have a working XB dev environment?

1. To ensure a consistent Node.js version. (CPU architecture would be relevant if we distributed server-side code as well.)
2. Given how you wisely suggested on Slack to stay pragmatic, especially with 0.2.0 being so close, I think we don't want to worry about CI. 🙂 The person tagging a new release can run this locally — then delete the artifacts in the subsequent commit as you outlined earlier. We can figure out a more solid distribution workflow later.

I don't see what's wrong with using the official NodeJS image? It's available for multiple architectures and does what we need - what does the skpr one do that the official one doesn't?

#11++ for pragmatism — but I was actually mostly getting at discoverability.

If this is not running on Drupal CI, then how would I ever even discover this if it's not documented in /ui/README.md nor /CONTRIBUTING.md?

Also: #13++ — if we deviate from the official one, we need to document why.

Agreed that it needs documentation, but since the MR was meant as a first pass, I was thinking we could get @larowlan's opinion, then if we're all happy, we can document the steps.

skpr/node:20-v2-latest was suggested instead of node:20-alpine in the Slack conversation that resulted this issue. I simply wanted to capture that, with the idea that we can easily change it back. I wasn't sure if @longwave missed the suggestion or deliberately added node:20-alpine. Now I know it's the latter.

@larowlad said skpr/node:20-v2-latest is his preferred image, so let's see if there is a good reason to go with that. Whichever we choose, it won't make too much of a difference.

Added some rudimentary documentation.

Lovely! 🚢

With 0.2.0 delayed, do we want a followup for automating this with CI? Or do we think that's too much effort compared to a manual step with every tag?

Retitling to reflect the part that was done in this issue.

#21: Too much effort for the far and few between releases.

#22: thanks! 🙏