Tag in Multiple Dimensions
The example above shows using a single dimension: scope
. It's the most commonly used one. But you can find other dimensions useful. You can define which projects contain components, state management code, and features, so you, for instance, can disallow projects containing dumb UI components to depend on state management code. You can define which projects are experimental and which are stable, so stable applications cannot depend on experimental projects etc. You can define which projects have server-side code and which have client-side code to make sure your node app doesn't bundle in your frontend framework.
Let's consider our previous three scopes - scope:client
. scope:admin
, scope:shared
. By using just a single dimension, our client-e2e
application would be able to import client
application or client-feature-main
. This is likely not something we want to allow as it's using framework that our E2E project doesn't have.
Let's add another dimension - type
. Some of our projects are applications, some are UI features and some are just plain helper libraries. Let's define three new tags: type:app
, type:feature
, type:ui
and type:util
.
Our project configurations might now look like this:
// project "client"
{
// ... more project configuration here
"tags": ["scope:client", "type:app"]
}
// project "client-e2e"
{
// ... more project configuration here
"tags": ["scope:client", "type:app"],
"implicitDependencies": ["client"]
}
// project "admin"
{
// ... more project configuration here
"tags": ["scope:admin", "type:app"]
}
// project "admin-e2e"
{
// ... more project configuration here
"tags": ["scope:admin", "type:app"],
"implicitDependencies": ["admin"]
}
// project "client-feature-main"
{
// ... more project configuration here
"tags": ["scope:client", "type:feature"]
},
// project "admin-feature-permissions"
{
// ... more project configuration here
"tags": ["scope:admin", "type:feature"]
}
// project "components-shared"
{
// ... more project configuration here
"tags": ["scope:shared", "type:ui"]
}
// project "utils"
{
// ... more project configuration here
"tags": ["scope:shared", "type:util"]
}
We can now restrict projects within the same group to depend on each other based on the type:
app
can only depend onfeature
,ui
orutil
, but not other appsfeature
cannot depend on app or another featureui
can only depend on otherui
- everyone can depend on
util
includingutil
itself
{
// ... more ESLint config here
// nx-enforce-module-boundaries should already exist at the top-level of your config
"nx-enforce-module-boundaries": [
"error",
{
"allow": [],
// update depConstraints based on your tags
"depConstraints": [
{
"sourceTag": "scope:shared",
"onlyDependOnLibsWithTags": ["scope:shared"]
},
{
"sourceTag": "scope:admin",
"onlyDependOnLibsWithTags": ["scope:shared", "scope:admin"]
},
{
"sourceTag": "scope:client",
"onlyDependOnLibsWithTags": ["scope:shared", "scope:client"]
},
{
"sourceTag": "type:app",
"onlyDependOnLibsWithTags": ["type:feature", "type:ui", "type:util"]
},
{
"sourceTag": "type:feature",
"onlyDependOnLibsWithTags": ["type:ui", "type:util"]
},
{
"sourceTag": "type:ui",
"onlyDependOnLibsWithTags": ["type:ui", "type:util"]
},
{
"sourceTag": "type:util",
"onlyDependOnLibsWithTags": ["type:util"]
}
]
}
]
// ... more ESLint config here
}
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.