You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+24-5Lines changed: 24 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -25,14 +25,12 @@ A Gradle plugin that helps keep your module graph healthy and lean.
25
25
- Dependency, which will not match any of those rules will fail the assertion.
26
26
-`restricted [':feature-[a-z]* -X> :forbidden-to-depend-on']` helps us to define custom rules by using `regex -X> regex` signature.
27
27
-`maxHeight = 4` can verify that the [height of the modules tree](https://stackoverflow.com/questions/2603692/what-is-the-difference-between-tree-depth-and-height) with a root in the module will not exceed 4. Tree height is a good metric to prevent module tree degeneration into a list.
28
-
-~~`moduleLayers`~~ are now deprecated in favor of `allowed` syntax.
configurations = ['api', 'implementation'] // Dependency configurations to look. ['api', 'implementation'] is the default
52
48
}
53
49
```
54
50
51
+
### Module name alias
52
+
- You don't have to rely on module names and set a property `ext.moduleNameAssertAlias = "ThisWillBeAssertedOn"`
53
+
- This can be set on any module and the `allowed`/`restricted` rules would use the alias instead of module name for asserting.
54
+
- This is useful for example if you want to use "module types" where eaach module has a type regardless the name and you want to manage only dependnecies of different types.
55
+
- It is recommended to use either module names or `moduleNameAssertAlias` everywhere. Mixing both is not recommended.
56
+
- Example of module rules you could implement for a flat module graph:
- Each module would have set `ext.moduleNameAssertAlias = "Api|Implementation|App"`
60
+
- Module rules example for such case: `allowed = ['Implementation -> Api', 'App -> Implementation', 'App -> Api']`
61
+
- In case you want to migrate to this structure incrementally, you can set a separate module type like `ext.moduleNameAssertAlias = "NeedsMigration"` and setting
62
+
```
63
+
allowed = [
64
+
'Implementation -> Api',
65
+
'App -> Implementation',
66
+
'App -> Api',
67
+
'NeedsMigration -> .*',
68
+
'.* -> NeedsMigration'
69
+
]
70
+
```
71
+
72
+
-`"NeedsMigration"` modules can be then tackled one by one to move them into `Implementation` or `Api` type. Example of app with this structure [can be seen here](https://github.com/jraska/github-client).
73
+
55
74
### Graphviz Graph Export
56
75
- Visualising the graph could be useful to help find your dependency issues, therefore a helper `generateModulesGraphvizText` task is included.
57
76
- This generates a graph of dependent modules when the plugin is applied.
0 commit comments