Nested ArrowFunctionExpression false negatives at v30.0.2

[raineorshine]

After upgrading to v30 v30.0.2, I am getting false negatives (linter was passing before) on nested ArrowFunctionExpressions.

e.g.

// FALSE NEGATIVE: previously bar did NOT require a JSDOC with my configuration
const foo = {
  bar: () => {
    ...
  }
}

// an arrow function assigned to a `const` correctly requires a JSDOC
const moo: () => {
  ...
}

Here is my rule configuration:

    "jsdoc/require-jsdoc": [
      2,
      {
        "require": {
          "ArrowFunctionExpression": true,
          "ClassDeclaration": true,
          "ClassExpression": true
        }
      }
    ]

I've read the changelog for v30 but I am not able to connect the description of breaking changes to the above issue. Neither removing ArrowFunctionExpression nor setting publicOnly fixes it. Thanks for your help!

My typescript version is ahead of the eslint parser, but it works fine on eslint-plugin-jsdoc v29.

    "eslint": "^7.14.0",
    "typescript": "4.0.5",
    "@typescript-eslint/eslint-plugin": "^3.10.1",
    "@typescript-eslint/parser": "^3.10.1",

[brettz9]

I don't recall the history of the change--I think someone might have wanted ArrowFunctionExpression to be triggered regardless of context (as may technically be more consistent with the other types). But you can specify the context of interest by such as the following:

{
      contexts: [
        ':not(Property) > ArrowFunctionExpression',
      ],
      require: {
        ArrowFunctionExpression: false, // Disable to allow the more limited `contexts` to be applied
        ClassDeclaration: true,
        ClassExpression: true,
      },
    }

Closing as that should I think address it, but feel free to comment further.

[raineorshine]

Thanks!

I wasn't aware of the contexts option. After fiddling around in AST Explorer, I figured out how to revert to the old behavior:

   "jsdoc/require-jsdoc": ["error", {
        "contexts": [
          "VariableDeclarator > ArrowFunctionExpression"
        ]
    }]

FYI The breaking change was in v30.0.2. I guess I was the lucky one that coded against incorrect behavior :).