`no-undefined-types`: false positives for built-in interface types in typescript mode

[tschaub]

Expected behavior

No error.

Actual behavior

The type 'Float32ArrayConstructor' is undefined. The type 'Uint32ArrayConstructor' is undefined.

ESLint Config

{
  "env": {
    "es6": true
  },
  "parserOptions": {
    "ecmaVersion": "latest",
    "sourceType": "module"
  },
  "plugins": ["jsdoc"],
  "rules": {
    "jsdoc/no-undefined-types": "error"
  },
  "settings": {
    "jsdoc": {
      "mode": "typescript"
    }
  }
}

const ELEMENT_ARRAY_BUFFER = 0x8893;
const ARRAY_BUFFER = 0x8892;

/**
 * Returns a typed array constructor based on the given buffer type
 * @param {number} type Buffer type, either ARRAY_BUFFER or ELEMENT_ARRAY_BUFFER.
 * @return {Float32ArrayConstructor|Uint32ArrayConstructor} The typed array class to use for this buffer.
 */
export function getArrayClassForType(type) {
  switch (type) {
    case ARRAY_BUFFER:
      return Float32Array;
    case ELEMENT_ARRAY_BUFFER:
      return Uint32Array;
    default:
      return Float32Array;
  }
}

Environment

• Node version: v17.5.0
• ESLint version v8.0.0
• eslint-plugin-jsdoc version: 39.3.2

Details

When using "mode": "typescript" it looks like TypeScript's built-in interface types are not recognized as defined types (e.g. the es2017 typed array types).

Let me know if you'd accept a pull request to add more extra/known types to the list used by the rule.

[brettz9]

Sure. For a PR, I think it'd be ideal to be systematic in covering currently supported items as a whole rather than piecemeal, though adding comments as to the source file of additions.

[brettz9]

Since this rule is meant to warn about types that are not available, I think we'd really need a way (for TS users) to check the tsconfig.json file so as to know if es5 globals, etc. should be loaded.

[AustinGil]

Looking for existing issues and I think this is the place, but is this why JSDoc comment complains that things like 'Record', 'Pick', 'T', 'NodeListOf', or 'SubmitEvent' are not defined?

[brettz9]

Looking for existing issues and I think this is the place, but is this why JSDoc comment complains that things like 'Record', 'Pick', 'T', 'NodeListOf', or 'SubmitEvent' are not defined?

Yes.

[jaydenseric]

As discussed here, the config plugin:jsdoc/recommended-typescript-error should disable the jsdoc/no-undefined-types rule because TypeScript itself is responsible for reporting errors about invalid JSDoc types.

When in TypeScript mode, the rule jsdoc/no-undefined-types doesn't just have false errors about global types; if you do {@link foo} within a class constructor parameter JSDoc description, where foo references a property/method of the same class, TypeScript is smart enough to know what is linked, but the rule jsdoc/no-undefined-types reports an error unless you change it to {@link ClassName.foo}.

[tschaub]

@jaydenseric - That sounds reasonable to me.

We no longer use the jsdoc/no-undefined-types rule due to this issue. To be honest, I'm uncertain if any problems (undetected undefined things) are sneaking through, or if this is the right solution.

[github-actions[bot]]

:tada: This issue has been resolved in version 45.0.0 :tada:

The release is available on:

• GitHub release
• npm package (@latest dist-tag)

Your semantic-release bot :package::rocket: