-
Notifications
You must be signed in to change notification settings - Fork 697
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
0.25.6 version fails to generate docs #2469
Comments
Please try 0.25.6, there was a bug introduced with .5 that caused failures similar to this |
Thanks for the super quick response! I'll wait for dependabot update to pick this up and see if it gets fixed. |
Seems like I was able to do it with Relevant PR: |
Been a while since I've seen an OOM on typedoc... Looks like this is the terribleness that is typedoc-plugin-not-exported.... Every time I have to fix a bug caused by that plugin doing terrible things I want to add more warnings to the top of the readme that it's a terrible idea to use it and you should export your public API... |
I'm general, I believe our API is exported, having said that, there might be places where exported types or methods depend on non exported types, in this case if the option is between finding all these types and exporting them (although there are not really part of the public API) or using this plugin, it's an easy choice - use the plugin and save a lot of time and grief (for us). |
You certainly aren't alone in thinking that it should be built in, I've been consistently resistant to this for a few reasons, not least among them that the slightly higher barrier to entry of installing a plugin results in people considering if some piece of their API really should be exported, which generally results in types being exported which make said library easier to use. There are legitimate uses for this capability, which is why the plugin exists, but I truly think that most libraries shouldn't need it. Your specific case is uniquely problematic for TypeDoc, as it considers classes to be a "leaf" of the type hierarchy, not something that contains additional types/classes.... which doesn't play well with Regarding the crash: With further review it looks like I made a bad assumption that it was the missing exports plugin causing this, the same bug can be triggered with a tiny amount of code: export type ExpressionSpecification =
| ["array", unknown | ExpressionSpecification]
| [
"array",
string | ExpressionSpecification,
unknown | ExpressionSpecification,
];
export class Map {
getFilter(layerId: string): ExpressionSpecification | void {
return;
}
} (This doesn't crash TypeDoc, but it does trigger TypeDoc's recursive type warning in 0.25.6, which really is something that shouldn't ever show up, and indicates something has probably gone wrong, or some edge case was missed. In this case, I accidentally inverted a check when refactoring in 0.25.5, and didn't notice so only half-fixed it in 0.25.6) |
Thanks for the quick fix! |
Latest version seems to pass doc build and are producing new warnings (which is great! thanks!). Thanks for the quick fix! |
Search terms
Expected Behavior
Build should pass
Actual Behavior
Build gets stuck
Steps to reproduce the bug
Build can be seen here:
This is part of a PR to automatically update dependencies to latest version:
https://github.com/maplibre/maplibre-gl-js/actions/runs/7376064163/job/20068383029?pr=3523
Let me know if this is enough.
Basically clone the repo, npm install, npm run generate-docs
Environment
The text was updated successfully, but these errors were encountered: