docs(linter): add doc for bannedExternalImports (#7605)

This commit is contained in:
Philip Fulcher 2021-11-04 10:28:01 -06:00 committed by GitHub
parent 1afeeb6be1
commit ed28e7d53a
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 124 additions and 0 deletions

View File

@ -289,3 +289,65 @@ We can now restrict projects within the same group to depend on each other based
```
There are no limits to number of tags, but as you add more tags the complexity of your dependency constraints rises exponentially. It's always good to draw a diagram and carefully plan the boundaries.
## Banning external imports
**This constraint is only available for projects using ESLint.**
You may want to constrain what external packages a project may import. For example, you may want to prevent backend projects from importing packages related to your frontend framework. You can ban these imports using `bannedExternalImports` property in your dependency constraints configuration.
A common example of this is for backend projects that use NestJS and frontend projects that use Angular. Both frameworks contain a class named `Injectable`. It's very easy for a developer to import the wrong one by mistake, especially when using auto-import in an IDE. To prevent this, add tags to define the type of project to distinguish between backend and frontend projects. Each tag should define its own list of banned external imports.
```jsonc
{
// ... more ESLint config here
// nx-enforce-module-boundaries should already exist at the top-level of your config
"nx-enforce-module-boundaries": [
true,
{
"allow": [],
// update depConstraints based on your tags
"depConstraints": [
// projects tagged with "frontend" can't import from "@nestjs/common"
{
"sourceTag": "frontend",
"bannedExternalImports": ["@nestjs/common"]
},
// projects tagged with "backend" can't import from "@angular/core"
{
"sourceTag": "backend",
"bannedExternalImports": ["@angular/core"]
}
]
}
]
// ... more ESLint config here
}
```
Another common example is ensuring that util libraries stay framework-free by banning imports from these frameworks. A workspace using React would have a configuration like this.
```jsonc
{
// ... more ESLint config here
// nx-enforce-module-boundaries should already exist at the top-level of your config
"nx-enforce-module-boundaries": [
true,
{
"allow": [],
// update depConstraints based on your tags
"depConstraints": [
// projects tagged with "type:ui" can't import from "react" or "react-dom"
{
"sourceTag": "type:ui",
"bannedExternalImports": ["react", "react-dom"]
}
]
}
]
// ... more ESLint config here
}
```

View File

@ -289,3 +289,65 @@ We can now restrict projects within the same group to depend on each other based
```
There are no limits to number of tags, but as you add more tags the complexity of your dependency constraints rises exponentially. It's always good to draw a diagram and carefully plan the boundaries.
## Banning external imports
**This constraint is only available for projects using ESLint.**
You may want to constrain what external packages a project may import. For example, you may want to prevent backend projects from importing packages related to your frontend framework. You can ban these imports using `bannedExternalImports` property in your dependency constraints configuration.
A common example of this is for backend projects that use NestJS and frontend projects that use Angular. Both frameworks contain a class named `Injectable`. It's very easy for a developer to import the wrong one by mistake, especially when using auto-import in an IDE. To prevent this, add tags to define the type of project to distinguish between backend and frontend projects. Each tag should define its own list of banned external imports.
```jsonc
{
// ... more ESLint config here
// nx-enforce-module-boundaries should already exist at the top-level of your config
"nx-enforce-module-boundaries": [
true,
{
"allow": [],
// update depConstraints based on your tags
"depConstraints": [
// projects tagged with "frontend" can't import from "@nestjs/common"
{
"sourceTag": "frontend",
"bannedExternalImports": ["@nestjs/common"]
},
// projects tagged with "backend" can't import from "@angular/core"
{
"sourceTag": "backend",
"bannedExternalImports": ["@angular/core"]
}
]
}
]
// ... more ESLint config here
}
```
Another common example is ensuring that util libraries stay framework-free by banning imports from these frameworks. A workspace using React would have a configuration like this.
```jsonc
{
// ... more ESLint config here
// nx-enforce-module-boundaries should already exist at the top-level of your config
"nx-enforce-module-boundaries": [
true,
{
"allow": [],
// update depConstraints based on your tags
"depConstraints": [
// projects tagged with "type:ui" can't import from "react" or "react-dom"
{
"sourceTag": "type:ui",
"bannedExternalImports": ["react", "react-dom"]
}
]
}
]
// ... more ESLint config here
}
```