Adjust default-pipeline.ts for fastboot production builds

In dev and test builds, @embroider/macros are left in place to runtime, which lets us produce a single build that will work in multiple contexts (including browser vs fastboot). But in production, @embroider/macros are resolved at build time to produce optimized output. See https://github.com/embroider-build/embroider/blob/e35bafa1efca396a65b395c08925a043e31c1a49/packages/core/src/app.ts#L737

So in production builds when an app uses fastboot, to get valid output for both fastboot and browser we need to run stage3 twice, with different settings.

There are a couple possibilities for what we do with both outputs, which really comes down to what’s more convenient for people’s deployment situations.

Option 1: We could put each build in a different subdirectory, so you’d get a shape like:

dist
├── browser
│   ├── assets
│   │   └── chunk-123.js
│   └── index.html
└── fastboot
    ├── assets
    │   └── chunk-456.js
    └── index.html

Or Option 2: we could use the data-fastboot-src attributes in index.html to combine both into one build, so that where there’s different build output between the two environments the HTML would say:

<script src="/assets/chunk-123.js" data-fastboot-src="/assets/chunk-456.js"></script>

Option 2 is probably better if you’re always serving your HTML from fastboot. Option 1 may be better if you only use fastboot for some things, and still want pristine browser-facing HTML the rest of the time, without relying on a fastboot server to strip out the fastboot-only metadata. Option 1 makes it easier to integrate other stage3 packagers because they can just emit entire builds into separate directories without learning about fastboot.

[ef4]

It turns out that it’s not super useful, in the usual case, to do completely separated fastboot and browser builds, because you want the HTML that the fastboot app emits to the browser to contain URLs to assets from the browser build.

So I expect packagers will just need to understand how to combine those two variants together correctly. This is implemented now in the webpack packager in https://github.com/embroider-build/embroider/pull/465

It should still be possible to add additional variants for things like browser targets, but of course those too may want an intelligent way to combine them (like the noscript hack), so I think “how to combine (or not) variants” will be up to each packager.

[ef4]

The first option is the easier one, I think. But yes, I think we can make sure this is a general purpose matrix-like feature that would let you do multiple flavors of builds for reasons other than fastboot.