Eslint-regler @typescript-eslint/naming-convention konflikter med @typescript-eslint/no-unused-vars

Jeg sætter eslint op for et TypeScript-projekt.

dette er denne regel for ubrugte variabler i tilfælde af destrukturering

"@typescript-eslint/no-unused-vars": [
  "error",
  {
    "argsIgnorePattern": "^_",
    "ignoreRestSiblings": true,
    "destructuredArrayIgnorePattern": "^_"
  }
],


//ex:
// error lint
const [a, b] = ['a', 'b']
console.log(b)

// ok
const [_a, b] = ['a', 'b']
console.log(b)

men reglen @typescript-eslint/naming-convention udløser en fejl. Jeg har ikke angivet den i reglerne, men jeg tror, den er tilføjet med plugin'et:"@typescript-eslint" og jeg ønskede ikke at fjerne den.

Hvordan får jeg en regel til ikke at forstyrre den anden? Eller en måde at bruge de to regler på

Svar #1

@typescript-eslint/naming-convention er normalt ikke aktiveret som standard i nogen af de konfigurationer, som typescript-eslint leveres med. Hvis det er indstillet i din konfiguration, skal du udvide en anden konfiguration, der aktiverer det.

For dit specifikke eksempel kan du springe specifikke elementer over i et array-destruktureringsmønster ved blot at sætte et komma, hvor elementet ville være. Se følgende eksempel fra Destructuring assignment:

function f() {
  return [1, 2, 3];
}

const [a, , b] = f();
console.log(a); // 1
console.log(b); // 3

const [c] = f();
console.log(c); // 1

Eller i dit tilfælde:

const [, b] = ['a', 'b']

Mere generelt, hvis du dog ønsker at præfikse en ubenyttet variabel med en understregning, er der en mulighed i @typescript-eslint/naming-convention-reglen for det. For eksempel:

"@typescript-eslint/naming-convention": [
  "error",
  {
    "selector": "variable",
    "modifiers": ["unused"],
    "format": ["strictCamelCase"],
    "leadingUnderscore": "require"
  },
]

Justér efter dine egne behov. Du kan lave det for andre typer end bare variable, eller du behøver ikke at bruge "strict" camel case (det samme som camelCase, men på hinanden følgende store bogstaver er ikke tilladt [dvs. myId er gyldigt, men myID er ikke]), eller du kan gøre underscore tilladt, men ikke nødvendigvis påkrævet. Der findes endda modificatorer, så det kun gælder for destrukturerede variable.

Derudover bør jeg påpege, at hvis denne regel blev sat fra en udvidet konfiguration, vil det at sætte den i din egen konfiguration tilsidesætte og erstatte naming-convention-reglen sat i den konfiguration, i stedet for at udvide den. Enhver konvention, der er sat i reglen fra den delte konfiguration, vil ikke blive respekteret; hvis du ønsker at bevare dem, skal de duplikeres i din konfigurations naming-convention-regel, ud over enhver ændring, du ønsker at foretage på den.

Relaterede artikler