be opinionated about dot chaining indentation

[chee]

and perhaps ?: indentation.

currently, this is accepted by standard(1):

export function opinions () {
  return rad()
.x
        ? 3
  : 1
}

which

really this came up because i wasn't sure whether to:

// a: keep level
if (cat) {
 woggle()
 .wiggle(w => {
   return w.x ? w.y : w.z
 })
}

or:

// b: indent
if (cat) {
 woggle()
   .wiggle(w => {
     return w.x ? w.y : w.z
   })
}

and depending on the particulars of what i'm writing one seems better than the other, but that has left me with some inconsistency in the codebase.

a has the upside of the closing braces ending up at the same indentation as the original target of the operation

b has the upside of sometimes feeling right

i'm sure i can learn to live with either should this project suggest one

[chee]

also in favour of a:

if you later decide to add a newline before a dot, you don't have to change indentation of its innards.

as in:

expect(a).toEqual({
  type: 'tears',
  number: 96
})

becomes:

expect(a)
.toEqual({
  type: 'tears',
  number: 96
})

rather than

expect(a)
  .toEqual({
    type: 'tears',
    number: 96
  })

[tunnckoCore]

use prettier, period. :D Standard is linter, not formatter (not always true).

[chee]

i mean, sure, but

The whole point of standard is to save you time by avoiding bikeshedding about code style.

this is now some code style that i am bikeshedding about.

there are plenty of formatting rules in standard. including that the dot should be on the same line as the property.

as well as comma-dangle, block-spacing, comma-style, func-call-spacing, key-spacing and so very on.

i mean, you know this, there's no need for me to repeat them here.

semi-spacing, padded-blocks, space-in-parens

there are projects on which i can't use prettier but i would still not like to think about these things

space-unary-ops, spaced-comment(!!!!), template-curly-spacing

i'll see what i can do about getting the tech lead to allow me to set up prettier, but the last time i reformatted the entire project he took it thick.

(i understand you said "not always true", and i understand your suggestion is probably quite a good one, but it doesn't help me much right now)

(but thank you)

semi

[timoxley]

Member expressions indentation is a dupe of #628 and both generally covered by #735. Suggest closing.

[chee]

thanks, tim