Saer reads your repository and resolves every JSX use to the component it renders, through imports, aliases, barrels and workspace packages. You get the system as it is used, not as it is documented: which components exist, which are defined twice, which variants are passed but never declared, and which call sites restyle what the component already sets. On the founder's own app it found 1,668 components, 15 names defined more than once, and a shared Button restyled at 164 of its 538 uses.
What you see that a component catalogue cannot show
- Use, not declaration: 10,774 JSX use sites in Lunary, each resolved to its definition, so "unused" means unused (100 were).
- Duplicates with evidence: the same name in two files, with the uses of each, so you know which one to keep.
- Restyled call sites: where a caller passes a class or style for a property the component already sets. For
Button, the most overridden properties were color (61 sites) and background-color (60 sites). - Variant sprawl: 20 variant findings in Lunary, values passed but not declared, or declared and never used.
Every finding names its files. Exact findings and inferred ones are never mixed. See the full Lunary case study.
How it runs on your repository
cd your-react-app
saer scan
# open .saer/report.htmlIt runs on your machine, uploads nothing, and writes only its report into a .saer folder. Monorepos are followed across workspace packages.
What Saer does about this
- Colour (in the beta): tokens across themes, exact drift, near-matches and dead tokens.
- Components: inventory, use sites, duplicates, variant sprawl, restyled call sites and unused components. In the beta.
- Generated documentation pages from the system found: planned.
- A pull request check that fails on new drift: planned.
Every capability and its state: what Saer checks.
See it on your own codebase.
Request early access