docs: fix typos in documentation files (#10124)

Co-authored-by: Anthony Shew <[email protected]>

Author: rootdiae

buildcontainer/README.md

@@ -16,7 +16,7 @@ Should you wish to see working [examples](#examples) instead of reading
 
 ## Credits
 
-This project is rather cookbook combing various projects into one. Special to [osxcross](https://github.com/tpoechtrager/osxcross) for amazing cross-compile environment for OSX.
+This project is rather cookbook combining various projects into one. Special to [osxcross](https://github.com/tpoechtrager/osxcross) for amazing cross-compile environment for OSX.
 
 ## Docker
 

crates/turborepo-wax/README.md

@@ -300,8 +300,8 @@ within a glob expression so long as they do not split tree wildcards (e.g.,
 can be negated by preceding the corresponding character with a minus `-`. Flags
 are toggled in the order in which they appear within `(?...)`.
 
-The only supported flag is the case-insensitivty flag `i`. By default, glob
-expressions use the same case sensitivity as the target platforms's file system
+The only supported flag is the case-insensitivity flag `i`. By default, glob
+expressions use the same case sensitivity as the target platforms' file system
 APIs (case-sensitive on Unix and case-insensitive on Windows), but `i` can be
 used to toggle this explicitly as needed. For example,
 `(?-i)photos/**/*.(?i){jpg,jpeg}` matches file paths beneath a `photos`
@@ -371,7 +371,7 @@ features = [
 
 ## Unsupported Path Features
 
-Any components not recognized as separators nor patterns are interpreted as
+Any components not recognized as separators or patterns are interpreted as
 literals. In combination with strict rules, this means **some platform-specific
 path features cannot be used directly in globs**. This limitation is by design
 and additional code may be necessary to bridge this gap for some use cases.
@@ -433,7 +433,7 @@ assert!(glob.has_semantic_literals());
 
 ### Schemes and Prefixes
 
-While globs can be rooted, they cannot include schemes nor Windows path
+While globs can be rooted, they cannot include schemes or Windows path
 prefixes. For example, the Windows UNC share path `\\server\share\src` cannot be
 represented directly as a glob.
 
@@ -468,7 +468,7 @@ match nor capture some literal byte strings.
 
 At the time of writing, Wax is experimental and unstable. It is possible that
 glob expression syntax and semantics may change between versions in the `0.y.z`
-series without warning nor deprecation.
+series without warning or deprecation.
 
 [miette]: https://github.com/zkat/miette
 [nym]: https://github.com/olson-sean-k/nym

docs/site/content/repo-docs/guides/generating-code.mdx

@@ -62,7 +62,7 @@ generators within a repo configured with Turborepo.
 
 1. Generators are automatically discovered, loaded, and organized per workspace (no need to manually `load` them within a single configuration file)
 2. Generators are automatically run from the root of the workspace where they are defined
-3. Generators can be invoked from anywhere within your repo (or outside out it via the [`--root`](/repo/docs/reference/generate#--root-path) flag)
+3. Generators can be invoked from anywhere within your repo (or outside it via the [`--root`](/repo/docs/reference/generate#--root-path) flag)
 4. TypeScript generators are supported with zero configuration
 5. `plop` is not required to be installed as a dependency of your repo
 

docs/site/content/repo-docs/guides/migrating-from-nx.mdx

@@ -433,7 +433,7 @@ We encourage incremental migration, meaning you will have both of Nx and Turbore
 
 - **Migrating one task at a time**: Changing `nx run lint` to `turbo run lint`
 - **Migrating one package/project at a time**: Changing `nx run-many lint test --projects=web` to `turbo run lint test --filter=web`
-- **Double-running some of your tasks**: To ensure stability, you may choose to run `turbo run lint` **and** `nx run lint` while you're still getting comfortable and builiding certainty in the early phases of your migration.
+- **Double-running some of your tasks**: To ensure stability, you may choose to run `turbo run lint` **and** `nx run lint` while you're still getting comfortable and building certainty in the early phases of your migration.
 
 ### Installing dependencies where they're used
 

docs/site/content/repo-docs/guides/tools/vitest.mdx

@@ -191,7 +191,7 @@ With this in place, run `turbo test && turbo report` to create a merged coverage
 
 ### Using Vitest's Workspace feature
 
-The Vitest Workspace feature doesn't follow the same model as a [package manager Workspace](/repo/docs/crafting-your-repository/structuring-a-repository). Instead, it uses a root script that then reaches out into each package in the repository to handle the tests in that repsective package.
+The Vitest Workspace feature doesn't follow the same model as a [package manager Workspace](/repo/docs/crafting-your-repository/structuring-a-repository). Instead, it uses a root script that then reaches out into each package in the repository to handle the tests in that respective package.
 
 In this model, there aren't package boundaries, from a modern JavaScript ecosystem perspective. This means you can't rely on Turborepo's caching, since Turborepo leans on those package boundaries.