Normalize .. token when matching a file with a DisallowPattern

[WilliamHarvey97]

I have a flutter app in which I am doing Feature Sliced Design. Feature Sliced Design prohibits cross-imports between different slices in a same layer and I would like to use this package to enforce this rule in my project.

For a slice in my layer, I want to disallow the import of all the slices in this layer except for my current slice.

For example:

Files under lib/src/entities/a cannot import files under lib/src/entities/b but still can import other files under lib/src/entities/a.

I think a rule like this in analysis_options.yaml could be appropriate:

import_rules:
  rules:
    - target: "lib/src/entities/**"
      disallow: "lib/src/entities/**"
      exclude_disallow:
        - "$TARGET_DIR/../**"
      reason: "No cross-imports between layers"

It would be fairly easy to accept the use of .. in the matches method of the Disallow rule. One could even use the normalize method from the path package https://pub.dev/documentation/path/latest/path/Context/normalize.html.

[fujidaiti]

Hi @WilliamHarvey97,

While we could allow $TARGET_DIR being used with .. notation, it wouldn't fully solve your problem.

$TARGET_DIR is replaced with the path to the direct parent directory of a target file. So when applying the rule to lib/src/entities/a/b/c/common.dart, for example, the exclude_disallow pattern $TARGET_DIR/../** is resolved to lib/src/entities/a/b/c/../**, which is equivalent to lib/src/entities/a/b/**. This exclude_disallow pattern indeed prevents common.dart from importing files from other slices like lib/src/entities/b, but it also disallow it to import some files within the same slice such as lib/src/entities/a/utils.dart and lib/src/entities/a/d/foo.dart.

A workaround is to define a dedicated rule for each slice:

  rules:
    - target: lib/src/entities/a/**
      disallow:
        - lib/src/entities/b/**
        - lib/src/entities/c/**
      reason: Module a cannot depend on other modules.

    - target: lib/src/entities/b/**
      disallow:
        - lib/src/entities/a/**
        - lib/src/entities/c/**
      reason: Module b cannot depend on other modules.

    - target: lib/src/entities/c/**
      disallow:
        - lib/src/entities/a/**
        - lib/src/entities/b/**
      reason: Module c cannot depend on other modules.

But yes, this is tedious and there should be a better way to do this.

One idea is a capture group syntax, with which we could write a single rule like:

  rules:
    - target: lib/src/entities/{MODULE}/**
      disallow: lib/src/entities/**
      exclude_disallow: lib/src/entities/$MODULE/**
      reason: Modules under entities/ must be isolated from each other.

[WilliamHarvey97]

Indeed, capture group would be fantastic!