Fix typos across documentation markdown files

compiler/CLAUDE.md

@@ -62,7 +62,7 @@ yarn snap minimize --update <path>
 
 ## Version Control
 
-This repository uses Sapling (`sl`) for version control. Sapling is similar to Mercurial: there is not staging area, but new/deleted files must be explicitlyu added/removed.
+This repository uses Sapling (`sl`) for version control. Sapling is similar to Mercurial: there is no staging area, but new/deleted files must be explicitly added/removed.
 
 ```bash
 # Check status

compiler/README.md

@@ -2,6 +2,6 @@
 
 React Compiler is a compiler that optimizes React applications, ensuring that only the minimal parts of components and hooks will re-render when state changes. The compiler also validates that components and hooks follow the Rules of React.
 
-More information about the design and architecture of the compiler are covered in the [Design Goals](./docs/DESIGN_GOALS.md).
+More information about the design and architecture of the compiler is covered in the [Design Goals](./docs/DESIGN_GOALS.md).
 
 More information about developing the compiler itself is covered in the [Development Guide](./docs/DEVELOPMENT_GUIDE.md).

compiler/docs/DESIGN_GOALS.md

@@ -8,7 +8,7 @@ The idea of React Compiler is to allow developers to use React's familiar declar
 
 * Bound the amount of re-rendering that happens on updates to ensure that apps have predictably fast performance by default.
 * Keep startup time neutral with pre-React Compiler performance. Notably, this means holding code size increases and memoization overhead low enough to not impact startup.
-* Retain React's familiar declarative, component-oriented programming model. Ie, the solution should not fundamentally change how developers think about writing React, and should generally _remove_ concepts (the need to use React.memo(), useMemo(), and useCallback()) rather than introduce new concepts.
+* Retain React's familiar declarative, component-oriented programming model. I.e., the solution should not fundamentally change how developers think about writing React, and should generally _remove_ concepts (the need to use React.memo(), useMemo(), and useCallback()) rather than introduce new concepts.
 * "Just work" on idiomatic React code that follows React's rules (pure render functions, the rules of hooks, etc).
 * Support typical debugging and profiling tools and workflows.
 * Be predictable and understandable enough by React developers — i.e. developers should be able to quickly develop a rough intuition of how React Compiler works.
@@ -19,12 +19,12 @@ The idea of React Compiler is to allow developers to use React's familiar declar
 The following are explicitly *not* goals for React Compiler:
 
 * Provide perfectly optimal re-rendering with zero unnecessary recomputation. This is a non-goal for several reasons:
-  * The runtime overhead of the extra tracking involved can outweight the cost of recomputation in many cases.
+  * The runtime overhead of the extra tracking involved can outweigh the cost of recomputation in many cases.
   * In cases with conditional dependencies it may not be possible to avoid recomputing some/all instructions.
   * The amount of code may regress startup times, which would conflict with our goal of neutral startup performance.
 * Support code that violates React's rules. React's rules exist to help developers build robust, scalable applications and form a contract that allows us to continue improving React without breaking applications. React Compiler depends on these rules to safely transform code, and violations of rules will therefore break React Compiler's optimizations.
 * Support legacy React features. Notably we will not support class components due to their inherent mutable state being shared across multiple methods with complex lifetimes and data flow.
-* Support 100% of the JavaScript language. In particular, we will not support rarely used features and/or features which are known to be unsafe or which cannot be modeled soundly. For example, nested classes that capture values from their closure are difficult to model accurately because of mutability, and `eval()` is unsafe. We aim to support the vast majority of JavaScript code (and the TypeScript and Flow dialects)
+* Support 100% of the JavaScript language. In particular, we will not support rarely used features and/or features which are known to be unsafe or which cannot be modeled soundly. For example, nested classes that capture values from their closure are difficult to model accurately because of mutability, and `eval()` is unsafe. We aim to support the vast majority of JavaScript code (and the TypeScript and Flow dialects).
 
 ## Design Principles
 
@@ -43,7 +43,7 @@ The core of the compiler is largely decoupled from Babel, using its own intermed
 
 - **Babel Plugin**: Determines which functions in a file should be compiled, based on the plugin options and any local opt-in/opt-out directives. For each component or hook to be compiled, the plugin calls the compiler, passing in the original function and getting back a new AST node which will replace the original.
 - **Lowering** (BuildHIR): The first step of the compiler is to convert the Babel AST into React Compiler's primary intermediate representation, HIR (High-level Intermediate Representation). This phase is primarily based on the AST itself, but currently leans on Babel to resolve identifiers. The HIR preserves the precise order-of-evaluation semantics of JavaScript, resolves break/continue to their jump points, etc. The resulting HIR forms a control-flow graph of basic blocks, each of which contains zero or more consecutive instructions followed by a terminal. The basic blocks are stored in reverse postorder, such that forward iteration of the blocks allows predecessors to be visited before successors _unless_ there is a "back edge" (ie a loop).
-- **SSA Conversion** (EnterSSA): The HIR is converted to HIR form, such that all Identifiers in the HIR are updated to an SSA-based identifier.
+- **SSA Conversion** (EnterSSA): The HIR is converted to SSA form, such that all Identifiers in the HIR are updated to an SSA-based identifier.
 - Validation: We run various validation passes to check that the input is valid React, ie that it does not break the rules. This includes looking for conditional hook calls, unconditional setState calls, etc.
 - **Optimization**: Various passes such as dead code elimination and constant propagation can generally improve performance and reduce the amount of instructions to be optimized later.
 - **Type Inference** (InferTypes): We run a conservative type inference pass to identify certain key types of data that may appear in the program that are relevant for further analysis, such as which values are hooks, primitives, etc. 

compiler/docs/DEVELOPMENT_GUIDE.md

@@ -17,7 +17,7 @@ yarn snap:build
 yarn snap --watch
 ```
 
-`snap` is our custom test runner, which creates "golden" test files that have the expected output for each input fixture, as well as the results of executing a specific input (or sequence of inputs) in both the uncompiled and compiler versions of the input.
+`snap` is our custom test runner, which creates "golden" test files that have the expected output for each input fixture, as well as the results of executing a specific input (or sequence of inputs) in both the uncompiled and compiled versions of the input.
 
 ### Compiling Arbitrary Files
 

compiler/packages/babel-plugin-react-compiler/README.md

@@ -2,4 +2,4 @@
 
 React Compiler is a compiler that optimizes React applications, ensuring that only the minimal parts of components and hooks will re-render when state changes. The compiler also validates that components and hooks follow the Rules of React.
 
-This package contains the React Compiler Babel plugin use in projects that make use of Babel. You can find instructions for using this plugin here: https://react.dev/learn/react-compiler
+This package contains the React Compiler Babel plugin used in projects that make use of Babel. You can find instructions for using this plugin here: https://react.dev/learn/react-compiler

compiler/packages/babel-plugin-react-compiler/src/Inference/MUTABILITY_ALIASING_MODEL.md

@@ -22,17 +22,17 @@ function Component() {
 
 The goal of mutability and aliasing inference is to understand the set of instructions that create/modify a, b, and c.
 
-In code, the mutability and aliasing model is compromised of the following phases:
+In code, the mutability and aliasing model is comprised of the following phases:
 
-* `InferMutationAliasingEffects`. Infers a set of mutation and aliasing effects for each instruction. The approach is to generate a set of candidate effects based purely on the semantics of each instruction and the types of the operands, then use abstract interpretation to determine the actual effects (or errros) that would apply. For example, an instruction that by default has a Capture effect might downgrade to an ImmutableCapture effect if the value is known to be frozen.
-* `InferMutationAliasingRanges`. Infers a mutable range (start:end instruction ids) for each value in the program, and annotates each Place with its effect type for usage in later passes. This builds a graph of data flow through the program over time in order to understand which mutations effect which values.
+* `InferMutationAliasingEffects`. Infers a set of mutation and aliasing effects for each instruction. The approach is to generate a set of candidate effects based purely on the semantics of each instruction and the types of the operands, then use abstract interpretation to determine the actual effects (or errors) that would apply. For example, an instruction that by default has a Capture effect might downgrade to an ImmutableCapture effect if the value is known to be frozen.
+* `InferMutationAliasingRanges`. Infers a mutable range (start:end instruction ids) for each value in the program, and annotates each Place with its effect type for usage in later passes. This builds a graph of data flow through the program over time in order to understand which mutations affect which values.
 * `InferReactiveScopeVariables`. Given the per-Place effects, determines disjoint sets of values that mutate together and assigns all identifiers in each set to a unique scope, and updates the range to include the ranges of all constituent values.
 
 Finally, `AnalyzeFunctions` needs to understand the mutation and aliasing semantics of nested FunctionExpression and ObjectMethod values. `AnalyzeFunctions` calls `InferFunctionExpressionAliasingEffectsSignature` to determine the publicly observable set of mutation/aliasing effects for nested functions.
 
 ## Mutation and Aliasing Effects
 
-The inference model is based on a set of "effects" that describe subtle aspects of mutation, aliasing, and other changes to the state of values over time
+The inference model is based on a set of "effects" that describe subtle aspects of mutation, aliasing, and other changes to the state of values over time.
 
 ### Creation Effects
 
@@ -69,7 +69,7 @@ Describes the creation of new function value, capturing the given set of mutable
     kind: 'Apply';
     receiver: Place;
     function: Place; // same as receiver for function calls
-    mutatesFunction: boolean; // indicates if this is a type that we consdier to mutate the function itself by default
+    mutatesFunction: boolean; // indicates if this is a type that we consider to mutate the function itself by default
     args: Array<Place | SpreadPattern | Hole>;
     into: Place; // where result is stored
     signature: FunctionSignature | null;
@@ -314,7 +314,7 @@ Mutate b
 Mutate a
 ```
 
-A derived value changes when it's source value is mutated.
+A derived value changes when its source value is mutated.
 
 Example:
 
@@ -526,7 +526,7 @@ Capture c <- a
 
 Intuition: these effects are inverses of each other (capturing into an object, extracting from an object). The result is based on the order of operations:
 
-Capture then CreatFrom is equivalent to Alias: we have to assume that the result _is_ the original value and that a local mutation of the result could mutate the original.
+Capture then CreateFrom is equivalent to Alias: we have to assume that the result _is_ the original value and that a local mutation of the result could mutate the original.
 
 ```js
 const b = [a]; // capture

compiler/packages/react-mcp-server/README.md

@@ -19,4 +19,4 @@ First, add this file if you're using Claude Desktop: `code ~/Library/Application
 }
 ```
 
-Next, run `yarn workspace react-mcp-server watch` from the `react/compiler` directory and make changes as needed. You will need to restart Claude everytime you want to try your changes.
+Next, run `yarn workspace react-mcp-server watch` from the `react/compiler` directory and make changes as needed. You will need to restart Claude every time you want to try your changes.

compiler/packages/react-mcp-server/todo.md

@@ -1,5 +1,5 @@
 TODO
 
-- [ ] If code doesnt compile, read diagnostics and try again
+- [ ] If code doesn't compile, read diagnostics and try again
 - [ ] Provide detailed examples in assistant prompt (use another LLM to generate good prompts, iterate from there)
 - [ ] Provide more tools for working with HIR/AST (eg so we can prompt it to try and optimize code via HIR, which it can then translate back into user code changes)

packages/dom-event-testing-library/README.md

@@ -3,7 +3,7 @@
 A library for unit testing events via high-level interactions, e.g., `pointerdown`,
 that produce realistic and complete DOM event sequences.
 
-There are number of challenges involved in unit testing modules that work with
+There are a number of challenges involved in unit testing modules that work with
 DOM events.
 
 1. Gesture recognizers may need to support environments with and without support for

packages/eslint-plugin-react-hooks/src/code-path-analysis/README.md

@@ -1,6 +1,6 @@
 # Code Path Analyzer
 
-This code is a forked version of ESLints Code Path Analyzer which includes
+This code is a forked version of ESLint's Code Path Analyzer which includes
 support for Component Syntax.
 
 Forked from: https://github.com/eslint/eslint/tree/main/lib/linter/code-path-analysis

packages/react-devtools/CONTRIBUTING.md

@@ -53,7 +53,7 @@ yarn start
 Now any changes you make to DevTools will automatically reload in the test app at http://localhost:8080
 
 ### Option 2: Using the extension
-Some changes requiring testing in the browser extension (e.g. like "named hooks"). To do this, run the following script:
+Some changes require testing in the browser extension (e.g. like "named hooks"). To do this, run the following script:
 ```sh
 cd <react-repo>
 cd packages/react-devtools-extensions

packages/react-devtools/OVERVIEW.md

@@ -49,7 +49,7 @@ Later operations will reference strings by a one-based index. For example, `1` w
 
 #### Adding a root node
 
-Adding a root to the tree requires sending 5 numbers:
+Adding a root to the tree requires sending 7 numbers:
 
 1. add operation constant (`1`)
 1. fiber id
@@ -234,7 +234,7 @@ for (let i = 0; i < this._roots.length; i++) {
 }
 ```
 
-We skip the root itself because don't display them in the tree:
+We skip the root itself because we don't display them in the tree:
 ```js
 const firstChildID = root.children[0];
 ```

packages/react-devtools/README.md

@@ -112,7 +112,7 @@ Or you could develop with a local HTTP server like [`serve`](https://www.npmjs.c
 ### The React tab shows no components
 
 #### The Issue with Chrome v101 and earlier
-As we migrate to a Chrome Extension Manifest V3, we start to use a new method to hook the DevTools with the inspected page. This new method is more secure, but relies on a new API that's only supported in Chrome v102+. For Chrome v101 or earlier, we use a fallback method, which can cause malfunctions (e.g. failure to load React Elements in the Components tab) if the JS resources on your page is loaded from cache. Please upgrade to Chrome v102+ to avoid this issue.
+As we migrate to a Chrome Extension Manifest V3, we start to use a new method to hook the DevTools with the inspected page. This new method is more secure, but relies on a new API that's only supported in Chrome v102+. For Chrome v101 or earlier, we use a fallback method, which can cause malfunctions (e.g. failure to load React Elements in the Components tab) if the JS resources on your page are loaded from cache. Please upgrade to Chrome v102+ to avoid this issue.
 
 #### Service Worker malfunction
 Go to chrome://extensions. If you see "service worker (inactive)" in the React Developer Tools extension, try disabling and re-enabling the extension. This will restart the service worker. Then go to the page you want to inspect, close the DevTools, and reload the page. Open the DevTools again and the React components tab should be working.