Move the addition of the XB field on the Article bundle to a hidden submodule

Sounds good! Let's not forget to update the docs :)

Took the liberty to start this given we want it for 0.2, this will probably break all the tests.

Looks good to me, merge on green. In 📌 Maintain a per-component set of prop expressions/sources Active I had to delete this field to get validation to pass in tests that are using the field_xb_test only so this smooths that too.

The tugboat config should probably also be updated to enable the new module.

Updated Tugboat config, also opened https://github.com/TravisCarden/ddev-drupal-xb-dev/pull/25 for developers using @TravisCarden's DDEV addon.

While we're here what is the end goal for nodes? A per-bundle checkbox somewhere that enables Experience Builder for the bundle? (a bit like the LB one I guess, except at the node level instead of the display)

While we're here what is the end goal for nodes? A per-bundle checkbox somewhere that enables Experience Builder for the bundle? (a bit like the LB one I guess, except at the node level instead of the display)

Seems reasonable

I have not yet seen designs that answer that question, so not sure where that currently is in the design / user-research process.

#10: yay, encouraging to read that!

#13 + #14 + #15: I have not seen clear answers to that yet, but at the very least, starting with how LB does that makes sense to me. Not because it's a pre-established pattern, but because to my knowledge, Field UI nor Entity Field API make it possible to only allow a single field of a certain type to be added.
Thanks to 📌 Add no_ui=TRUE to XB's field type definition Active , the XB field type does not show up, preventing any instances (and hence also multiple) to be created, so a checkbox seems like the most pragmatic solution for now.

This conflicted with 📌 Add JavaScript build artifacts to tagged releases Active . Fixed.

I also realized while reviewing that xb_test_node was a misnomer/setting wrong expectations. So I renamed it to xb_dev_standard. Rationale: https://git.drupalcode.org/project/experience_builder/-/merge_requests/5...

Oops, turns out this is failing:

Failed asserting that 'The following reasons prevent the modules from being uninstalled: The <em class="placeholder">Experience Builder</em> field type is used in the following fields: node.field_xb_test, taxonomy_term.field_tag_test' [ASCII](length: 210) contains "The following reasons prevent the modules from being uninstalled: The <em class="placeholder">Experience Builder</em> field type is used in the following field: node.field_xb_test" [ASCII](length: 179).

🤯

How could the taxonomy_term.field_tag_test field possibly be an XB field?!? 🤯🤪

That last bit is definitely not 🙈

I started looking at getting rid of this special case but we quickly run into 📌 Finalize API for creating, overriding, and altering code-defined bundle fields Needs work - it would be great if we could just provide a single named bundle fields instead of configurable fields for XB which would simplify things elsewhere but this is non trivial as there are unfinished parts in core.

#17 is down to plurals - "field" vs "fields" in the error message now we have 1 vs 2 fields instead of 2 vs 3, along with assertUninstallFailureReasons() using lax comparisons via assertStringContainsString(). Tightened that up here to use assertSame() instead and specified the exact error messages.

We also can't depend on a profile from a module, and even if we could then we can't guarantee the article type exists. I think better just to make assumptions here for now (as we did before) and spend efforts on expanding XB to support other node bundles via a proper UI, bundle fields, etc.

What?! I even manually tested whether the module could depend on the profile — it seemed to work fine?! What did I miss? 🤯

even if we could then we can't guarantee the article type exists.

Very good point!

At least the name is now implying this, and the description is specifying it.