Confused by "@nrwl/nx/enforce-module-boundaries" rule

[mandaputtra]

Hello, this is my first time using nx and react. I maybe had some feedback and question here. This rule require you to use relative import on a shared lib. That is mean you should use '../../path/to/your/file/' it doesn't make sense, I think. It will be more useful if the rule would be use absolute import in shared libs

What do you think? Are there any way to reverse this config? My ESLint file.

{
  "root": true,
  "ignorePatterns": ["**/*"],
  "plugins": ["@nrwl/nx"],
  "overrides": [
    {
      "files": ["*.ts", "*.tsx", "*.js", "*.jsx"],
      "rules": {
        "@nrwl/nx/enforce-module-boundaries": [
          "error",
          {
            "enforceBuildableLibDependency": true,
            "allow": [],
            "depConstraints": [
              {
                "sourceTag": "*",
                "onlyDependOnLibsWithTags": ["*"]
              }
            ]
          }
        ]
      }
    },
    {
      "files": ["*.ts", "*.tsx"],
      "extends": ["plugin:@nrwl/nx/typescript"],
      "rules": {}
    },
    {
      "files": ["*.js", "*.jsx"],
      "extends": ["plugin:@nrwl/nx/javascript"],
      "rules": {}
    }
  ]
}

[meeroslav]

Hi @mandaputtra,
Thank you for the question.

Based on the paths in your screenshot, you should not see this message. It could be that TS process running the lint did not pick up your changes. The TS server in VS Code is often slow. Try to restart the TS server process or the whole IDE and check if error remains. You can always run nx affected --target=lint in your terminal to get up to date information on linting status, unbiased by your IDE.

Regarding your absolute vs relative path question:
If you would use the absolute path (e.g. /home/mptr8/Code/Projects/me/todoapp/libs/front-ui/some/path/to/confetti) what would happen if you move the app to another folder? Or perhaps if someone else would clone your solution to /home/someone/dev/todoapp? The absolute paths are (almost) always bad idea. You need to use them when dealing with I/O but they should always be result of a path calculation between working directory and relative path.

That being said, if you still don't like this rule, you can apply flag allowCircularSelfDependency to your enforce-module-boundaries plugin which will allow you to still have namespaced imports from within the same project (e.g. import @todoapp/front-ui/shared from within your front-ui-shared project.

"@nrwl/nx/enforce-module-boundaries": [
  "error",
  {
    "enforceBuildableLibDependency": true,
    "allowCircularSelfDependency": true,
    "allow": [],
    "depConstraints": [
      {
        "sourceTag": "*",
        "onlyDependOnLibsWithTags": ["*"]
      }
    ]
  }
]

[mandaputtra]

It is indeed the TS lint do not pick up the changes. After tried to recreate the project, It works.

Sorry I'm wrong, turn out absolute path are /home/mptr8/to/project I thought absolute path is this @todoapp/front-ui/shared. Since on the image I tried to write @todoapp/front-ui/shared but got errors.

Thanks!

[binary64]

I also stumbled on this. I liked the idea of importing from the self project using tsconfig paths (@todoapp/front-ui/shared). In my opinion it's just a stylistic opinion, I don't think there is any risk of infinite loops, which is what the wording of the error message made me initially assume.

It would be more useful if the rule came with autofixers, because another point is that a) the IDE autosuggests the tsconfig path format (@todoapp/front-ui/shared) as auto-suggested imports, and b) if you move a file into a different project, it would still work, whereas if you had relative, and even if your IDE auto-fixed it for you, Nx would still complain about cross-project boundries.

[plutotv-aaa]

Are any compilation output differences or side effects introduced if allowCircularSelfDependency is used with @binary64 's case?

[meeroslav]

I don't know what you mean by linking that GitHub account.

Self-circular dependency gets reported when the project tries to import from itself using non-relative import (e.g. @scope/my-project). We use typescript path resolver to find out to which project the import belongs to and if it belongs to the same we throw the error (unless the allowCircularSelfDependency is set to true).

Hope that helps.