Enforce no braces in arrow function body where they can be omitted (arrow-body-style)

[tunnckoCore]

Digging more and more in ESLint rules, i found some good ones which enforces good style and more readable code. This issue is for arrow-body-style rule - fixable.

Suggested configuration.

{
  "arrow-body-style": ["error", "as-needed", { "requireReturnForObjectLiteral": false }]
}

This makes shorter and readable code, that does not returns if there no other assignments in the block body.

Example

// OK
let foo = () => ({})
let foo = () => ({ bar: 0 })

// OK
let foo = () => {}

// NOT OKEY
let foo = () => { return { bar: 0 } }
// CORRECT
let foo = () => ({ bar: 0 })

// OK
let foo = () => {
  var a = true
  return 0
}

// NOT OK
let foo = () => {
  return 0
}
// CORRECT
let foo = () => 0

// OK
let foo = (retv, name) => {
  var a = true
  return { bar: 0 }
}

// OK
let foo = (retv, name) => {
  retv[name] = true
  return retv
}

[dcousens]

ACK, but not sure of ecosystem impact.

[daedalus28]

We just started pushing standardjs for all our repos, but there are a lot of eslint rules we used to have that we miss like this one. This really helps developers who are not as familiar with modern js discover how awesome it is.

[yoshuawuyts]

Mixed feelings as I feel there's legit uses for newline returns. I guess +0 as I've stopped using arrow funcfions all together

…

On Tue, Mar 21, 2017, 21:39 Samuel Greene ***@***.***> wrote: We just started pushing standardjs for but there are a lot of eslint rules we used to have that we miss like this one. This really helps developers who are not as familiar with modern js discover how awesome it is. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#792 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACWleuBul0Rix6gEzEfSzMkkHKKzVT6dks5roDVlgaJpZM4MHoS3> .

[falmar]

I use this type of style even without any eslint rules and it is quite amazing less code for more

[daedalus28]

@yoshuawuyts what real use case do you have? This is only about arrow functions that are nothing more than return statements. If your return value is such a large expression that you want it on multiple lines, there's nothing preventing you from putting line breaks in the expression (and/or wrapping in parens if you're worried people can't follow).

[tunnckoCore]

@daedalus28 it is cool, definitely. But after the suggestion i faced such cases too. It may be in conflict with max-len rule (80) that isn't in standard but I always try to follow it as much as possible. Behind such cases is the reason why i'm not using some autoformatter such as prettier. In some cases I need and must set return explicitly on new line, so the line won't go too long.

And some examples tunnckoCore/ideas#64 (working examples btw ;p)

or this one

const VFile = require('vfile')
const each = require('each-promise')
const fs = require('pify')(require('fs'))

const readFiles = (dir, options) => readdir(dir, options).then((files) => {
  const __files = files.filter((file) => file.stat.isFile())
  if (!__files.length) return files

  return each.parallel(__files.map((file) => () => {
    // notice
    return fs.readFile(file.path).then((contents) => VFile({
      path: file.path,
      stat: file.stat,
      contents: contents
    }))
  }))
})

readFiles('./_xtemplates').then(console.log)

But yea. This cases can be fixed a bit and can look a bit better with splitting the code to functions, which can be enforced by another rule that I suggested - #794 - max-depth and max-nested-callbacks.

[ghost]

Too prescriptive. If it makes valid JS, and that JS runs without "bad parts", it probably doesn't belong in Standard.

[feross]

Ecosystem impact is 4%.

# tests 238
# pass  229
# fail  9

[tunnckoCore]

Cool. 4% for fixable rule sounds pretty much okey.