Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issue with the class hierarchy where the base class is from the web platform API #2486

Closed
DmitrySharabin opened this issue Jan 22, 2024 · 9 comments
Labels
bug Functionality does not match expectation question Question about functionality

Comments

@DmitrySharabin
Copy link

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 {...}
SCR-20240122-svky

When I try to view the entire class hierarchy, I can't see any expected (backend) classes.

SCR-20240122-svqh

However, if I remove the EventTarget class, I can see the correct class hierarchy.

SCR-20240122-svuu

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

@DmitrySharabin DmitrySharabin added the question Question about functionality label Jan 22, 2024
@Gerrit0 Gerrit0 added the bug Functionality does not match expectation label Jan 26, 2024
@Gerrit0
Copy link
Collaborator

Gerrit0 commented 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
Copy link
Author

Thank you, @Gerrit0, for clearing this out. Eagerly waiting for the fix. 🙏

@Gerrit0 Gerrit0 closed this as completed in 2318949 Feb 9, 2024
@DmitrySharabin
Copy link
Author

DmitrySharabin commented Feb 10, 2024

@Gerrit0 I'm sorry, but it looks like the issue isn't fixed yet. Moreover, I see any instead of the previously correct base class (EventTarget). And the correct hierarchy isn't built.

Before the fix (correct)

SCR-20240122-svky

After the fix (wrong)

SCR-20240210-qkbr

Would you mind re-opening this issue, please?

@Gerrit0
Copy link
Collaborator

Gerrit0 commented Feb 10, 2024

Going to need a reproduction, I can't infer where the problem is from that.

@DmitrySharabin
Copy link
Author

Going to need a reproduction, I can't infer where the problem is from that.

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
Copy link
Collaborator

Gerrit0 commented Feb 10, 2024

StackBlitz works, a repo I can clone and just npm i then npm run docs is great too

@DmitrySharabin
Copy link
Author

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.json file. 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.

SCR-20240210-qkbr

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.

a repo I can clone and just npm i then npm run docs is great too

Did it this 👆 way. 😄

@Gerrit0
Copy link
Collaborator

Gerrit0 commented Feb 11, 2024

TypeDoc uses the type in order to figure out what EventTarget is. In a TS file extends EventTarget would be an error, because EventTarget isn't defined by either npm install @types/node or by including the DOM in your lib:

diff --git a/tsconfig.json b/tsconfig.json
index 2ae115a..0577b11 100644
--- a/tsconfig.json
+++ b/tsconfig.json
@@ -2,7 +2,7 @@
        "compilerOptions": {
                "allowJs": true,
                "skipLibCheck": true,
-               "lib": ["ESNext"],
+               "lib": ["ESNext", "DOM"],
                "outDir": "./dist"
        },
        "include": ["src"],

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
Copy link
Author

TypeDoc uses the type in order to figure out what EventTarget is. In a TS file extends EventTarget would be an error, because EventTarget isn't defined by either npm install @types/node or by including the DOM in your lib:

Fair.

"lib": ["ESNext", "DOM"]

Thank you so much, @Gerrit0! The change you proposed fixes the issue I face. 🥳

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Functionality does not match expectation question Question about functionality
Projects
None yet
Development

No branches or pull requests

2 participants