chore: typos and grammar fixes (#1)

Author: aaronmcadam

exercises/02.vitest-browser-mode/02.problem.migrate-the-test/README.mdx

@@ -1,7 +1,7 @@
 # Migrate the test
 
-Since you are migrating your test from running in Node.js to running in the browser, some changes have to be made to your test suites for that to work. Luckily, those changes aren't dramatic, and mostly involve importing the same things from different packages.
+Since you are migrating your test from running in Node.js to running in the browser, some changes have to be made to your test suites for that to work. Luckily, these changes aren't dramatic, and mostly involve importing the same things from different packages.
 
-> 🦉 The biggest change from adopting Vitest Browser Mode is that it splits the rendering and the UI selection/interaction between two separate packages: `@vitest/browser` and the framework-specific renderer package, like `vitest-browser-react`.
+> 🦉 The biggest change when adopting Vitest Browser Mode is that it splits the rendering and the UI selection/interaction between two separate packages: `@vitest/browser` and a framework-specific renderer package, like `vitest-browser-react`.
 
-👨‍💼 In this exercise, your task is to complete the migration of the `file-review.test.tsx` test suite to Vitest Browser Mode. Follow the instructions in that file and have the test passing at the end by calling `npm test`.
+👨‍💼 In this exercise, your task is to complete the migration of the `file-review.test.tsx` test suite to Vitest Browser Mode. Follow the instructions in that file and check the test is passing at the end by calling `npm test`.

exercises/02.vitest-browser-mode/03.solution.playwright/README.mdx

@@ -1,15 +1,10 @@
 # Playwright
 
-Problem: Using the default `preview` provider in Vitest is great to try things out, but it relies on Chromium being installed in your system (and also isn't that powerful). To have a proper setup, and be able to run it in CI, we need to define an explicit provider. Let's use Playwright.
-
-0. Explain why we want `playwright` and not the default `preview` browser provider (works better for CI, more powerful since it taps into the Chrome DevTools Protocol).
-1. Install `playwright`.
-1. Run `npx playwright install --with-deps chromium` and configure your repo so this runs automatically (this can be quite annoying). Also, install just the browsers we need, not all of them, to save time on CI.
-1. Update the Vitest configuration to use `playwright` as the browser automation tool.
+Problem: Using the default `preview` provider in Vitest is great to try things out, but it relies on Chromium being installed on your system (and also isn't that powerful). To have a proper setup, and be able to run it in CI, we need to define an explicit provider. Let's use Playwright.
 
 ---
 
-Let's start from installing `playwright`:
+Let's start by installing `playwright`:
 
 ```sh nonumber
 npm i -D playwright
@@ -18,10 +13,10 @@ npm i -D playwright
 Playwright needs browser executables to be present on your machine to run. In this workshop, I am using Chromium as my browser of choice, so I can install just that particular browser by running the following command:
 
 ```sh nonumber
-npx playwright install --with-dewps chromium
+npx playwright install --with-deps chromium
 ```
 
-> 🦉 You can provide the Playwright CLI with the explicit browsers you want to be installed. This reduces its footprint in the system by fetching only the browsers you need.
+> 🦉 You can provide the Playwright CLI with a specific browser you want to be installed. This reduces its footprint in the system by fetching only the browsers you need.
 
 The next step is to tell Vitest to use Playwright as the browser provider for component tests. In `vite.config.ts`, set the `test.browser.provider` option to `'playwright'`:
 
@@ -65,4 +60,4 @@ And, finally, let's update the type definitions for the assertion matchers to be
 }
 ```
 
-This will make sure that the locators, user events, and matchers are correctly annotated.
+This will make sure that the locators, user events, and matchers are correctly typed.

exercises/02.vitest-browser-mode/README.mdx

@@ -1,6 +1,6 @@
 # Vitest Browser Mode
 
-[Browser Mode](https://vitest.dev/guide/browser/) is a recent addition to [Vitest](https://vitest.dev/) that allows you to run your tests in the actual browser. With the browser-like environment issues becoming more and more pressing, a lot of testing frameworks have invested into designing a component-level testing model:
+[Browser Mode](https://vitest.dev/guide/browser/) is a recent addition to [Vitest](https://vitest.dev/) that allows you to run your tests in the actual browser. With browser-like environment issues becoming more and more problematic, a lot of testing frameworks have invested into designing a component-level testing model:
 
 - [Component testing in Playwright](https://playwright.dev/docs/test-components)
 - [Cypress component testing](https://docs.cypress.io/app/component-testing/get-started)
@@ -16,7 +16,7 @@ The next thing to solve was the _test process_ itself. Different tools run your
 
 Vitest Browser Mode is similar to Cypress in this regard, meaning that your browser tests are run in the browser. One important distinction here is that since Vitest relies on Vite to compile tests, it can compile your test suite _in the browser_, enabling features like TypeScript and ESM out of the box. You don't have to write lengthy Jest configurations just to have ESM in your tests anymore 🎉
 
-> This is _incredibly_ powerful. Not only does Vitest reuse your existing Vite config, making your code in production and your code in tests be transformed the same way, you can use its rich plugins system to achieve virtually anything. This makes your testing setup highly customizable.
+> This is _incredibly_ powerful. Not only does Vitest reuse your existing Vite config, letting your code in production and your code in tests be transformed the same way, you can use its rich plugins system to achieve virtually anything. This makes your testing setup highly customizable.
 
 And, finally, Vitest needs something to _render_ the components. Browser Mode is not specific to any particular front-end framework and presently can render React, Vue, and Svelte components natively. You can also build your custom renderers a bit easier since the rendering actually happens in the DOM.
 
@@ -33,7 +33,7 @@ Compared to browser-like environments, Vitest Browser Mode has the following ben
 There are also a few advantages I find in Vitest Browser Mode when compared to other component-testing approaches:
 
 - **Consistency**. Vitest can use your existing Vite configuration both for your app and for your tests. This means a smaller difference between your production and tested code, which is always a win.
-- **Component rendering model**. Running in the browser, your components can render similarly to how they are rendered in production. Vitest has a more [straighforward rendering flow](https://github.com/vitest-dev/vitest-browser-react/blob/1d6be8ca8d94bb2289b6260886f76a6e527c45f7/src/pure.tsx#L50) compared to [Playwright Component Testing](https://github.com/microsoft/playwright/blob/91f46bb5d057a284ff33def5802aba496033c030/packages/playwright-ct-core/src/mount.ts#L61), where Playwright has to channel the rendering from the test (Node.js) to the browser.
+- **Component rendering model**. Running in the browser, your components can render similarly to how they are rendered in production. Vitest has a more [straightforward rendering flow](https://github.com/vitest-dev/vitest-browser-react/blob/1d6be8ca8d94bb2289b6260886f76a6e527c45f7/src/pure.tsx#L50) compared to [Playwright Component Testing](https://github.com/microsoft/playwright/blob/91f46bb5d057a284ff33def5802aba496033c030/packages/playwright-ct-core/src/mount.ts#L61), where Playwright has to channel the rendering from the test (Node.js) to the browser.
 - **Flexibility**. You can use Vitest for both unit tests, Node.js integration tests, and in-browser integration tests. In fact, Vitest makes that easy to do with the concept of workspaces, which you will get your hands on later in this workshop.
 
-Alright, that's enough details. It's time you put Vitest Browser Mode to work for your tests. Let's go!
+Alright, we've set the scene well. Now it's time you put Vitest Browser Mode to work in your tests. Let's go!