Remove MSW infrastucture + `pages` CI job

I am currently using the mocked data since it has nested components to implement the layers menu in ✨ Implement the updated insert menu and layers panel Active . But once 📌 Introduce an example set of representative SDC components; transition from "component list" to "component tree" Fixed is in and there is a way to have nested components on /node/1 then I don't care if MSW gets removed.

But as a side note, there are currently Cypress unit tests that use layout-default.json as a fixture (not MSW) so we need to make sure thats in sync. Wondering if there's a way that can check a hard-coded json file is still in sync data structure/schema-wise with what the Drupal endpoints for /api/layout returns. Or on a unit test run, if it's possible to generate a fixture based on the current data structure/schema of what /api/layout returns but maybe thats overkill for unit tests.

Wim Leers → credited bnjmnm → .

Wondering if there's a way that can check a hard-coded json file is still in sync data structure/schema-wise with what the Drupal endpoints for /api/layout returns.

Very good point! Neither Jesse nor Ben mentioned this, so I don't think they remembered/realized that the unit tests were using the fixtures too 😅 (Or perhaps it was an implementation detail to them, not sure.)

And yes, that is possible, that is literally what we added in 📌 Create an Open API spec for the current mock HTTP responses Fixed 👍 See \Drupal\Tests\experience_builder\Unit\UiFixturesValidationTest.

📌 Introduce an example set of representative SDC components; transition from "component list" to "component tree" Fixed is in, so @hooroomoo should not need this anymore.

Looks like 📌 [needs design] [RESEARCH] Previewed component tree for Content Creator does not match the result for Visitor Active broke the pages CI job, so now our builds look red, when really, all tests are passing 😅 Increasing priority.

Fixed the test failures.There are still some warnings in the CI but that's not related to the changes that i made, so marking it needs review.
Thanks!

Almost! components.json should be removed AFAICT, because it is unused.

Addressed the feedbacks.Marking it NR

We cannot delete the components.json as PHP tests are using it, so added back the file.

We cannot delete the components.json as PHP tests are using it, so added back the file.

👎 This is clearly the wrong conclusion.

Walking you through it:

1. nothing is using components.json. Hence it should be removed. I explained this above.
2. the only thing that failed is UiFixturesValidationTest::testUiComponentsFixture(), which is just making sure that this fixture complies with openapi.yml
3. … so clearly, if components.json is gone, then that sole test method can be removed too

The difference with layout-default.json is that that file is actually used by a Cypress unit test. That's why we keep that file. And that's why continuing to test its conformance in UiFixturesValidationTest::testUiLayoutDefaultFixture() makes sense too.

A simple search for msw in the codebase shows the incompleteness of this MR:

1. package-lock.json still contains msw
2. the scripts in package.json still allow using the mocks
3. README.md still contains instructions for how to use the mocks

I think this is ready, but needs final sign-off from a /ui owner 😊

I realise I'm in the minority, but I still feel this is a mistake, we're going against best-practice in the FE world. Registering my thoughts for posterity. Hope I'm wrong.

@larowlan What is the mistake here in your opinion? Requiring a Drupal API server? Using server-side-generated forms? Something else?

Too heavy a reliance on e2e tests makes the test suite slow and brittle

Thanks! Interesting. Didn't expect that response 😄 (Especially because this MR didn't remove any tests.)

Well, the good news is @traviscarden is improving all aspects of this project's use of OpenAPI (see 📌 Add TravisCarden to `CODEOWNERS` for OpenAPI Fixed ). So if anything, introducing functional JS or component tests tests that do not use the Drupal back end but fixtures instead will become easier, not harder.

In the current state of this project, I agree with @jessebaker's and @bnjmnm's assessment that it's the better choice to indeed only use the Drupal back end. When the UI and/or API get to a point of being more complete, I think it may make sense to reintroduce API response fixtures.

Automatically closed - issue fixed for 2 weeks with no activity.