radius-spec 0.3.0 → 0.7.0

data/bin/ci

@@ -15,7 +15,7 @@ bin/rspec
 # bundle-audit provides patch-level verification for Bundler
 # https://github.com/rubysec/bundler-audit.
 echo " ---> Running bundler-audit"
-gem install --no-rdoc --no-ri bundler-audit
+gem install --no-document bundler-audit
 bundle-audit check --update
 
 # Run style checker

data/common_rubocop.yml

@@ -1,26 +1,66 @@
 AllCops:
-  TargetRubyVersion: 2.5.0
+  TargetRubyVersion: 2.7.0
   Exclude:
     # Exclude generated binstubs
     - 'bin/bundle'
     - 'bin/bundler-travis'
+    - 'bin/pronto'
     - 'bin/pry'
+    - 'bin/radius-cli'
     - 'bin/rake'
     - 'bin/rspec'
     - 'bin/rubocop'
     - 'bin/travis'
+    - 'bin/webpack'
+    - 'bin/webpack-dev-server'
     - 'bin/yard'
+    - 'bin/yarn'
     # Exclude vendored content
     - 'vendor/**/*'
 
-# Modifiers should be indented as deep as method definitions, or as deep as the
-# class/module keyword, depending on configuration.
+# We prefer outdented access modifiers as we feel they provide demarcation of
+# the class similar to `rescue` and `ensure` in a method.
 #
-# Configuration parameters: EnforcedStyle, SupportedStyles, IndentationWidth.
+# Configuration parameters: EnforcedStyle, IndentationWidth.
 # SupportedStyles: outdent, indent
 Layout/AccessModifierIndentation:
+  Details: |
+
+    Prefer outdented access modifiers to provide demarcation of the class
+    similar to `rescue` and `ensure` in a method.
   EnforcedStyle: outdent
 
+# Rubocop 0.60.0 changed how it handled value alignments in this cop. This
+# breaks our preference for wanting keys to be aligned, but allowing values to
+# either use the `key` or `table` style:
+#
+#     key_style = {
+#       key: :value,
+#       another: :value,
+#       yet_another: :value
+#     }
+#     table_style = {
+#       key:         :value,
+#       another:     :value
+#       yet_another: :value
+#     }
+#
+# This is logged with Rubocop: https://github.com/rubocop-hq/rubocop/issues/6410
+#
+# Until Rubocop resolves this we've decided to enforce the key style so that we
+# do not lose all associated formatting checks. Additionally, in response to
+# the referenced issue the Rubocop disables the alignment check by default. To
+# continue using it we force enable it here.
+#
+# Configuration parameters: EnforcedHashRocketStyle, EnforcedColonStyle, EnforcedLastArgumentHashStyle.
+# SupportedHashRocketStyles: key, separator, table
+# SupportedColonStyles: key, separator, table
+# SupportedLastArgumentHashStyles: always_inspect, always_ignore, ignore_implicit, ignore_explicit
+Layout/AlignHash:
+  Enabled: true
+  EnforcedHashRocketStyle: key
+  EnforcedColonStyle: key
+
 # Disabling this until it is fixed to support multi-line block chains using the
 # semantic style.
 #
@@ -34,12 +74,15 @@ Layout/BlockAlignment:
 # Disabling this until it is fixed to handle multi-line method chains where the
 # first method call is multi-line.
 #
-# See # https://github.com/bbatsov/rubocop/issues/5650
+# See https://github.com/bbatsov/rubocop/issues/5650
 #
 # Configuration parameters: EnforcedStyle, IndentationWidth.
 # SupportedStyles: consistent, consistent_relative_to_receiver,
 #                  special_for_inner_method_call, special_for_inner_method_call_in_parentheses
-Layout/FirstParameterIndentation:
+#
+# TODO: At some point this is split into both Layout/FirstArgumentIndentation
+# and Layout/FirstParameterIndentation
+Layout/IndentFirstArgument:
   Enabled: false
 
 # This project only uses newer Ruby versions which all support the "squiggly"
@@ -51,14 +94,15 @@ Layout/FirstParameterIndentation:
 Layout/IndentHeredoc:
   EnforcedStyle: squiggly
 
-# We tend to indent multi-line operation statements. I think this is because
-# it's tends to be the default style auto-formatted by VIM (which many of us
-# use). It also helps show the continuation of the statement instead of it
+# We tend to indent multi-line operation statements. I think this is because it
+# tends to be the default style auto-formatted by VIM (which many of us use).
+# It also helps show the continuation of the statement instead of it
 # potentially blending in with the start of the next statement.
 #
 # Configuration parameters: EnforcedStyle, IndentationWidth.
 # SupportedStyles: aligned, indented
 Layout/MultilineOperationIndentation:
+  Details: "This helps show expression continuation setting it apart from the following LOC."
   EnforcedStyle: indented
 
 # In our specs Rubocop inconsistently complains when using the block form of
@@ -83,7 +127,32 @@ Lint/AmbiguousBlockAssociation:
   Exclude:
     - 'spec/**/*_spec.rb'
 
-# Often with benchmarking we don't explictly "use" a variable or return value.
+# We prefer to enforce a consistent usage for readability
+#
+#     <<~SQL.strip
+#       bar
+#     SQL
+#
+#     display(<<~SQL.strip)
+#       bar
+#     SQL
+#
+# Alternatively, refactoring the heredoc into a local also improves
+# readability:
+#
+#     custom_sql = <<~SQL
+#       bar
+#     SQL
+#     display(custom_sql.strip)
+Lint/HeredocMethodCallPosition:
+  Enabled: true
+
+# We prefer people suggesting people subclass `StandardError` for their custom
+# exceptions as this is a relatively common Ruby idiom.
+Lint/InheritException:
+  EnforcedStyle: standard_error
+
+# Often with benchmarking we don't explicitly "use" a variable or return value.
 # We simply need to perform the operation which generates said value for the
 # benchmark.
 #
@@ -92,7 +161,17 @@ Lint/Void:
   Exclude:
     - 'benchmarks/**/*'
 
+Metrics/AbcSize:
+  # TODO: When we are able to upgrade to Rubocop 1.5.0 we want to enable the
+  # following `CountRepeatedAttributes` option. We often find the
+  # multi-references to the same object to be necessary for reability and that
+  # for our team it does not increase complexity.
+  #
+  # CountRepeatedAttributes: false
+  Max: 17
+
 # Configuration parameters: CountComments, ExcludedMethods, Max.
+# ExcludedMethods: refine
 Metrics/BlockLength:
   Exclude:
     - '**/Rakefile'
@@ -100,6 +179,12 @@ Metrics/BlockLength:
     - 'spec/spec_helper.rb'
     - 'spec/**/*_spec.rb'
     - 'spec/support/model_factories.rb'
+  ExcludedMethods:
+    - 'chdir'
+    - 'refine'
+    - 'Capybara.register_driver'
+    - 'RSpec.configure'
+    - 'VCR.configure'
 
 # We generally prefer to use the default line length of 80. Though sometimes
 # we just need a little extra space because it makes it easier to read.
@@ -133,6 +218,22 @@ Metrics/LineLength:
     # Attempt at trailing comments
     - '\A.{1,78}\s#\s.*\z'
   Max: 100
+  Exclude:
+    - '**/*.gemspec'
+
+# TODO: Remove this when we get to 0.89.0 as the new default max is 8
+#
+# Configuration parameters: IgnoredMethods, Max
+Metrics/PerceivedComplexity:
+  Max: 8
+
+# This is overly pedantic (only allowing `other` as the parameter name). Ruby
+# core doesn't follow this consistently either. Looking at several classes
+# throughout Ruby core we do often see `other`, but also often `obj` or
+# `other_*`. In some cases, the parameter is named more meaningfully with names
+# like `real`, `numeric`, or `str`.
+Naming/BinaryOperatorParameterName:
+  Enabled: false
 
 # Configuration parameters: ExpectMatchingDefinition, Regex, IgnoreExecutableScripts, AllowedAcronyms.
 # AllowedAcronyms: CLI, DSL, ACL, API, ASCII, CPU, CSS, DNS, EOF, GUID, HTML, HTTP, HTTPS, ID, IP, JSON, LHS, QPS, RAM, RHS, RPC, SLA, SMTP, SQL, SSH, TCP, TLS, TTL, UDP, UI, UID, UUID, URI, URL, UTF8, VM, XML, XMPP, XSRF, XSS
@@ -148,11 +249,41 @@ Naming/FileName:
 # for those heredocs which represent "file" text.
 #
 # Configuration parameters: Blacklist.
-# Blacklist: END, (?-mix:EO[A-Z]{1})
+# Blacklist: (?-mix:(^|\s)(EO[A-Z]{1}|END)(\s|$))
 Naming/HeredocDelimiterNaming:
+  Details: |
+
+    Use meaningful delimiter names to provide context to the text. The only
+    allowed `EO*` variant if `EOF` which has specific meaning for file content.
   Blacklist:
     - !ruby/regexp '/(^|\s)(EO[A-EG-Z]{1}|END)(\s|$)/'
 
+# It is generally a good idea to match the instance variable names with their
+# methods to keep consistent with the attribute reader / writer pattern.
+# However, this can pose an issue in Rails. Most notably, when writing modules
+# that will be used as controller plugins. The reason is that the Rails
+# controllers-to-view interface is ivars. Using a leading underscore can help
+# avoid accidental controller ivar naming conflicts.
+#
+# Configuration parameters: EnforcedStyleForLeadingUnderscores.
+# SupportedStylesForLeadingUnderscores: disallowed, required, optional
+Naming/MemoizedInstanceVariableName:
+  Details: |
+
+    It is generally a good idea to match the instance variable names with their
+    methods to keep consistent with the attribute reader / writer pattern. An
+    exception can be made for modules that want to avoid naming conflicts with
+    classes that include them. In this case a single leading underscore is
+    acceptable.
+  EnforcedStyleForLeadingUnderscores: optional
+
+# We don't really care about this check. Sometimes using something simple such
+# as `err` is just fine. Other times it may improve readability to have a more
+# descriptive name. We feel this is a personal judgement call and not something
+# that needs to be enforced.
+Naming/RescuedExceptionsVariableName:
+  Enabled: false
+
 # `alias` behavior changes on scope. In general we expect the behavior to be
 # that which is defined by `alias_method`.
 #
@@ -161,6 +292,13 @@ Naming/HeredocDelimiterNaming:
 # Configuration parameters: EnforcedStyle.
 # SupportedStyles: prefer_alias, prefer_alias_method
 Style/Alias:
+  Details: |
+
+    Prefer `alias_method` because `alias` behavior changes based on scope.
+
+    See:
+      - https://stackoverflow.com/questions/4763121/should-i-use-alias-or-alias-method
+      - https://blog.bigbinary.com/2012/01/08/alias-vs-alias-method.html
   EnforcedStyle: prefer_alias_method
 
 # Keeping with our semantic style we allow use of `and` / `or` conditionals
@@ -175,6 +313,12 @@ Style/Alias:
 # Configuration parameters: EnforcedStyle.
 # SupportedStyles: always, conditionals
 Style/AndOr:
+  Details: |
+
+    Use `&&` / `||` for conditionals or general comparison. Use `and` / `or`
+    for control flow to provide additional semantic hints:
+
+        system("some command") or system("another command")
   EnforcedStyle: conditionals
 
 # These days most people have editors which support unicode and other
@@ -189,19 +333,23 @@ Style/AsciiComments:
 #   - Prefer `{...}` over `do...end` for functional blocks.
 #
 # When the return value of the method receiving the block is important prefer
-# `{..}` over `do..end`.
+# `{...}` over `do...end`.
 #
-# Configuration parameters: EnforcedStyle, SupportedStyles, ProceduralMethods,
-#   FunctionalMethods, IgnoredMethods.
+# Some people enjoy the compact readability of `{...}` for one-liners so we
+# allow that style as well.
+#
+# Configuration parameters: EnforcedStyle, ProceduralMethods, FunctionalMethods, IgnoredMethods.
 # SupportedStyles: line_count_based, semantic, braces_for_chaining
 Style/BlockDelimiters:
   Details: |
+
     Use semantic style for blocks:
       - Prefer `do...end` over `{...}` for procedural blocks.
       - Prefer `{...}` over `do...end` for functional blocks.
 
     When the return value of the method receiving the block is important prefer
     `{..}` over `do..end`.
+  AllowBracesOnProceduralOneLiners: true
   Enabled: true
   EnforcedStyle: semantic
   ProceduralMethods:
@@ -212,7 +360,13 @@ Style/BlockDelimiters:
     - realtime
     - with_object
   FunctionalMethods:
+    - create
+    - create!
+    - build
+    - build!
+    - default_scope
     - each_with_object
+    - filter_sensitive_data
     - find
     - git_source
     - let
@@ -226,6 +380,19 @@ Style/BlockDelimiters:
     - proc
     - it
 
+# Prefer `Time` over `DateTime`.
+#
+# While these are not necessarily interchangeable we prefer `Time`. According
+# to the Ruby docs `DateTime` is meant more for historical dates; it also does
+# not consider leap seconds or summer time rules.
+#
+# Lastly, `DateTime` is part of the stdlib which is written in Ruby; where as
+# `Time` is part of core and written in C.
+#
+# Configuration parameters: AllowCoercion
+Style/DateTime:
+  Enabled: true
+
 # The double negation idiom is a common Ruby-ism. All languages have various
 # idioms and part of learning the language is learning the common idioms. Once
 # learning the meaning it is not cryptic as Rubocop implies.
@@ -303,6 +470,7 @@ Style/EmptyMethod:
 # SupportedStyles: ruby19, hash_rockets, no_mixed_keys, ruby19_no_mixed_keys
 Style/HashSyntax:
   Details: |
+
     Prefer symbol keys using the 1.9 hash syntax. However, when keys are mixed
     use a consistent mapping style; which generally means using hash rockets.
   EnforcedStyle: ruby19_no_mixed_keys
@@ -316,6 +484,7 @@ Style/HashSyntax:
 # SupportedStyles: line_count_dependent, lambda, literal
 Style/Lambda:
   Details: |
+
     As part of our semantic style we generally use the literal `-> { }` format
     to indicate this is a function with a return value we care about. As this
     cop doesn't have a more flexible setting we prefer the literal syntax to
@@ -335,9 +504,10 @@ Style/MethodCalledOnDoEndBlock:
 Style/MultilineBlockChain:
   Enabled: false
 
-# Context for this cop is too dependent. Often using the numeric comparision is
-# faster. An in certain contexts, Also, depending on the context a numeric
-# comparison is more consistent and can even be more natural:
+# Context for this cop is too dependent.
+#
+# Often using the numeric comparison is faster. Also, depending on the context
+# a numeric comparison may produce a more consistent style:
 #
 #     # numeric comparison is more natural and consistent
 #     if n < 0
@@ -350,6 +520,32 @@ Style/MultilineBlockChain:
 Style/NumericPredicate:
   Enabled: false
 
+# In Ruby every method returns a value. Implicitly this is the value of the
+# last line of the method. This means using `return` is often redundant.
+# However, there isn't anything inherently wrong about doing so. In fact, in
+# some cases it can help with a consistent style in a method:
+#
+#     def transform(value)
+#       return value.call if value.is_a?(Proc)
+#       return value if value.frozen?
+#       return value.dup
+#     end
+#
+# Other times it can add context to a seemingly oddly place value:
+#
+#     def munge(data)
+#       data.slice! 5
+#       return nil
+#     end
+#
+# We often omit the explicit `return` in our code. Though sometimes we include
+# it for improved contextual clues and we don't want Rubocop to complain for
+# those cases.
+#
+# Configuration parameters: AllowMultipleReturnValues.
+Style/RedundantReturn:
+  Enabled: false
+
 # Prefer slashes for simple expressions. For multi-line use percent literal
 # to support comments and other advanced features. By using the mixed style we
 # are choosing to use `%r{}` for multi-line regexps. In general we are not a
@@ -366,6 +562,13 @@ Style/NumericPredicate:
 # Configuration parameters: EnforcedStyle, AllowInnerSlashes.
 # SupportedStyles: slashes, percent_r, mixed
 Style/RegexpLiteral:
+  Details: |
+
+    Prefer slashes for simple expressions. Use `%r` for expressions containing
+    slashes and for complex expressions so then can be written across multiple
+    lines (allowing advanced features such as comments). Use of `%r` for
+    expressions spanning multiple lines provides some comprehension parity with
+    general code blocks.
   EnforcedStyle: mixed
 
 # If you only need to rescue a single, or predefined set of exceptions, then
@@ -407,13 +610,28 @@ Style/RegexpLiteral:
 # Configuration parameters: EnforcedStyle.
 # SupportedStyles: implicit, explicit
 Style/RescueStandardError:
+  Details: |
+
+    If you only need to rescue a single, or predefined set of exceptions, then
+    catch each exception explicitly. When you need to include a general error
+    handler or "catch-all" use the "unspecified rescue":
+
+        begin
+          # do something that may cause a standard error
+        rescue TypeError
+          handle_type_error
+        rescue => e
+          handle_error e
+        end
+
+    Avoid rescuing `Exception` as this may hide system errors.
   EnforcedStyle: implicit
 
 # We generally prefer double quotes but many generators use single quotes. We
 # don't view the performance difference to be all that much so we don't care
 # if the style is mixed or double quotes are used for static strings.
 #
-# Configuration parameters: EnforcedStyle, SupportedStyles, ConsistentQuotesInMultiline.
+# Configuration parameters: EnforcedStyle, ConsistentQuotesInMultiline.
 # SupportedStyles: single_quotes, double_quotes
 Style/StringLiterals:
   Enabled: false
@@ -440,7 +658,7 @@ Style/SymbolArray:
   MinSize: 3
 
 # When ternaries become complex they can be difficult to read due to increased
-# cognative load parsing the expression. Cognative load can increase further
+# cognitive load parsing the expression. Cognitive load can increase further
 # when assignment is involved.
 #
 # Configuration parameters: EnforcedStyle, AllowSafeAssignment.
@@ -448,9 +666,10 @@ Style/SymbolArray:
 Style/TernaryParentheses:
   AllowSafeAssignment: false
   Details: |
+
     When ternaries become complex they can be difficult to read due to
-    increased cognative load parsing the expression. Cognative load can
-    increase further when assignment is involved. To help reduce this cognative
+    increased cognitive load parsing the expression. Cognitive load can
+    increase further when assignment is involved. To help reduce this cognitive
     use parentheses for complex expressions.
   EnforcedStyle: require_parentheses_when_complex
 
@@ -466,6 +685,7 @@ Style/TernaryParentheses:
 # SupportedStylesForMultiline: comma, consistent_comma, no_comma
 Style/TrailingCommaInArguments:
   Details: |
+
     Always use trailing commas for multiline arguments. This makes git diffs
     easier to read by cutting down on noise when commas are appended. It also
     simplifies adding, removing, and swapping argument orders.
@@ -480,6 +700,7 @@ Style/TrailingCommaInArguments:
 # SupportedStylesForMultiline: comma, consistent_comma, no_comma
 Style/TrailingCommaInArrayLiteral:
   Details: |
+
     Always use trailing commas for multiline arrays. This makes git diffs
     easier to read by cutting down on noise when commas are appended. It also
     simplifies adding, removing, and re-arranging the elements.
@@ -492,6 +713,7 @@ Style/TrailingCommaInArrayLiteral:
 # SupportedStylesForMultiline: comma, consistent_comma, no_comma
 Style/TrailingCommaInHashLiteral:
   Details: |
+
     Always use trailing commas for multiline hashes. This makes git diffs
     easier to read by cutting down on noise when commas are appended. It also
     simplifies adding, removing, and re-arranging the elements.