Disable rule suggestions

[dferber90]

In a fairly large codebase I've found these rules to be unnecessary/conflicting when using prettier:

no-spaced-func

Prettier fixes callback(/* foo */) to callback /* foo */() at which point the rule warns.

no-confusing-arrow with allowParens option

/*eslint no-confusing-arrow: ["error", {"allowParens": true}]*/
/*eslint-env es6*/
var x = a => (1 ? 2 : 3);
var x = (a) => (1 ? 2 : 3);

Prettier removes the brackets which would avoid the error.

react/wrap-multilines

No example here.

no-unexpected-multiline

Prettier transforms

wrapper.find('FilterBy').prop('activeFilters')[1].filters.map(_ => _.key),

to

        wrapper
          .find('FilterBy')
          .prop('activeFilters')
          [1].filters.map(_ => _.key),

At which point the rule warns. But I'd maybe keep it as this can be solved by extracting the stuff into a variable. Wanted to mention it anyways.

Any thoughts on disabling these?

[lydell]

Thank you for the issue!

no-spaced-func and react/wrap-multilines

These rules are deprecated. So far, I’ve not added any deprecated rules. I’m not sure which way is the best: Go through all deprecated rules, or document that deprecated rules won’t be added. What do you think?

no-confusing-arrow

So far, no rule options are checked. I’m not sure if we want to do that.

We could add it as a new “special rule”, and document that the allowParens option is not a good idea. But since that option isn’t enabled by default, it might do more harm than good? Perhaps it is better to document that eslint-config-prettier isn’t 100% bullet proof and mention this rule?

I wonder if there are any other rules where one might want to check for rule options, rather than the entire rule.

no-unexpected-multiline

I have always considered this rule to be very useful, since it catches those nasty semicolon mistakes. But on the other hand, I guess prettier shows such errors implicitly. For example:

console.log("test")
["a", "b", "c"].forEach(doSomething)

The above is turned into the following by prettier:

console.log("test")[("a", "b", "c")].forEach(doSomething);

That reveals the semicolon mistake just as much as the eslint rule, doesn’t it?

So I guess we could safely add this rule. Perhaps as a “special rule”?

EDIT: Very much related: prettier/prettier#775

[lydell]

@dferber90 I’d love to hear your thoughts!

[dferber90]

@lydell I've not forgotten about this, I have it on my todo-list. I have been super busy (flew from Munich to Rio on the weekend) and getting set up here took a bit. I'll get back to this!

[jacobp100]

Thought I'd add here rather than a new issue.

I'm using airbnb-base. I need no-confusing-arrow turned off, as prettier removes the extra parens required to get this rule to pass. I also need spaced-comment turned off for flow annotation comments!

[lydell]

Thanks for the feedback, @jacobp100!

Regarding no-confusing-arrow, you could also keep it on and turn the allowParens option back to the default value of false (docs). That's the crux of the issue. But I'm starting to feel like eslint-config-prettier should just turn it off and document it as one of the "special rules".

Regarding the spaced-comment rule, I don't see how it has anything to do with prettier. Could you clarify? :)

[jacobp100]

Oh I see about the parens now—I didn't realise it was so strict by default. And thinking about it, you're right about the spaced comments too! 😂

I didn't realise that there would need to be extra config on top of this—but thinking about it, for some rules you'll always need to decide yourself whether you want to keep it!

[lydell]

I think I have made up my mind:

• I will go through all deprecated core, react and flow rules and add what's needed. There's really nothing to lose, only to win.
• no-confusing-arrow will be added as a special rule, since it is conflicting by default in the airbnb config (https://github.com/airbnb/javascript/blob/b153231867170e28c199d6216d36b6367018aab0/packages/eslint-config-airbnb-base/rules/es6.js#L45-L47).
• no-unexpected-multiline will continue to be left alone, since Consider [0] to be part of a member group prettier#775 has been resolved. Yes, in theory it can still cause problems. But I'd rather revisit it in the future if new problematic cases come up.

[lydell]

Should be fixed in 1.4.0.

[dferber90]

Thank you for taking over, the decisions made sound good!

[yaminyaylo]

As a solution you can use "prettier.printWidth": 100(or more) setting to extend line