require: rubocop-performance

Layout/ArgumentAlignment:
  EnforcedStyle: with_fixed_indentation

Layout/ParameterAlignment:
  EnforcedStyle: with_fixed_indentation

Layout/FirstArrayElementIndentation:
  EnforcedStyle: consistent

Layout/MultilineMethodCallIndentation:
  EnforcedStyle: indented

Metrics/BlockLength:
  Exclude:
    - 'spec/**/*'

Layout/LineLength:
  Max: 100
  Severity: refactor

Metrics/ModuleLength:
  Exclude:
    - 'spec/**/*'

Style/ConditionalAssignment:
  EnforcedStyle: assign_inside_condition
  IncludeTernaryExpressions: false

Style/Documentation:
  Enabled: false

Style/EmptyMethod:
  EnforcedStyle: expanded

Style/FrozenStringLiteralComment:
  Enabled: false

Style/GuardClause:
  Enabled: false

Style/IfUnlessModifier:
  Enabled: false

Style/ParenthesesAroundCondition:
  Enabled: false

Style/StringLiterals:
  EnforcedStyle: double_quotes
  Exclude:
    - 'Gemfile'

Style/SymbolArray:
  EnforcedStyle: brackets

Style/TrailingCommaInArguments:
  EnforcedStyleForMultiline: comma

Style/TrailingCommaInArrayLiteral:
  EnforcedStyleForMultiline: comma

Style/TrailingCommaInHashLiteral:
  EnforcedStyleForMultiline: comma

# ---------------------------------------------------
# PENDING COPS: REMOVE AFTER INCORPORATED INTO RUBOCOP
# ---------------------------------------------------

Style/HashEachMethods:
  Enabled: true

Style/HashTransformKeys:
  Enabled: true

Style/HashTransformValues:
  Enabled: true

AllCops:
  NewCops: enable

require: rubocop-performance

Layout/ArgumentAlignment:
  EnforcedStyle: with_fixed_indentation

Layout/ParameterAlignment:
  EnforcedStyle: with_fixed_indentation

Layout/FirstArrayElementIndentation:
  EnforcedStyle: consistent

Layout/MultilineMethodCallIndentation:
  EnforcedStyle: indented

Metrics/BlockLength:
  Exclude:
    - 'spec/**/*'

Layout/LineLength:
  Max: 100
  Severity: refactor

Metrics/ModuleLength:
  Exclude:
    - 'spec/**/*'

Style/ConditionalAssignment:
  EnforcedStyle: assign_inside_condition
  IncludeTernaryExpressions: false

Style/Documentation:
  Enabled: false

Style/EmptyMethod:
  EnforcedStyle: expanded

Style/FrozenStringLiteralComment:
  Enabled: false

Style/GuardClause:
  Enabled: false

Style/IfUnlessModifier:
  Enabled: false

Style/ParenthesesAroundCondition:
  Enabled: false

Style/StringLiterals:
  EnforcedStyle: double_quotes
  Exclude:
    - 'Gemfile'

Style/SymbolArray:
  EnforcedStyle: brackets

Style/TrailingCommaInArguments:
  EnforcedStyleForMultiline: comma

Style/TrailingCommaInArrayLiteral:
  EnforcedStyleForMultiline: comma

Style/TrailingCommaInHashLiteral:
  EnforcedStyleForMultiline: comma

Enable pending rules by default
Enable pending rules by default

As rubocop continues towards a stable [1.0 release](https://github.com/rubocop-hq/rubocop/milestone/4)
new pending rules continue to be introduced with various new versions.

Now, to be clear, according to their [versioning strategy](https://docs.rubocop.org/rubocop/versioning.html),
new pending rules can and will be introduced even after 1.0.

> Now new cops introduced between major versions are set to a special pending status and are not enabled by default. A warning is emitted if such cops are not explicitly enabled or disabled in the user configuration.

Keeping up with these rules as they're introduced and considering each
independently is, quite frankly, a cat and mouse game that I feel like
we're losing with each rubocop release. However, we are seeing noise in
our applications that use this gem alerting us to this every time these
rules are added.

Yet, given our slow rate of adoption (and perhaps my own annoyances
about seeing the warning messages), it seems that we're not apt to
consider each new cop soon after it's introduced with a new version of
rubocop.

As a result, I'm proposing an approach which will enable all pending
rules by default. I'm considering this not only because of the
alleviated maintenance burden, but also because:

1. When introducing this gem initially, our approach was not to
thoughtfully consider each rule that existed in rubocop. Instead, we
accepted the defaults, and tweaked and changed from there as needed and
necessary.
2. gnar-style is not meant to be dogmatically adhered to. I do not
want, and hope that it's not used, as a gating mechanism for code to be
expected. Instead, they should be hints, suggestions, or reminders, much
like any pull request comment left by a team member might be.
3. Should one of the new rules prove to be something that we disagree
with, we're still welcome to tweak it, just as any other existing rule
in the system. I personally don't feel like we need to treat it
differently because it's new, and that's mostly because of item (2)
above.
