When the ui-kit lives in its own repository and ships as a package, its components are defined in one place and called in many. The ui-kit repository alone can't say how much of the product a change will touch. The consumer repositories can.
For example (illustrative), Button is defined in the acme-ui repository and imported from @acme/ui in acme-web and acme-admin. In this example, acme-ui itself never calls Button: every call sits in the two consumer repositories.
What a consumer tells you
A consumer tells you usage: which components are called, where and how often. That is what reach is counted from. Together with severity, reach decides which divergences come first. Without consumers, a component can look unused even though the product calls it from another repository.
How FISYCO reads consumers
In FISYCO, consumers are called product repositories. A team adds them in the design system settings, and they are read after each index run of the design system. Each one shows its status and last indexed commit, or why reading failed.
Only usage is collected from them. Imports are matched by the ui-kit's package name (the name field of package.json), taken from the nearest package.json at or above the ui-kit folder. On GitHub, the FISYCO app installation must include each repository.
If the ui-kit and the product share one repository, there is no product repository to add. The index run reads the ui-kit folder and up to 600 other .tsx and .jsx files.
Related
- Connect the design system from code: adding product repositories.
- Reach
- Design system drift