[Docs]: boundaries/elements instead of boundaries/element-types in the README?

[vitalets]

Thanks for that plugin! I've just read the docs in the readme and a bit confused.
In the overview there is an example of settings, that uses boundaries/elements:

export default [{
  settings: {
    "boundaries/elements": [
      {
        type: "helpers",
        pattern: "helpers/*"
      },
      {
        type: "components",
        pattern: "components/*"
      },
      {
        type: "modules",
        pattern: "modules/*"
      }
    ]
  }
}]

But in the configuration section it is referenced as boundaries/element-types:

Is it correct or I'm missing something?

[javierbrea]

Hi @vitalets , you're right, it is a typo that should be fixed in the docs. The right setting name is boundaries/elements.
Thank you!

[vitalets]

@javierbrea I'm looking on it again, and.. shouldn't it be opposite?
I mean in settings we define element types - some basic entities.
And then we define rules - how these types interact with each other?

Define element types in settings:

  settings: {
    "boundaries/element-types": [
      {
        type: "app",
        pattern: "src/app/*"
      },
      {
        type: "features",
        pattern: "src/features/*"
      },
    ],
  },

Define rules:

  rules: {
    'boundaries/elements': [
      'error',
      {
        default: 'disallow',
        rules: [
          { from: 'app', allow: ['shared'] },
        ],
      },
    ],
  },

[javierbrea]

Well... it depends on the point of view, I suppose. I named the setting "boundaries/elements" because it defines the elements that the rules will use. Not only the types, also the capturing groups, etc. (I recognize that, for now, they are basically just types, yes 😜, but this may change in the future. I'm planning to modify it so that each element can have multiple "types" or even different values for various "tags," e.g., "domain": x, "type": y, "feature": z, allowing users to configure them entirely. See #348 )

Then, we define rules—you're right—but not just for how these types interact with each other. They also determine how they interact with external dependencies (boundaries/external), how to enforce entry points for each element (boundaries/entry-point), and more.

In summary:

• The setting is named "elements" because it defines the elements that the rules will be able to use. It allows capturing attributes beyond just the type, and in the future, it will support even more flexibility.
• The rule is named "element-types", because it defines "how element types interact with each other". A better name might be "element-dependencies" or something similar, but that could be redundant since the entire plugin focuses on setting boundaries for dependencies. I'm not sure—I’m open to suggestions for renaming it in the next major release to make it clearer (while keeping the old name as deprecated to avoid a breaking change, of course).

[vitalets]

That's very clear explanation. Thank you!
For the alternative naming, maybe just element-rules?

rules: {
    'boundaries/element-rules': [
      'error',
      {
        default: 'disallow',
        rules: [
          { from: 'app', allow: ['shared'] },
        ],
      },
    ],
  },

Let's wait for community feedback, anyway!

PS: concerning tags - I've recently discovered boundaries RFC in turborepo, and they also use tags. Maybe would be helpful for you!

[vitalets]

Another naming idea if there is upcoming "tags" feature:

• in settings: boundaries/tags
• in rules: boundaries/rules

Example:

  rules: {
    'boundaries/rules': [
      'error',
      {
        default: 'disallow',
        rules: [
          { from: 'app', allow: ['features'] },
        ],
      },
    ],
  },

  settings: {
    "boundaries/tags": [
      {
        tag: "app",
        pattern: "src/app/*"
      },
      {
        tag: "features",
        pattern: "src/features/*"
      },
    ],
  },