eslint-plugin-jsdoc
eslint-plugin-jsdoc copied to clipboard
Revive the `no-undefined-types` rule for all mods/configs
Motivation
Hey guys! First of all, thank you for such a cool and useful plugin!
This has already been discussed a bit in other issues, and I've read most of them. Here it is explained why this rule was excluded from plugin:jsdoc/recommended-typescript-error
, and it was suggested using noUnusedLocals
and noUnusedParameters
options in the TS config. But in reality, I've encountered quite a few projects that use TS config options for linting (like noUnusedLocals
or noUnusedParameters
). Usually, most project tries to prefer linters for linting issues, as it's their task.
The no-unused-vars
rule from the typescript-eslint plugin provides reasons why it's better to use a linter for linting rather than tsconfig options. And it seems that they are all valid. Right now, the situation is that users, when working with different ESLint plugins, have to figure out whom to trust on this issue and whom not to.
After working with eslint-plugin-jsdoc, specifically with the no-undefined-types
rule, I managed to identify several cases where it doesn't mark variables through markVariableAsUsed
:
Current behavior
Generics in functions
❌ Linter error: @typescript-eslint/no-unused-vars / no-unused-vars: MyOwnType in unused
/**
* @param {<T extends unknown>(element: MyOwnType) => T} cb
* @returns {void}
*/
const getValue = (
Template Literal Types
❌ Linter error: @typescript-eslint/no-unused-vars / no-unused-vars: MyOwnType in unused
/**
* @param {`${'MyOwnType'}-${string}`} tagName
* @param {CustomElementConstructor} component
*/
const defineCustomElement = (tagName, component) => {
Desired behavior
Generics in functions
✅
/**
* @param {<T extends unknown>(element: MyOwnType) => T} cb
* @returns {void}
*/
const getValue = (
Template Literal Types
✅
/**
* @param {`${'MyOwnType'}-${string}`} tagName
* @param {CustomElementConstructor} component
*/
const defineCustomElement = (tagName, component) => {
Perhaps I don't fully understand why it's still better not to use no-undefined-types
when working with TypeScript and the recommended-typescript-flavor
config. I'd be happy to hear any thoughts you have on this.