Disable Arrow-Parens Lint rule in XO and Prettier

TLDR

How do you disable arrow-parens eslint rule if you are using XO and Prettier?

Instead of overriding the configuration under XO, do that under a specific prettier node in your package.json, but reference it in camelCase instead of kebab-case.

// in your package json
"prettier": {
    "arrowParens": "avoid"
  },
"xo" : {
prettier:true
}

---

What is Arrow-Parens rule anyway?

Arrow functions can omit parentheses when they have exactly one parameter. In all other cases, the parameter(s) must be wrapped in parentheses. This rule enforces the consistent use of parentheses in arrow functions.

This means that I can write :

const greet = param =>  console.log(`Hi, ${param.name}!`)

but I have to write

const greetWithTitle =  (param, title) =>  console.log(`Hi, {title} ${param.name}!`)

If there is only one parameter, we can omit the parenthesis, but if we have more than one we must wrap the params within brackets!
Handy, isn´t it? Yes, and this is how we normally were used to writing our methods.

Until we updated our linter and we found that the rule was automatically configured and we were getting more than 300 errors like the following:

  ✖  355:30   Replace param with (param)                                              prettier/prettier

The change being suggested was clear, the error was not.

It had no mention of arrow-parens and since the rule wasn't mentioned directly by clicking on it, it wasn't opening the description page like this but rather just a generic prettier configuration page.

By googling the suggestion though I immediately found the ESLint rule arrow-parens.
Still I was not able to disable to rule nor by
// eslint-disable-next-line arrow-parens
nor by configuring it in the Rules section of XO in the package json:

"xo": {
    "semicolon": false,
    "space": 4,
    "prettier": true,
    "rules": {
      'arrow-parens': 0,
   }
}

Then I found this issue on prettier that pointed me in the right direction, because I noticed that the rule name was not in kebab-case rather in camelCase and since it was listed under Prettier I had to override it there and not under the opinionated but overrideable configuration of XO.

Thus, in the package.json, just put alongside xo the configuration of prettier:

 "prettier": {
    "arrowParens": "avoid"
  },
"xo" : {
// same as above
}

OK, but what´s so bad avoiding the parenthesis?

arrow functions (=>) may be mistakenly included in a condition when a comparison such as >= was the intent.

Imagine the following code:

a.then(foo => a);
// or 
if(foo => a) {}

In such cases, it is not really clear if that is a comparison or an arrow function declaration and a mistake could lead to hard to debug unexpected behaviors.

Therefore, better avoid it and stick to the parenthesis all the time.

if it's such a good rule why did I want to disable it?

Well, because in my current ticket/task I had to just update all the outdated dependencies, but I found myself with more than 372 code modifications split among more than 70 files.

I didn't have time to review all of them nor I wanted to pollute my current branch with such changes.
So I preferred to just update the XO dependency, but disable the rule and postpone the code updates at a later moment, where I could enable one rule at a time, unit test the codebase and commit individually every modification that rule required ( either done manually by me or automatically by the --fix command).

I hope it helps

Comments

[Hutch]

Surely any decent linter could figure out that you wouldn't want to use a function as a condition check. I don't see why this rule would be important.

I usually write in TS, tho, so I have to use parentheses anyway when I include the type of the argument.