The eslint-plugin-tsdoc appears to be issuing a false-positive "tsdoc/syntax" linter error when Generator or AsyncGenerator types appear in a tuple. ["eslint-plugin-tsdoc": "0.2.16"]
The linter DOES NOT complain for a simple case like the following:
The linter DOES complain if the generator type appears in a named tuple.
/**
* :
* @returns [stdoutGen: AsyncGenerator<Buffer, string, undefined>, stderrGen: AsyncGenerator<Buffer, string, undefined>]
^The HTML tag has invalid syntax: Expecting an attribute or ">" or "/>"
*/
EDIT: I see that escaping < with \< satisfies the linter. Is this expected?
The linter DOES complain if the generator type appears in a (not named) tuple.
/**
* :
* @returns [AsyncGenerator<Buffer, string, undefined>, AsyncGenerator<Buffer, string, undefined>]
^The HTML tag has invalid syntax: Expecting an attribute or ">" or "/>"
*/
The linter DOES NOT complain if a type alias is introduced for AsyncGenerator<Buffer, string, undefined>.
BUT, ... adding types to avoid a linter complaint feels like a step toward "type hell" (in the spirit of "callback hell", "promise hell" ...).
What is the best approach in this situation?
(a) escape the < with \<
(b) enhance the linter to accept the construct
(c) enhance the linter to improve the error message
(d) mute the linter rule
(e) add the intermediate type (side-step the error)
(f) other
I suspect the answer may relate to any constraints imposed by best-practices or downstream "compatible documentation tools".
The
eslint-plugin-tsdoc
appears to be issuing a false-positive "tsdoc/syntax" linter error when Generator or AsyncGenerator types appear in a tuple. ["eslint-plugin-tsdoc": "0.2.16"]The linter DOES NOT complain for a simple case like the following:
The linter DOES complain if the generator type appears in a named tuple.
EDIT: I see that escaping
<
with\<
satisfies the linter. Is this expected?The linter DOES complain if the generator type appears in a (not named) tuple.
The linter DOES NOT complain if a type alias is introduced for
AsyncGenerator<Buffer, string, undefined>
.BUT, ... adding types to avoid a linter complaint feels like a step toward "type hell" (in the spirit of "callback hell", "promise hell" ...).
What is the best approach in this situation? (a) escape the
<
with\<
(b) enhance the linter to accept the construct (c) enhance the linter to improve the error message (d) mute the linter rule (e) add the intermediate type (side-step the error) (f) otherI suspect the answer may relate to any constraints imposed by best-practices or downstream "compatible documentation tools".
Thanks in Advance!