Cypress test infrastructure clean-up + baseline E2E test

* Removed Cypress module fork and rely on it as a dev dependency

I didn't even realize it was a fork of https://www.drupal.org/project/cypress → ! 😅

To be fair, that has not been touched in >3.5 years, and is not even compatible with Drupal 10, let alone 11. So a fork seems to be the pragmatic approach.
Based on the state of that module, it seems literally nothing is using the Cypress module! So it'd make sense to evolve the Cypress module as part of this module, where it'll see its first deep/wide/active adoption (for reasons 🌱 [policy no patch] Set expectations around testing for Frontend Active will document).

https://git.drupalcode.org/project/experience_builder/-/merge_requests/5 added a lot of phony tests for react components that we don't use. (see the components in the test folder).
We should remove those.

Also for context: it took @bnjmnm (with a little help from me, but he did 99%) a lot of effort to get it up and running on GitLab CI. >100 pipelines to get it working! I'm glad we have it up and running at all … before we have an actual E2E test, so that we don't need to lose days fighting GitLab CI then 🤠

Establish baseline for E2E tests with Cypress

Yes, I agree we should have this. OTOH, there literally was no UI to speak of yet until 📌 [MR Only] provide UI foundation with Drag and Drop + panels Fixed landed (i.e. MR 33 which you linked). I trust @bnjmnm and @jessebaker will make the call when it's worth adding a first E2E test.
@jessebaker, what do you see as the point where a first E2E test will make sense?

@larowlan:

https://git.drupalcode.org/project/experience_builder/-/merge_requests/33 added code to juggle API paths and ports
This should be configuration to the store so that it can be configured to run in any setup - e.g. in a prod scenario we will likely need to configure this from drupalSettings

This part of the issue summary is identical to 📌 Make store API paths/uris configurable via environment variables (and eventually drupalSettings) Needs work — looks like a copy/paste error? Can you confirm? I think the part is what you intended to be there?

Yep, copy paste error

👍

There is still a lot of "experimental" coding going on with the UI/front end. We are awaiting more detailed UX/user journeys and hopefully UI designs. At the moment a large amount of the React code is just me noodling and showing what is possible and what we might do. As such I'm hesitant to add the overhead of tests too early and risk slowing these experiments.

With that said, some parts of the code are now starting to form a foundation/base so it's getting closer to needing some tests. In addition to that I think having some tests sooner rather than later onto which we can build is worthwhile.

In particular I think tests around 📌 Implement undo/redo Active would be a good start.

I will discuss further with @bnjmnm in a few hours.

Per #3452584-11: [policy no patch] Set expectations around testing for Frontend → and -12: @jessebaker is pushing this forward.

Throwing in a requirement that I think all Cypress tests should be written using the principals/api outlined by https://testing-library.com/docs/cypress-testing-library/intro/ for all the reasons given on the Testing Library website.

@jessebaker Can we enforce that? Using 📌 Add eslint and type checking to CI jobs Needs work ? 🤞