typedoc is being super slow for a pretty small file
See original GitHub issueSearch terms
slow
Expected Behavior
It should run in a normal amount of time.
Actual Behavior
Runs really slowly (takes over 1 minute) for a pretty simple file.
Steps to reproduce the bug
Source:
import { FunctionComponent as ReactFunctionComponent, ReactElement } from 'react';
/** Make keys `K` of `T` required, retaining other keys. */
export type MakeRequired<T, K extends keyof T> = T & Required<Pick<T, K>>;
/** Similar to `Required`, however `null` and `undefined` are removed from each value. */
export type NonNullableValues<T> = {
[K in keyof T]-?: NonNullable<T[K]>;
};
/** Make keys `K` of `T` non-nullable, retaining other keys. */
export type MakeNonNullable<T, K extends keyof T> = T & NonNullableValues<Pick<T, K>>;
/**
* Type where default keys of props are extracted and made required (non-nullable).
*
* @template P Props of components, where default values are optional / `undefined` / `null`
* @template D Keys of `P` with default values
*/
export type PickDefaultProps<P extends {}, D extends keyof P> = NonNullableValues<Pick<P, D>>;
/**
* Base interface that redeclares `React.FunctionComponent` call signature.
*
* @template P Props of component
*/
export interface FunctionComponentCallSignature<P> {
(props: React.PropsWithChildren<P>, context?: unknown): ReactElement | null;
}
/** `React.FunctionComponent` with no props, hence no `propTypes` nor `defaultProps`. */
export interface EmptyFunctionComponent
extends Omit<ReactFunctionComponent, 'defaultProps' | 'propTypes'>,
FunctionComponentCallSignature<{}> {}
/** `React.FunctionComponent` where `defaultProps` are omitted. */
export interface FunctionComponentWithoutDefaults<P = {}>
extends MakeRequired<Omit<ReactFunctionComponent<P>, 'defaultProps'>, 'propTypes'>,
FunctionComponentCallSignature<P> {}
/** `React.FunctionComponent` where `defaultProps` are correctly typed and required. */
export interface FunctionComponentWithDefaults<P, D extends keyof P>
extends MakeRequired<Omit<ReactFunctionComponent<P>, 'defaultProps'>, 'propTypes'>,
FunctionComponentCallSignature<MakeNonNullable<P, D>> {
defaultProps: PickDefaultProps<P, D>;
}
/**
* `React.FunctionComponent` where props passed to component and `defaultProps` are correctly typed.
*
* @template P Props of component (default props should be optional)
* @template D Keys of `P` whose values are given defaults in `defaultProps`
*/
export type FunctionComponent<P extends {} = {}, D extends keyof P = never> = [keyof P] extends [
never,
]
? EmptyFunctionComponent
: [D] extends [never]
? FunctionComponentWithoutDefaults<P>
: FunctionComponentWithDefaults<P, D>;
tsconfig:
{
"compilerOptions": {
"allowJs": true,
"allowSyntheticDefaultImports": true,
"alwaysStrict": true,
"declaration": true,
"esModuleInterop": true,
"importHelpers": true,
"jsx": "react",
"module": "commonjs",
"noFallthroughCasesInSwitch": true,
"noImplicitReturns": true,
"noUnusedLocals": true,
"noUnusedParameters": true,
"outDir": "dist",
"strict": true,
"target": "esnext",
"types": ["jest", "node"]
},
"typedocOptions": {
"entryPoints": ["types"],
"excludeExternals": "true",
"excludePrivate": "true",
"excludeProtected": "true",
"includeVersion": "true",
"out": "docs",
"readme": "README.md"
}
}
Environment
- Typedoc version: 0.22.13
- TypeScript version: 4.6.3
- Node.js version: 16.13.0
- OS: Windows 10, Linux
Issue Analytics
- State:
- Created a year ago
- Comments:7
Top Results From Across the Web
Options - TypeDoc
Define patterns for extra files that should be considered external. ... Prevent externally resolved TypeScript files from being documented.
Read more >Can't ignore some files using typedoc with angularcli
I am trying to generate a documentation for my AngularCli App using typedoc. The result is beautiful but I can't manage to ignore...
Read more >Thoughts on TypeScript
Slow compiler .d.ts files. Conclusion ... And that's pretty accurate. ... This ends up being far less cumbersome than I would have imagined, ......
Read more >Why is Google Docs SO SLOW to respond to my typing???
I have been using google docs for writing on novels and short ... the only way to break your current document into smaller...
Read more >Bun: A Complete Overhaul of the JavaScript Ecosystem
No extra tricks or clever caching, just really fast code written in a fast, low-level language. Bun is still very new and probably...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
My repo is already split into separate packages and this particular package that’s exhibiting the issue isn’t that huge. My
src/
directory has about two dozen React components, and none of them are that big. That said, I’m seeing some non-trivial improvements (for both type checking and docs generation) by having separate tsconfig files for the different tasks and specifying a much more narrowinclude
value, so I think I’ll pursue that approach.Before (not specifying
include
at all):After (using a bespoke
include
for each task):We’ve gone from over 3 minutes for TS-related tasks to less than a minute, so I’d call this a win! Feel free to close this issue.
TypeDoc used to (~3 years ago now I think) try to call TypeScript with the minimum number of files necessary to build the documentation. It, unfortunately, resulted in a never ending stream of bug reports where it would fail to compile code because people assumed that it would work the same way that tsc did. Eventually I just gave up that attempt at improving performance and made typedoc behave like tsc… not really sure I want to go back to that, at least not without hiding it behind an option with a scary name.
Project references can be a major performance boost once your projects are that large, particularly for separate pieces of code.