-
Notifications
You must be signed in to change notification settings - Fork 692
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
feat: add extra entry-point related paths on reflections #2309
Conversation
b8d2198
to
4aaede4
Compare
4aaede4
to
f6f374c
Compare
Is there a reason to do this for every reflection, rather than just the top level module created for an entry point? It feels like a lot of redundant information to include it in all declaration reflections. Including |
Any chance we could revive this discussion? Typedoc is currently the only maintained solution to generate documentation from Typescript comments and having the option to add custom pages would be very useful. |
Yeah sorry I got busy; I'll check out latest typedoc versions soon to see if I find my way without this change; otherwise I'll rebase my PR and push a bit more for it. |
I'm also interested in this feature 👍 |
👍 Also interested into having this functionality added |
Based on the use cases mentioned in the description, I believe TypeDoc 0.26's Note: This attribute is not serialized, as it includes the absolute path on a machine, and JSON files are intended to be suitable for use in areas without that being available. It's also not the path of the reflection's declaration location, but the path to the file where the comment exists. This can be different if a comment was inherited from a base class defined in another file. |
0.26 is now out, as nobody has told me that I'm wrong about the comment paths meeting this need... I'm going to assume they do. |
This PR adds extra informations about the entrypoint on declarations & projects.
As a plugin author, I would use those informations to read some files relative to each entrypoint. I found a hack to do this with 0.23.x, but it does not work for 0.24.x. So, the simplest solution I found was to add the required informations directly in TypeDoc.
Note that this inability to bring this hack from 0.23.x to 0.24.x prevents me from releasing versions of @knodes/typedoc-plugin-pages & @knodes/typedoc-plugin-code-blocks compatible with 0.24.x onwards.
Feedbacks are welcome. This is a quick approximate draft, that I will continue by adding more precise tests if you'll be susceptible to accept such addition.
Thanks !