API design constraints and known issues
This tool puts several constraints on your API design.
Some of them are imposed by api-extractor and api-documenter, and some are imposed by this tool.
Basically, if you use this tool, you will be creating boring, object-oriented APIs with classes, interfaces and functions. You will not be using all the fancy TypeScript constructs.
Quoting a comment from a GitHub Issue:
For the large corporate code bases that inspired API Extractor, historically we have tended to prefer standard coding stereotypes over flexible free-form expressions. For example, "a function" is a friendlier concept than "a constant variable whose data type is a lambda." And "an interface" is a friendlier concept than "a type signature describing a non-nested object without any alternatives." Building your API from standardized bricks makes it easier for beginners to learn, easier to organize the docs, and easier to talk about when providing support.
| Limitation | Workaround |
|---|---|
Default export is not supported. |
Use only named exports instead. |
CommonJS |
Use only module export syntax only. |
Type aliases are not documented. |
Use interfaces instead. |
Call signatures are not documented. |
Use methods instead. |
Namespaces are not supported. |
Use classes with static methods instead. |