Fix typos in docs (#5694)

Co-authored-by: Daniel Choudhury <dannychoudhury@gmail.com>

docs/docs/deploy/baremetal.md

@@ -470,7 +470,7 @@ host = 'server.com'
 # ...
 ```
 
-Server specific commands are defined with a `before.command` and `after.commmand` key directly in your server config:
+Server specific commands are defined with a `before.command` and `after.command` key directly in your server config:
 
 ```toml
 [[production.servers]]

docs/docs/testing.md

@@ -350,7 +350,7 @@ describe('useAccumulator hook example in docs', () => {
     expect(result.current.total).toBe(15)
   })
 
-  it('re-initializes the accumulator if passed a new initilizing value', () => {
+  it('re-initializes the accumulator if passed a new initializing value', () => {
     const { result, rerender } = renderHook(
       (initialValue) => useAccumulator(initialValue),
       {

docs/versioned_docs/version-1.0/deploy.md

@@ -209,7 +209,7 @@ There are even more places you can get environment variables from, check out Ser
 > **Note:**
 > Serverless Dashboard CI/CD does not support projects structured like Redwood, although they're working on it. For CD, you'll need to use something like GitHub Actions.
 >
-> It can still be worthwhile to integrate your project with Serverless Dashboard — you'll have features like deploy logs and monitoring, analytics, secret management, and AWS account integration. You can also [authenticate into your Serverless acount within a CI context](https://www.serverless.com/framework/docs/guides/cicd/running-in-your-own-cicd). Just remember that if you do use the Dashboard to manage secrets, you'll need to use the `${param:VAR_NAME}` syntax.
+> It can still be worthwhile to integrate your project with Serverless Dashboard — you'll have features like deploy logs and monitoring, analytics, secret management, and AWS account integration. You can also [authenticate into your Serverless account within a CI context](https://www.serverless.com/framework/docs/guides/cicd/running-in-your-own-cicd). Just remember that if you do use the Dashboard to manage secrets, you'll need to use the `${param:VAR_NAME}` syntax.
 
 To integrate your site into the Serverless Dashboard, there are two ways:
 

docs/versioned_docs/version-1.0/deploy/serverless.md

@@ -68,7 +68,7 @@ There are even more places you can get environment variables from, check out Ser
 > **Note:**
 > Serverless Dashboard CI/CD does not support projects structured like Redwood, although they're working on it. For CD, you'll need to use something like GitHub Actions.
 >
-> It can still be worthwhile to integrate your project with Serverless Dashboard — you'll have features like deploy logs and monitoring, analytics, secret management, and AWS account integration. You can also [authenticate into your Serverless acount within a CI context](https://www.serverless.com/framework/docs/guides/cicd/running-in-your-own-cicd). Just remember that if you do use the Dashboard to manage secrets, you'll need to use the `${param:VAR_NAME}` syntax.
+> It can still be worthwhile to integrate your project with Serverless Dashboard — you'll have features like deploy logs and monitoring, analytics, secret management, and AWS account integration. You can also [authenticate into your Serverless account within a CI context](https://www.serverless.com/framework/docs/guides/cicd/running-in-your-own-cicd). Just remember that if you do use the Dashboard to manage secrets, you'll need to use the `${param:VAR_NAME}` syntax.
 
 To integrate your site into the Serverless Dashboard, there are two ways:
 

docs/versioned_docs/version-1.0/tutorial/chapter3/saving-data.md

@@ -767,7 +767,7 @@ We get that error message at the top saying something went wrong in plain Englis
 > - `listStyle` / `listClassName`: the `<ul>` that contains the list of errors
 > - `listItemStyle` / `listItemClassName`: each individual `<li>` around each error
 
-This just scratches the service of what Service Validations can do. You can perform more complex validations, including combining multiple directives in a single call. What if we had a model representing a `Car`, and users could submit them to us for sale on our exclusive car shopping site. How do we make sure we only get the cream of the crop of motorized vehicles? Sevice validations would allow us to be very particular about the values someone would be allowed to submit, all without any custom checks, just built-in `validate()` calls:
+This just scratches the service of what Service Validations can do. You can perform more complex validations, including combining multiple directives in a single call. What if we had a model representing a `Car`, and users could submit them to us for sale on our exclusive car shopping site. How do we make sure we only get the cream of the crop of motorized vehicles? Service validations would allow us to be very particular about the values someone would be allowed to submit, all without any custom checks, just built-in `validate()` calls:
 
 ```javascript
 export const createCar = ({ input }) => {
@@ -792,7 +792,7 @@ export const createCar = ({ input }) => {
 }
 ```
 
-You can still include your own custom valiation logic and have the errors handled in the same manner as the built-in validations:
+You can still include your own custom validation logic and have the errors handled in the same manner as the built-in validations:
 
 ```javascript
 validateWith(() => {

docs/versioned_docs/version-1.0/tutorial/chapter5/first-test.md

@@ -194,7 +194,7 @@ export const success = () => {
 export default { title: 'Cells/BlogPostsCell' }
 ```
 
-Some folks find this syntax a little *too* succinct and would rather see the `<Success>` component being invoked the same way it is in their actual code. If that sounds like you, skip the spread syntax and just call the `articles` property on `standard()` the old fashoined way:
+Some folks find this syntax a little *too* succinct and would rather see the `<Success>` component being invoked the same way it is in their actual code. If that sounds like you, skip the spread syntax and just call the `articles` property on `standard()` the old fashioned way:
 
 ```jsx
 import { Success } from './BlogPostsCell'

docs/versioned_docs/version-1.0/tutorial/chapter6/comment-form.md

@@ -736,7 +736,7 @@ export const standard = defineScenario({
 })
 ```
 
-Each scenario here is associated with its own post, so rather than counting all the comments in the database (like the test does now) let's only count the number of comments attached to the single post we're getting commnents for (we're passing the postId into the `comments()` call now). Let's see what it looks like in test form:
+Each scenario here is associated with its own post, so rather than counting all the comments in the database (like the test does now) let's only count the number of comments attached to the single post we're getting comments for (we're passing the postId into the `comments()` call now). Let's see what it looks like in test form:
 
 ```javascript title="api/src/services/comments/comments.test.js"
 import { comments, createComment } from './comments'

docs/versioned_docs/version-1.0/tutorial/chapter6/multiple-comments.md

@@ -284,7 +284,7 @@ describe('CommentsCell', () => {
 
 ```
 
-We're looping through each `comment` from the mock, the same mock used by Storybook, so that even if we add more later, we're covered. You may find youself writing a test and saying "just test that there are 3 comments," which will work today, but months from now when you add more comments to the mock to try some different iterations in Storybook, that test will start failing. Avoid hardcoding data like this into your test when you can derive it from your mocked data!
+We're looping through each `comment` from the mock, the same mock used by Storybook, so that even if we add more later, we're covered. You may find yourself writing a test and saying "just test that there are 3 comments," which will work today, but months from now when you add more comments to the mock to try some different iterations in Storybook, that test will start failing. Avoid hardcoding data like this into your test when you can derive it from your mocked data!
 
 #### Testing Article
 

docs/versioned_docs/version-1.0/tutorial/intermission.md

@@ -22,7 +22,7 @@ yarn rw setup ui tailwindcss
 
 However, none of the screenshots that follow will come anywhere close to what you're seeing in your browser (except for those isolated components you build in Storybook) so you may want to just start with the [example repo](https://github.com/redwoodjs/redwood-tutorial). You'll also be missing out on a good starting test suite that we've added!
 
-If you're *still* set on continuting with your own repo, and you deployed to a service like Netlify, you would have changed database the provider in `schema.prisma` to `postgres`. If that's the case then make sure your local development environment has changed over as well. Check out the [Local Postgres Setup](../local-postgres-setup.md) for assistance. If you stick with the [example repo](https://github.com/redwoodjs/redwood-tutorial) instead, you can go ahead good ol' SQLite (what we were using locally to build everything in the first half).
+If you're *still* set on continuing with your own repo, and you deployed to a service like Netlify, you would have changed database the provider in `schema.prisma` to `postgres`. If that's the case then make sure your local development environment has changed over as well. Check out the [Local Postgres Setup](../local-postgres-setup.md) for assistance. If you stick with the [example repo](https://github.com/redwoodjs/redwood-tutorial) instead, you can go ahead good ol' SQLite (what we were using locally to build everything in the first half).
 
 Once you're ready, start up the dev server with your repor:
 

docs/versioned_docs/version-1.1/deploy/serverless.md

@@ -68,7 +68,7 @@ There are even more places you can get environment variables from, check out Ser
 > **Note:**
 > Serverless Dashboard CI/CD does not support projects structured like Redwood, although they're working on it. For CD, you'll need to use something like GitHub Actions.
 >
-> It can still be worthwhile to integrate your project with Serverless Dashboard — you'll have features like deploy logs and monitoring, analytics, secret management, and AWS account integration. You can also [authenticate into your Serverless acount within a CI context](https://www.serverless.com/framework/docs/guides/cicd/running-in-your-own-cicd). Just remember that if you do use the Dashboard to manage secrets, you'll need to use the `${param:VAR_NAME}` syntax.
+> It can still be worthwhile to integrate your project with Serverless Dashboard — you'll have features like deploy logs and monitoring, analytics, secret management, and AWS account integration. You can also [authenticate into your Serverless account within a CI context](https://www.serverless.com/framework/docs/guides/cicd/running-in-your-own-cicd). Just remember that if you do use the Dashboard to manage secrets, you'll need to use the `${param:VAR_NAME}` syntax.
 
 To integrate your site into the Serverless Dashboard, there are two ways:
 

docs/versioned_docs/version-1.1/tutorial/chapter3/saving-data.md

@@ -792,7 +792,7 @@ We get that error message at the top saying something went wrong in plain Englis
 > - `listStyle` / `listClassName`: the `<ul>` that contains the list of errors
 > - `listItemStyle` / `listItemClassName`: each individual `<li>` around each error
 
-This just scratches the surface of what Service Validations can do. You can perform more complex validations, including combining multiple directives in a single call. What if we had a model representing a `Car`, and users could submit them to us for sale on our exclusive car shopping site. How do we make sure we only get the cream of the crop of motorized vehicles? Sevice validations would allow us to be very particular about the values someone would be allowed to submit, all without any custom checks, just built-in `validate()` calls:
+This just scratches the surface of what Service Validations can do. You can perform more complex validations, including combining multiple directives in a single call. What if we had a model representing a `Car`, and users could submit them to us for sale on our exclusive car shopping site. How do we make sure we only get the cream of the crop of motorized vehicles? Service validations would allow us to be very particular about the values someone would be allowed to submit, all without any custom checks, just built-in `validate()` calls:
 
 ```js
 export const createCar = ({ input }) => {

docs/versioned_docs/version-1.1/tutorial/chapter6/comment-form.md

@@ -736,7 +736,7 @@ export const standard = defineScenario({
 })
 ```
 
-Each scenario here is associated with its own post, so rather than counting all the comments in the database (like the test does now) let's only count the number of comments attached to the single post we're getting commnents for (we're passing the postId into the `comments()` call now). Let's see what it looks like in test form:
+Each scenario here is associated with its own post, so rather than counting all the comments in the database (like the test does now) let's only count the number of comments attached to the single post we're getting comments for (we're passing the postId into the `comments()` call now). Let's see what it looks like in test form:
 
 ```jsx title="api/src/services/comments/comments.test.js"
 import { comments, createComment } from './comments'

docs/versioned_docs/version-1.1/tutorial/chapter6/multiple-comments.md

@@ -284,7 +284,7 @@ describe('CommentsCell', () => {
 
 ```
 
-We're looping through each `comment` from the mock, the same mock used by Storybook, so that even if we add more later, we're covered. You may find youself writing a test and saying "just test that there are 3 comments," which will work today, but months from now when you add more comments to the mock to try some different iterations in Storybook, that test will start failing. Avoid hardcoding data like this into your test when you can derive it from your mocked data!
+We're looping through each `comment` from the mock, the same mock used by Storybook, so that even if we add more later, we're covered. You may find yourself writing a test and saying "just test that there are 3 comments," which will work today, but months from now when you add more comments to the mock to try some different iterations in Storybook, that test will start failing. Avoid hardcoding data like this into your test when you can derive it from your mocked data!
 
 #### Testing Article
 

docs/versioned_docs/version-1.1/tutorial/intermission.md

@@ -22,7 +22,7 @@ yarn rw setup ui tailwindcss
 
 However, none of the screenshots that follow will come anywhere close to what you're seeing in your browser (except for those isolated components you build in Storybook) so you may want to just start with the [example repo](https://github.com/redwoodjs/redwood-tutorial). You'll also be missing out on a good starting test suite that we've added!
 
-If you're *still* set on continuting with your own repo, and you deployed to a service like Netlify, you would have changed the database provider in `schema.prisma` to `postgresql`. If that's the case then make sure your local development environment has changed over as well. Check out the [Local Postgres Setup](../local-postgres-setup.md) for assistance. If you stick with the [example repo](https://github.com/redwoodjs/redwood-tutorial) instead, you can go ahead good ol' SQLite (what we were using locally to build everything in the first half).
+If you're *still* set on continuing with your own repo, and you deployed to a service like Netlify, you would have changed the database provider in `schema.prisma` to `postgresql`. If that's the case then make sure your local development environment has changed over as well. Check out the [Local Postgres Setup](../local-postgres-setup.md) for assistance. If you stick with the [example repo](https://github.com/redwoodjs/redwood-tutorial) instead, you can go ahead good ol' SQLite (what we were using locally to build everything in the first half).
 
 Once you're ready, start up the dev server:
 

docs/versioned_docs/version-1.2/forms.md

@@ -321,7 +321,7 @@ The treatment of empty field values is governed by the following:
 
 ### emptyAs prop
 
-The `emptyAs` prop allows the user to overide the default value for an input field if the field is empty. Provided that a `setValueAs` prop is not specified, Redwood will allow you to override the default empty value returned.
+The `emptyAs` prop allows the user to override the default value for an input field if the field is empty. Provided that a `setValueAs` prop is not specified, Redwood will allow you to override the default empty value returned.
 The possible values for `emptyAs` are:
 - `null`
 - `'undefined'`

docs/versioned_docs/version-1.2/tutorial/chapter4/authentication.md

@@ -495,7 +495,7 @@ Before we leave this file, take a look at `requireAuth()`. Remember when we talk
 
 ## Session Secret
 
-After the initial `setup` command, which installed dbAuth, you may have noticed that an edit was made to the `.env` file in the root of your project. The `setup` script appened a new ENV var called `SESSION_SECRET` along with a big random string of numbers and letters. This is the encryption key for the cookies that are stored in the user's browser when they log in. This secret should never be shared, never checked into your repo, and should be re-generated for each environment you deploy to.
+After the initial `setup` command, which installed dbAuth, you may have noticed that an edit was made to the `.env` file in the root of your project. The `setup` script appended a new ENV var called `SESSION_SECRET` along with a big random string of numbers and letters. This is the encryption key for the cookies that are stored in the user's browser when they log in. This secret should never be shared, never checked into your repo, and should be re-generated for each environment you deploy to.
 
 You can generate a new value with the `yarn rw g secret` command. It only outputs it to the terminal, you'll need to copy/paste to your `.env` file. Note that if you change this secret in a production environment, all users will be logged out on their next request because the cookie they currently have cannot be decrypted with the new key! They'll need to log in again to a new cookie encrypted with the new key.
 

docs/versioned_docs/version-1.2/tutorial/intermission.md

@@ -22,7 +22,7 @@ yarn rw setup ui tailwindcss
 
 However, none of the screenshots that follow will come anywhere close to what you're seeing in your browser (except for those isolated components you build in Storybook) so you may want to just start with the [example repo](https://github.com/redwoodjs/redwood-tutorial). You'll also be missing out on a good starting test suite that we've added!
 
-If you're *still* set on continuting with your own repo, and you deployed to a service like Netlify, you would have changed the database provider in `schema.prisma` to `postgresql`. If that's the case then make sure your local development environment has changed over as well. Check out the [Local Postgres Setup](../local-postgres-setup.md) for assistance. If you stick with the [example repo](https://github.com/redwoodjs/redwood-tutorial) instead, you can go ahead good ol' SQLite (what we were using locally to build everything in the first half).
+If you're *still* set on continuing with your own repo, and you deployed to a service like Netlify, you would have changed the database provider in `schema.prisma` to `postgresql`. If that's the case then make sure your local development environment has changed over as well. Check out the [Local Postgres Setup](../local-postgres-setup.md) for assistance. If you stick with the [example repo](https://github.com/redwoodjs/redwood-tutorial) instead, you can go ahead good ol' SQLite (what we were using locally to build everything in the first half).
 
 Once you're ready, start up the dev server: