Disable Arrow-Parens Lint rule in XO and Prettier
Tags: beginners, bestpractice, javascript, codequality
Published: 2020-08-25 16:10:53

---
title: Disable Arrow-Parens Lint rule in XO and Prettier
published: true
description: what is arrow-parent lint rule and how to disable it
tags: #beginners, #bestpractice, #javascript, #codequality
---

### TLDR 
How do you disable [arrow-parens](https://eslint.org/docs/rules/arrow-parens) eslint rule if you are using [XO](https://github.com/xojs/xo) and [Prettier](https://prettier.io/docs/en/index.html)? 

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](https://eslint.org/docs/rules/max-params)  but rather just a [generic prettier configuration page](https://github.com/prettier/eslint-plugin-prettier).

By googling the suggestion though I immediately found the ESLint rule [arrow-parens](https://eslint.org/docs/rules/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](https://github.com/prettier/prettier-vscode/issues/1374) 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