Can I turn off eslint tyfedef rule for destructuring in lambdas

Question

I am wondering is it possible to turn off typedef rule only for array or object destructuring in lambdas ?

getPersonsNames(): string[] {
    type Person = { name: string; age: number };
    const persons: Person[] = [
        { name: `Jan Kowalski`, age: 12 },
        { name: `Justyna Kowalczyk`, age: 22 }
    ];
    return persons.map(({ name }) => name); // ESLint: Expected a type annotation.(@typescript-eslint/typedef)
}

In general, I want to use typedfees for destructuring but in those kinds of cases I do not want to. Is there a way to exclude those cases ?

---

I tried to add 'arrow-parameter': false, (and arrowParameter: false as you can see above) to @typescript-eslint/typedef but it didn't help at all.

Documentation of this rule which I used: @typescript-eslint/typedef

Files to reproduce

.eslintrc.js config file:

module.exports = {
    parser: '@typescript-eslint/parser',
    parserOptions: {
        project: './tsconfig.json',
        createDefaultProgram: true,
        ecmaVersion: 2020,
        sourceType: 'module',
    },
    extends: [
        'eslint:recommended',
        'plugin:@typescript-eslint/recommended',
    ],
    rules: {
        '@typescript-eslint/typedef': [
            'error',
            {
                'arrowParameter': false,
                'propertyDeclaration': true,
                'parameter': true,
                'memberVariableDeclaration': true,
                'callSignature': true,
                'variableDeclaration': true,
                'arrayDestructuring': true,
                'objectDestructuring': true
            }
        ],
    },
}

.gitignore :

node_modules

index.ts :

function getPersonsNames(): string[] {
    type Person = { name: string; age: number };
    const persons: Person[] = [
        { name: `Jan Kowalski`, age: 12 },
        { name: `Justyna Kowalczyk`, age: 22 }
    ];
    return persons.map(({ name }) => name); // ESLint: Expected a type annotation.(@typescript-eslint/typedef)
}

getPersonsNames();

package.json :

{
  "name": "typedef-in-destructuring-lambdas",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1",
    "lint": "eslint . --ext .ts"
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
  "devDependencies": {
    "@typescript-eslint/eslint-plugin": "^4.3.0",
    "@typescript-eslint/parser": "^4.3.0",
    "eslint": "^7.10.0",
    "typescript": "^4.0.3"
  }
}

tsconfig.json :

{
    "compilerOptions": {
        "target": "ES2017",
        "module": "commonjs",
        "moduleResolution": "node",
        "emitDecoratorMetadata": true,
        "experimentalDecorators": true,
        "allowSyntheticDefaultImports": true,
        "sourceMap": true,
        "noEmit": true,
        "noEmitHelpers": true,
        "importHelpers": true,
        "strictNullChecks": false,
        "skipLibCheck": true,
        "lib": [
            "dom",
            "es6",
            "es2019"
        ]
    }
}

Answer 1

The rule does not support this - it treats all destructuring as the same.
Note that more customisability won't be added to the rule because it shouldn't be used in most codebases.

Using it, and adding unnecessary type annotations is an anti-pattern, and has a negative effect on your codebase.

---

This rule isn't really intended to be used day-to-day in a codebase, it's intended to help you migrate your codebase so you can turn on the noImplicitAny compiler option.

Unnecessary type annotations everywhere is bad for your codebase. Each one incurs a maintenance cost (you have to manually update them to keep them in sync), and each one also slows down compilation , because TypeScript has to take time to validate that the annotation is correct.

As the maintainer of @typescript-eslint , I strongly advise against using the typedef rule.