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

TypeDoc should export sufficient values to set options without importing internals #1163

Closed
Gerrit0 opened this issue Jan 12, 2020 · 5 comments
Labels
bug Functionality does not match expectation

Comments

@Gerrit0
Copy link
Collaborator

Gerrit0 commented Jan 12, 2020

Currently (0.16.1) TypeDoc doesn't export all the enums required to set options with type checking. SourceFileMode (and possibly other enums) are missing from the root level export.

All options should export sufficient types + values to be able to be set.

Also export TypeDocAndTypeScriptOptions + friends as they are missing.

@Gerrit0 Gerrit0 added the bug Functionality does not match expectation label Jan 12, 2020
@socsieng
Copy link
Contributor

Is this also the reason for not being able to create custom options using the @Option decorator?

Custom options fail because they don't meet the following criterial: function Option<K extends keyof TypeDocOptionMap>(option: { name: K } & KeyToDeclaration<K>)

@Gerrit0
Copy link
Collaborator Author

Gerrit0 commented Jan 13, 2020

The @Option decorator is more strictly typed since it was intended for internal use, I'd be open to a request to make the types more lax with an overload (like addDeclaration) so that external consumers can use it though.

Alternatively, maybe we should encourage plugin developers to add their options to the TypeDocOptionMap via declaration merging and then the types on addDeclaration can be made more strict.

@Gerrit0
Copy link
Collaborator Author

Gerrit0 commented Jan 13, 2020

Looking at this:

mode: typeof SourceFileMode;

This is wrong. I think it should be { file: SourceFileMode.File, modules: SourceFileMode.Modules }

@socsieng
Copy link
Contributor

The @Option decorator is more strictly typed since it was intended for internal use, I'd be open to a request to make the types more lax with an overload (like addDeclaration) so that external consumers can use it though.

That explains #1165

+1 for making @Option available for use externally. I would prefer this option over declaration merging.

@Gerrit0
Copy link
Collaborator Author

Gerrit0 commented Jan 13, 2020

Fixed in 0.16.2

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
Projects
None yet
Development

No branches or pull requests

2 participants