Fix typos (#747)

* typos: fix typos

* typos: fix capitalization

* whitespace: remove trailing whitespace

* tree-sitter: remove executable permission from WASM files

They're not actually directly executable, so remove the bit.

Author: mathstuf

website/advanced/faq.md

@@ -197,7 +197,7 @@ If your rule depends on using meta variables in later rules, the best way is to
 
 ## `kind` and `pattern` rules are not working together, why?
 
-The most common scneario is that your pattern is parsed as a different AST node than you expected. And you may use `kind` rule to filter out the AST node you want to match. This does not work in ast-grep for two reasons:
+The most common scenario is that your pattern is parsed as a different AST node than you expected. And you may use `kind` rule to filter out the AST node you want to match. This does not work in ast-grep for two reasons:
 1. tree-sitter, the underlying parser library, does not offer a way to parse a string of a specific kind. So `kind` rule cannot be used to change the parsing outcome of a `pattern`.
 2. ast-grep rules are mostly independent of each other, except sharing meta-variables during a match. `pattern` will behave the same regardless of another `kind` rule.
 

website/blog/new-ver-38.md

@@ -34,7 +34,7 @@ One of the exciting new additions is the `labels` field for your rule configurat
 
 ![Example of Customizable Code Highlighting](/image/blog/labels-demo.png)
 
-But the benefits don't stop at individual understanding. The labels field offers a fantastic way to embed more guidance directly into your rules, and it allow you to share coding best practices, style guide reminders, or domain-specific knowledge across your entire team. This feature helps disseminate expertise and maintain consistency effortlessly. For example, [Sam Wight](https://github.com/samwightt), the lables feature's proposer, is using ast-grep to help his team to write better [Angular code](/catalog/typescript/missing-component-decorator.html)!
+But the benefits don't stop at individual understanding. The labels field offers a fantastic way to embed more guidance directly into your rules, and it allow you to share coding best practices, style guide reminders, or domain-specific knowledge across your entire team. This feature helps disseminate expertise and maintain consistency effortlessly. For example, [Sam Wight](https://github.com/samwightt), the labels feature's proposer, is using ast-grep to help his team to write better [Angular code](/catalog/typescript/missing-component-decorator.html)!
 
 ![Example of VSCode](/image/blog/labels-vscode.jpeg)
 

website/blog/optimize-ast-grep.md

@@ -114,7 +114,7 @@ ast-grep can match an AST node by rules, and those rules can be composed togethe
 For example, the rule `any: [rule1, rule2]` is a composite rule that consists of two sub-rules and the composite rule matches a node when either one of the sub-rules matches the node.
 This can be expensive since multiple rules must be tried for every node to see if they actually make a match.
 
-I have already forsee it so every rule in ast-grep has an optimzation called `potential_kinds`. AST node in tree-sitter has its own type encoded in a unsigned number called `kind`.
+I have already forsee it so every rule in ast-grep has an optimization called `potential_kinds`. AST node in tree-sitter has its own type encoded in a unsigned number called `kind`.
 If a rule can only match nodes with specific kinds, then we can avoid calling `match_node` for nodes if its kind is not in the `potential_kinds` set.
 I used a BitSet to encode the set of potential kinds. Naturally the `potential_kinds` of composite rules can be constructed by merging the `potential_kinds` of its sub-rules, according to their logic nature.
 For example, `any`'s potential_kinds is the union of its sub-rules' potential_kinds, and `all`'s potential_kinds is the intersection of its sub-rules' potential_kinds.

website/blog/stars-6000.md

@@ -93,4 +93,4 @@ As ast-grep continues to grow, we remain committed to providing a tool that not
 ![sponsors](/image/blog/sponsor2.png)
 
 
-We thank each and every one of you, espeically ast-grep's sponsors, for your support, contributions, and feedback that have shaped ast-grep into what it is today. Here's to many more milestones ahead!
+We thank each and every one of you, especially ast-grep's sponsors, for your support, contributions, and feedback that have shaped ast-grep into what it is today. Here's to many more milestones ahead!

website/blog/typed-napi.md

@@ -170,7 +170,7 @@ class SgNode<M extends TypesMap, K extends Kinds<M> = Kinds<M>> {
 }
 ```
 
-It represents a node in a language with type map `M` that has a specific kind `K`. e.g. `SgNode<TypeScript, "function_declaration">` means a function declaration node in TypeScript. When used without a specific kind parameter, `SgNode` defaults to accepting any valid node kind in the language.
+It represents a node in a language with type map `M` that has a specific kind `K`. E.g. `SgNode<TypeScript, "function_declaration">` means a function declaration node in TypeScript. When used without a specific kind parameter, `SgNode` defaults to accepting any valid node kind in the language.
 
 `SgNode` provides a **correct** AST interface in a specific language. While at the same time, it is still **robust** enough to not trigger compiler error when no type information is available.
 

website/catalog/python/recursive-rewrite-type.md

@@ -9,9 +9,9 @@ Suppose we want to transform Python's `Union[T1, T2]` to `T1 | T2` and `Optional
 
 By default, ast-grep will only fix the outermost node that matches a pattern and will not rewrite the inner AST nodes inside a match. This avoids unexpected rewriting or infinite rewriting loop.
 
-So if you are using non-recurisve rewriter like [this](https://github.com/ast-grep/ast-grep/discussions/1566#discussion-7401382), `Optional[Union[int, str]]` will only be converted to `Union[int, str] | None`. Note the inner `Union[int, str]` is not enabled. This is because the rewriter `optional` matches `Optional[$TYPE]` and rewrite it to `$TYPE | None`. The inner `$TYPE` is not processed.
+So if you are using non-recursive rewriter like [this](https://github.com/ast-grep/ast-grep/discussions/1566#discussion-7401382), `Optional[Union[int, str]]` will only be converted to `Union[int, str] | None`. Note the inner `Union[int, str]` is not enabled. This is because the rewriter `optional` matches `Optional[$TYPE]` and rewrite it to `$TYPE | None`. The inner `$TYPE` is not processed.
 
-However, we can apply `rewriters` to inner types recursively. Take the `optional` rewriter as an example, we need to apply rewriters, `optional` and `unioins`, **recursively** to `$TYPE` and get a new variable `$NT`.
+However, we can apply `rewriters` to inner types recursively. Take the `optional` rewriter as an example, we need to apply rewriters, `optional` and `unions`, **recursively** to `$TYPE` and get a new variable `$NT`.
 
 ### YAML
 ```yml

website/catalog/python/refactor-pytest-fixtures.md

@@ -31,7 +31,7 @@ utils:
 
 Pytest fixtures are declared with a decorator `@pytest.fixture`. We match the `function_definition` node that directly follows a `decorator` node. That decorator node must have a `fixture` identifier somewhere. This accounts for different location of the `fixture` node depending on the type of imports and whether the decorator is used as is or called with parameters.
 
-Pytest functions are fairly straghtforward to detect, as they always start with `test_` by convention.
+Pytest functions are fairly straightforward to detect, as they always start with `test_` by convention.
 
 The next utils builds onto those two to incrementally:
 - Find if a node is inside a pytest context (test/fixture)

website/catalog/typescript/find-import-identifiers.md

@@ -59,7 +59,7 @@ rule:
         - has:
             field: source
             pattern: $SOURCE
-    
+
     # REGULAR IMPORTS
     # ------------------------------------------------------------
     # import { ORIGINAL } from 'SOURCE'
@@ -79,7 +79,7 @@ rule:
               field: source
               pattern: $SOURCE
 
-    # DYNAMIC IMPORTS (Single Variable Assignment) 
+    # DYNAMIC IMPORTS (Single Variable Assignment)
     # ------------------------------------------------------------
     # const VAR_NAME = require('SOURCE')
     # ------------------------------------------------------------
@@ -105,7 +105,7 @@ rule:
                     - has: { field: function, regex: '^(require|import)$' }
                     - has: { field: arguments, has: { kind: string, pattern: $SOURCE } } # Capture source
 
-    # DYNAMIC IMPORTS (Destructured Shorthand Assignment)     
+    # DYNAMIC IMPORTS (Destructured Shorthand Assignment)
     # ------------------------------------------------------------
     # const { ORIGINAL } = require('SOURCE')
     # ------------------------------------------------------------
@@ -136,7 +136,7 @@ rule:
                         - has: { field: arguments, has: { kind: string, pattern: $SOURCE } } # Capture source
               stopBy: end # Search ancestors to find the correct variable_declarator
 
-    # DYNAMIC IMPORTS (Destructured Alias Assignment) 
+    # DYNAMIC IMPORTS (Destructured Alias Assignment)
     # ------------------------------------------------------------
     # const { ORIGINAL: ALIAS } = require('SOURCE')
     # ------------------------------------------------------------
@@ -177,7 +177,7 @@ rule:
               stopBy: end # Search ancestors to find the correct variable_declarator
             stopBy: end # Ensure we check ancestors for the variable_declarator
 
-    # DYNAMIC IMPORTS (Side Effect / Source Only) 
+    # DYNAMIC IMPORTS (Side Effect / Source Only)
     # ------------------------------------------------------------
     # require('SOURCE')
     # ------------------------------------------------------------
@@ -198,7 +198,7 @@ rule:
               kind: lexical_declaration
               stopBy: end # Search all ancestors up to the root
 
-    # NAMESPACE IMPORTS 
+    # NAMESPACE IMPORTS
     # ------------------------------------------------------------
     # import * as ns from 'mod'
     # ------------------------------------------------------------
@@ -216,7 +216,7 @@ rule:
             field: source
             pattern: $SOURCE
 
-    # SIDE EFFECT IMPORTS 
+    # SIDE EFFECT IMPORTS
     # ------------------------------------------------------------
     # import 'mod'
     # ------------------------------------------------------------
@@ -289,10 +289,10 @@ const asyncDynamicModule = await import('./async_dynamic1').then(module => modul
 const { originalIdentifier: aliasedDynamicImport} = await import('./async_dynamic2');
 
 // Comments in imports
-import /* test */ { 
+import /* test */ {
     // Comment in import
-    commentedImport 
-} from './commented'; // End of line comment 
+    commentedImport
+} from './commented'; // End of line comment
 ```
 
 ### Contributed by

website/guide/project/lint-rule.md

@@ -166,7 +166,7 @@ The label config object contains two fields: the required `style` and the option
   * `secondary` provides additional context for a diagnostic.
 * `message` specifies the message to be displayed along with the label.
 
-Note, a `label` meta-variable must have a corresponding AST node in the matched code because highlighting requires a range in the code for label. That is, the **label meta-variables must be defined in `rule` or `constraints`**. meta-variables in `transform` cannot be used in `labels` as they are not part of the matched AST node.
+Note, a `label` meta-variable must have a corresponding AST node in the matched code because highlighting requires a range in the code for label. That is, the **label meta-variables must be defined in `rule` or `constraints`**. Meta-variables in `transform` cannot be used in `labels` as they are not part of the matched AST node.
 
 ---
 

website/guide/rewrite-code.md

@@ -173,7 +173,7 @@ This is because it has two spaces indentation as a part of the fix string, and t
 
 **ast-grep rule can only fix one target node at one time by replacing the target node text with a new string.**
 
-Using `fix` string alone is not enough to handle complex cases where we need to delete surrounding nodes like a comma, or to change surrounding brackets. We may leave redundant text in the fixed code because we cannot delete the surrounding trivias around the matched node.
+Using `fix` string alone is not enough to handle complex cases where we need to delete surrounding nodes like a comma, or to change surrounding brackets. We may leave redundant text in the fixed code because we cannot delete the surrounding trivials around the matched node.
 
 To accommodate these scenarios, ast-grep's `fix` also accepts an advanced object configuration that specifies how to fix the matched AST node: `FixConfig`. It allows you to expand the matched AST node range via two additional rules.