docs: fix various typos (#6001)

Co-authored-by: ematipico <[email protected]>
Co-authored-by: siketyan <[email protected]>

Author: 3 people

CONTRIBUTING.md

@@ -39,7 +39,7 @@ We can use help in a bunch of areas and any help is greatly appreciated!
 
 ## Asking questions, making proposals
 
-If you have any questions, proposals, or feedbacks, open a [GitHub discussion](https://github.com/biomejs/biome/discussions).
+If you have any questions, proposals, or feedback, open a [GitHub discussion](https://github.com/biomejs/biome/discussions).
 Make sure your comment adds value: [don't post a comment just to get attention](https://jacobtomlinson.dev/posts/2022/dont-be-that-open-source-user-dont-be-me/).
 
 Our [Discord server](https://biomejs.dev/chat) is open for help and more ad-hoc discussion.
@@ -88,7 +88,7 @@ You can install `just` using cargo:
 cargo install just
 ```
 
-But we **highly recommend** to [install it using an OS package manager](https://github.com/casey/just#packages),  so you won't need to prefix every command with `cargo`.
+But we **highly recommend** to [install it using an OS package manager](https://github.com/casey/just#packages), so you won't need to prefix every command with `cargo`.
 
 Once installed, run the following command to install the required tools:
 
@@ -264,7 +264,7 @@ When you finished your work, and you are ready to **commit and open a PR**, ther
 things you would need to run and check:
 - `just f` (alias for `just format`), formats Rust and TOML files.
 - `just l` (alias for `just lint`), run the linter for the whole project.
-- Code generation. The code generation of the repository is spread in the different parts of the code base. Sometimes is needed and sometime it isn't:
+- Code generation. The code generation of the repository is spread in the different parts of the codebase. Sometimes is needed and sometime it isn't:
   - run `just gen-analyzer` when you're working on the **linter**;
   - run `just gen-bindings` in case you worked around the **workspace**.
 
@@ -327,7 +327,7 @@ For more information on how to help with translation, please see the [translatio
 ## Commit messages
 
 Internally, the Biome team adheres as closely as possible to the [conventional commit specification](https://www.conventionalcommits.org/en/v1.0.0-beta.2/).
-The following this convention encourages commit best-practices and facilitates commit-powered features like change log generation.
+The following this convention encourages commit best-practices and facilitates commit-powered features like changelog generation.
 
 The following commit prefixes are supported:
 
@@ -405,7 +405,7 @@ We are very strict about `major` changes in the `@biomejs/biome` package. To bet
 The description of the changeset should follow the these guidelines:
 
 - Use the past tense when describing what you did, e.g. "Added new feature", "Fixed edge case".
-- Use the present tense when describing Biome behaviour, e.g. "Biome now supports ...".
+- Use the present tense when describing Biome behavior, e.g. "Biome now supports ...".
 - If you fixed a bug, please add the link to the issue, e.g. "Fixed [#4444](https://github.com/biomejs/biome/issues/4444)".
 - If you reference a rule, please add the link to the rule on the website, e.g. "Added the rule [`useAwesomeThing`](https://biomejs.dev/linter/rules/use-awesome-thing/)" (even if the website isn't updated yet, the URL is pretty predictable...).
 - Similarly, if you reference an assist, please add the link to the assist on the website, e.g. "Added the assist [`awesomeAction`](https://biomejs.dev/assist/actions/awesome-action/)".

GOVERNANCE.md

@@ -199,7 +199,7 @@ We have a reasonably liberal approach to code review and merging. We value quick
 - If there are comments or suggestions after a PR is merged after the fact, allow yourself time to address them in a follow-up PR. If you don't respond in a reasonable timeframe, then create an issue to track.
 - Ensure that the PR summary is detailed, listing steps you took to verify the rationale and relevant issues and people involved in any prior discussion.
 - Ensure that PRs contain adequate tests and code comments for a future contributor to derive intent and modify your code safely.
-- You are welcome to the repos for your WIP branches. If you don't use your own fork, prepend the name of the branch with your github handle, e.g. `<handle>/experiment-code` Branches that have more than four months of inactivity will be pruned.
+- You are welcome to the repos for your WIP branches. If you don't use your own fork, prepend the name of the branch with your GitHub handle, e.g. `<handle>/experiment-code` Branches that have more than four months of inactivity will be pruned.
 - If you add a new feature, ensure it has been discussed or approved on GitHub or Discord.
 - If necessary, identify potential owners for PR review and approval.
 - All code must go through Pull Requests (PR) and pass status checks before being merged. If a PR is merged that breaks `main` due to the branch not being up-to-date, then it should either be reverted or a quick fix merged as a separate PR.

crates/biome_analyze/CONTRIBUTING.md

@@ -40,7 +40,7 @@ The analyzer allows implementors to create **four different** types of rules:
     - [Using Rule Options](#using-rule-options)
     - [Full Documentation Example](#full-documentation-example)
   - [Code generation](#code-generation)
-  - [Commiting your work](#commiting-your-work)
+  - [Committing your work](#commiting-your-work)
   - [Sidenote: Deprecating a rule](#sidenote-deprecating-a-rule)
 
 ## Creating a Rule
@@ -131,7 +131,7 @@ Here is a non-exhaustive list of common names:
 
   These rules report errors which are the result of mistyping and led to runtime errors or ignored code.
   This naming convention is used for CSS rules.
-  For example, `noUnknownUnit` reports CSS units that are not standarized.
+  For example, `noUnknownUnit` reports CSS units that are not standardized.
 
 - `noMisleading<Concept>`
 
@@ -155,8 +155,8 @@ Here is a non-exhaustive list of common names:
 
 - `useConsistent<Concept>`
 
-  These rules ensure consistency across the entire code base.
-  For example, `useConsistentArrayType` ensures that developers use either `Arra<T>` or `T[]`.
+  These rules ensure consistency across the entire codebase.
+  For example, `useConsistentArrayType` ensures that developers use either `Array<T>` or `T[]`.
 
 - `useShorthand<Concept>`
 
@@ -210,7 +210,7 @@ Let's say we want to create a new **lint** rule called `useMyRuleName`, follow t
    The script `just new-js-lintrule` script will generate a bunch of files for the _JavaScript_ language inside the `biome_js_analyze` crate.
    Among the other files, you'll find a file called `use_my_rule_name.rs` inside the `biome_js_analyze/lib/src/lint/nursery` folder. You'll implement your rule in this file.
 
-2. Let's have a look at the generated code in  `use_my_rule_name.rs`:
+2. Let's have a look at the generated code in `use_my_rule_name.rs`:
 
    ```rust
    ...
@@ -388,7 +388,7 @@ declare_lint_rule! {
 
 If a **lint** rule is inspired by an existing rule from other ecosystems (ESLint, ESLint plugins, clippy, etc.), you can add a new metadata to the macro called `source`. Its value is `&'static [RuleSource]`, which is a reference to a slice of `RuleSource` elements, each representing a different source.
 
-If you're implementing a lint rule that matches the behaviour of the ESLint rule `no-debugger`, you'll use the variant `::ESLint` and pass the name of the rule:
+If you're implementing a lint rule that matches the behavior of the ESLint rule `no-debugger`, you'll use the variant `::ESLint` and pass the name of the rule:
 
 ```rust
 use biome_analyze::{declare_lint_rule, RuleSource};
@@ -405,7 +405,7 @@ declare_lint_rule! {
 }
 ```
 
-If the rule you're implementing has a different behaviour or option, you can add the `source_kind` metadata and use the `RuleSourceKind::Inspired` type. If there are multiple sources, we assume that each source has the same `source_kind`.
+If the rule you're implementing has a different behavior or option, you can add the `source_kind` metadata and use the `RuleSourceKind::Inspired` type. If there are multiple sources, we assume that each source has the same `source_kind`.
 
 ```rust
 use biome_analyze::{declare_lint_rule, RuleSource, RuleSourceKind};
@@ -621,7 +621,7 @@ and do not need to be handled by the rule itself.
 > We instead provide a ***`serde`-inspired*** implementation in `biome_deserialize` and `biome_deserialize_macros` that [differs in some aspects](../biome_deserialize/README.md), like being fault-tolerant.
 
 The compiler should warn you that `MyRuleOptions` does not implement some required types.
-We currently require implementing _serde_'s traits `Deserialize`/`Serialize`.
+We currently require implementing _serde_'s `Deserialize`/`Serialize` traits.
 
 Also, we use other `serde` macros to adjust the JSON configuration:
 - `rename_all = "camelCase"`: it renames all fields in camel-case, so they are in line with the naming style of the `biome.json`.
@@ -708,7 +708,7 @@ The semantic model provides information about the references of a binding (decla
 
 ##### How to use the query `Semantic<>` in a lint rule
 
-We have a for loop that creates an index i, and we need to identify where this index is used inside the body of the loop
+We have a for loop that creates an index `i`, and we need to identify where this index is used inside the body of the loop
 
 ```js
 for (let i = 0; i < array.length; i++) {
@@ -951,7 +951,7 @@ There are some common mistakes that can lead to bugs or false positives in lint
 
 ##### Not checking if a variable is global
 
-Some rules aim to ban certain functions or variables (eg. `noConsoleLog` bans `console.log`). A common mistake make this check without considering if the variable is global or not. This can lead to false positives if the variable is declared in a local scope.
+Some rules aim to ban certain functions or variables (e.g. `noConsoleLog` bans `console.log`). A common mistake make this check without considering if the variable is global or not. This can lead to false positives if the variable is declared in a local scope.
 
 ```js
 console.log(); // <-- This should be reported because `console` is a global variable
@@ -1030,7 +1030,7 @@ Run the command:
 just test-lintrule myRuleName
 ```
 
-and if you've done everything correctly, you should see some snapshots emitted with diagnostics and code actions.
+And if you've done everything correctly, you should see some snapshots emitted with diagnostics and code actions.
 
 Check our main [contribution document](https://github.com/biomejs/biome/blob/main/CONTRIBUTING.md#testing) to know how to deal with the snapshot tests.
 
@@ -1285,7 +1285,7 @@ For simplicity, use `just` to run all the commands with:
 just gen-analyzer
 ```
 
-### Commiting your work
+### Committing your work
 
 Once the rule is implemented, tested and documented, you are ready to open a pull request!
 

crates/biome_js_type_info/CONTRIBUTING.md

@@ -57,7 +57,7 @@ own challenges.
 ## Type Data Structures
 
 In Biome, the most basic data structure for type information is a giant `enum`,
-called `TypeData`, defined in [type_info.rs](src/type_info.rs).
+called `TypeData`, defined in [`type_info.rs`](src/type_info.rs).
 
 This enum has many different variants in order to cover all the different kinds
 of types that TypeScript supports. But a few are specifically
@@ -157,7 +157,7 @@ Local inference doesn't do any type resolution yet, it only creates type
 references. So in most cases we won't know a concrete type yet, but it still
 provides a useful starting point for later inference.
 
-Local inference is implemented in [local_inference.rs](src/local_inference.rs).
+Local inference is implemented in [`local_inference.rs`](src/local_inference.rs).
 
 ### Module-Level ("Thin") Inference
 
@@ -202,7 +202,7 @@ But ultimately, if not even a global declaration was found, then we're at a loss
 and fall back to `TypeReference::Unknown`.
 
 Thin inference is implemented in
-[js_module_info/collector.rs](../biome_module_graph/src/js_module_info/collector.rs).
+[`js_module_info/collector.rs`](../biome_module_graph/src/js_module_info/collector.rs).
 
 ## Full Inference
 
@@ -216,21 +216,21 @@ we've seen before: Such a cache would get stale the moment a module is replaced,
 and we don't want to have complex cache invalidation schemes.
 
 Full inference is implemented in
-[scoped_resolver.rs](../biome_module_graph/src/js_module_info/scoped_resolver.rs).
+[`scoped_resolver.rs`](../biome_module_graph/src/js_module_info/scoped_resolver.rs).
 
 ## Type Resolvers
 
 The thing about having all these type references all over the place is that you
 need to perform explicit type resolution to follow these references. That's why
 we have _type resolvers_. There's a `TypeResolver` trait, defined in
-[resolver.rs](src/resolver.rs). As of today, we have 6 implementations of it:
+[`resolver.rs`](src/resolver.rs). As of today, we have 6 implementations of it:
 
 * **`HardcodedSymbolResolver`**. This one is purely for test purposes.
 * **`GlobalsResolver`**. This is the one that is responsible for resolving
   globals such as `Promise` and `Array`. The way we do this is still rather
   primitive with hardcoded, predefined symbols. At some point we probably should
   be able to use TypeScript's own global `.d.ts` files, such as
-  [es2023.array.d.ts](https://github.com/microsoft/TypeScript/blob/main/src/lib/es2023.array.d.ts),
+  [`es2023.array.d.ts`](https://github.com/microsoft/TypeScript/blob/main/src/lib/es2023.array.d.ts),
   directly.
 * **`JsModuleInfoCollector`**. This one is responsible for collecting
   information about a module, and for performing our module-level inference.
@@ -285,7 +285,7 @@ both `left` and `right` resolve to `TypeData::Number`, the entire expression can
 be _flattened_ to `TypeData::Number`, because that's the result of adding two
 numbers. And in most other cases it will become `TypeData::String` instead.
 
-Flattening is implemented in [flattening.rs](src/flattening.rs).
+Flattening is implemented in [`flattening.rs`](src/flattening.rs).
 
 ## `ResolvedTypeData`
 

crates/biome_parser/CONTRIBUTING.md

@@ -208,7 +208,7 @@ if !p.at(T![if]) {
 }
 ```
 
-Why return `ParsedSyntax::Absent`? The function must return `ParsedSyntax::Absent` if the rule can't predict by the next token(s) if they form the expected node or not. Doing so allows the calling rule to decide if this is an error and perform an error recovery if necessary.  The second reason is to ensure that the rule doesn't return a node where all children are missing.
+Why return `ParsedSyntax::Absent`? The function must return `ParsedSyntax::Absent` if the rule can't predict by the next token(s) if they form the expected node or not. Doing so allows the calling rule to decide if this is an error and perform an error recovery if necessary. The second reason is to ensure that the rule doesn't return a node where all children are missing.
 
 Your rule implementation may want to consider more than just the first child to determine if it can parse at least some of the expected children.
 For example, the if statement rule could test if the parser is located at an `else` clause and then create an `if` statement where all children are missing except the `else` clause:
@@ -358,7 +358,7 @@ In these cases the `ParseSeparatedList` and `ParseNodeList` will recover the par
 The conditional syntax allows you to express that some syntax may not be valid in all source files. Some use cases are:
 
 * syntax that is only supported in strict or sloppy mode: for example, `with` statements is not valid when a JavaScript file uses `"use strict"` or is a module;
-* syntax that is only supported in certain file types: Typescript, JSX, modules;
+* syntax that is only supported in certain file types: TypeScript, JSX, modules;
 * syntax that is only available in specific language versions: experimental features, different versions of the language e.g. (ECMA versions for JavaScript);
 
 The idea is that the parser always parses the syntax regardless of whatever it is supported in this specific file or context.

crates/biome_service/CONTRIBUTING.md

@@ -17,16 +17,16 @@ Note that there are two implementations of the `Workspace` trait:
 
 ## Watcher
 
-The state inside our workspace is kept in sync with the file system using the
+The state inside our workspace is kept in sync with the filesystem using the
 [`WorkspaceWatcher`](src/workspace_watcher.rs). The watcher is only active in
 daemon mode and not used by the CLI.
 
 ### Debugging
 
 Debugging the watcher can be tricky, because you need to run the daemon,
-interact with the file system, and observe the daemon's state somehow.
+interact with the filesystem, and observe the daemon's state somehow.
 
-Debugging is possible with the VS Code extension or Zed extension,  but for an easier experience,
+Debugging is possible with the VS Code extension or Zed extension, but for an easier experience,
 you can use these CLI commands:
 
 1. Start the daemon using `cargo run --bin=biome -- start`. Note there won't be