formatting.eslintrc.yaml

# Formatting rules which overrule Prettier.  These are in their own file so
# we can follow each Prettier run with a streamlined (and faster) ESLint run
# that uses only these rules.

parser: babel-eslint

plugins:
  - flowtype

rules:
  # Disallow tucking a condition or loop body in at the end of a line, like
  # `if (condition) return;`.  That makes it much too easy to miss control flow.
  nonblock-statement-body-position: [error, below]
  curly: [error, all]

  # When breaking a line at a binary operator, the operator goes
  # at the start of a line, not the end.  This makes it much more
  # conspicuous whether we're using e.g. `&&` or `||`.
  operator-linebreak:
    - error
    - before
    - overrides:
        # Assignment operators are a very different beast, which it would make
        # no sense to format this way.
        "=": after
        "+=": after
        "-=": after
        # ... There are 10 other assignment operators in JavaScript;
        # if they come up, add them.

  # This *would* overrule Prettier, and in particular run roughshod over
  # line-length limits.  Let Prettier take care of it.
  implicit-arrow-linebreak: off

  # Not sure this rule is quite *right* -- in a type fragment like
  #   foo:
  #     | 'have_a_long_name_number_the_first'
  #     | 'have_a_long_name_number_the_second'
  #     | 'have_a_long_name_number_the_third'
  # Prettier would format that code like above, while this rule
  # causes the first item to get stuffed on the previous line,
  # like `foo: | 'have_a_...'`.  But it's what we've had, so make
  # prettier and lint runs agree.
  #
  # TODO: try fixing this to follow what Prettier does.
  flowtype/space-after-type-colon: [error, always]