Bug: test --watch runs all tests when developing one rule

[sergioflores-j]

The current approach for loading the rules (the registry) somehow makes all rules depend on each other.

Steps to reproduce Change a line in any rule and run npm test -- --watch

Current behavior

npm test -- --watch runs all test cases

Expected behavior

npm test -- --watch runs only the tests cases for the rule I'm changing (and its dependencies)

[flaviostutz]

That's because:

• all rules tests depends on registry (to do loadBaseConfig() for example)
• registry depends on all rules

   [rule a test ] ----> [registry] ---->  [rule a] <--- [rule a test] ---> [rule a]
   [rule b test ] ---/             \----> [rule b] <--- [rule b test] ---> [rule b]

[flaviostutz]

It's not easy to decouple these because those "loadConfig" "loadModules" functions uses all other rules registrations to validate the configuration itself...

Not the best way, but maybe using jest file patterns for the specific test you are working on is a workaround for now.

[flaviostutz]

@sergioflores-j I was wondering, and with current data structure we can't avoid this circular dependencies because:

• a rule receives an array of "modules" in their interface, and each module of the array have a reference to all enabled modules for that specific module
• so it means that if one rule changes, it might affect N modules, which have references to N rules, thus, leading to the circular dependency

One way of getting rid of that is to change the data structure of a module not to depend on "enabledRules", because actually one rule doesn't need to receive reference to other rules for a specific module to run. It was created just for the framework itself to use, not the rule, so we could have a representation of the "Module" for internal usage, and another for exposing to the Rules, which might fix our issue. Makes sense?

[sergioflores-j]

structure we can't avoid this circular dependencies because:

• a rule receives an array of "modules" in their interface, and each module of the array have a reference to all enabled modules for that specific module

It makes sense indeed.

---

I was wondering a way to fix that and even sketched a rule "lazy-loader". So we could keep the same structure as now (enabledRules) but make it only load the rules that are really enabled. But it didn't fix the issue, because we have "default" recommended rules enabled as well. So even setting a config like the following for the tests, it was still loading more rules to the list.

// .monolint...
{
  "rule-a": true
}

[flaviostutz]

In these situations what we can do is to instead of having a direct reference do the object, make it have a reference only to the id, then who needs it can get the actual object. In this case instead of having reference to the rule instances, we could have only the rule id…Sent from my iPhoneOn 23 Nov 2022, at 21:33, Sergio Eduardo Flores Jr. @.***> wrote:

structure we can't avoid this circular dependencies because:

a rule receives an array of "modules" in their interface, and each module of the array have a reference to all enabled modules for that specific module

It makes sense indeed.

I was wondering a way to fix that and even sketched a rule "lazy-loader". So we could keep the same structure as now (enabledRules) but make it only load the rules that are really enabled. But it didn't fix the issue, because we have "default" recommended rules enabled as well. So even setting a config like the following for the tests, it was still loading more rules to the list. // .monolint... { "rule-a": true }

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>