Developer Guide
This section documents how eslint-plugin-repo is structured, how the docs and rule catalogs are maintained, and how to make changes without breaking the docs pipeline.
:::info Maintainer mindset
Treat the docs site as a real application surface, not a folder of loose markdown files. TypeDoc output, inspectors, blog posts, generated sidebars, and hand-authored guides all meet here.
:::
What this section coversâ
- Architecture and maintenance notes for docs, rules, and presets.
- API documentation workflow for generated TypeDoc pages.
- Architecture Decision Records (ADRs) for long-lived technical decisions.
- Diagrams that explain rule lifecycle and docs synchronization flows.
Quick workflow for maintainersâ
- Make your source changes (
src/**,docs/rules/**, or docs app files). - Run validation from repository root:
npm run docs:typechecknpm run docs:apinpm run docs:build
- Verify internal links and navigation routes still resolve.
- If you changed rule metadata, run the sync scripts that update derived docs tables.
High-signal maintainer routesâ
| If you need to... | Start here |
|---|---|
| Understand the docs architecture | Charts |
| Change TypeDoc or generated API behavior | API guide |
| Review long-lived design choices | ADRs |
| Understand path aliases and typed imports | Typed paths inventory |
Practical workflowâ
Change rule docs or presetsâ
- Update the source docs or metadata.
- Run the sync steps that derive navigation or preset matrices.
- Rebuild docs so the rules section and generated indexes stay honest.
Change the docs app itselfâ
- Update
docs/docusaurus/**thoughtfully. - Re-run
npm run docs:typecheckandnpm run docs:buildfrom repository root. - Verify sidebars, social metadata, and generated asset paths still resolve.
Change public plugin exportsâ
- Update source and exported types first.
- Re-run
npm run docs:apiso generated API docs reflect reality. - Check navigation pages that link to generated API ids.