docs: fix grammar + typos (#10661)

Co-authored-by: Brooks Lybrand <[email protected]>

Author: MichaelDeBoey

CHANGELOG.md

@@ -2,12 +2,12 @@
 
 # Remix Releases
 
-This page lists all releases/release notes for Remix back to `v2.0.0`. For releases prior to v2, please refer to the [Github Releases Page](https://github.com/remix-run/remix/releases).
+This page lists all releases/release notes for Remix back to `v2.0.0`. For releases prior to v2, please refer to the [GitHub Releases Page](https://github.com/remix-run/remix/releases).
 
-We manage release notes in this file instead of the paginated Github Releases Page for 2 reasons:
+We manage release notes in this file instead of the paginated GitHub Releases Page for 2 reasons:
 
-- Pagination in the Github UI means that you cannot easily search release notes for a large span of releases at once
-- The paginated Github interface also cuts off longer releases notes without indication in list view, and you need to click into the detail view to see the full set of release notes
+- Pagination in the GitHub UI means that you cannot easily search release notes for a large span of releases at once
+- The paginated GitHub interface also cuts off longer releases notes without indication in list view, and you need to click into the detail view to see the full set of release notes
 
 <details>
   <summary>Table of Contents</summary>

CODE_OF_CONDUCT.md

@@ -31,11 +31,11 @@ Examples of unacceptable behavior include:
 
 - The use of sexualized language or imagery, and sexual attention or
   advances of any kind
-- Trolling, insulting or derogatory comments, and personal or political attacks
+- Trolling, insulting, or derogatory comments, and personal or political attacks
 - Public or private harassment
 - Publishing others' private information, such as a physical or email
   address, without their explicit permission
-- Other conduct which could reasonably be considered inappropriate in a
+- Other conduct, which could reasonably be considered inappropriate in a
   professional setting
 
 ## Enforcement Responsibilities

DEVELOPMENT.md

@@ -38,7 +38,7 @@ pnpm test:integration integration/client-data --project chromium
 
 New releases should be created from release branches originating from the `dev` branch. When you are ready to begin the release process:
 
-- Make sure you've pulled all of the changes from GitHub for both `dev` and `main` branches
+- Make sure you've pulled all the changes from GitHub for both `dev` and `main` branches
 - Check out the `dev` branch
 - If needed, bump the dependencies to the correct React Router release
   - `./scripts/bump-router-versions.sh [pre|latest]`
@@ -54,7 +54,7 @@ Changesets will do most of the heavy lifting for our releases. When changes are
 - Ensure you are on the new `release-*` branch
 - Enter Changesets pre-release mode using the `pre` tag: `pnpm changeset pre enter pre`
 - Commit the change and push the `release-*` branch to GitHub
-- Wait for the release workflow to finish - the Changesets action in the workflow will open a PR that will increment all versions and generate the changelogs
+- Wait for the release workflow to finish — the Changesets action in the workflow will open a PR that will increment all versions and generate the changelogs
 - Review the updated `CHANGELOG` files and make any adjustments necessary, then merge the PR into the `release-*` branch
   - `find packages -name 'CHANGELOG.md' -mindepth 2 -maxdepth 2 -exec code {} \;`
 - Once the PR is merged, the release workflow will publish the updated packages to npm
@@ -65,12 +65,12 @@ Changesets will do most of the heavy lifting for our releases. When changes are
 
 ### Iterating a pre-release
 
-You may need to make changes to a pre-release prior to publishing a final stable release. To do so:
+You may need to make changes to a pre-release before publishing a final stable release. To do so:
 
 - Make whatever changes you need
 - Create a new changeset: `pnpm changeset`
   - **IMPORTANT:** This is required even if you ultimately don't want to include these changes in the logs
-  - Remember, changelogs can be edited prior to publishing, but the Changeset version script needs to see new changesets in order to create a new version
+  - Remember, changelogs can be edited before publishing, but the Changeset version script needs to see new changesets to create a new version
 - Commit the changesets and push the `release-*` branch to GitHub
 - Wait for the release workflow to finish and the Changesets action to open its PR that will increment all versions
 - Review the PR, make any adjustments necessary, and merge it into the `release-*` branch
@@ -81,7 +81,7 @@ You may need to make changes to a pre-release prior to publishing a final stable
 
 - Exit Changesets pre-release mode: `pnpm changeset pre exit`
 - Commit the edited `pre.json` file along with any unpublished changesets, and push the `release-*` branch to GitHub
-- Wait for the release workflow to finish - the Changesets action in the workflow will open a PR that will increment all versions and generate the changelogs for the stable release
+- Wait for the release workflow to finish — the Changesets action in the workflow will open a PR that will increment all versions and generate the changelogs for the stable release
 - Review the updated `CHANGELOG` files and make any adjustments necessary
   - `find packages -name 'CHANGELOG.md' -mindepth 2 -maxdepth 2 -exec code {} \;`
   - Our automated release process should have removed prerelease entries
@@ -104,25 +104,25 @@ Hotfix releases follow the same process as standard releases above, but the `rel
 
 ### Experimental releases
 
-Experimental releases use a [manually-triggered Github Actions workflow](./.github/workflows/release-experimental.yml) and can be built from any existing branch. to build and publish an experimental release:
+Experimental releases use a [manually triggered GitHub Actions workflow](./.github/workflows/release-experimental.yml) and can be built from any existing branch. To build and publish an experimental release:
 
 - Commit your changes to a branch
-- Push the branch to github
-- Go to the Github Actions UI for the [release-experimental.yml workflow](https://github.com/remix-run/remix/actions/workflows/release-experimental-dispatch.yml)
+- Push the branch to GitHub
+- Go to the GitHub Actions UI for the [release-experimental.yml workflow](https://github.com/remix-run/remix/actions/workflows/release-experimental-dispatch.yml)
 - Click the `Run workflow` dropdown
 - Leave the `Use workflow from` dropdown as `main`
 - Enter your feature branch in the `branch` input
 - Click the `Run workflow` button
 
 ### Nightly releases
 
-Nightly releases happen automatically at midnight PST via a [cron-driven workflow](./.github/workflows/nightly.yml) that is essentially the same as the experimental releases, but also performs some validations after the release.
+Nightly releases happen automatically at midnight PST via a [cron-driven workflow](./.github/workflows/nightly.yml) that is essentially the same as the experimental releases but also performs some validations after the release.
 
 ## Local Development Tips and Tricks
 
 ### Environment Variables
 
-This repository supports handful of environment variables to streamline the local development/testing process.
+This repository supports a handful of environment variables to streamline the local development/testing process.
 
 **`REMIX_DEBUG`**
 
@@ -134,7 +134,7 @@ REMIX_DEBUG=true pnpm watch
 
 **`LOCAL_BUILD_DIRECTORY`**
 
-When developing Remix locally, you often need to go beyond unit/integration tests and test your changes in a local Remix application. The easiest way to do this is to run your local Remix build and use this environment variable to direct `rollup` to write the output files directly into the local Remix application's `node_modules` folder. Then you just need to restart your local Remix application server to pick up the changes.
+When developing Remix locally, you often need to go beyond unit/integration tests and test your changes in a local Remix application. The easiest way to do this is to run your local Remix build and use this environment variable to direct `rollup` to write the output files directly into the local Remix application's `node_modules` folder. Then you need to restart your local Remix application server to pick up the changes.
 
 ```sh
 # Tab 1 - create and run a local remix application

README.md

@@ -9,7 +9,7 @@
 
 We are happy you're here!
 
-[Remix](https://remix.run) is a full stack web framework that lets you focus on the user interface and work back through web fundamentals to deliver a fast, slick, and resilient user experience that deploys to any Node.js server and even non-Node.js environments at the edge like Cloudflare Workers.
+[Remix](https://remix.run) is a full-stack web framework that lets you focus on the user interface and work back through web fundamentals to deliver a fast, slick, and resilient user experience that deploys to any Node.js server and even non-Node.js environments at the edge like Cloudflare Workers.
 
 Want to know more? Read the [Technical Explanation of Remix](https://remix.run/discussion/introduction).
 
@@ -30,4 +30,4 @@ If you're interested in contributing code and/or documentation, please see [our
 
 ## Code of Conduct
 
-Please see our [code of conduct](CODE_OF_CONDUCT.md) for any questions about the kind of community we are trying to build here and what to do if you need help with someone who is not acting professionally.
+Please see our [code of conduct](CODE_OF_CONDUCT.md) for any questions about the kind of community we are trying to build here and what to do if you need help with someone not acting professionally.