[no-promise-executor-return]: false positive on arrow function

What rule do you want to change?

no-promise-executor-return

Does this change cause the rule to produce more or fewer warnings?

Fewer warnings

How will the change be implemented? (New option, new default behavior, etc.)?

New default behaviour that could be changed via an option

Please provide some example code that this change will affect:

It is a common practice to have arrow functions as executors in Promise. Those cases are written that way because they can be one-liners which is to improve the readability.

E.g. writing a delay function as this:

new Promise((resolve) => setTimeout(resolve, millis));

What does the rule currently do for this code?

It reports Return values from promise executor functions cannot be read

What will the rule do after it’s changed?

If it is an arrow function, I believe it makes sense to suppress the warning. Although, there is a possibility to have a code such as:

const someValue = new Promise((resolve) => {
  // code
  // code
  return someValue; // which is wrong, aggre
})

Are you willing to submit a pull request to implement this change?

Not sure how to do this. It is definitely a false positive, because my intention was not consuming the value at all, but to have a one-liner.

[btmills]

👋 hi @ghaiklor-wix! In the original discussion around adding this rule, we explicitly decided not to make an exception for arrow functions, and you can read more about the rationale there. An arrow function is also shown as an example of incorrect code in the rule docs. For those reasons, I’m 👎 to an option that would allow any expression-bodied arrow functions. In most cases, adding curly braces makes the intent more clear, e.g. new Promise((resolve) => { setTimeout(resolve, millis); });.

However, in the original issue, we also contemplated a future enhancement to allow returning function calls as a shortcut. That option would allow your setTimeout() as written without curly braces. Is that something you’d be interested in @ghaiklor-wix? I could be convinced to be in favor of adding such an option, though definitely not as the default behavior because it is contrary to the intent of the rule. @mdjermanovic since you originally suggested it, what are your current thoughts on an option to allow returning call expressions?

[mmkal]

@btmills I’d also like to allow expression arrow functions. In projects that use prettier, I’ve tended to see this rule just get turned off, because it expands

new Promise(resolve => { setTimeout(resolve, 1000) })

into

new Promise(resolve => {
  setTimeout(resolve, 1000)
})

And taking up three lines for such a simple thing just feels wrong. It’s not the hugest deal, but it makes codebases more cluttered, so it gets turned off.

I’d like an option. But failing that, what if it’s allowed when the return value is explicitly voided?

new Promise(resolve => void setTimeout(resolve, 1000))

Would the team be open to a PR doing one of these things?