Differences from Upstream
This comparison covers the published npm packages @rdlabo/capacitor-docgen@0.4.1 and @capacitor/docgen@0.3.1. The fork is based on the Ionic project, but is published and maintained separately by rdlabo.
Compatibility summary
| Surface | Upstream 0.3.1 | rdlabo fork 0.4.1 |
|---|---|---|
| Package | @capacitor/docgen |
@rdlabo/capacitor-docgen |
| Binary | docgen |
docgen |
| CLI flags | --api (-a), --output-readme (-r), --output-json (-j), --project (-p), --silent (-s) |
Same |
| README placeholders | <docgen-index>, <docgen-api> |
Same |
| Core exports | generate, parse, output helpers, run, public types |
Same |
| Interface heritage metadata | Not exposed | DocsInterface.extends: string[] |
| Inherited methods and properties | Not expanded | Appended from resolved base interface objects |
| Primary API inheritance | Only directly declared API members | Resolved base object members are appended to the API |
| Base interface through a type alias | Not resolved for inheritance | Alias complexTypes are used to find base interfaces |
The published tarballs have byte-identical compiled modules for CLI parsing, generation, Markdown handling, output formatting, and TypeScript program creation. The behavioral implementation changes are confined to dist/parse.js; the public declaration change is in dist/types.d.ts. Package metadata and README content also differ.
What the parser adds
For each top-level interface, the fork stores the text of its TypeScript heritage expressions in DocsInterface.extends. When docgen collects that interface, it:
- keeps a base name that directly matches a parsed interface;
- resolves a matching type alias to its referenced
complexTypes; - finds the resulting base interfaces; and
- appends the methods and properties currently held by those base interface objects to the derived interface.
Since v0.4.1 the same collection runs for the primary API interface, so a plugin API can inherit methods from a base plugin interface. In v0.4.0 the flattening occurred only for supporting interfaces.
Observable output
Given a derived options interface, upstream emits only members declared directly on that interface. The fork emits those members followed by the members currently present on its resolved base interface object. Raw JSON and the generated Markdown table therefore contain inherited members, and the programmatic result includes the extends array.
Collection mutates the shared parsed interface objects in place. If another API member causes a base interface to be collected and expanded first, that base object already contains copied ancestor members when a later derived interface uses it. Those indirect members then propagate to the derived interface. Output can therefore depend on member collection order even though the code does not recursively walk the entire heritage chain in one operation.
The existing CLI flags, placeholder replacement, heading generation, JSON writer, and exported functions otherwise keep upstream behavior.
Current boundaries
The enhancement is intentionally a small parser extension, not full TypeScript type flattening:
- It does not recursively flatten an entire multi-level heritage chain in one collection operation. However, in-place mutation means a base expanded earlier can pass its already-copied ancestor members to a later derived interface; without that earlier collection, the same derived interface receives only the base's original direct members.
- A child member that overrides a base member is not reconciled by name. Both entries can appear because deduplication uses object identity.
- Heritage matching is name-based against parsed top-level interfaces. Qualified expressions and declaration merging are not normalized by the enhancement.
- The package still uses the same TypeScript
~4.2.4parser dependency and Node.js>=18engine declaration as upstream 0.3.1. - Both packages expose the same
docgenbinary, so they should be alternatives rather than simultaneous direct dependencies.
These boundaries, including both collection orders, are contract-tested in this documentation repository so the comparison changes when a future fork release changes behavior.
Release lineage
- Fork v0.3.x introduced the separately published
@rdlabo/capacitor-docgenpackage and early inheritance handling. - Fork v0.4.0 switched inheritance discovery to TypeScript heritage clauses, added
DocsInterface.extends, resolved interface aliases, and expanded inherited methods and properties. - Fork v0.4.1 applied inheritance expansion to the primary API interface as well.
Review the pinned fork v0.4.1 source and upstream v0.3.1 source when evaluating later versions.