prettier / prettier/eslint-plugin-prettier

prefer-arrow-callback fix conflicting with prettier fix

Open
#65 23 comments 9 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

bug
Dominant language
JavaScript
Stars
3.7k
Forks
212
PR merge metrics
No merged PRs in 30d

Description

Edit by @lydell: TL;DR We recommend turning off these rules for the time being:

{
  "rules": {
    "arrow-body-style": "off",
    "prefer-arrow-callback": "off"
  }
}

What version of eslint are you using?
v4.9.0

What version of prettier are you using?
v1.7.4

What version of eslint-plugin-prettier are you using?
v2.3.1

Please paste any applicable config files that you're using (e.g. .prettierrc or .eslintrc files)
https://github.com/ismail-syed/prettier-eslint-config-invalid-code

What source code are you linting?

function foo() {
  return isTrue && [0,1,2].map(function(num) {
    return num * 2;
  });
}

What did you expect to happen?
The code above should be formatted as per prettiers config and also should adhere to that prefer-arrow-callback fix

What actually happened?
Invalid code was generated, closing parenthesis is missing on the return statement.

function foo() {
  return (
    isTrue &&
    [0, 1, 2].map((num) => {
    return num * 2;
  });
}

Is the underlying issue from the prefer-arrow-callback fixer or the prettier plugin fixer?

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the linked prettier-eslint-config-invalid-code reproduction and the JavaScript sample in this issue, using the reported ESLint, Prettier, and eslint-plugin-prettier versions. Determine whether prefer-arrow-callback or the Prettier plugin produces the missing parenthesis, then verify that the reproduction formats and lints to valid code without conflicting fixes.

Written by the indexing model from the issue text.

Assessment

Tech stack
javascript
Domain
tooling
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.