Repository: create-react-app
Issue: Consider using Mock Service Worker as the default API mocking solution
Labels: issue: proposal,needs triage

### Is your proposal related to a problem?

Indirectly.

Create React App comes with [React Testing Library](https://testing-library.com/) as a great default for testing React applications. Elaborating on the topic of great defaults, I think it's safe to say that most CRA projects involve some extent of data fetching. Those components that do HTTP requests must be tested as well, so developers have full confidence in the applications they build. I think it makes sense to include an API mocking layer in CRA with a minimal setup that not only achieved the goal, but encourages best practices along the way.

### Describe the solution you'd like

I'd like to suggest integrating [Mock Service Worker](https://github.com/mswjs/msw) (MSW) as the default API mocking solution in Create React App.

You can see [the example of the proposed integration](https://github.com/mswjs/examples/tree/9c6f60d2784f65733fa99326087386df117de4fa/examples/rest-react) that features the minimalistic setup and re-usage of the same mock definitions in integration and E2E tests. I will be happy to open a pull request that showcases the changes necessary to have the library set up in Create React App.

### Why I think Mock Service Worker is a good suggestion

1. It's a request client-agnostic solution. This means that no matter how developers fetch the data, be it `window.fetch`, React Query, Apollo, SWR, they will be able to capture and mock the responses they need.
2. Derived from the previous point, MSW setup remains the same when switching request clients. This means that the recommended setup we provide is not only suitable for the current tools that the developer uses, but also for any tools they may consider migrating to in the future.
2. It can run across environments. You can reuse the same mock definitions in a browser, Node.js, React Native, Electron. All that with the same setup. The project is strictly following a framework-agnostic policy and does not introduce code specific to any framework.
3. API types support. The library supports mocking of REST and GraphQL API, with Server-Side Events and WebSockets being in the future works. For instance, I've heard a lot of positive feedback from people migrating to MSW from the `MockedProvider` in Apollo. 
3. It's actively used and maintained. The library is years old and is being used by companies like Google, Spotify (read the [case study](https://backstage.io/docs/architecture-decisions/adrs-adr007)), Auth0, and hundreds of others around the globe. We keep growing our community and the ecosystem around the project.

### Describe alternatives you've considered

There are no alternatives (to my best knowledge) that would allow seamlessly reusing the same mock definitions across environments and, thus, different testing levels, on the same scale that MSW does. The current testing reality is that developers configure different tools, often repeating the testing setup, to achieve the same goal—all that to compensate for how such tools are written and function. Code repetition is the least concern here, as the technical implementation of most API mocking tools _replace_ request-issuing clients, significantly decreasing the confidence in any related tests, as opposed to allowing the tested code to make requests as it does in production. MSW does not suffer from this.

> I can also be terribly biased regarding this, so feel free to correct me and reference similar technologies that developers may consider.

### Additional context

MSW introduced a brand-new approach to API mocking by utilizing the Service Worker API. That allows your application to perform requests and receive responses _and_ have control over the network without stubbing anything. The concept and implementation behind MSW had brought it ["The Most Exciting Use of Technology"](https://osawards.com/javascript/2020) award on Open Source Awards 2020 and established it as [a technology to assess](https://www.thoughtworks.com/radar/languages-and-frameworks/mock-service-worker) by TechRadar.

I can't ignore the fact that the adoption of MSW in Create React App would increase its usage surface, which would help to discover more issues and usage scenarios, improving the developer's experience for all our users and the ecosystem in general. Perhaps such integration could also bring more collaborators to the project and ensure its bright future.

**You can learn more about Mock Service Worker:**

- [**Why MSW is the next chapter in API mocking**](https://www.youtube.com/watch?v=76yEzm07Kfk) (a talk from TestJS Summit 2021)
- [GitHub repository](https://github.com/mswjs/msw)
- [Getting started](https://mswjs.io/docs/getting-started/install)
- [Comparison with other tools](https://mswjs.io/docs/comparison)