Replace Experience Builder name everywhere

I

I ran tests/src/Kernel/ApiLayoutControllerGetTest.php locally and only 1 test failed.

The failure was because the client "type" for components has some sort of hash at the end. So it changed from

'type' => 'sdc.cv_test_sdc.two_column@d99140cbd47c0b51',
to
'type' => 'sdc.cv_test_sdc.image@cc9b97c9370aabdf',
so only the hash after `@` I always ignored this. But is this because it is somehow related the file, module, or path that has changed?

We could update all of these but also is it really more that these match exactly? Could we write `assertSameXB()` that would compare arrays and let "type" match more loosely? If so we could do this in another issue as prep

Not currently working on this

Working on this for a bit.

Proposal for a workflow to collaborate on this working with the two branches.

Ok, I'm stepping back before I get on Ted's toes.
I wrote a proposal for collaborating on this on the IS. That should make possible to collaborate with less risk. Please review.

@penyaskito another option for how to work would just be to remove of `scripts/src/ConverterCommand.php` from the 3543402-replace-experience-builder branch. The we change the script to have argument TARGET_DIRECTORY

Then to run the script you just have 2 clones of the repo locally
3543402-script-only - doesn't need to be a in drupal core directory, only used to run the script
3543402-replace-experience-builder is the actually version that will be changed

so from inside 3543402-script-only you would run composer rename -=TARGET_DIRECTORY=/path/to/other/clone

Or would it simpler to just have 1 MR? since the script doesn't change itself at all it could work.
I just made 2 MR's because the 3543402-replace-experience-builder hads thousands of file changes so I thought would be harder to look at just the script.

So to be clear I didn't really have a reason to make 2 MRs versus just 1 expect when I saw the number of files changed I thought it would hard to find the script file and the changes need just for it, like composer.json scripts changes. Also wonder if gitlab UI would be laggy with so many changes.

So whatever works for people

I'm aware Ted is not working on this ATM and I'm not planning to do so for a few hours.

AMAZING WORK both of you! 🤯🤩

933+ files, +10082, −11279 🕺

@tedbow in #5:

• Amazing that there's only such a trivial failure!
• Yes, those hashes are important. It's essential for data integrity. Observing the hashes change throughout the codebase is an important indicator of things either working correctly or being broken (depending on which code change triggers those versions changing).

Looking forward to continuing where y'all left off in ~1.5-2 hours. (@jessebaker and I will start pairing on it at his start of day.)

Update with the gitlabci.yml restoring.

Identified blockers:

• 🐛 Ensure element_info_alter hook runs after editor implementation Active
• 🐛 `test_site` recipe needs to install `xb_stark` Active

penyaskito → credited jessebaker → .

Third blocker, already landed: 📌 In prep for renaming the module to Canvas rename things already called Canvas Active .

Been working on this for a while...
Just phpunit tests we have failures...

1. CollapseComponentInputsUpdate & CollapseComponentInputsUpdateTest- fails because update .gz fixture probably needs to remade, I guess in the converted version.
2. ComponentValidationTest.php - fails at least because of component version strings
3. SegmentFormTest.php - Form field with id|name|label|value "settings[theme]" not found. // not sure why
4. SingleDirectoryComponentTest.php & CanvasTwigExtensionFiltersTest.php & ParametrizedImageStyleTest.php- probably itok replacements
5. PropShapeToFieldInstanceTest.php mega array that needs reordering

Probably a few more but I tired of looking through the logs right now. I am probably done for the day

Working on this.