compodoc: the repository is called an Angular, Nest and Stencil tool, and the readme only mentions Angular

Two source trees and a circular dependency check pointed at one of them

The repository root contains both `src/` and `src-refactored/`, and the distinction matters because the tooling is not aimed at both.

The npm script named `madge` runs the circular dependency detector against a single file, `src-refactored/index-cli.ts`, and writes its output to `dist/madge.png`. A `.madgerc` config file sits in the root.

So one of the two trees is where the dependency graph is policed, and the other is not policed by that script at all. Nothing in the readme explains the split, which is the kind of thing you discover by looking at the scripts rather than the documentation.

The rest of the tooling tells you what kind of project this is. There are two coverage configs, `.nycrc` and `.nycrc-refactoring`, which is the same split applied to coverage measurement. A Playwright config sits beside them, so browser tests exist. `biome.json` is the linter and formatter, `tsdown.config.ts` is the bundler, and `codecov.yml` and `sonar-project.properties` are both present, so coverage and static analysis results are both being sent somewhere.

There is also a `.sauceignore`, which is the marker for browser testing across a provider's virtual browsers.

The readme says Angular and the repository description says three frameworks

The GitHub description for the repository reads as a documentation tool for your Angular, Nest and Stencil application.

The readme's own headline line, centred under the badges, says the missing documentation tool for your Angular application. Angular only.

The feature list agrees with the readme rather than with the description. It talks about standalone APIs, signal inputs and aliases, `styleUrl`, injectable metadata and inheritance details for the modern Angular support item, then about `provideRouter`, lazy routes, default-export route files and classic NgModule routing for the standalone-aware routing item.

Those are Angular-specific concepts. A Nest application is a server framework and a Stencil project is a component library, and nothing in the readme's feature list speaks to either.

So the claim of three frameworks lives in the repository metadata and nowhere else in the repository. If you arrived searching for Nest or Stencil documentation, the description is what brought you, and the file you land on does not confirm it.

The default branch is develop and the contributing link still says master

The default branch is `develop`, not `main`, which is worth knowing before you clone.

Then there is the link in the readme's contributing section, which points at a path containing `blob/master/CONTRIBUTING.md`. If that branch does not exist in the repository any more, the link is dead; if it does exist, it is a different line of development from the one you get by default.

Either way the two disagree, and neither the readme nor the repository metadata resolves which is current.

That matters more for this project than for most, because the releases make the pattern visible. The recent tags are 1.2.0 on 12 January 2026, 1.2.1 on 16 January 2026, and 2.0.0 on 28 June 2026. So the patch line was cut in January, then a major version followed five months later. A major bump in a documentation tool usually means the output changed shape, and the branch that receives it is the one you would want.

The official documentation has also moved, to a separate site, and the readme points at a getting started guide there rather than at anything in the repository.

Renovate is configured in a text file and a banner script writes the changelog

Two root files are unusual enough to be worth naming.

The first is `renovaterc-in-github-folder.txt`. Renovate's configuration is normally a `renovate.json` in the repository root or a config file inside a dedicated folder. Here the configuration exists as a text file whose name says where it belongs, presumably so a workflow copies it into a GitHub folder before Renovate runs.

The second is the shape of the npm scripts themselves. The script list is divided by banner entries whose names are strings of asterisks: one marks the build section, one marks a utilities section, and one marks a template playground section. So `build`, `prebuild` and `build-schematics` sit under the build banner, while `madge`, `changelog`, `download-api-list` and the backup and restore scripts for the package manifest sit under utilities.

That is a generated or hand-formatted script list rather than a plain one, and it is the clearest description of the project you get anywhere: a build, a bundle of maintenance utilities, and a template playground.

Coverage is designed to fail a build, not only to report

One feature line covers documentation coverage: it generates coverage reports and supports coverage checks for CI workflows.

The second half is the one that changes how the tool is used. A coverage report that only reports is something you look at. A coverage check is something that fails, and for a documentation tool the metric is whether your documented code matches your code.

That is the interesting property here. Because the output is generated by parsing source rather than written by hand, documentation can silently rot when someone adds a public method without a comment, and nothing in a hand-maintained docs site would notice. A threshold in CI turns that into a build failure.

The rest of the output story is broader than HTML. The readme lists static offline docs, JSON export and LLM-ready Markdown output alongside support for Angular CLI projects. Three formats rather than one, which means the generated documentation is intended to be consumed by something other than a person reading a browser page.

The package publishes a CLI and Angular schematics from one manifest

The manifest declares a scoped package name, `@compodoc/compodoc`, and two entry points.

"main": "dist/index.js",
"bin": {
    "compodoc": "./bin/index-cli.js"
}

So there is a library entry point and a command named `compodoc` whose file lives under `bin/` rather than being generated into the build output.

There is a third surface. A `schematics/` directory sits in the root, and a script named `build-schematics` compiles that directory with its own tsconfig and then copies a `collection.json` into `dist`. That file is the manifest format Angular CLI schematics use, which means installing this package can add the tool to an Angular workspace through the CLI rather than by editing a configuration file by hand.

Three consumers, then: something importing the package, something running the command, and an Angular workspace picking it up through schematics. The version in the manifest is 2.0.0, which matches the newest release.

Six themes borrowed from other documentation sites and a search index

The presentation options are borrowed rather than original, and the readme names all six sources: Gitbook, Read the Docs, Vagrant, Laravel, Postmark and Stripe.

That is a useful design decision for a documentation generator, because the people evaluating the output have strong associations with those looks already. It also means the visual identity belongs to other projects, and the differentiation has to come from the parsing.

Search is a separate feature line and names its implementation: a search engine built on lunr.js, described as a way to quickly find documented APIs.

Search matters more here than it would for a hand-written site, because the output is large and mechanical. A generated API reference for a mid-sized Angular application has thousands of symbols, and the navigation structure is automatic rather than designed. The readme lists automatic table of contents as its own feature, built from the elements found while parsing the project, which is the other half of the same problem.

So the two features that make generated documentation usable are navigation and search, and both are automatic here.

Editorial conclusion

compodoc suits an Angular project that wants API documentation generated from source comments and checked in CI, rather than a site someone writes by hand. Read the coverage output before you wire it into a pipeline, because that is the part designed to fail a build. Note the branch: the default is develop, so a link to master in the contributing section and a clone of the default branch are not the same code. And if you plan to generate documentation for a Nest or Stencil project rather than an Angular one, the readme you will find does not describe it.

Frequently asked questions

Official sources

1. compodoc/compodoc on GitHub
2. License: MIT
3. Project website
4. README
5. Releases