Indentation/alignment within ternary branches (consequent/alternate)

[josephfrazier]

(extracted from #811 (comment))

Currently (commit 05595b5), standard formats the following code:

let options
const events = typeof options.trigger === 'string'
  ? options.trigger.split(' ').filter(trigger => {
      return ['click', 'hover', 'focus'].indexOf(trigger) !== -1
    })
  : []
console.log(events)

as:

let options
const events = typeof options.trigger === 'string'
  ? options.trigger.split(' ').filter(trigger => {
    return ['click', 'hover', 'focus'].indexOf(trigger) !== -1
  })
  : []
console.log(events)

That is, it unindents the function body and closing brace. Here's the diff:

diff --git a/p.js b/s.js
index c778a36e..0ccb242f 100644
--- a/p.js
+++ b/s.js
@@ -1,7 +1,7 @@
 let options
 const events = typeof options.trigger === 'string'
   ? options.trigger.split(' ').filter(trigger => {
-      return ['click', 'hover', 'focus'].indexOf(trigger) !== -1
-    })
+    return ['click', 'hover', 'focus'].indexOf(trigger) !== -1
+  })
   : []
 console.log(events)

If ESLint makes it possible (see eslint/eslint#6606 and eslint/eslint#7698), would it be acceptable to have standard use the original indentation in this case?

I might be able to hack together a way to test breakage by postprocessing standard's output with prettier-miscellaneous, which produces standard-formatted code with prettier --no-semi --single-quote --jsx-single-quote --space-before-function-paren (with the exception of this issue, as far as I know).

EDIT: This is similar to #521

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[feross]

I agree that we should auto-format to the former example. Re-opening and setting this as a goal for standard v12.

[brodybits]

This would definitely resolve an unfortunate consistency with Prettier (#811 (comment)).

Unfortunately both eslint/eslint#6606 and eslint/eslint#7698 reports are now "archived due to age".

I suspect the best solution would be for someone to make an eslint plugin, similar to the following:

• divyagnan/eslint-plugin-ternaries (eslint-plugin-ternaries)
• dugokontov/eslint-plugin-formatting (eslint-plugin-formatting)

[sheerun]

This is similar to #1451 that I've recently reported. This indeed makes indentation inconsistent

[mightyiam]

More examples in #1451.

[sheerun]

I believe the right thing to do right now is to disable this rule and leave ternary expressions untouched. Implementing this rule in eslint can take long time or even never

[sheerun]

Never mind, I've prepared pull request for eslint, please upvote:

eslint/eslint#12556

[sheerun]

Here's one more example from @Janpot: eslint/eslint#12556 (comment)

[sheerun]

offsetTernaryExpressions indent rule is available in eslint 7.0, it should fix this issue :) eslint/eslint#12556

[feross]

@sheerun Thanks for championing this new option for the indent rule in ESLint. We'll ship it in standard v15.

1..215
# tests 215
# pass  206
# fail  9

Affects 4% of the ecosystem.

These packages need PRs to update to the new style:

• testdouble
• pino
• leveldown
• webtorrent-desktop
• bittorrent-tracker
• electron-mocha
• webtorrent
• buffer
• dependency-check

[feross]

It seems like this rule makes some silly decisions. For example:

    var bytesPerSequence = (firstByte > 0xEF) ? 4
      : (firstByte > 0xDF) ? 3
          : (firstByte > 0xBF) ? 2
              : 1

It's doing 4 spaces after the first ternary. However, when I also enable multiline-ternary (#1558) then this works:

    var bytesPerSequence = (firstByte > 0xEF)
      ? 4
      : (firstByte > 0xDF)
          ? 3
          : (firstByte > 0xBF)
              ? 2
              : 1

Which makes a lot more sense.

[feross]

@sheerun @mightyiam @brodybits @josephfrazier Any interest in helping send PRs to the remaining 5 repos in #927 (comment) ?

[feross]

From #1564 (comment) there is one downside of this rule. Standard doesn't like this code:

export const y = new Date().getTime() % 2
  ? (
    <span>
      ghi
    </span>
  )
  : 'jkl'

Instead it wants:

export const y = new Date().getTime() % 2
  ? (
    <span>
      ghi
    </span>
    )
  : 'jkl'

I think that ideally, we'd make an exception to this rule when an expression wrapped in parens or an array or object appears as the value in the ternary. In this case, we don't want the closing paren/bracket/brace to also be indented. Does someone want to explore getting an option added to ESLint to support this multi-line case?

[brodybits]

@feross @sheerun you can blame me for dropping the ball on prettierx. But it looks to me like Prettier may go in a different direction: prettier/prettier#9561

I do happen to like the Standard 15 way better, would recommend some input on prettier/prettier#9561 before it is too late.

[sheerun]

@brodybits Thanks for letting us know, I've commented there what I find clean. Proposed style should be compatible with what's proposed here

[sheerun]

@feross This probably should read:

export const y = new Date().getTime() % 2
  ? (
      <span>
        ghi
      </span>
    )
  : 'jkl'

but parens are not really necessary:

export const y = new Date().getTime() % 2
  ? <span>
      ghi
    </span>
  : 'jkl'