Following Nx best practices, we should resolve any circular dependencies between apps/libs/configs in our monorepo, and prevent any apps from having any interdependencies. We can leverage rules with ESLint to enforce this. An example is explained on the Nx blog. See Project Dependency Rules and Tag in Multiple Dimensions in the Nx docs for further details.
Dev objectives
[ ] Determine rules for module dependency (see below for some proposed rules).
[ ] Add any further tags required.
[ ] Add rules to ESLint configs to enforce boundaries.
[ ] TODO more objectives
Current graph
The following is a graph of our monorepo:
Of particular interest is the loop between Registration(2) and Registration1. While Registration(2) is based off of 1, we probably shouldn't have a circular dependency between them. Optimally, they would instead have any of those dependencies refactored out into libraries and depend on those instead.
Proposed dependency rules
Apps cannot depend on any other apps.
Anything can depend on configs.
Apps can depend on component libs.
Component libs can depend on other component libs.
No circular dependencies.
Tech Debt Triage
The purpose of our technical debt triage process is to analyze technical debt to determine risk level of the technical debt and the value in tackling that technical debt.
Risk Value Scoring:
Level
Value
High
3
Medium
2
Low
1
Technical Debt - Risk Types
Level
Value
Business Area Risk - Risk of business area visibility / damage to user experience
Developer Fault Risk - How likely will this tech debt cause a future error related to coding on top of it
System Fault Risk - Risk of system errors or application downtime
Time Scale Risk - Compound risk effect if left alone. How much more difficult to fix or dangerous will this become over time?
Time Sink Risk - How much will this tech debt slow the development process down
Description of the Tech Debt
Following Nx best practices, we should resolve any circular dependencies between apps/libs/configs in our monorepo, and prevent any apps from having any interdependencies. We can leverage rules with ESLint to enforce this. An example is explained on the Nx blog. See Project Dependency Rules and Tag in Multiple Dimensions in the Nx docs for further details.
Dev objectives
Current graph
The following is a graph of our monorepo:![graph](https://github.com/bcgov/cas-registration/assets/11062580/08dc4a4a-4058-4646-a463-dd4c6e92591c)
Of particular interest is the loop between Registration(2) and Registration1. While Registration(2) is based off of 1, we probably shouldn't have a circular dependency between them. Optimally, they would instead have any of those dependencies refactored out into libraries and depend on those instead.
Proposed dependency rules
Tech Debt Triage
The purpose of our technical debt triage process is to analyze technical debt to determine risk level of the technical debt and the value in tackling that technical debt.
Risk Value Scoring: