Components don't load

Adding 📌 Move `PropSourceEndpointTest` into new `XbConfigEntityHttpApiTest::testComponent()` Active where we plan to just remove this from that API
Given the whack-a-mole this creates with tests, going to be bold and just remove it here. We can add the new API in 📌 Move `PropSourceEndpointTest` into new `XbConfigEntityHttpApiTest::testComponent()` Active

This looks ready to me and fixes HEAD

Agreed with @larowlan that basically doing a subset of 📌 Move `PropSourceEndpointTest` into new `XbConfigEntityHttpApiTest::testComponent()` Active here to make CI green again is a good idea.

But there's 2 things I don't understand:

1. why xb_test_sdc can't be installed as part of the recipe: https://git.drupalcode.org/project/experience_builder/-/merge_requests/1...
2. why most functionality was moved out of the test recipe that the Playwright CI job uses, and into the test

I couldn't find MR comments, d.o comments nor commit messages explaining why we need to strip down tests/fixtures/recipes/test_site/recipe.yml so much. Trying to restore it, piece-by-piece.

From failing hard like

The configuration 'experience_builder.component.js.xb_test_code_components_  
      using_imports' exists already and does not match the recipe's configuration  

— https://git.drupalcode.org/project/experience_builder/-/jobs/5666583

to partially like

    - Expected  - 1
    + Received  + 0
    @@ -6,11 +6,10 @@
        - heading "meow!" [level=1]
        - paragraph: this is a hero
        - link "View":
          - /url: https://drupal.org
        - button "Click"
    -   - text: Component With props, Hello Kitty, 50 years old.

— https://git.drupalcode.org/project/experience_builder/-/jobs/5666899

Feels like I'm tantalizingly close.

Some demo content seems to not be getting created:

  - Expected  - 14
    + Received  +  2
    - - heading "Homepage" [level=1]
    - - heading "Welcome to the site!" [level=1]
    - - paragraph:
    -   - text: Example value for
    -   - strong: the_body
    -   - text: slot in
    -   - strong: prop-slots
    -   - text: component.
    - - text: Example value for <strong>the_footer</strong>.
    - - link "Home":
    -   - /url: /
    -   - img "Home"
    - - link "Drupal":
    -   - /url: /
    + - heading "Page not found" [level=1]
    + - text: The requested page could not be found.

But this makes little sense: this is a default Page content entity; how could that not have been created?!

So, added explicit test coverage for it to \Drupal\Tests\experience_builder\Kernel\EventSubscriber\RecipeSubscriberTest.

I tried to bring back as much of @phenaproxima's ✨ To support site templates, ensure component definitions are rebuilt while applying recipes Active as I could.

In doing so:

1. I made the test_site recipe more explicit, and added comments that I believe will be helpful for maintaining this recipe going forward
2. duplicated what \xb_dev_standard_install() does into the recipe itself, to hopefully eventually drop that hook (and the xb_dev_standard module altogether → created 📌 Remove the `xb_dev_standard` module, instead recommend using XB's `test_site` recipe for development Active for this)
3. expanded the RecipeSubscriberTest test coverage to assert that a number of things that the Playwright tests failed on along the way, do in fact work … just not when done through Drush (which is what Playwright uses) 🤪 → see #8 + #9

For the bits I could not figure out in a reasonable amount of time in #6 + #7 + #8 + #9, I opened 📌 XB's `test_site` recipe fails to install its default content through Drush in Playwright Active and assigned to @phenaproxima.

Note that this is not a recent regression, but an assumption that's been present for about a year (back when we still had a ApiComponentsController)! It made it impossible to use XB if there was >=1 enabled sdc-sourced Component and no article node type 😅 (Which makes sense: for the first many months of XB's existence, we were hardcoding the installing of an XB field into the article node type!)

Argh, JsComponentTest::testRenderComponentLive() now fails because it needed those UUIDs to be set to ensure predictable generated JS files on disk. Only possible solution: strict: false, because this is a bug in Recipes.

Created upstream bug report at 🐛 \Drupal\Core\Recipe\ConfigConfigurator unsets the uuid of active configuration, but it should only do that if the recipe data does not contain a UUID Active .

Great find, @justafish! 👏🙏