When "npx monolint" is run from a specific module folder, make it look for the root folder and merge configurations

[flaviostutz]

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.

[flaviostutz]

Design proposal:

• we create a special mark { "root": true } in .monolint.json file that represents the root of the monorepo, so that the command will try to find this file in parent dirs of the current dir

{
  "root": true
}

• multiple { "root": true } in a monorepo is supported, indicating from where the configuration should be "resetted" in the hierarchy (we will be declaring "config roots"). For more complex monorepos this could be useful to simplify the management of the configuration of large branches, so when you have a folder with .monolint.json with "root:true" it indicates that all configuration from parent folders are ignored and we are starting a brand new config hierarchy.

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?

[sergioflores-j]

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!

[tiagostutz]

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.

[flaviostutz]

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.

I don't like this approach because:

• it gets farther from tsconfig, jest and Yarn package.json parent dirs auto discovery
• it makes the actual configuration for a certain module dependant on from which dir the developer run the command, making it a little confusing for someone that is starting in the project
• about running the commands on the root level, I got myself migrating from npm workspaces to yarn workspaces simply because I wanted to run the commands from inside the dir I was working on, which seems more "simple" in a way (information hiding)