Search code examples
vue.jsvisual-studio-codeeslintprettier

Eslint no-extra-parens rule does not work


I have a vue project with an ESLint and prettier config like so:

"@typescript-eslint/eslint-plugin": "^4.26.1",
"@typescript-eslint/parser": "^4.26.1",
"@vue/eslint-config-prettier": "^6.0.0",
"@vue/eslint-config-typescript": "^7.0.0",
"eslint": "^7.28.0",
"eslint-plugin-prettier": "^3.4.0",
"eslint-plugin-vue": "^7.9.0",
"prettier": "^2.3.1",

All of the packages should be up to date.

I get this error in VSCode and in the console, which I would like to supress because I want to allow such parantheses for better reading:

enter image description here

enter image description here

As far as I can read, this is what the no-extra-parens rule is for, but I cannot get it to work. The documentation (https://eslint.org/docs/rules/no-extra-parens) states that it has an object option with several adjustments to this rule. If I, for an example, try any of these options:

"no-extra-parens": "0",

or

"no-extra-parens" :{
            "returnAssign": false,
            "nestedBinaryExpressions": false,
            "ignoreJSX": "none|all|multi-line|single-line",
            "enforceForArrowConditionals": false,
            "enforceForSequenceExpressions": false,
            "enforceForNewInMemberExpressions": false,
            "enforceForFunctionPrototypeMethods": false
        },

    

... the error in VSCode dissapears, and everything seems to be working fine. But upon serve the console throws this error:

enter image description here

I´ve tried with

"no-extra-parens": 0,

as the console says, but then the rule is ignored and the first rule break error is shown.

I´ve tried to define the rule in alot of different ways with arrays and objects, setting it to "off", etc. But either the rule does not work in VSCode, or the console states that the rule definition is invalid.

This is my .eslintrc.js file:

module.exports = {
  root: true,
  env: {
    node: true
  },
  extends: [
    "plugin:vue/essential",
    "eslint:recommended",
    "@vue/typescript/recommended",
    "@vue/prettier",
    "@vue/prettier/@typescript-eslint"
  ],
  parserOptions: {
        ecmaVersion: 2020,
        ecmaFeatures: {
            "jsx": false
        },
  },
  rules: {      
        "no-extra-parens": 0,               
    "no-console": ["warn", { allow: ["warn", "error"] }],
        "no-debugger": "warn",   
        "curly": "error", 
    "quotes": [
      "error",
      "single"
        ],
        "@typescript-eslint/ban-ts-comment": "off",
        "@typescript-eslint/ban-ts-ignore": "off",
    "@typescript-eslint/no-explicit-any": "off",
        "@typescript-eslint/no-non-null-assertion": "off",      
        "@typescript-eslint/no-inferrable-types": "off",
        "@typescript-eslint/no-use-before-define" : "off",
        "@typescript-eslint/consistent-type-assertions" : "off",
    "@typescript-eslint/no-empty-function": "warn",     
        "@typescript-eslint/interface-name-prefix": "off",
        "@typescript-eslint/explicit-module-boundary-types": "off",
        "@typescript-eslint/no-var-requires" : "off",
        "@typescript-eslint/no-extra-parens": ["error"]

  }
};

Any clue? 🤔


Solution

  • ESLint uses @typescript-eslint/no-extra-parens and doesn't need no-extra-parens, @typescript-eslint/* are supposed to aggregate * rules with same names, with the addition of features specific to TypeScript.

    It's Prettier that affects this code, changing ESLint rules without disabling Prettier won't change the way it works.

    The use of parentheses in this piece of code is redundant, as any as ... is a common construct in TypeScript and can be read and processed without parentheses:

    const foo = bar as any as Foo;
    

    Double as can be avoided in this case with:

    const foo: Foo = bar as any;
    

    Parentheses are necessary where type assertion is used as a part of an expression, in this case they will be kept by Prettier:

    (bar as any as Foo).baz()
    

    Prettier provides a consistent way to format the code with little configurability, this is its purpose, it shouldn't be expected to be fine-tuned for specific styles.

    In case it's vital for the code to be formatted the way it is, and the setup uses Prettier through ESLint, it can be disabled where needed:

    // eslint-disable-next-line prettier/prettier