Support destructuring assignment (array, object, and array/object rest) on param and property checks

[gajus]

Support destructuring assignment in function parameter.

• https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Operators/Destructuring_assignment
• Destructuring and using a typed object won't perform a type check codemix/babel-plugin-typecheck#95

Example:

/**
 * @param {Object} coordinates
 * @param {number} coordinates.latitude
 * @param {number} coordinates.longitude
 * @returns {Promise}
 */
({latitude, longitude}) => {
}

[gajus]

https://github.com/gajus/eslint-plugin-jsdoc#deconstructing-function-parameter

[brokentone]

Is this still the case, that the AST does not provide sufficient hints for the names here? I don't see why this is fundamentally different than the various prop-type validation rules which consider destructures which have been added to the eslint-plugin-react.

[gajus]

Is this still the case, that the AST does not provide sufficient hints for the names here? I don't see why this is fundamentally different than the various prop-type validation rules which consider destructures which have been added to the eslint-plugin-react.

I would think that by now AST for this is available.

I am not using JSDoc myself anymore. Wouldn't investigate this myself, but will accept a PR.

[brokentone]

Wow, rapid response! I'm happy to take a look, will report back.

[brettz9]

I'd hope this could also support:

1. object rest params (as in function a ({b, ...c}) {})...
2. array destructuring (as in function a ([b, c]) {})

Also ties into defaults #227

[Volem]

This is not the case anymore for below implementation.

/**
 * Verify TCKN from tckimlik.nvi.gov.tr
 * @param {object} userIdentity - Identity informations for user
 * @param {string} userIdentity.tckn - tckn of user
 * @param {string} userIdentity.name - name of user
 * @param {string} userIdentity.surname - surname of user
 * @param {number} userIdentity.birthYear - year of bearth
 * @returns {Promise<ResponseObject>} - Contains isVerified property on success. This is a boolen value 
 */
const verifyTCKN = async function ({ tckn, name, surname, birthYear }) {

This is not giving any error for me on version 8.4.2 of eslint-plugin-jsdoc

eslint parsing options

"parserOptions": {
        "sourceType": "module",
        "ecmaVersion": 8,
        "ecmaFeatures": {
            "experimentalObjectRestSpread": true
        }
    }

VSCode version
Version: 1.36.1 (user setup)
Commit: 2213894ea0415ee8c85c5eea0d0ff81ecc191529
Date: 2019-07-08T22:59:35.033Z
Electron: 4.2.5
Chrome: 69.0.3497.128
Node.js: 10.11.0
V8: 6.9.427.31-electron.0
OS: Windows_NT x64 10.0.17134

[brettz9]

@Volem , check-param-names is ignoring such structures so they don't err, but it is not reporting problems with them...

[bodinsamuel]

Hey everyone,
is there any progress on this? this would be awesome ☺️

[brettz9]

@bodinsamuel : It would indeed be great to have, but not assigned to anyone currently, and I have no plans currently to take it on. PRs welcome!

[brettz9]

This support should I think also be added for require-property and check-property-names when attached to an object.

[brettz9]

Two complexities to consider...

For repeating (rest-like) elements, the jsdoc docs for param only have this example:

/**
 * Returns the sum of all numbers passed to the function.
 * @param {...number} num - A positive or negative number.
 */
function sum(num) {

It is not clear here what should be used with actual destructuring.

And if there is an object rest property:

/**
 * @param {PlainObject} cfg
 * @param cfg.num
 * @param cfg.cfg1
 * @param cfg.cfg2
*/
function sum({num ...extra}) {
}

...should the above be ok? I would think it could be since extra is just what is being used inside the function to grab the extra properties, but the documentor may still wish to be explicit.
OTOH, one could require that extra be documented and point to a @typedef or such to describe its contents.

[brettz9]

The great work on @dstaley from #498 is now merged into master (30835cd) and part of release 25! 🎉🎉🎉

Though not checking properties (as with the object attached beneath a @namespace), I think that could be a separate issue if there is interest.