Repository navigation
Issue with the class hierarchy where the base class is from the web platform API #2486
Description
Search terms
Class Hierarchy
Question
First of all, thank you so much for this wonderful library! It helps us a lot in documenting the API of our library. ❤️
We have a class in the library that extends the EventTarget class from the web platform API. That means that EventTarget is not defined in our library.
export default class Backend extends EventTarget {...}
When I try to view the entire class hierarchy, I can't see any expected (backend) classes.
However, if I remove the EventTarget class, I can see the correct class hierarchy.
I can't eliminate EventTarget for obvious reasons to get the desired class hierarchy. Is there a way to ask TypeDoc to ignore the classes defined in other places and generate the correct class hierarchy, e.g., by stopping on the classes it doesn't know? Or is there a way to “teach” TypeDoc to handle the EventTarget class (or any platform-specific class) correctly? Or is there anything I'm doing wrong?
If it might help, our project is written in vanilla JS. And here is our typedoc.json file.
{
"name": "Madata API",
"compilerOptions": {
"allowJs": true,
"skipLibCheck": true,
},
"plugin": [
"typedoc-plugin-merge-modules",
],
"mergeModulesRenameDefaults": true,
"mergeModulesMergeMode": "module",
"entryPoints": [
"src/*.js",
"backends/index.js",
"formats/index.js",
],
"exclude": [
"src/node-shims.js",
],
"excludeReferences": true,
"navigation": {
"includeCategories": true,
"includeFolders": false,
},
"readme": "API.md",
"out": "api",
"customCss": "api.css",
}I would be grateful for any help!
Regards,
Dmitry
Activity
Gerrit0 commentedon Jan 26, 2024
That's a bug, the "full hierarchy" page is supposed to ignore base classes in your docs which don't exist so those classes still appear
DmitrySharabin commentedon Jan 26, 2024
Thank you, @Gerrit0, for clearing this out. Eagerly waiting for the fix. 🙏
Include all base classes
DmitrySharabin commentedon Feb 10, 2024
@Gerrit0 I'm sorry, but it looks like the issue isn't fixed yet. Moreover, I see
anyinstead of the previously correct base class (EventTarget). And the correct hierarchy isn't built.Before the fix (correct)
After the fix (wrong)
Would you mind re-opening this issue, please?
Gerrit0 commentedon Feb 10, 2024
Going to need a reproduction, I can't infer where the problem is from that.
DmitrySharabin commentedon Feb 10, 2024
I would love to do it. Do you have any instructions on how to build a reproduction so that it's helpful? Will it be enough if I provide you a link on StackBlitz or something similar reproducing the bug?
Gerrit0 commentedon Feb 10, 2024
StackBlitz works, a repo I can clone and just
npm ithennpm run docsis great tooDmitrySharabin commentedon Feb 10, 2024
I rechecked our docs and found out why the hierarchy wasn't correct. The problem was on our side — we had the outdated
package-lock.jsonfile. And our docs were generated with the old version of TypeDoc. Sorry about that!Unfortunately, there is an issue with the wrong name of the base (not included in the documentation) class — now, it's called
any.It would be nice to have this class's real name taken from the definition.
I hope this repo with the minimal reproduction helps: https://github.com/DmitrySharabin/typedoc-hierarchy-reproduction.
Did it this 👆 way. 😄
Gerrit0 commentedon Feb 11, 2024
TypeDoc uses the type in order to figure out what
EventTargetis. In a TS fileextends EventTargetwould be an error, because EventTarget isn't defined by eithernpm install @types/nodeor by including the DOM in your lib:Undefined types appearing as "any" in the docs is a design limitation. I've considered ways to avoid it, but making those changes require hacks that I really don't want to introduce.
DmitrySharabin commentedon Feb 11, 2024
Fair.
Thank you so much, @Gerrit0! The change you proposed fixes the issue I face. 🥳