jsdoc/require-returns: Fails inside classes and interfaces

[iliubinskii]

Expected behavior

Should show error for class method, interface method, interface function-type property, and function.

NOTE:
I have checked that jsdoc/require-jsdoc works in all 4 cases. So, I expect jsdoc/require-returns to work where jsdoc/require-jsdoc works.

NOTE 2:
I see the lack of unification between rules.
I see that jsdoc/require-jsdoc has 4 options that determine where this rule is apply: checkConstructors, checkGetters, checkSetters, contexts.
I would expect all other rules to have these options.
However, some rules have none of the 4.
And some have only contexts option, but not the other 3.

Actual behavior

Shows error only for the function.

ESLint Config

const contexts = [
  ":not(BlockStatement) > FunctionDeclaration",
  "MethodDefinition",
  "TSMethodSignature",
  "TSPropertySignature > TSTypeAnnotation > TSFunctionType"
];

module.exports = {
  rules: {
    "jsdoc/require-jsdoc": [
      "warn",
      {
        checkConstructors: true,
        checkGetters: true,
        checkSetters: true,
        contexts,
        require: {
          ArrowFunctionExpression: false,
          ClassDeclaration: false,
          ClassExpression: false,
          FunctionDeclaration: false,
          FunctionExpression: false,
          MethodDefinition: false
        }
      }
    ],
    "jsdoc/require-returns": [
      "warn",
      {
        contexts
      }
    ]
  }
};

ESLint sample

export class A {
  /**
   * Description.
   */
  public f(): string {
    return "";
  }
}

export interface B {
  /**
   * Description.
   */
  f(): string;

  /**
   * Description.
   */
  g: () => string;
}

/**
 * Description.
 */
export function f(): string {
  return "";
}

Environment

    "node": ">=14.0.0",
    "eslint": "^7.30.0",
    "eslint-plugin-jsdoc": "^35.4.3",

[gajus]

🎉 This issue has been resolved in version 35.4.7 🎉

The release is available on:

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

Your semantic-release bot 📦🚀

[brettz9]

As per convention, I avoided treating void or undefined as triggering the error by default within the TS contexts.