-
-
Notifications
You must be signed in to change notification settings - Fork 735
Ability to define a converter for JSDocNamepathType
#2947
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
Comments
I believe I would like to add something here: typedoc/src/lib/converter/types.ts Lines 60 to 107 in 8921f13
The current implementation does not permit this. |
AI-based solutions try to something like this: app.converter.on(Converter.EVENT_CREATE_DECLARATION, (context, reflection, node) => {
if (node?.kind === ts.SyntaxKind.JSDocNamepathType) {
// Create a custom type manually
const myType = new Type('custom-jsdoc-namepath');
reflection.type = myType;
}
});
// Alternatively, a lower-level hook could be added:
app.converter.addUnknownNodeConverter({
supports: (node) => node.kind === ts.SyntaxKind.JSDocNamepathType,
convert: (context, node) => {
// You would resolve the namepath here.
return new ReferenceType('EditorConfig', context.project);
},
}); or even more hacky: app.converter.on('resolveBegin', (context: Context) => {
const typeConverter = context.converter.typeConverter;
const oldConvertNode = typeConverter.convertNode.bind(typeConverter);
typeConverter.convertNode = function (context, node) {
if (node.kind === ts.SyntaxKind.JSDocNamepathType) {
const text = (node as any).name.getText(); // risky, but no better option
return new ReferenceType(text, context.project);
}
return oldConvertNode(context, node);
};
}); But none of this works. |
TypeDoc's converters are not extensible today because the discrimination logic is considered an implementation detail and is subject to change at any time... I'm not interested in exposing hooks for that at this time as I'm not convinced the existing method of discrimination is a good way of doing it. It mostly works, but has several annoying edge cases. If AI is utterly hopeless at doing anything even remotely useful in TypeDoc's source. |
Thanks for the answer. So, let's go back to this warning:
How could I suppress it? I want to avoid modifying the logger level because we have several plugins that also print warnings. Switching them to the error level does not make sense as we treat warnings as something to fix while it does not crash. |
Self-answer: avoid executing So, I think, we can close the issue. |
Search Terms
JSDocNamepathType
Problem
The problem I described touches the 0.28 branch. However, to give you some context, I'd like to share a brief story.
In CKEditor 5, we render API pages based on output produced by
typedoc
. We wrote a custom plugin for handling the@error
tag, so the following code (block comment) - https://github.com/ckeditor/ckeditor5/blob/dcb0b8c936c197acf215a96153350d0a4ce83834/packages/ckeditor5-core/src/accessibility.ts#L331-L339 - can be displayed on our error codes page.Recently, we started migrating from version 0.23. x to the latest (0.28.3 at the moment of writing this). The documentation is based on the older version so far.
While processing the project, typedoc prints a few warnings that look like this:
Even when the warning appears, I can translate the
{module:...}
part to a link because I know how to map a module between brackets.☝ This is a screenshot of my local build using the latest typedoc package and the plugin I share below.
There is a logic responsible for converting parameters from the
@param
annotation for error codes: https://github.com/ckeditor/ckeditor5-dev/blob/4f1a3acfd3b79c634b9b5b147c54ce922b61bfc7/packages/typedoc-plugins/src/tag-error/index.ts#L133-L158I would like to request the addition of an option to define a converter for resolving the JSDocNamepathType kind. Or, at least, to mute the warnings, because in my case, they are false positives.
The text was updated successfully, but these errors were encountered: