Open flaviostutz opened 1 year ago
Design proposal:
{
"root": true
}
Example:
/.monolint.json - activates rule "rule1" (which is not enabled by default)
/group1
/.monolint.json - defines "root:true"
/module1a
/module1b
/group2
/.monolint.json - doesn't define "root", which defaults to "root:false"
/module2a
In this example, module 1a and module1b won't have "rule1" activated, and module 2a will have it activated.
The configuration for a specific module must be the same regardless of calling it from inside the folder, or if calling it from any other parent level (in which all modules inside are discovered and the checks applied)
@sergioflores-j @tiagostutz what are your thoughts?
Sounds good to me!
Although I'd prefer to have only one way to resolve the configuration (running from the root folder) to make it less complex.
In a messy monorepo, this can indeed save some developer time because it gives some flexibility! But can also mean that people will never take the time for fixing the "repo as a whole" issues.
Going back to find the closest root
is pretty much how ESLint handles its configuration files. So it sounds like a fair and understandable addition!
What about having a runtime arg/flag to specify which module to check, but the execution command always treat the current folder as root? For instance:
monorepo
-- /packages
---- /backend
-------- /service1
-------- /service2
-------- .monolint.json
---- /frontend
-- .monolint.json
From the monorepo
folder, the user would execute: npx monolint --path=packages/backend
and it would use the cascaded config starting from the .monorepo.json
file on monorepo
.
If the user runs npx monolint
from the backend
folder, it would run using config starting from the .monorepo.json
file on backend
folder.
What about having a runtime arg/flag to specify which module to check, but the execution command always treat the current folder as root? For instance:
monorepo -- /packages ---- /backend -------- /service1 -------- /service2 -------- .monolint.json ---- /frontend -- .monolint.json
From the
monorepo
folder, the user would execute:npx monolint --path=packages/backend
and it would use the cascaded config starting from the.monorepo.json
file onmonorepo
. If the user runsnpx monolint
from thebackend
folder, it would run using config starting from the.monorepo.json
file onbackend
folder.
I don't like this approach because:
When you run monolint it will get configuration only from current folder.
It's useful to call monolint from inside a specific module folder when you want to see only errors for that folder, but monolint have to look for the root .monolint.json file and process all configuration in folders between root and the module folder to express the actual configuration for that module.