address workshop feedback

Author: kettanaito

README.md

@@ -50,7 +50,7 @@ speed on some of the tools and concepts we'll be covering:
 ## System Requirements
 
 - [git][git] v2.18 or greater
-- **[NodeJS][node] v23 or greater**
+- **[NodeJS][node] v23.11.0 or greater**
 - [npm][npm] v8 or greater
 
 All of these must be available in your `PATH`. To verify things are set up

exercises/01.setup/02.solution.multiple-workspaces/README.mdx

@@ -166,7 +166,7 @@ npm test
    Duration  221ms (transform 31ms, setup 0ms, collect 30ms, tests 5ms, environment 16ms, prepare 73ms)
 ```
 
-<callout-success>Motice how Vitest prints the workspace name (`unit` and `edge`) next to the respective test files. This lets you know which workspace is handling that file.</callout-success>
+<callout-success>Notice how Vitest prints the workspace name (`unit` and `edge`) next to the respective test files. This lets you know which workspace is handling that file.</callout-success>
 
 But I can also run individual workspaces by providing the `--project` option to the Vitest CLI and giving it the name of the workspace I want to run:
 

exercises/02.context/02.problem.automatic-fixtures/src/query-user.test.ts

@@ -1,7 +1,7 @@
 import { test } from '../test-extend'
 import { queryUser } from './query-user'
 
-test('throws if the user is not found', async () => {
+test('returns undefined if the user is not found', async () => {
 	await expect(queryUser('abc-123')).resolves.toBeUndefined()
 })
 

exercises/02.context/02.solution.automatic-fixtures/src/query-user.test.ts

@@ -1,7 +1,7 @@
 import { test } from '../test-extend'
 import { queryUser } from './query-user'
 
-test('throws if the user is not found', async () => {
+test('returns undefined if the user is not found', async () => {
 	await expect(queryUser('abc-123')).resolves.toBeUndefined()
 })
 

exercises/03.assertions/01.solution.custom-matchers/README.mdx

@@ -14,7 +14,7 @@ interface CustomMatchers<MatcherResult = any> {
 }
 ```
 
-Here, I am declaring a new interface called `CustomMatchers` that will describe all the custom matchers I want in my tests. It accepts the `MatcherResult` type argument, which is a requirement in order to make marchers worker correctly with Vitest.
+Here, I am declaring a new interface called `CustomMatchers` that will describe all the custom matchers I want in my tests. It accepts the `MatcherResult` type argument, which is a requirement in order to make matchers work correctly with Vitest.
 
 The type definition for the matcher itself describes it as a simple function that accepts a `schema` and returns the `MatchResult`. This is how you can imagine this call signature upon usage:
 

exercises/03.assertions/05.solution.soft-assertions/README.mdx

@@ -11,10 +11,10 @@ test('cancels the user subscription', () => {
 	const user = new User()
 	user.subscribe(new UnlimitedPlan())
 
-	expect.(user.subscription.name).toBe('Unlimited')
-	expect.(user.subscription.kind).toBe('yearly')
-	expect.(user.subscription.state).toBe('active')
-	expect.(user.subscription.endsAt).toBeUndefined()
+	expect(user.subscription.name).toBe('Unlimited')
+	expect(user.subscription.kind).toBe('yearly')
+	expect(user.subscription.state).toBe('active')
+	expect(user.subscription.endsAt).toBeUndefined()
 	expect.soft(user.subscription.name).toBe('Unlimited')
 	expect.soft(user.subscription.kind).toBe('yearly')
 	expect.soft(user.subscription.state).toBe('active')
@@ -89,7 +89,6 @@ This gives me an overview of the entire system, not just the first failed assert
 
 		this.endsAt = today.toISOString()
 	}
-}
 ```
 
 ## When to use soft assertions

exercises/04.performance/03.solution.sharding/README.mdx

@@ -11,7 +11,8 @@ These changes can be illustrated in a simple Bash script. Let's call it `run-tes
 npx vitest --reporter=blob --shard=1/4 & \
 npx vitest --reporter=blob --shard=2/4 & \
 npx vitest --reporter=blob --shard=3/4 & \
-npx vitest --reporter=blob --shard=4/4
+npx vitest --reporter=blob --shard=4/4 & \
+wait
 ```
 
 <callout-info>In this exercise, we are using a script to illustrate a sharded test run. On CI, you can put each individual `npx vitest` command from above into a separate job, splitting the entire test suite into multiple shards.</callout-info>