To make a comparison with a previous PR (#6878), this, along with the relevant classes under unit-test-resources, is effectively an up-do on its hostConfiguration.js. The caveat is that the backing script must be built first with this version, unlike that in #6878.

That said, it does allow us to do user-testing on classes that will see use by upcoming unit testing, so that's pretty neat. Well, it would be... if this were saved by our CI as a testing artifact. But it's not in a good place for that. (At least, not yet.)

... and the differences between Mac sed (and awk) strike again.

GNU awk, at least, is possible to get on macOS via Homebrew, but that would mean more build-agent setup.

Alternatively... a small headless TS program should be able to handle this. Maybe I'll just take that approach instead, since we've already got Node in place anyway.

And, done. Fixture extraction + insertion each have their own node script now.

The exact setup may not be optimized, but it's at least "good enough".

(sorry, this might be a dumb question/comment, but I'm not too familiar with Typescript/Javascript...)

Why do we have the exact same c'tor declaration/definition twice? Wouldn't it be sufficient to just have the ones in lines 42-45 and delete lines 38-41?

Or does it define the default c'tor? That might be more obvious by indenting lines 38-41 or something like that.

The final constructor signature is the true internal signature, a catch-all that's compatible with the others seen above.

Any extra, preceding constructors are public overloads of each other. Intellisense will not include the final one; only the other versions.

In JS/TS, you can only ever define a single constructor per class. That multi-signature constructor is TypeScript's workaround to give the illusion of multiple constructors, but developers still have to do the "heavy lifting" within a single function to differentiate the possible intended codepaths for each public signature.

What's the reason for not specifying the type here? Or why do you specify the type for layoutConfiguration() below?

TS can pretty easily infer types in straightforward properties like these, though I'll still normally annotate them anyway just to be clear. I might have gotten a bit lazy here and relied on that for this particular property.

I don't understand why we need all the complexity of update-index.js and host-fixture for this? Why do we need to construct all this each time -- it seems like a lot of code to maintain.

1. To perform in-browser unit-tests, especially ones that match the user tests defined in one of this PR's ancestors, we need an HTML fixture. That much is pretty unavoidable.

2. To keep our maintenance load down, it's best if that fixture match what is used on the recorder page. The unit tests may then function by simply "playing back" the recording on the same element configuration and verifying that we get the same results.

3. For maintaining that fixture... note that the fixture will not function properly without its associated CSS. It's difficult to maintain those elements in isolation when the CSS isn't linked. (Of course, having a WET copy with it linked, then doing the ol' CTRL-C CTRL-V works well enough.) Took me a while to get the element configuration + CSS structure functional and to its current state, after all; even the HTML arrangement by itself isn't that straightforward.

4. Since our team policy is generally "write DRY code when possible," this turned out to be the least complex / most maintainable way I could discern to meet that goal. We clearly need the same 'fixture' for both unit tests and unit-test resource recording. (It's also a near-duplicate with the user-testing 'host page, technically.) I could easily see updating the recorder page but forgetting to update the fixture at some point in the future; why not prevent that?

As far as the "maintenance" angle goes...

At one stage in development, I was using sed and awk to extract and insert, respectively. That said, my sed and awk skills are quite low, and the scripts broke instantly on Mac due to differences with the versions it natively includes.

On the flip-side, we're already using Node, JS, and TS, and we have code using the modules and functions in that script already. Also, I personally find it much easier to parse at a glance than the dense sed and awk constructions I "Frakensteined" together via StackOverflow references.

Now, one idea that may be slightly more palatable - what if the fixture were extracted from the recorder page, rather than defined in its own separate subfolder? We'd still need the extractor, to be sure, and it's worth noting that this proposal would technically overload the purpose of the tools/recorder subfolder.