chore: fix grammar (#10)

README.md

@@ -35,7 +35,7 @@ npm install @epic-web/config
 ## The problem
 
 You're a professional, but you're mature enough to know that even professionals
-can make mistakes and you value your time enough to not want to waste time
+can make mistakes, and you value your time enough to not want to waste time
 configuring code quality tools or babysitting them.
 
 ## This solution
@@ -63,7 +63,7 @@ The easiest way to use this config is in your `package.json`:
 ```
 
 <details>
-  <summary>Customizing prettier</summary>
+  <summary>Customizing Prettier</summary>
 
 If you want to customize things, you should probably just copy/paste the
 built-in config. But if you really want, you can override it using regular

docs/README.md

@@ -1,5 +1,5 @@
 # Epic Web Config Docs
 
-This package is pretty simple and small so the docs can been found in the root.
+This package is pretty simple and small so the docs can be found in the root.
 However, there are decision documents in this folder that you may find
 interesting.

docs/decisions/002-minimal-eslint.md

@@ -24,11 +24,11 @@ impact on the user. This is going to be relatively subjective for everyone.
 There are some rules which cover high impact issues, but are so unlikely to
 happen in any project that they are not worth including. For example,
 `no-compare-neg-zero` is protecting you from a pretty odd behavior, but the
-liklihood of it catching a real issue is so low it's not worth including.
+likelihood of it catching a real issue is so low it's not worth including.
 
 Another thing to consider is for TypeScript files, there are many rules which
-are completely redudant. For example, `no-setter-return` is a redudant rule in a
-TypeScript project because TypeScript will give a compiler error if you try to
+are completely redundant. For example, `no-setter-return` is a redundant rule in
+a TypeScript project because TypeScript will give a compiler error if you try to
 return from a setter.
 
 ## Decision

docs/decisions/005-sorting-imports.md

@@ -19,13 +19,13 @@ you don't even have to think about then it's fine.
 
 Prettier is often used for formatting. Changing the import order isn't really
 formatting though, so even though there is
-[a plugin](https://npm.im/prettier-plugin-organize-imports) to make prettier
-format the import order, it has a few limitations and it's philosophically
-counter to the purpose of prettier because changing the import order technically
+[a plugin](https://npm.im/prettier-plugin-organize-imports) to make Prettier
+format the import order, it has a few limitations, and it's philosophically
+counter to the purpose of Prettier because changing the import order technically
 affects the semantics of the code.
 
 ESLint on the other hand can handle this for us automatically and allows us to
-customize the order itself a bit better. Additionally, if you have a side-effect
+customize the order itself a bit better. Additionally, if you have a side effect
 import (like `import './foo.js'`), it doesn't enforce the import order.
 
 ## Decision

docs/decisions/005-verbatim-module-syntax.md

@@ -12,7 +12,7 @@ Turns out in Remix that `verbatimModuleSyntax` will cause issues if you try to
 import a `type` from a `.server` file into a non `.server` file. Like what we do
 in the Epic Stack for our toast utilities:
 
-```ts
+```tsx
 import { useEffect } from 'react'
 import { toast as showToast } from 'sonner'
 import { type Toast } from '#app/utils/toast.server.ts' // <-- the build is very unhappy about this with verbatimModuleSyntax

docs/decisions/006-arrow-parens.md

@@ -30,16 +30,16 @@ parentheses".
 
 Additionally, consider this: if you have a single argument in an arrow function,
 you will not have parentheses around it. If you then decide to destructure it,
-add an additional argument, add a type, or add a default value, you will have to
-add parentheses.
+add an argument, add a type, or add a default value, you will have to add
+parentheses.
 
 We want to avoid the extra work required to refactor code as much as possible.
 Additionally, simpler rules are often better. The simple rule of "always have
 parentheses" around the arguments of arrow functions is much simpler.
 
 ## Decision
 
-Update the prettier config from "avoid" to "always."
+Update the Prettier config from "avoid" to "always."
 
 ## Consequences
 

docs/decisions/007-no-semi.md

@@ -14,9 +14,10 @@ and everything, they'll add the semicolons for us automatically.
 
 Another issue people have with leaving off semicolons is you can start a line
 with a bracket or a parentheses and that can cause problems if the previous line
-doesn't have a semicolon. We're not gonna have those problems because we use the
+doesn't have a semicolon. We're not going to have those problems because we use
+the
 [`no-unexpected-multiline`](https://eslint.org/docs/latest/rules/no-unexpected-multiline)
-rule from ESLint (not to mention prettier makes the code look funny if you try
+rule from ESLint (not to mention Prettier makes the code look funny if you try
 that). For example, if you were to write something like this:
 
 <!-- prettier-ignore -->
@@ -73,15 +74,15 @@ I call this "semicolon babysitting". However, if I don't have semicolons then I
 simply move the line.
 
 It's small, but it's also just one less thing to worry about when refactoring
-code and it shows up in enough situations like this one and others that it's
+code, and it shows up in enough situations like this one and others that it's
 enough reason to set `semi` to `false`.
 
 ## Decision
 
-Set the prettier config to `semi: false`.
+Set the Prettier config to `semi: false`.
 
 ## Consequences
 
-This is the way the config was from the beginning so it won't affect existing
+This is the way the config was from the beginning, so it won't affect existing
 users. Anyone who wants to use this config and wants to use semicolons can
 override that option.

docs/decisions/008-new-ts-eslint-rules.md

@@ -30,12 +30,12 @@ And here's the justification for those which will not be enabled:
 - `@typescript-eslint/require-await` - sometimes you really do want async
   without await to make a function async. TypeScript will ensure it's treated as
   an async function by consumers and that's enough for me.
-- @typescript-eslint/prefer-promise-reject-errors - sometimes you aren't the one
-  creating the error and you just want to propogate an error object with an
-  unknown type.
-- `@typescript-eslint/only-throw-error` - same reason as above. However this
+- `@typescript-eslint/prefer-promise-reject-errors` - sometimes you aren't the
+  one creating the error, and you just want to propagate an error object with an
+  `unknown` type.
+- `@typescript-eslint/only-throw-error` - same reason as above. However, this
   rule supports options to allow you to throw `any` and `unknown`.
-  Unfortunately, in Remix you can throw Response objects and we don't want to
+  Unfortunately, in Remix you can throw `Response` objects, and we don't want to
   enable this rule for those cases.
 - `@typescript-eslint/no-unsafe-declaration-merging` - this is a rare enough
   problem (especially if you focus on types over interfaces) that it's not worth
@@ -45,19 +45,19 @@ And here's the justification for those which will not be enabled:
 - `@typescript-eslint/no-unsafe-unary-minus` - this is a rare enough problem
   that it's not worth enabling.
 - `@typescript-eslint/no-base-to-string` - this doesn't handle when your object
-  actually does implement toString unless you do so with a class which is not
+  actually does implement `toString` unless you do so with a class which is not
   100% of the time. For example, the timings object in the epic stack uses
-  defineProperty to implement toString. It's not high enough risk/impact to
+  `defineProperty` to implement `toString`. It's not high enough risk/impact to
   enable.
-- `@typescript-eslint/no-non-null-assertion` - normally you should not use ! to
-  tell TS to ignore the null case, but you're a responsible adult and if you're
-  going to do that, the linter shouldn't yell at you about it.
-- `@typescript-eslint/restrict-template-expressions` - toString is a feature of
-  many built-in objects and custom ones. It's not worth enabling.
+- `@typescript-eslint/no-non-null-assertion` - normally you should not use `!`
+  to tell TypeScript to ignore the null case, but you're a responsible adult and
+  if you're going to do that, the linter shouldn't yell at you about it.
+- `@typescript-eslint/restrict-template-expressions` - `toString` is a feature
+  of many built-in objects and custom ones. It's not worth enabling.
 - `@typescript-eslint/no-confusing-void-expression` - what's confusing to one
   person isn't necessarily confusing to others. Arrow functions that call
-  something that returns void is not confusing and the types will make sure you
-  don't mess something up.
+  something that returns `void` is not confusing and the types will make sure
+  you don't mess something up.
 
 These each protect you from `any` and while it's best to avoid using `any`, it's
 not worth having a lint rule yell at you when you do:

eslint.js

@@ -176,12 +176,12 @@ export const config = [
 					// it's treated as an async function by consumers and that's enough for me.
 
 					// @typescript-eslint/prefer-promise-reject-errors - sometimes you
-					// aren't the one creating the error and you just want to propogate an
+					// aren't the one creating the error, and you just want to propagate an
 					// error object with an unknown type.
 
 					// @typescript-eslint/only-throw-error - same reason as above.
-					// However this rule supports options to allow you to throw `any` and
-					// `unknown`. Unfortunately, in Remix you can throw Response objects
+					// However, this rule supports options to allow you to throw `any` and
+					// `unknown`. Unfortunately, in Remix you can throw Response objects,
 					// and we don't want to enable this rule for those cases.
 
 					// @typescript-eslint/no-unsafe-declaration-merging - this is a rare

prettier.js

@@ -31,9 +31,9 @@ export const config = {
 			files: ['**/*.mdx'],
 			options: {
 				// This stinks, if you don't do this, then an inline component on the
-				// end of the line will end up wrapping, then the next save prettier
+				// end of the line will end up wrapping, then the next save Prettier
 				// will add an extra line break. Super annoying and probably a bug in
-				// prettier, but until it's fixed, this is the best we can do.
+				// Prettier, but until it's fixed, this is the best we can do.
 				proseWrap: 'preserve',
 				htmlWhitespaceSensitivity: 'ignore',
 			},