chore: format markdown

Author: HerringtonDarkholme

dprint.json

@@ -52,4 +52,4 @@
     "https://plugins.dprint.dev/g-plane/markup_fmt-v0.23.0.wasm",
     "https://plugins.dprint.dev/g-plane/pretty_yaml-v0.5.1.wasm"
   ]
-}
+}

website/advanced/custom-language.md

@@ -100,9 +100,9 @@ You need to add a new entry under the `customLanguages` key with the name of you
 ruleDirs: ["./rules"]
 customLanguages:
   mojo:
-      libraryPath: mojo.so     # path to dynamic library
-      extensions: [mojo, 🔥]   # file extensions for this language
-      expandoChar: _           # optional char to replace $ in your pattern
+    libraryPath: mojo.so # path to dynamic library
+    extensions: [mojo, 🔥] # file extensions for this language
+    expandoChar: _ # optional char to replace $ in your pattern
 ```
 
 The `libraryPath` property specifies the path to the dynamic library relative to the `sgconfig.yml` file or an absolute path. The `extensions` property specifies a list of file extensions for this language.
@@ -130,7 +130,7 @@ Or you can write a rule in yaml like this:
 
 ```yaml
 id: my-first-mojo-rule
-language: mojo  # the name we register before!
+language: mojo # the name we register before!
 severity: hint
 rule:
   pattern: print

website/advanced/faq.md

@@ -57,7 +57,7 @@ Different results are usually caused by incomplete or wrong code snippet in the
 ```yaml
 rule:
   pattern:
-    context: 'int main() { return 0; }'
+    context: "int main() { return 0; }"
     selector: function
 ```
 
@@ -113,7 +113,7 @@ The workaround is using [`constraints`](https://ast-grep.github.io/guide/project
 rule:
   pattern: $HOOK($$$ARGS)
 constraints:
-  HOOK: { regex: '^use' }
+  HOOK: { regex: "^use" }
 ```
 
 [Example usage](/playground.html#eyJtb2RlIjoiQ29uZmlnIiwibGFuZyI6ImphdmFzY3JpcHQiLCJxdWVyeSI6ImZvbygkJCRBLCBiLCAkJCRDKSIsInJld3JpdGUiOiIiLCJjb25maWciOiJydWxlOlxuICBwYXR0ZXJuOiAkSE9PSygkJCRBUkdTKVxuY29uc3RyYWludHM6XG4gIEhPT0s6IHsgcmVnZXg6IF51c2UgfSIsInNvdXJjZSI6ImZ1bmN0aW9uIFJlYWN0Q29tcG9uZW50KCkge1xuICAgIGNvbnN0IGRhdGEgPSBub3RIb28oKVxuICAgIGNvbnN0IFtmb28sIHNldEZvb10gPSB1c2VTdGF0ZSgnJylcbn0ifQ==).
@@ -153,10 +153,10 @@ id: recursive-call
 language: JavaScript
 rule:
   all:
-  - pattern: function $F() { $$$ }
-  - has:
-      pattern: $F()
-      stopBy: end
+    - pattern: function $F() { $$$ }
+    - has:
+        pattern: $F()
+        stopBy: end
 ```
 
 ```js [match.js]
@@ -177,10 +177,10 @@ id: recursive-call
 language: JavaScript
 rule:
   all:
-  - has:  # N.B. has is the first rule
-      pattern: $F()
-      stopBy: end
-  - pattern: function $F() { $$$ }
+    - has: # N.B. has is the first rule
+        pattern: $F()
+        stopBy: end
+    - pattern: function $F() { $$$ }
 ```
 
 In this case, the `has` rule matches first and captures `$F` as `foo` since `foo()` is the first function call matching the pattern `$F()`. The later rule `function $F() { $$$ }` will only find the `foo` declaration instead of `recurse`.
@@ -208,8 +208,8 @@ For example, to match class field in JavaScript, a kind + pattern rule [will not
 
 ```yaml
 # these are two separate rules
-pattern: a = 123          # rule 1
-kind: field_definition    # rule 2
+pattern: a = 123 # rule 1
+kind: field_definition # rule 2
 ```
 
 This is because pattern `a = 123` is parsed as [`assignment_expression`](/playground.html#eyJtb2RlIjoiUGF0Y2giLCJsYW5nIjoiamF2YXNjcmlwdCIsInF1ZXJ5IjoiYSA9IDEyMyIsInJld3JpdGUiOiIiLCJzdHJpY3RuZXNzIjoic21hcnQiLCJzZWxlY3RvciI6IiIsImNvbmZpZyI6IiIsInNvdXJjZSI6IiJ9). Pattern and kind are two separate rules. And using them together will match nothing because no AST will have both `assignment_expression` and `field_definition` kind at once.
@@ -219,8 +219,8 @@ Instead, you need to use pattern object to provide enough context code for the p
 ```yaml
 # this is one single pattern rule!
 pattern:
-  context: 'class A { a = 123 }' # provide full context code
-  selector: field_definition     # select the effective pattern
+  context: "class A { a = 123 }" # provide full context code
+  selector: field_definition # select the effective pattern
 ```
 
 Note the rule above is one single pattern rule, instead of two. The `context` field provides the full unambiguous code snippet of `class`. So the `a = 123` will be parsed as `field_definition`. The `selector` field then selects the `field_definition` node as the [effective pattern](/advanced/pattern-parse.html#steps-to-create-a-pattern) matcher.

website/advanced/find-n-patch.md

@@ -128,11 +128,11 @@ To do this, we register a rewriter that acts as a separate rewriter rule for eac
 
 ```yaml
 rewriters:
-- id: rewrite-identifer
-  rule:
-    pattern: $IDENT
-    kind: identifier
-  fix: import $IDENT from './barrel/$IDENT'
+  - id: rewrite-identifer
+    rule:
+      pattern: $IDENT
+      kind: identifier
+    fix: import $IDENT from './barrel/$IDENT'
 ```
 
 The `rewrite-identifier` above will:
@@ -168,11 +168,11 @@ The final rule will be like this. See the [online playground](https://ast-grep.g
 rule:
   pattern: import {$$$IDENTS} from './barrel'
 rewriters:
-- id: rewrite-identifer
-  rule:
-    pattern: $IDENT
-    kind: identifier
-  fix: import $IDENT from './barrel/$IDENT'
+  - id: rewrite-identifer
+    rule:
+      pattern: $IDENT
+      kind: identifier
+    fix: import $IDENT from './barrel/$IDENT'
 transform:
   IMPORTS:
     rewrite:

website/advanced/language-injection.md

@@ -111,10 +111,10 @@ You can add the `languageInjections` section in the project configuration file `
 
 ```yaml
 languageInjections:
-- hostLanguage: js
-  rule:
-    pattern: styled.$TAG`$CONTENT`
-  injected: css
+  - hostLanguage: js
+    rule:
+      pattern: styled.$TAG`$CONTENT`
+    injected: css
 ```
 
 Let's break the configuration down.
@@ -183,8 +183,8 @@ First, we need to register graphql as a custom language in ast-grep. See [custom
 customLanguages:
   graphql:
     libraryPath: graphql.so # the graphql tree-sitter parser dynamic library
-    extensions: [graphql]   # graphql file extension
-    expandoChar: $          # see reference above for explanation
+    extensions: [graphql] # graphql file extension
+    expandoChar: $ # see reference above for explanation
 ```
 
 ### Define graphql injection in `sgconfig.yml`.
@@ -193,10 +193,10 @@ Next, we need to customize what region should be parsed as graphql string in Jav
 
 ```yaml
 languageInjections:
-- hostLanguage: js
-  rule:
-    pattern: graphql`$CONTENT`
-  injected: graphql
+  - hostLanguage: js
+    rule:
+      pattern: graphql`$CONTENT`
+    injected: graphql
 ```
 
 ### Search GraphQL in JavaScript

website/advanced/pattern-parse.md

@@ -103,7 +103,7 @@ Without other hints, ast-grep will parse it as labeled statement by default. To
 
 ```yaml
 pattern:
-  context: '{ a: 123 }'
+  context: "{ a: 123 }"
   selector: pair
 ```
 
@@ -155,8 +155,8 @@ Examples:
 
 ```yaml
 program
-  expression_statement
-    number              <--- effective node
+expression_statement
+number              <--- effective node
 ```
 
 See [Playground](/playground.html#eyJtb2RlIjoiUGF0Y2giLCJsYW5nIjoiamF2YXNjcmlwdCIsInF1ZXJ5IjoiMTIzIiwicmV3cml0ZSI6IiIsInN0cmljdG5lc3MiOiJzbWFydCIsInNlbGVjdG9yIjoiIiwiY29uZmlnIjoiIiwic291cmNlIjoiIn0=).
@@ -165,11 +165,11 @@ See [Playground](/playground.html#eyJtb2RlIjoiUGF0Y2giLCJsYW5nIjoiamF2YXNjcmlwdC
 
 ```yaml
 program
-  expression_statement
-    call_expression       <--- effective node
-      identifier
-      arguments
-        identifier
+expression_statement
+call_expression       <--- effective node
+identifier
+arguments
+identifier
 ```
 
 See [Playground](/playground.html#eyJtb2RlIjoiUGF0Y2giLCJsYW5nIjoiamF2YXNjcmlwdCIsInF1ZXJ5IjoiZm9vKGJhcikiLCJyZXdyaXRlIjoiIiwic3RyaWN0bmVzcyI6InNtYXJ0Iiwic2VsZWN0b3IiOiJjYWxsX2V4cHJlc3Npb24iLCJjb25maWciOiIiLCJzb3VyY2UiOiIifQ==).

website/blog/yaml-vs-dsl.md

@@ -16,15 +16,13 @@ head:
   - - meta
     - property: og:description
       content: YAML and DSL are two different approaches to configure rule in structural search. The question "which is better" is largely subjective.
-
 ---
 
 # YAML vs DSL: comparison is subjective
 
 As stated in the [tool comparison](/advanced/tool-comparison.html#gritql), YAML configuration and DSL (Domain Specific Language) are two different approaches to configure rules in structural search. The question "which is better" is largely subjective.
 
-However, recently I have received some feedback that YAML is __objectively__ not as good as DSL, and I would like to clarify some points.
-
+However, recently I have received some feedback that YAML is **objectively** not as good as DSL, and I would like to clarify some points.
 
 The original argument is quoted as follows:
 
@@ -56,7 +54,6 @@ This argument is a [slippery slope fallacy](https://en.wikipedia.org/wiki/Slippe
 
 Using one concept in your library, framework or tool does not imply that you have to design a whole new syntax for it. The similar comparison will be frontend frameworks. Some frameworks like React and Vue use [hook](https://react.dev/reference/react/hooks) or [signals](https://dev.to/this-is-learning/the-evolution-of-signals-in-javascript-8ob) to represent state changes. But using these building blocks does not grant the verdict to design a new language for your frontend framework. Even the most avant-garde company only introduces [new syntax](https://flow.org/en/docs/react/hook-syntax/) in JavaScript, not inventing a new language.
 
-
 ### Subjective opinion is not objective fact
 
 > I think GritQL queries are significantly easier to read than ast-grep's mix of DSL of YAML.
@@ -88,9 +85,9 @@ Biome's DSL is a mix of several different paradigms: declarative, logic, and imp
 }
 ```
 
-* `$method('$message')` is a declarative pattern matching syntax.
-* `where` and `<:` are related to [logic programming](https://en.wikipedia.org/wiki/Logic_programming#:~:text=Logic%20programming%20is%20a%20programming,solve%20problems%20in%20the%20domain.) paradigm, say, [Prolog](https://en.wikipedia.org/wiki/Prolog) or SQL.
-* `if` is a typical imperative programming paradigm
+- `$method('$message')` is a declarative pattern matching syntax.
+- `where` and `<:` are related to [logic programming](https://en.wikipedia.org/wiki/Logic_programming#:~:text=Logic%20programming%20is%20a%20programming,solve%20problems%20in%20the%20domain.) paradigm, say, [Prolog](https://en.wikipedia.org/wiki/Prolog) or SQL.
+- `if` is a typical imperative programming paradigm
 
 The mixture of paradigms does not blend well. At least, in the eye of a programming language veteran, it is too messy for a DSL for linting or structural search. We are not designing a next-era programming language.
 
@@ -159,9 +156,9 @@ They all look like function calls, but they are not. See explanation below for t
 
 These three concepts are very similar, but they have slightly different usage in the DSL.
 
-* `pattern` is used in `<:` or somewhere else, I dunno, the doc does not explain it well.
-* `predicate` is used in `where` condition.
-* `function` is used in `assignment`, `insertion` or `rewrite`.
+- `pattern` is used in `<:` or somewhere else, I dunno, the doc does not explain it well.
+- `predicate` is used in `where` condition.
+- `function` is used in `assignment`, `insertion` or `rewrite`.
 
 Example:
 
@@ -189,19 +186,19 @@ If you still have patience, you need one last thing to learn: variable scope.
 
 I have no better explanation for it since I don't understand it well, so I will quote the [official documentation](https://docs.grit.io/language/bubble):
 
->  Once a metavariable is bound to a value, it retains this value throughout the target code. Therefore, the scope of the metavariable spans the entire target file.
+> Once a metavariable is bound to a value, it retains this value throughout the target code. Therefore, the scope of the metavariable spans the entire target file.
 
 To fully understand it, you also need to know `bubble`, `bubble($argument)` and pattern auto wrap.
 
 ## What can go even more wrong?
 
 Integrating a custom linting rule from another parser ecosystem to your own has several more decisions to make. Making bad decisions can lead to even more confusion.
 
-* Your pattern syntax includes non standard syntax, like `$...`. You need to [change your parser](https://github.com/biomejs/biome/blob/31e439674493da76e0ce213e5660be3d903efbef/crates/biome_js_parser/src/syntax/jsx/mod.rs#L321) to support it.
-* You need to make a decision if you want to support existing pattern libraries. But these patterns are built upon [tree-sitter](https://tree-sitter.github.io/tree-sitter/). So you have to [map tree-sitter AST to your own](https://github.com/biomejs/biome/blob/7bf9a608e1592fd595f658f5f800e12d51835d34/crates/biome_grit_patterns/src/grit_target_language/js_target_language.rs#L42-L55)
-* Even worse, if you chose to support existing pattern libraries, you also need to work on a general algorithm to handle incompatibility between different ASTs. For example, different AST structures, different node names, different node properties, etc.
-* If you only supports part of it, how can you teach your users what is supported and what is not, without [reading the source](https://github.com/biomejs/biome/blob/7bf9a608e1592fd595f658f5f800e12d51835d34/crates/biome_grit_patterns/src/grit_target_language/js_target_language.rs#L48-L50)?
-* You also need to update your playground or editor plugins to support mapping between tree-sitter AST and your own AST. And teach users to use it.
+- Your pattern syntax includes non standard syntax, like `$...`. You need to [change your parser](https://github.com/biomejs/biome/blob/31e439674493da76e0ce213e5660be3d903efbef/crates/biome_js_parser/src/syntax/jsx/mod.rs#L321) to support it.
+- You need to make a decision if you want to support existing pattern libraries. But these patterns are built upon [tree-sitter](https://tree-sitter.github.io/tree-sitter/). So you have to [map tree-sitter AST to your own](https://github.com/biomejs/biome/blob/7bf9a608e1592fd595f658f5f800e12d51835d34/crates/biome_grit_patterns/src/grit_target_language/js_target_language.rs#L42-L55)
+- Even worse, if you chose to support existing pattern libraries, you also need to work on a general algorithm to handle incompatibility between different ASTs. For example, different AST structures, different node names, different node properties, etc.
+- If you only supports part of it, how can you teach your users what is supported and what is not, without [reading the source](https://github.com/biomejs/biome/blob/7bf9a608e1592fd595f658f5f800e12d51835d34/crates/biome_grit_patterns/src/grit_target_language/js_target_language.rs#L48-L50)?
+- You also need to update your playground or editor plugins to support mapping between tree-sitter AST and your own AST. And teach users to use it.
 
 ## Conclusion
 
@@ -213,11 +210,11 @@ If you are a library or framework author, you can make decision based on your ow
 
 Consider these points when you want to have objective comparison:
 
-* Documentation?
-* User Education? Howe you teach users to write your DSL?
-* Tooling support like [playground](/playground.html).
-* Editor support beyong syntax highlighting. Say LSP.
-* Integration with API, how you bring type-safe DSL into your general purpose programming language, like [graphql](https://github.com/Quramy/ts-graphql-plugin) and [styled component](https://github.com/styled-components/typescript-styled-plugin).
-* Broader ecosystem support, such as GitHub language detection, AI support, etc.
+- Documentation?
+- User Education? Howe you teach users to write your DSL?
+- Tooling support like [playground](/playground.html).
+- Editor support beyong syntax highlighting. Say LSP.
+- Integration with API, how you bring type-safe DSL into your general purpose programming language, like [graphql](https://github.com/Quramy/ts-graphql-plugin) and [styled component](https://github.com/styled-components/typescript-styled-plugin).
+- Broader ecosystem support, such as GitHub language detection, AI support, etc.
 
 If you are going to use native tooling in your JavaScript/TypeScript project, I recommend you to use [oxlint](https://oxc.rs/) and, if you need simple custom rules, [ast-grep](https://ast-grep.github.io/).

website/catalog/c/rewrite-method-to-function-call.md

@@ -26,8 +26,8 @@ transform:
   MAYBE_COMMA:
     replace:
       source: $$$ARGS
-      replace: '^.+'
-      by: ', '
+      replace: "^.+"
+      by: ", "
 fix:
   $METHOD(&$R$MAYBE_COMMA$$$ARGS)
 ```

website/catalog/c/yoda-condition.md

@@ -16,12 +16,12 @@ In programming jargon, a [Yoda condition](https://en.wikipedia.org/wiki/Yoda_con
 id: may-the-force-be-with-you
 language: c
 rule:
-  pattern: $A == $B                 # Find equality comparison
-  inside:                           # inside an if_statement
+  pattern: $A == $B # Find equality comparison
+  inside: # inside an if_statement
     kind: parenthesized_expression
-    inside: {kind: if_statement}
-constraints:                        # with the constraint that
-  B: { kind: number_literal }       # right side is a number
+    inside: { kind: if_statement }
+constraints: # with the constraint that
+  B: { kind: number_literal } # right side is a number
 fix: $B == $A
 ```
 

website/catalog/cpp/fix-format-vuln.md

@@ -25,8 +25,8 @@ constraints:
   VAR: # not a literal string
     not:
       any:
-      - { kind: string_literal }
-      - { kind: concatenated_string }
+        - { kind: string_literal }
+        - { kind: concatenated_string }
 fix: $PRINTF($S, "%s", $VAR)
 ```