[check-param-names] Inline parameter type throws error with TypeScript

[AndrewLeedham]

Expected behavior

Valid TypeScript with complex inline type to not throw an error.

Actual behavior

Using a complex inline parameter type throws an error.

ESLint Config

// .eslintrc.js
module.exports = {
  plugins: ['@typescript-eslint', 'jsdoc'],
  extends: ['plugin:@typescript-eslint/recommended'],
  parser: '@typescript-eslint/parser',
  parserOptions: {
    project: './tsconfig.json',
  },
  settings: {
    jsdoc: {
      mode: 'typescript',
    },
  },
  rules: {
    'jsdoc/check-param-names': 'error',
  },
};

ESLint sample

/**
 * Logs a string.
 *
 * @param input - String to output.
 */
export default function (input: {
  [foo: string]: { a: string; b: string };
}): void {
  input;
}

I have created a minimal repro here: https://github.com/AndrewLeedham/repros/tree/master/packages/eslint-jsdoc-7

Environment

• Node version: 12.16.1
• ESLint version 7.2.0
• eslint-plugin-jsdoc version: 27.0.4

[gajus]

🎉 This issue has been resolved in version 27.0.5 🎉

The release is available on:

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

Your semantic-release bot 📦🚀

[brettz9]

Note that TSIndexSignature is, with this fix, simply ignored early to avoid erring out.

Note that we are not delving into the contents of the signature.

So for your:

      /**
       * Logs a string.
       *
       * @param input - String to output.
       */
      export default function (input: {
        [foo: string]: { a: string; b: string };
      }): void {
        input;
      }

...we would still be reporting errors if you were to document with a sample key (including if the key aFooKey were instead named foo, etc.):

      /**
       * Logs a string.
       *
       * @param input - String to output.
       * @param input.aFooKey
       * @param input.aFooKey.a
       */
      export default function (input: {
        [foo: string]: { a: string; b: string };
      }): void {
        input;
      }

Feel free to file a separate issue if you wanted some separate handling to allow for such jsdocs, but besides my not being sure accepting that would be a good practice (as opposed to more precise and equivalent jsdocs like @param {object<string, {a: string, b: string}>} input), I don't think we will have any priority to implement.

[AndrewLeedham]

Thanks for the fix @brettz9. I don't see the need for the extra checking, was just concerned about the error as it was blocking upgrading to eslint 7 :)