checkRestProperty on `check-param-names` and `require-param` not report if destructoring have param root name declared with type

[thanhdx0]

Expected behaviour

It should warn missing param declaration on rest property even if param root name have type or not

Actual behaviour

No warning reported

ESLint Config

rules: {
    "jsdoc/check-param-names": [
          "warn",
          {
            checkRestProperty: true,
          },
    ],
    "jsdoc/require-param": [
          "warn",
          {
            checkRestProperty: true,
          }
    ],
}

ESLint sample

/**
* @param {*} param0
*/
function hello({foo, ...baz}) => {
  return foo + baz;
}

The code above will not be reported a warning by eslint.
Then if I remove param0's type ({*}), warn will show up.
So I can't make sure a function has properly its param in docs.
I'm currently working around this by leaving eslint auto-fix these with enableRootFixer and enableRestElementFixer, but not convenient to do this way with everyone in my team.

Environment

• Node version: 13.9.0
• ESLint version: 6.8.0
• eslint-plugin-jsdoc version:

[brettz9]

The idea here is that if you have a type like "MySpecialObject", we don't want to give warnings that you have to indicate all over again what its properties are.

You can change checkTypesPattern from the default of /^(?:[oO]bject|[aA]rray|PlainObject|Generic(?:Object|Array))$/ to allow more types for which it is expected to have inner documentation (you could even set this to match any type, e.g., [\s\S]*, but again, you probably don't want to do that when you have your own types such as those defined by @typedef for which you have already indicated the expected properties).

While we could look to add * and any to the default regex since indeed, these should not exempt checking since they don't help make clear what the child properties are, I would think it would be better to have a separate rule to report these types when used for destructuring since it no longer becomes "any" if there are certain child properties that end up required on the object, and it is a bad practice to specify such an overly generic type even if the child properties are documented.

[brettz9]

Actually, I think this could be rolled up into #505 as it is not only good to report against any or *, but to be able to have a rule with a regex which either blacklisted certain types from destructuring, or blacklisted all by default and offered a whitelist to allow some (checkTypesPattern is only relative to this rule for reporting missing params--it won't complain if the params are present). Such a rule could be helpful in ensuring that:

1. Valid but overly generic types like "any" were not used when an object (or array) was expected
2. Types like "string" or null were not labeled as having properties.
3. Depending on config, types like "MyType" could be disallowed redundant re-documentation of their child properties, e.g. some projects wouldn't want the redundancy here:

/**
 * @typedef MyType
 * @property {string} someProp
 */

/**
 * @param {MyType}  typeObj
 * @param {string} typeObj.someProp
 */
function aFunc ({someProp}) {
}

[thanhdx0]

@brettz9 Thank you. #505 also points out my problem. I used checkTypesPattern for this rule.