chore: update contribution guidelines

CONTRIBUTING.md

@@ -225,3 +225,42 @@ Even minor versions are dedicated to official releases, e.g. `*.6.*`.
 Internally, we use [`insta`](https://insta.rs/) for snapshot tests. This means that you
 follow their [installation instructions](https://insta.rs/docs/cli/) to update/accept
 the new snapshot tests.
+
+### Using just
+
+A lot of the commands above are mor easily accessible using our [Just](https://just.systems/man/en/) recipes. For example:
+
+### Install just
+
+You can install `just` using cargo:
+
+```shell
+cargo install just
+```
+
+Or, using different methods, like explained in their [documentation](https://just.systems/man/en/chapter_4.html).
+
+### Usage
+
+```ignore
+❯ just
+just --list -u
+Available recipes:
+    codegen
+    documentation
+    new-lintrule path name
+    test-lintrule name
+    check-ready
+```
+
+All the necessary `codegen` can be called using
+
+```ignore
+> just codegen
+```
+
+After all changes are done, the code can be checked if is ready to be pushed with
+
+```ignore
+> just check-ready
+```

crates/rome_analyze/CONTRIBUTING.md

@@ -1,7 +1,7 @@
 # Analyzer
 
 The analyzer is a generic crate aimed to implement a visitor-like infrastructure, where
-it's possible to inspect a piece of AST and emit diagnostics or actions based on a 
+it's possible to inspect a piece of AST and emit diagnostics or actions based on a
 static check.
 
 # Folder structure
@@ -11,8 +11,9 @@ is going to be implemented for the JavaScript language (and its super languages)
 will be implemented inside the `rome_js_analyze` crate.
 
 Rules are divided by capabilities:
-- `analyzers/` folder contains rules that don't require any particular capabilities;
-- `semantic_analyzer/` folder contains rules that require the use of the semantic model;
+- `analyzers/` folder contains rules that don't require any particular capabilities, via the `Ast<>` query type;
+- `semantic_analyzer/` folder contains rules that require the use of the semantic model, via `Semantic<>` query type;
+- `aria_analyzers/` folder contains rules that require the use ARIA metadata, via `Aria<>` query type;
 - `assists/` folder contains rules that contribute to refactor code, with not associated diagnostics;
 these are rules that are usually meant for editors/IDEs;
 
@@ -52,10 +53,10 @@ inside the `semantic_analyzers` folder
 3. from there, use the [`declare_rule`](#declare_rule) macro to create a new type
    ```rust,ignore
    use rome_analyze::declare_rule;
-    
+
    declare_rule! {
      /// Promotes the use of awesome tricks
-     /// 
+     ///
      /// ## Examples
      ///
      /// ### Invalid
@@ -72,20 +73,20 @@ inside the `semantic_analyzers` folder
    use rome_analyze::{Rule, RuleCategory};
    use rome_js_syntax::JsAnyExpression;
    use rome_analyze::context::RuleContext;
-   
+
    impl Rule for UseAwesomeTricks {
         const CATEGORY: RuleCategory = RuleCategory::Lint;
         type Query = Semantic<JsAnyExpression>;
         type State = String;
         type Signals = Option<Self::State>;
         type Options = ();
-   
+
         fn run(ctx: &RuleContext<Self>) -> Self::Signals {}
    }
    ```
 5. the const `CATEGORY` must be `RuleCategory::Lint` otherwise it won't work
 6. the `Query` needs to have the `Semantic` type, because we want to have access to the semantic model.
-`Query` tells the engine on which AST node we want to trigger the rule. 
+`Query` tells the engine on which AST node we want to trigger the rule.
 7. The `State` type doesn't have to be used, so it can be considered optional, but it has
 be defined as `type State = ()`
 8. The `run` function must be implemented. This function is called every time the analyzer
@@ -99,7 +100,7 @@ finds a match for the query specified by the rule, and may return zero or more "
     ```
     While implementing the diagnostic, please keep [Rome's technical principals](https://rome.tools/#technical) in mind.
     This function is called of every signal emitted by the `run` function, and it may return
-    zero or one diagnostic. 
+    zero or one diagnostic.
 
     You will have to manually update the file `rome_diagnostics_categories/src/categories.rs` and add a new category
     for the new rule you're about to create.
@@ -225,9 +226,9 @@ declare_rule! {
 use rome_analyze::declare_rule;
  declare_rule! {
      ///  Disallow the use of `var`
-     /// 
+     ///
      ///  ### Invalid
-     /// 
+     ///
      ///  ```js,expect_diagnostic
      ///  var a, b;
      ///  ```
@@ -255,9 +256,9 @@ use rome_analyze::declare_rule;
 
  declare_rule! {
       /// Disallow the use of `var`
-      /// 
+      ///
       /// ### Invalid
-      /// 
+      ///
       /// ```js,expect_diagnostic
       /// var a, b;
       /// ```
@@ -387,3 +388,26 @@ If this the rule can retrieve its option with
 ```rust,ignore
 let options = ctx.options();
 ```
+
+# Using Just
+
+It is also possible to do all the steps above using our `Just` automation. For example, we can create
+a rule calling
+
+```ignore
+> just new-lintrule crates/rome_js_analyze/src/analyzers/nursery myRuleName
+```
+
+Once we are happy with our implementation we can call
+
+```ignore
+> just test-lintrule myRuleName
+```
+
+And at the end, to test our commits are ready to be push we can call
+
+```ignore
+> just check-ready
+```
+
+For more details on the available automations, look at our `justfile` at the root of the repository.

justfile

@@ -0,0 +1,38 @@
+_default:
+  just --list -u
+
+codegen:
+  cargo codegen all
+  cargo codegen-configuration
+  cargo codegen-schema
+  cargo codegen-bindings
+
+documentation:
+  cargo lintdoc
+  cargo documentation
+
+new-lintrule path name:
+  cargo run -p xtask_codegen -- newlintrule --path={{path}} --name={{name}}
+  just codegen
+  just documentation
+
+[unix]
+_touch file:
+  touch {{file}}
+
+[windows]
+_touch file:
+  (gci {{file}}).LastWriteTime = Get-Date
+
+test-lintrule name:
+  just _touch crates/rome_js_analyze/tests/spec_tests.rs
+  cargo test -p rome_js_analyze -- {{snakecase(name)}}
+
+check-ready:
+  git diff --exit-code --quiet
+  just codegen
+  just documentation
+  cargo lint
+  cargo fmt
+  cargo test
+  git diff --exit-code --quiet