📚 TYPOS!!

Author: danieldelcore

website/docs/authoring.mdx

@@ -14,7 +14,7 @@ Which one to use depends on your particular use case.
 ## 1. Contribute to the Community Folder
 
 The Community Folder is the public directory of codemods hosted and published directly from this repository, [visible here](https://github.com/CodeshiftCommunity/CodeshiftCommunity/tree/main/community).
-This directory can be compared to and treated the same as the Typescript type definition regisistry: [DefinitelyTyped](https://github.com/DefinitelyTyped/DefinitelyTyped).
+This directory can be compared to and treated the same as the Typescript type definition registry: [DefinitelyTyped](https://github.com/DefinitelyTyped/DefinitelyTyped).
 
 _Please see the [Contribution guide](contribution) for more information._
 
@@ -23,7 +23,7 @@ Use this method if you want:
 - Your codemods to be open source
 - Build tooling, dependency management and project setup to be handled for you
 - The community to help maintain and contribute to your codemods
-- Documentation to be automatically generated and available on the [Regisistry page](registry)
+- Documentation to be automatically generated and available on the [Registry page](registry)
 
 Do not use this method if:
 
@@ -46,7 +46,7 @@ Use this method if you want:
 
 Do not use this method if:
 
-- You want docs to be automatically generated and available on the [Regisistry page](registry)
+- You want docs to be automatically generated and available on the [Registry page](registry)
 
 ## 3. Create a stand-alone codeshift package
 

website/docs/contribution.mdx

@@ -9,7 +9,7 @@ This page covers contribution to the [Community Folder](https://github.com/Codes
 - Codemods to be open source
 - Build tooling, dependency management and project setup to be handled for you
 - The community to help maintain and contribute to your codemods
-- Documentation to be automatically generated and available on the [Regisistry page](registry)
+- Documentation to be automatically generated and available on the [Registry page](registry)
 
 If you prefer to create codemods outside of this repo, please see the [Authoring guide](authoring) for other options.
 

website/docs/external-packages.mdx

@@ -19,7 +19,7 @@ To create a standalone codeshift package automatically, install the install and
 - **npm:** `npm install -g @codeshift/cli` or
 - **yarn:** `yarn global add @codeshift/cli`
 
-Then given you want to initialize a new project called "foobar", with a codemod targetting version `10.0.0` you can run the following command:
+Then given you want to initialize a new project called "foobar", with a codemod targeting version `10.0.0` you can run the following command:
 
 `$ codeshift init --package-name="foobar" --version="10.0.0" ~/Desktop`
 

website/docs/guides/css-codemods.mdx

@@ -7,7 +7,7 @@ slug: /css-codemods
 In some cases, it's possible that you may need to write a codemod that applies changes across different programming languages JS, CSS, etc.
 It could be because the package you're writing a codemod for has an API that spans across both JS and CSS, for example a Design System or CSS-in-JS library. Where some of your consumers may be using the JS interface and some the CSS interface.
 
-In this scenario, it's possible to repurpose JSCodeshift to handle this by treating JSCodeshift purely as a "Runner", or in otherwords, as the entrypoint to the files you're looking to modify and substitute a transformation library of your choice.
+In this scenario, it's possible to repurpose JSCodeshift to handle this by treating JSCodeshift purely as a "Runner", or in other words, as the entrypoint to the files you're looking to modify and substitute a transformation library of your choice.
 For example [PostCSS](https://postcss.org/), [Babel](https://babeljs.io/), etc.
 
 However, this does come with drawbacks, you will no longer have access to JSCodeshift parsers and transformation API. This guide will explain how to handle these yourself.
@@ -91,10 +91,7 @@ const plugin = (): Plugin => {
     Declaration: decl => {
       if (decl[processed]) return;
 
-      decl.prop = decl.prop
-        .split('')
-        .reverse()
-        .join('');
+      decl.prop = decl.prop.split('').reverse().join('');
 
       decl[processed] = true;
     },

website/docs/guides/monorepos.mdx

@@ -90,7 +90,7 @@ ie:
 
 And show an interactive list for you to search and can choose from.
 
-## Publising
+## Publishing
 
 The workflow to publishing your codemod enhanced packages should remain completely unchanged.
 However, it's important to verify that your `codeshift.config.js` and codemods are not ignored by npm (via `.npmignore` or similar) so that they are successfully published to the registry.

website/docs/guides/prompting-for-human-input.mdx

@@ -13,7 +13,7 @@ Or in other words: **"Insert a comment"**.
 Inserting comments as codemod output is a completely valid thing to do and highlights to maintainers that they need to manually complete the migration.
 When leaving comments, it's helpful to be as descriptive as possible, including all or as much of the context required for the maintainer.
 
-Comments are also helpful because when a PR is raised, these prompts can easily be seen in the diff and actioned at the maintainers discression. The key is to make the surface area of your codemod known and let maintainers know where they're needed.
+Comments are also helpful because when a PR is raised, these prompts can easily be seen in the diff and actioned at the maintainers discretion. The key is to make the surface area of your codemod known and let maintainers know where they're needed.
 
 ## Inserting a comment
 

website/docs/guides/understanding-asts.mdx

@@ -14,7 +14,7 @@ Before writing your first codemod, it’s important to first have a good concept
 
 Abstract Syntax Trees can be thought of as simply the object representation of your code after being parsed.
 You might already be familiar with the tools and libraries that do this, for example [babeljs](https://babeljs.io/), [recast](https://github.com/benjamn/recast), [eslint](https://eslint.org/) etc.
-These tools parse files into ASTs in preperaton for some work, which generally consists of breaking a raw file down into "Nodes" which are then organized and categorized into a hierarchial format that can be reasoned about, manipulated and output back into a file.
+These tools parse files into ASTs in preparation for some work, which generally consists of breaking a raw file down into "Nodes" which are then organized and categorized into a hierarchial format that can be reasoned about, manipulated and output back into a file.
 
 ![Code — AST — AST(mutated) — Code](/img/ast.png)
 
@@ -28,7 +28,7 @@ For instance, consider this snippet:
 console.log('Hello, World');
 ```
 
-The way you might catagorise the anatomy of this expression in your mind is probably not too dissimilar to how it's actually done in [recast](https://github.com/benjamn/recast) (which is what is used in this project).
+The way you might categorise the anatomy of this expression in your mind is probably not too dissimilar to how it's actually done in [recast](https://github.com/benjamn/recast) (which is what is used in this project).
 So now compare it to the actual resulting AST, generated by recast.
 
 ```js
@@ -76,7 +76,7 @@ Every [Node](/docs/glossary#node) in this tree is given a "type", these types ar
 
 So for example, if you want to know the arguments this method contains, you could first look at the `arguments` property on the `ExpressionStatement`.
 Arguments in functions can be conceptually thought of as arrays, so it's no surprise that we're presented with an array here.
-Now we can see that in our array we have one element, which is of the type `StringLiteral` and has it's own meta data attached to it containing the value we're looking for: `Hello, World` – Hooray 🎉.
+Now we can see that in our array we have one element, which is of the type `StringLiteral` and has its own metadata attached to it containing the value we're looking for: `Hello, World` – Hooray 🎉.
 
 Great but where do we go from here? Well it totally depends on what you're trying to achieve.
 If you want to replace the message that's logged, all you'd have to do is replace the `StringLiteral` node with one containing the appropriate message.
@@ -94,7 +94,7 @@ How can one make sense of it all? Well luckily there are indispensable tools out
 ![AST Explorer screenshot](/img/astexplorer.png)
 
 It provides a real-time representation of your code as an AST which is inspectable and lets you write and test transforms against it live in the browser.
-It also supports other ASTs like babel, typescript etc. so for our usecase we'll need to configure it a bit to support recast + jscodeshift.
+It also supports other ASTs like babel, typescript etc. so for our use-case we'll need to configure it a bit to support recast + jscodeshift.
 
 To configure it, follow these steps:
 

website/docs/guides/your-first-codemod.mdx

@@ -35,7 +35,7 @@ Our transform will look something like this.
 
 ```ts
 export default function transform(file, { jscodeshift: j }, options) {
-  const source = j(file.source); // (1) Create an AST of the fiven file
+  const source = j(file.source); // (1) Create an AST of the given file
 
   const imports = source
     .find(j.ImportDeclaration) // (2) Find all import declarations!
@@ -50,16 +50,17 @@ export default function transform(file, { jscodeshift: j }, options) {
 If you prefer a more declarative approach, you can provide a second argument to `find` describing the expected shape of the node you are looking for.
 
 ```ts
-  const imports = source
-    .find(j.ImportDeclaration, { source: { value: 'my-module' } }) // Find all import declarations that match this shape
+const imports = source.find(j.ImportDeclaration, {
+  source: { value: 'my-module' },
+}); // Find all import declarations that match this shape
 ```
 
 This behaves like a fuzzy searcher: The more details provided the more narrow the search is.
 
 ## Modify & Insert
 
 Now let's say that we want to pull in a new import from 'my-module' called `baz`. Luckily you've already written a majority of the code above.
-All we'll need to do now is "insert" an new ImportSpecifier into the ImportDeclaration node that we've just retrieved.
+All we'll need to do now is "insert" an new `ImportSpecifier` into the `ImportDeclaration` node that we've just retrieved.
 
 Now inserting can look a little awkward at first, because what we're really doing is building a new node based on what we've found and replacing it with a modified version of itself.
 
@@ -92,7 +93,7 @@ Now there are a few moving pieces in this example, let's step through them:
 
 (1) Here we "build" a new node of type `ImportSpecifier`.
 
-You can build a node by using the camelCase variant methos of a node type.
+You can build a node by using the camelCase variant method of its node type.
 So to build an `ImportSpecifier` you use `j.importSpecifier(...)` and when you want to search for one, you use the CapitalCase variant `j.ImportSpecifier`.
 
 (2) Create a new import declaration
@@ -106,7 +107,7 @@ Here we push our new import specifier into the array of existing specifiers.
 
 (4) Replace the node
 
-Finally we replace our ImportDeclaration with our new one and the resulting output should look like this:
+Finally we replace our `ImportDeclaration` with our new one and the resulting output should look like this:
 
 ```diff
 -import { foo, bar } from 'my-module';

website/docs/guiding-principles.mdx

@@ -30,7 +30,7 @@ In these cases we recommend that you are aware of [when not to codemod](/docs/wh
 ## Codemods should do as much as can be safely done automatically or prompt for human intervention
 
 Writing a codemod to completely migrate a package from one working state to another is not always feasible. Some edge cases might simply be too hard to support.
-When this is the case, bailing out and pompting for human intervention should be your first fallback.
+When this is the case, bailing out and prompting for human intervention should be your first fallback.
 This gives consumers a chance to review the changes of the codemod, read the prompts containing context about the changes they need to action and make the remaining manual steps as painless and straight forward as possible.
 
 For more information, please see the [Prompting for human input](/docs/prompting-for-human-input) guide.

website/docs/introduction.mdx

@@ -57,12 +57,12 @@ By consolidating codemods in the same way, the ecosystem can benefit from:
 Ultimately, with the wider JS community collaborating to produce high quality versioned codemods, our goal is to achieve solid coverage over common js dependencies (ie react, jest, chalk, etc), in a similar way to how quality type definitions are created and shared within the DefinitelyTyped community.
 
 CodeshiftCommunity provides a similar registry that hosts and automatically publishes codemods for you under the [/community directory](https://github.com/CodeshiftCommunity/CodeshiftCommunity/tree/main/community).
-The community directory organizes codemods by package name and version. They are then published to npm as modules that can be retrospectivally patched or improved.
+The community directory organizes codemods by package name and version. They are then published to npm as modules that can be retrospectively patched or improved.
 This ensures that users running codemods are always getting the latest and greatest version of your codemod.
 
 ### Rich documentation
 
-CodeshiftCommunity is a documentation hub first, by provding guides, recipes and reference material we aim demystify codemods, which are often seen as "arcane knowledge".
+CodeshiftCommunity is a documentation hub first, by providing guides, recipes and reference material we aim demystify codemods, which are often seen as "arcane knowledge".
 
 With the right documentation and guidance in place, it will be significantly easier to normalize codemods and reduce their learning curve.
 We want to remove the stigma that "codemods are hard" or "they take a long time to write" and get everyone into the healthy practice of writing them.