More levels of categorization

Currently type detection possible if file will be located in specific folder. It’s kind of old type of separation: type of file in one folder: controllers, models, views, etc. But, there are projects where grouping is happen by feature: Angular X, NestJS (three layered architecture).

Example 1: https://github.com/nestjs/nest/blob/master/sample/01-cats-app/src/app.module.ts

import { Module } from '@nestjs/common';
import { CatsModule } from './cats/cats.module';
import { CoreModule } from './core/core.module';

@Module({
  imports: [CoreModule, CatsModule],
})
export class AppModule {}

Module can import other modules.

And another issue, example 2: https://github.com/nestjs/nest/blob/2525e9406d8f4a4c16c973320176564b447a860f/sample/01-cats-app/src/cats/cats.module.ts

import { Module } from '@nestjs/common';
import { CatsController } from './cats.controller';
import { CatsService } from './cats.service';

@Module({
  controllers: [CatsController],
  providers: [CatsService],
})
export class CatsModule {}

Module can import other modules and any components of own feature, but can not import components of other modules (we can’t import FoodService here)

https://github.com/nestjs/nest/blob/2525e9406d8f4a4c16c973320176564b447a860f/sample/01-cats-app/src/cats/cats.service.ts cat.service can import others services and cat.repository, and cannot import other repositories (e.g. food.repository)

Looks like, currently it’s not possible to configure plugin in such way. So, besides of type, this requires to detect another attribute of the file - feature (sub module, group).

[javierbrea]

Hi again, I think I have a simpler but still powerful enough solution.

In settings, types could be defined as simple strings, as currently, or as an object containing name and a glob pattern. It would be also possible to define capture, as in the previous examples, but maintaining the standard glob expressions (it would be used the micromatch capture method) to capture all matches in pattern, and users could give a name to each capture in the same order that they will be received:

{
  "settings": {
    "boundaries/types": [
      {
        "name": "helpers",
        "pattern": "**/helpers/*"
      },
      {
        "name": "components",
        "pattern": "**/components/*/*",
        "capture": ["parents", "family", "elementName"]
      },
      "views",
      "layouts",
      "pages",
      "app"
    ],
  }
}

Doing it this way, settings would be backward compatible, and could be still defined as strings for simple scenarios, or as objects for more complex ones. The pattern for strings would be assigned internally to **/[string]/*, so it would match any folder named as the string value, as the plugin currently does.

The other part is how to define allowed types. In this case, it is required a change in the configuration, which currently receives an object. It should receive an array of objects with the keys from and allows, but maintaining the same simplicity that current settings, so users could define from which elements can be imported other elements using an array of strings in the allow property:

{
  "rules": {
    "boundaries/allowed-types": [2,
      [
        {
          "from": "helpers",
          "allow": ["helpers"]
        },
        {
          "from": "components",
          "allow": ["helpers"]
        }
      ]
    ]
  }
}

Then, for more complex scenarios, the plugin would give the possibility to use an array with options instead of a string when defining from, and allow types. The array would have the element type in the first position, and an object with options to use captures in the second one, so it could be specified the capture values that should have to be applied for that rule, both in from or target types.

{
  "rules": {
    "boundaries/allowed-types": [2,
      [
        {
          "from": ["helpers", "components"],
          "allow": ["helpers"]
        },
        {
          "from": [["components", { "family": "atom" }]],
          "allow": [
            "helpers",
            ["components", { "family": "atom" }]
          ]
        },
        {
          "from": [["components", { "family": "molecule" }]],
          "allow": [
            "helpers",
            ["components", { "family": "atom" }],
            ["components", { "family": "molecule" }]
          ]
        }
      ]
    ]
  }
}

I still have to write an example of the configurations for the @unlight’s requirements using this pattern, but I think it could be done easier and simpler than in the previous proposal, and in my opinion the resultant configuration would be more readable.

[javierbrea]

@unlight Ok, I didn’t understand.

You’re right, my fault. It does not support multiple patterns in the pattern property of boundaries/elements setting. But I think it should, because it could be a good solution for some cases, as in your example. Tomorrow I will publish v2.0.0-beta.4 adding the feature. I will also add unit tests based on your second example, in order to know what can be happening.