base.yaml

parserOptions:
  ecmaVersion: 2018
env:
  es6: true
plugins:
- prettier
rules:
  ###########
  # Plugins #
  ###########
 
  # Prettier's default config is used here in order to promote consistency,
  # even though my personal preference would be to make the following changes:
  #
  # - `bracketSpacing: false`: Never add spaces between the braces of an object
  #   literal or destructuring assignment, and the tokens inside; it reduces
  #   elegance. This rule is highly subjective.
  #
  # - `printWidth: 79`: Never exceed 79 characters in a line. Otherwise, it
  #   reduces elegance. Note that 79 is used so that the cursor never wraps
  #   over to the next line when using a terminal width of 80. This rule is
  #   highly subjective.
  #
  # - `trailingComma: all`: When defining a multiline list in any context,
  #   always include a comma at the end of the last item. Otherwise, it reduces
  #   maintainability by producing noisy diffs when an item is added to or
  #   removed from the end.
  prettier/prettier: error

  ###################
  # Possible Errors #
  ###################

  # Never create a `for` loop that updates the counter variable in such a way
  # that it gets further away from fulfilling the condition; it reduces
  # correctness because it's easy to make a mistake in logic that results in an
  # infinite loop, and reduces expressiveness because it's unclear whether or
  # not it's intentional.
  for-direction: error

  # When defining an object getter, always return a value. Otherwise, it
  # reduces consistency by defying the expectation that a getter's purpose is
  # to return a value, and reduces expressiveness because it's unclear whether
  # or not it's intentional. Also, when returning `undefined`, always do so
  # explicitly instead of implicitly. See the `no-undefined` rule for reasons
  # why.
  getter-return:
  - error
  - allowImplicit: false

  # When using the `new Promise` constructor, never pass an `async function` as
  # the executor; it reduces debuggability because any error thrown inside of
  # the function will be swallowed instead of being passed to the `reject`
  # function, and reduces consistency because it defies the expectation that a
  # promise executor will just be a standard function.
  no-async-promise-executor: error

  # Don't put an `await` statement inside of a loop unless it's intentional
  # that each promise resolve before iterating, in which case express intent by
  # disabling this rule via an inline comment. Otherwise, it reduces
  # correctness and performance because it's easy to make a mistake in logic
  # that results in independent asynchronous operations running in serial
  # instead of parallel, and reduces expressiveness because it's unclear
  # whether or not it's intentional. If intending to run asynchronous
  # operations in parallel, then store all of the promises in an array and use
  # `await Promise.all(myArray)` after the loop.
  #
  # If frequent use of `await` statements inside of loops is expected in a
  # project, then disable this rule in the local config file.
  no-await-in-loop: error

  # When comparing a value to `-0`, always use `Object.is` instead of `===`.
  # Otherwise, it reduces correctness because `x === -0` passes for both `+0`
  # and `-0`.
  no-compare-neg-zero: error

  # Never put an assignment expression inside of a conditional; it reduces
  # correctness because it's easy to accidentally type `=` instead of `===`,
  # and reduces expressiveness because it's unclear whether or not it's
  # intentional.
  #
  # The `always` option is set instead of the default `except-parens` option
  # because wrapping the assignment in an extra set of parentheses doesn't
  # sufficiently express intent.
  no-cond-assign:
  - error
  - always

  # Don't release code containing a `console` statement unless in a development
  # environment, in which case set this rule to `warn` instead of `error` in
  # the local config file so that the build doesn't fail but reminders are
  # still provided. Otherwise, it reduces security by leaking debugging
  # information to users.
  no-console: error

  # When using a constant expression as a conditional, always express intent by
  # disabling this rule via an inline comment. Otherwise, it reduces
  # correctness because it's easy to make a mistake in logic that results in an
  # infinite loop, and reduces expressiveness because it's unclear whether or
  # not it's intentional.
  no-constant-condition:
  - error
  - checkLoops: true

  # When using a control character in a regular expression, always express
  # intent by disabling this rule via an inline comment. Otherwise, it reduces
  # correctness because it's easy to accidentally type a control character, and
  # reduces expressiveness because it's unclear whether or not it's
  # intentional.
  #
  # If frequent use of control characters is expected in a project, then
  # disable this rule in the local config file.
  no-control-regex: error

  # Don't release code containing a `debugger` statement unless in a
  # development environment, in which case set this rule to `warn` instead of
  # `error` in the local config file so that the build doesn't fail but
  # reminders are still provided. Otherwise, it reduces security by leaking
  # debugging information to users.
  no-debugger: error

  # Never define a function that has multiple arguments with the same name;
  # it's pointless because the last occurrence shadows the one(s) before it.
  # This problem usually happens on accident.
  no-dupe-args: error

  # Never define an object literal that has multiple properties with the same
  # name; it's pointless because the last occurrence shadows the one(s) before
  # it. This problem usually happens on accident.
  no-dupe-keys: error

  # Never define a `switch` statement that has multiple cases with the same
  # clause; it's pointless because the first occurrence is the only one that'll
  # ever be matched. This problem usually happens on accident.
  no-duplicate-case: error

  # When writing an empty code block, always express intent by adding a comment
  # inside. Otherwise, it reduces correctness because it's easy to accidentally
  # delete the contents of a block, or to forget to remove the braces after
  # refactoring. It also reduces expressiveness because it's unclear whether or
  # not it's intentional.
  no-empty:
  - error
  - allowEmptyCatch: false

  # Never include empty brackets in a regular expression; it's pointless
  # because an empty character set doesn't match anything. If needing to
  # include "[]" as part of the pattern, then escape each bracket. This problem
  # usually happens on accident.
  no-empty-character-class: error

  # Never reassign the exception parameter in a `catch` block; it reduces
  # correctness because it's easy to accidentally reassign the exception
  # parameter since it's not protected via `const`, and reduces debuggability
  # because the original error might be lost, and reduces consistency by
  # defying the expectation that the exception parameter will always reference
  # the caught error. Instead, assign the exception to a separate variable that 
  # can later be reassigned as necessary.
  no-ex-assign: error

  # Never cast a variable to a boolean as part of a test condition; it's
  # pointless because it's done automatically by the engine. This problem
  # usually happens as a misguided attempt to add expressiveness where none is
  # needed.
  no-extra-boolean-cast: error

  # This rule is disabled due to being handled by Prettier.
  no-extra-parens: off

  # This rule is disabled due to being handled by Prettier.
  no-extra-semi: off

  # Never reassign a function declaration; it reduces correctness because it's
  # easy to accidentally reassign a function declaration since it's not
  # protected via `const`, and reduces debuggability because it's sometimes
  # difficult to realize that a function declaration has been reassigned, and
  # reduces consistency by defying the expectation that a function defined in
  # this manner will never be reassigned. Instead, assign a function expression
  # to a variable using `let` so that it can later be reassigned as necessary.
  #
  # Note that the `func-style` rule enforces the use of function expressions
  # over function declarations.
  no-func-assign: error

  # Feel free to use a function declaration in a nested block; starting with
  # ES6, function declarations are appropriately block-scoped.
  # 
  # This rule is disabled because it only applies to pre-ES5 environments. Note
  # that the `func-style` rule enforces the use of function expressions over
  # function declarations. Also, the `no-var` rule enforces the use of  `let`
  # and `const` over `var`.
  no-inner-declarations: off

  # Never put an invalid regular expression inside of a `RegExp` constructor;
  # it throws a `SyntaxError` when executed. This problem usually happens on
  # accident.
  no-invalid-regexp: error

  # Don't use a non-standard whitespace character unless necessary for a reason
  # other than elegance, in which case express intent by disabling this rule
  # via an inline comment. Otherwise, it reduces correctness because it's easy
  # to accidentally copy and paste a non-standard whitespace character,
  # resulting in unexpected behavior during string operations. It also reduces
  # expressiveness because it's unclear whether or not it's intentional, and
  # reduces debuggability because it's not visually obvious that a non-standard
  # whitespace character is present.
  no-irregular-whitespace:
  - error
  - skipStrings: false
    skipComments: false
    skipRegExps: false
    skipTemplates: false

  # Never use regular expression character class syntax (e.g., `/[abc]/`) with
  # a character that consists of multiple code points; it reduces correctness
  # because the character is broken down into its code points, resulting in
  # unexpected results.
  no-misleading-character-class: error

  # Never invoke a non-function global object such as `Math` or `JSON` as if
  # it's a function; it throws a `TypeError` when executed. This problem
  # usually happens on accident.
  no-obj-calls: error

  # Never directly invoke an `Object.prototype` method on an object; it reduces
  # correctness because it's possible for such methods to be shadowed, or for
  # an object to not even have `Object.prototype` in its prototype chain.
  # Instead, use `call`.
  no-prototype-builtins: error

  # Never chain multiple spaces together in a regex; it reduces correctness
  # because it's easy to accidentally type `  ` instead of ` `, and reduces
  # expressiveness because it's unclear whether or not it's intentional.
  # Instead, use a single space followed by `{n}` where `n` is the number of
  # spaces.
  no-regex-spaces: error

  # When creating a sparse array via an array literal, always express intent by
  # disabling this rule via an inline comment. Otherwise, it reduces
  # correctness because it's easy to accidentally type `,,` instead of `,`, and
  # reduces expressiveness because it's unclear whether or not it's
  # intentional, and reduces accessibility because it's not widely understood
  # that a sparse array is created when an extra comma is added in an array
  # literal. Better yet, don't use sparse arrays at all; they're not widely
  # understood.
  no-sparse-arrays: error

  # Don't put a template literal placeholder such as `${var}` inside of a
  # single- or double-quoted string unless necessary for a reason other than
  # elegance, in which case express intent by disabling this rule via an inline
  # comment. Otherwise, it reduces correctness because it's easy to
  # accidentally use single or double quotes instead of backticks, and reduces
  # expressiveness because it's unclear whether or not it's intentional.
  no-template-curly-in-string: error

  # This rule is disabled due to being handled by Prettier.
  no-unexpected-multiline: off

  # Never put code after an unconditional exit statement; it's pointless
  # because it's never executed. This problem usually happens on accident.
  no-unreachable: error

  # Never put a control flow statement such as `return` inside of a `finally`
  # block; it reduces accessibility because it's not widely understood that
  # control flow statements inside of a `finally` block take priority over
  # control flow statement inside of a `try` or `catch` block, and reduces
  # correctness because it's easy to forget that rule and make a mistake.
  no-unsafe-finally: error

  # Never negate the left operand when using `in` or `instanceof`; it reduces
  # correctness because it's easy to accidentally only negate the left operand
  # instead of the full expression, resulting in faulty logic. It also reduces
  # expressiveness because it's unclear whether or not it's intentional.
  no-unsafe-negation: error

  # When using `yield` or `await` while reassigning a variable or property to a
  # new value that is based on its old value, always read the old value after
  # `yield` or `await`; otherwise, it reduces correctness because the
  # expression won't take into account any other reassignments that may have
  # occurred to the variable after the initial read but before fulfillment of
  # the promise.
  require-automic-updates: error

  # Never compare a value to `NaN`; it reduces accessibility because it's not
  # widely understood that `NaN` is the only value in JavaScript that's not
  # equal to itself, and reduces correctness because it's easy to forget that
  # rule and make a mistake. Instead, use `isNaN` or `Number.isNaN`.
  use-isnan: error

  # This rule is disabled due to lack of jsdoc usage.
  valid-jsdoc: off

  # Never compare a `typeof` expression to any string literal other than one of
  # the valid types; it's pointless because it always fails.
  #
  # The `requireStringLiterals` option is set to `false` because comparing a
  # `typeof` expression to a variable is a normal thing to do, and it doesn't
  # inherently reduce correctness.
  valid-typeof:
  - error
  - requireStringLiterals: false

  ##################
  # Best Practices #
  ##################

  # Never define a setter via `set` without a corresponding getter, or
  # vice-versa; it reduces testability because it often leads to unverifiable
  # results, and reduces consistency by defying the expectation that a property
  # that can be assigned a value via an assignment operator can also have the
  # value retrieved via simple property access, and vice-versa.
  accessor-pairs:
  - error
  - setWithoutGet: true
    getWithoutSet: true
  
  # When invoking one of Array's map/reduce methods, always return a value in
  # the callback. Otherwise, it reduces correctness because such methods rely
  # on a return value in order to complete their task, but it's easy to forget
  # to add a `return` statement. Also, when returning `undefined`, always do so
  # explicitly instead of implicitly. See the `no-undefined` rule for reasons
  # why. If the method was just being used to invoke a function for each entry
  # in an array, then use `Array.prototype.forEach` instead.
  array-callback-return:
  - error
  - allowImplicit: false

  # Never use a variable defined via `var` outside of the block in which it was
  # defined; it reduces accessibility because it's not widely understood that
  # variables defined via `var` are hoisted and aren't block-scoped, and
  # reduces correctness because it's easy to forget those concepts and make a
  # mistake. Instead, move the `var` statement to the top of the variable
  # scope.
  #
  # Note that the `no-var` rule enforces the use of `let` and `const` over
  # `var`.
  block-scoped-var: error

  # Never define a class method that doesn't reference `this`; it reduces
  # correctness because it's easy to accidentally reference a local variable
  # instead of an instance property, and reduces expressiveness because it's
  # unclear whether or not it's intentional. Instead, use a static class
  # function. Better yet, don't use classes or `this` at all; they reduce
  # correctness, expressiveness, and accessibility due to the ambiguity of
  # `this`.
  class-methods-use-this: error

  # This rule is highly subjective. It's disabled because it's too arbitrary;
  # complexity is based off of so much more than the number of linearly
  # independent code paths.
  complexity: off

  # Never define a function that returns a value in one code path but not
  # another; it reduces correctness because it's easy to forget to add a
  # `return` statement at the end of a function, and reduces expressiveness
  # because it's unclear whether or not it's intentional. If one code path
  # needs to return a value, but another doesn't, then express intent by having
  # the latter return `null` instead of `undefined`. See the `no-undefined`
  # rule for reasons why.
  consistent-return:
  - error
  - treatUndefinedAsUnspecified: false

  # When writing a conditional execution block, always add braces. Otherwise,
  # it reduces correctness because it's easy to forget to add braces later on
  # when a second statement is added to the execution block, and reduces
  # maintainability by producing noisy diffs when the number of statements in
  # the execution block is increased from (or decreased to) one.
  #
  # Note that the above reasoning doesn't really apply when writing a
  # conditional execution block that fits on the same line as its conditional
  # expression. However, the `all` option is still used instead of `multi-line`
  # due to `multi-line` being incompatible with Prettier.
  curly:
  - error
  - all

  # When defining a `switch` block without a default case, always add a
  # `// no default` comment at the bottom. Otherwise, it reduces correctness
  # because it's easy to forget to add a `default` case, and reduces
  # expressiveness because it's unclear whether or not it's intentional.
  default-case: error

  # This rule is disabled due to being handled by Prettier.
  dot-location: off

  # When accessing an object's property, use dot notation unless it's not
  # allowed, in which case use bracket notation. Otherwise, it reduces
  # elegance, and reduces the effectiveness of minifiers.
  #
  # This rule is highly subjective. Note that the `allowKeywords` option is set
  # to `true` because maintaining ES3 compatibility usually isn't a
  # requirement. If it's a requirement, then set `allowKeywords` to `false` in
  # the local config file.
  dot-notation:
  - error
  - allowKeywords: true

  # Always use `===` instead of `==`. Otherwise, it reduces correctness because
  # it's easy to accidentally type `==` instead of `===`, and reduces
  # expressiveness because it's unclear whether or not it's intentional, and
  # reduces accessibility because the rules of `==` regarding type coercion
  # aren't widely understood.
  eqeqeq:
  - error
  - always
  - null: always

  # When looping through keys via `for`/`in`, filter out inherited properties
  # via `Object.prototype.hasOwnProperty` unless inherited properties are
  # necessary, in which case express intent by disabling this rule via an
  # inline comment. Otherwise, it reduces correctness because it's easy to
  # forget to filter out inherited properties, and reduces expressiveness
  # because it's unclear whether or not it's intentional, and reduces
  # accessibility because it's not widely understood that `for`/`in` includes
  # inherited properties.
  guard-for-in: error

  # Never define more than one class in a file; it reduces maintainability
  # because it makes it difficult to locate class definitions.
  max-classes-per-file:
  - error
  - 1

  # Never use `alert`, `prompt`, or `confirm`; they create a poor user
  # experience. Instead, use a custom UI widget.
  no-alert: error

  # Never use `arguments.caller` or `arguments.callee`; they're deprecated.
  # Instead of using `arguments.caller`, the called function should accept the
  # calling function as a parameter. Instead of using `arguments.callee`, the
  # function should just reference itself by name.
  no-caller: error

  # When writing a `case` execution block containing a lexical declaration,
  # always put braces around the block. Otherwise, it reduces accessibility
  # because it's not widely understood that the variable will be scoped to the
  # entire `switch` block instead of only the `case`'s execution block, and
  # reduces correctness because it's easy to forget that rule and make a
  # mistake.
  no-case-declarations: error

  # Don't bother escaping an equal sign at the start of a regex literal; it's
  # pointless, and the rest of the line provides sufficient context to avoid
  # ambiguity with a division operator.
  #
  # This rule is highly subjective. It's disabled because it promotes a
  # pointlessly inelegant style.
  no-div-regex: off

  # When defining an `if` block that always returns when executed, feel free to
  # define an `else` block afterward, even though there's no functional
  # difference between putting code in an `else` block and putting it directly
  # after the `if` block. In some situations, defining an `else` block may even
  # improve expressiveness. 
  #
  # This rule is highly subjective. It's disabled because it protects against
  # something that's not a problem.
  no-else-return: off

  # When defining an empty function, always express intent by adding a comment
  # inside. Otherwise, it reduces correctness because it's easy to accidentally
  # delete the contents of a function, or to forget to remove the braces after
  # refactoring. It also reduces expressiveness because it's unclear whether or
  # not it's intentional.
  #
  # It'd be nice if there was an option in ESLint to allow a function named
  # "noop" to be empty without needing a comment, since the name expresses
  # intent.
  no-empty-function: error

  # Never define an empty pattern (e.g., `let {a: {}} = obj`) when
  # destructuring; it's pointless because no properties are ever assigned. If
  # setting the default value of a property to an empty object, then type `=`
  # instead of `:` (e.g., `let {a = {}} = obj`). This problem usually happens
  # on accident.
  no-empty-pattern: error

  # When comparing a value against `null`, always use `===` instead of `==`.
  # Otherwise, it reduces accessibility because it's not widely understood that
  # `true` will be returned if the value is either `null` or `undefined`, and
  # reduces correctness because it's easy to forget that rule and make a
  # mistake, and reduces expressiveness because it's unclear whether or not
  # it's intentional. If testing for both `null` or `undefined`, then express
  # intent by performing two separate comparisons using `===`.
  #
  # Note that the `eqeqeq` rule enforces the use of `===` over `==`. This rule
  # is only enabled in case the `eqeqeq` rule is disabled.
  no-eq-null: error

  # Never use `eval`; it reduces security by opening the door for injection
  # attacks, and reduces performance.
  no-eval:
  - error
  - allowIndirect: false

  # Never modify a native object such as `Object`; it reduces consistency by
  # defying the expectation that native objects always behave the same way
  # across projects, and reduces correctness because it breaks code that relies
  # on the default implementation.
  no-extend-native: error

  # Never create a new function with `bind` if the target function is an arrow
  # function, or if the new function doesn't use `this` or perform argument
  # binding; it's pointless because it adds no functionality over the unbound
  # version.
  no-extra-bind: error

  # Only use a label in a loop or switch if it's nested, and only if it's
  # necessary for a reason other than elegance. Otherwise, it reduces
  # consistency because it defies the expectation of how labels should be used,
  # and reduces accessibility because labels aren't widely used.
  #
  # Note that the `no-labels` rule disallows the use of labels except in loops.
  no-extra-label: error

  # Never use fall-through logic in a `switch` block unless necessary for a
  # reason other than elegance, in which case express intent by adding a
  # `// fall through` comment at the end of the `case` block. Otherwise, it
  # reduces correctness because it's easy to forget to add a `break` statement
  # at the end of a `case` block, and reduces expressiveness because it's
  # unclear whether or not it's intentional.
  no-fallthrough: error

  # This rule is disabled due to being handled by Prettier.
  no-floating-decimal: off

  # Never reassign a built-in global variable; it reduces consistency by
  # defying the expectation that built-in global variables always behave the
  # same way across projects, and reduces correctness because it breaks code
  # that relies on the default implementation.
  no-global-assign: error

  # Always perform a coercion explicitly (e.g., `Boolean(val)`) instead of
  # implicitly (e.g., `!!val`). Otherwise, it reduces correctness because it's
  # easy to accidentally type `!!` instead of `!`, and reduces expressiveness
  # because it's unclear whether or not it's intentional, and reduces
  # accessibility because operators such as `~` aren't widely understood.
  no-implicit-coercion:
  - error
  - boolean: true
    number: true
    string: true

  # Only declare a `var` or function declaration in the global scope when
  # necessary for a reason other than elegance, in which case express intent by
  # explicitly assigning it to the global object (e.g., `window` in the
  # browser, or `global` in Node.js). Otherwise, it reduces accessibility
  # because it's not widely understood that top-level `var` and function
  # declarations are added as properties to the global object, and reduces
  # correctness because it's easy to forget that rule and make a mistake, and
  # reduces expressiveness because it's unclear whether or not it's
  # intentional.
  #
  # Note that the `func-style` enforces the use of function expressions over
  # function declarations and arrow functions. Also, the `no-var` rule enforces
  # the use of `let` and `const` over `var`.
  no-implicit-globals: error

  # Never indirectly invoke `eval`-like behavior (e.g., by passing code as the
  # first argument to `setTimeout`); it reduces security by opening the door
  # for injection attacks, and reduces performance.
  no-implied-eval: error

  # Don't use `this` outside of expected blocks, such as constructors and
  # object methods, unless necessary for a reason other than elegance, in which
  # case disable this rule via an inline comment, and provide a comment that
  # explains how the code is supposed to be used. Otherwise, it reduces
  # expressiveness because it's unclear what `this` represents in such a
  # context, and reduces correctness because it's easy to accidentally execute
  # the code the wrong way by providing the wrong value for `this`, and reduces
  # consistency because it defies the expectation that `this` is reserved for
  # constructors and object methods. Better yet, don't use classes or `this` at
  # all; they reduce correctness, expressiveness, and accessibility due to the
  # ambiguity of `this`. 
  no-invalid-this: error

  # Never use the __iterator__ property; it's deprecated. Instead, use ES6
  # ES6 iterators and generators.
  no-iterator: error

  # Only use a label in conjunction with a nested loop, and only when
  # necessary. Otherwise, it reduces consistency because it defies the
  # expectation of how labels should be used, and reduces accessibility because
  # labels aren't widely used.
  #
  # Note that the `no-extra-label` rule disallows the use of labels in
  # non-nested loops.
  no-labels:
  - error
  - allowLoop: true
    allowSwitch: false

  # Don't create a standalone code block unless necessary for a reason other
  # than elegance, in which case express intent by disabling this rule via an
  # inline comment. Otherwise, it reduces correctness because it's easy to
  # accidentally delete a related conditional statement during refactoring, and
  # reduces expressiveness because it's unclear whether or not it's
  # intentional.
  no-lone-blocks: error

  # Don't define a function inside of a loop unless necessary for a reason
  # other than elegance, in which case express intent by disabling this rule
  # via an inline comment. Otherwise, it reduces accessibility because it's not
  # widely understood that all instances of an inner function will reference
  # the same outer incremental variable declared via `var`, and reduces
  # correctness because it's easy to forget that rule and make a mistake, and
  # reduces expressiveness because it's unclear whether or not it's
  # intentional, and reduces performance because the same function is redefined
  # many times.
  #
  # Note that the `no-var` rule enforces the use of `let` and `const` over
  # `var`.
  no-loop-func: error

  # Don't explicitly reference a number unless accessing an array element.
  # Otherwise, it reduces expressiveness and accessibility because it's not
  # always obvious what the number represents. Instead, assign the number to a
  # descriptively named constant or property.
  #
  # It'd be nice if the `ignoreArrayIndexes` option also applied to `indexOf`.
  # If this rule proves too onerous, then disable it in the local config file.
  no-magic-numbers:
  - error
  - detectObjects: false
    enforceConst: true
    ignoreArrayIndexes: true

  # This rule is disabled due to being handled by Prettier.
  no-multi-spaces: off

  # Never create a multiline string by putting `\` at the end of each line; it
  # reduces elegance. Instead, use string concatenation or a template literal.
  #
  # This rule is highly subjective.
  no-multi-str: error

  # Never create a function using `new Function()`; it reduces security by
  # opening the door for injection attacks, and reduces performance.
  no-new-func: error

  # Never create a primitive via `new String`, `new Number`, or `new Boolean`;
  # it reduces accessibility because it's not widely understood that such
  # variables are considered objects, causing `typeof` to return "object", and
  # `new Boolean(false)` to resolve to `true`. It also reduces correctness
  # because it's easy to forget that rule and make a mistake.
  no-new-wrappers: error

  # When using `new` but not assigning the result to a variable, always express
  # intent by disabling this rule via an inline comment. Otherwise, it reduces
  # correctness because it's easy to forget to assign the result of the
  # constructor invocation to a variable, and reduces expressiveness because
  # it's unclear whether or not it's intentional, and reduces consistency
  # because it defies the expectation that newly instantiated objects should be
  # assigned to a variable.
  no-new: error

  # Never use an octal escape sequence in a string literal; it's deprecated in
  # ES5. Instead, use a Unicode escape sequence.
  no-octal-escape: error

  # Never use an octal literal (e.g., `071`); it's deprecated in ES5.
  no-octal: error

  # Never reassign a function argument; it reduces correctness because it's
  # easy to accidentally reassign a function argument since it's not protected
  # via `const`, and reduces expressiveness because it's unclear whether or not
  # it's intentional, and reduces consistency because it defies the expectation
  # that an argument always references the variable that was passed in when the
  # function was invoked. Instead, assign the argument to a local variable that
  # can later be reassigned as necessary.
  #
  # The `props` option is highly subjective. Setting it to `true` is an
  # important step toward embracing a purely functional programming style. It
  # significantly increases correctness because arguments are treated as if
  # they're immutable, thus eliminating the risk of accidentally being changed.
  # However, it significantly reduces accessibility because functional
  # programming has a steep learning curve. It also reduces performance because
  # objects are constantly recreated, and reduces elegance due to the amount of
  # boilerplate needed to support the management of immutable objects.
  no-param-reassign:
  - error
  - props: false

  # Never use the `__proto__` property; it's deprecated in ES3.1. Instead, use
  # `Object.getPrototypeOf`.
  no-proto: error

  # Never redeclare a variable using `var`; it's pointless. Instead, just
  # reassign the previously declared variable.
  #
  # Note that the `no-var` rule enforces the use of `let` and `const` over
  # `var`.
  no-redeclare:
  - error
  - builtinGlobals: true

  # This rule is highly subjective. It's disabled because there aren't any
  # properties that are important enough to disallow by default.
  no-restricted-properties: off

  # Never return an assignment expression; it reduces correctness because it's
  # easy to accidentally type `=` instead of `===`, and reduces expressiveness
  # because it's unclear whether or not it's intentional, and reduces
  # accessibility because it's not widely understood that the value returned
  # from an assignment expression is the value that was assigned.
  #
  # The `always` option is used instead of the `except-parens` option because
  # wrapping the assignment in an extra set of parentheses doesn't sufficiently
  # express intent.
  no-return-assign:
  - error
  - always

  # Never combine `await` with `return`; it's pointless because the return
  # value inside of an `async function` is already wrapped inside a promise.
  # All it'll do is add an extra tick of the event loop before the promise is
  # resolved. Instead, just return the value directly.
  no-return-await: error

  # Never use `location.href = "javascript:<code>"`; it reduces security by
  # opening the door for injection attacks, and reduces performance.
  no-script-url: error

  # Never assign a variable or object property to itself; it's pointless. It's
  # common for this to be done on accident.
  no-self-assign:
  - error
  - props: true

  # Never compare a variable to itself; it reduces accessibility because it's
  # not widely understood that `NaN` is the only value in JavaScript that
  # doesn't equal itself, and reduces correctness because it's easy to forget
  # that rule and make a mistake, and reduces expressiveness because it's
  # unclear whether or not it's intentional. If testing for `NaN`, then use the
  # global `isNaN` or `Number.isNaN` functions instead.
  no-self-compare: error

  # Never use the comma operator unless defining the initialization or
  # final-expression portions of a `for` statement. Otherwise, it reduces
  # accessibility because it's not widely understood that the comma operator
  # executes each expression from left to right and returns the value of the
  # last operand.
  #
  # Note that this rule doesn't apply to using commas in argument lists.
  no-sequences: error

  # Never throw any value other than an `Error` object, or an object that
  # extends `Error`; it reduces debuggability due to the lack of a stack trace,
  # and reduces consistency because it defies the expectation that a thrown
  # error is an instance of `Error` with a `stack` property.
  no-throw-literal: error

  # Don't create a loop with a condition that's not modified within the loop
  # unless necessary for a reason other than elegance, in which case express
  # intent by disabling this rule via an inline comment. Otherwise, it reduces
  # correctness because it's easy to make a mistake in logic that results in an
  # infinite loop, and reduces expressiveness because it's unclear whether or
  # not it's intentional.
  no-unmodified-loop-condition: error

  # Never write an expression that doesn't have any effect; in most cases, it's
  # pointless. In other cases, such as when used to short-circuit logic using
  # logical operators or the ternary operator, or when used with a tagged
  # template that has side-effects, it reduces accessibility because it's
  # difficult to understand the resulting logic, and reduces correctness
  # because it's easy to make a mistake that results in an unused expression,
  # and reduces expressiveness because it's unclear whether or not it's
  # intentional. Instead of short-circuiting logic, use an `if` statement.
  # Instead of tagged templates with side-effects, use a normal function.
  no-unused-expressions:
  - error
  - allowShortCircuit: false
    allowTernary: false
    allowTaggedTemplates: false

  # Never define a label that's never used; it's pointless. This problem
  # usually happens on accident as a result of refactoring.
  no-unused-labels: error

  # Only use `.call` or `.apply` when necessary, such as when explicitly
  # setting `this`, or, in the case of `.apply`, when passing in arguments as
  # an array. Otherwise, it's pointless because it's the same as invoking the
  # function normally, except it reduces elegance and performance. This problem
  # usually happens on accident as a result of refactoring.
  #
  # Note that the `prefer-spread` rule enforces the use of the spread operator
  # over using `.apply`.
  no-useless-call: error

  # Never rethrow a caught error without doing anything else in between the
  # error being caught and the error being rethrown; it's pointless. This
  # problem usually happens on accident as a result of refactoring.
  no-useless-catch: error

  # Only use string concatenation when necessary, such as when breaking up a
  # long string across multiple lines. Otherwise, it's pointless because it's
  # the same as putting everything inside of a single string, except it reduces
  # elegance and performance. This problem usually happens on accident as a
  # result of refactoring.
  # 
  # Note that the `prefer-template` rule enforces the use of template literals
  # over string concatenation when embedding expressions. This rule addresses
  # situations that don't involve embedding expressions.
  no-useless-concat: error

  # Never escape a non-special character in a string, template literal, or
  # regular expression; it's pointless. This problem usually happens on
  # accident due to escaping the wrong character.
  no-useless-escape: error

  # When writing a function that doesn't return a value, never add a `return`
  # statement anywhere that doesn't have any code to execute after it anyway;
  # it's pointless.
  no-useless-return: error

  # Never use the `void` operator; it reduces accessibility because it's not
  # widely understood that `void` always returns `undefined`. Instead,
  # reference `undefined` explicitly. Better yet, use `null` instead of
  # `undefined` whenever possible. See the `no-undefined` rule for reasons why.
  no-void: error

  # Feel free to add an inline reminder using a `// TODO:` comment; it improves
  # maintainability, and is more effective than keeping a list of issues in a
  # separate document.
  #
  # This rule is set to `warn` so that it provides reminders about outstanding
  # issues but doesn't cause the build to fail.
  no-warning-comments: warn

  # Never use the `with` statement; it's disallowed in strict mode, and it
  # reduces correctness, expressiveness, and accessibility because it's a
  # highly error-prone and misunderstood feature.
  no-with: error

  # When writing regular expressions with capture groups, always use named
  # capture groups instead of numbered capture groups. Otherwise, it reduces
  # expressiveness because it's not always clear where all of the capture groups
  # are and what each one represents.
  prefer-named-capture-group: error

  # When rejecting a promise, always provide an `Error` object, or an object
  # that extends `Error`. Otherwise, it reduces debuggability due to the lack
  # of a stack trace, and reduces consistency because it defies the expectation
  # that a rejected promise is an instance of `Error` with a `stack` property.
  prefer-promise-reject-errors:
  - error
  - allowEmptyReject: false

  # When using `parseInt`, always provide the radix. Otherwise, it reduces
  # correctness because the engine auto-detects which type of number it should
  # return based on the first argument, thus opening the door to mistakes. It
  # also reduces expressiveness, especially when the first argument is a
  # variable instead of a string, since it might not be clear which type of
  # number is expected to be returned.
  #
  # This rule is still worth it even though in ES5 the `parseInt` function no
  # longer auto-detects octals, so the risk of accidentally ending up with the
  # wrong radix via auto-detection due to an errant leading zero is reduced. It
  # can still auto-detect hexadecimal values (starting with "0x").
  radix:
  - error
  - always

  # Never define an `async function` that doesn't contain at least one `await`
  # statement; it's pointless because it adds no functionality over a standard
  # function.
  require-await: error

  # When defining regular expressions, always set the `u` flag to enable
  # Unicode; otherwise, it reduces correctness because UTF-16 surrogate pairs
  # won't be handled correctly, and reduces debuggability because JavaScript
  # will swallow syntax errors related to the regular expression instead of
  # throwing them.
  require-unicode-regexp: error

  # Always put a `var` declaration at the top of the function or program.
  # Otherwise, it reduces accessibility because it's not widely understood that
  # variables defined via `var` are hoisted and aren't block-scoped, and
  # reduces correctness because it's easy to forget those concepts and make a
  # mistake.
  #
  # Note that the `no-var` rule enforces the use of `let` and `const` over
  # `var`.
  vars-on-top: error

  # This rule is disabled due to being handled by Prettier.
  wrap-iife: off

  # Never use the yoda style (e.g., `if (5 === x)`); it reduces consistency
  # because it's not widely used in other projects, and reduces accessibility
  # because it acts contrary to the natural flow of thought. Also, the
  # `no-cond-assign` rule already protects against the accidental assignment of
  # variables in conditionals, overlapping any benefit of the yoda style in
  # terms of correctness.
  yoda:
  - error
  - never

  ###############
  # Strict Mode #
  ###############

  # Always enable strict mode at the global level. Otherwise, it reduces
  # correctness by allowing bad practices. In Node.js code, put `"use strict";`
  # at the top of each module file. Once ES6 modules are implemented, or when
  # transpiling via babel, disable this rule in the local config file; strict
  # mode is either implied or enabled automatically.
  strict:
  - error
  - global

  #############
  # Variables #
  #############

  # When declaring a variable, always assign it an initial value. Otherwise, it
  # reduces correctness because it's easy to forget to assign a value during
  # initialization, and reduces expressiveness because it's unclear whether or
  # not it's intentional. If declaring a variable before its value has been
  # determined, then assign it to `null` instead of `undefined`. See the
  # `no-undefined` rule for reasons why.
  init-declarations:
  - error
  - always

  # Never use `delete` on a variable; it only works on object properties. If
  # resetting a variable, then reassign it to `null`.
  no-delete-var: error

  # Never declare a variable with the same name as a label, or vice-versa; it
  # reduces elegance due to the resulting ambiguity.
  no-label-var: error

  # This rule is highly subjective. It's disabled because there aren't any
  # globals that are important enough to disallow by default.
  no-restricted-globals: off

  # Never shadow a global object or identifier such as `undefined`; it reduces
  # correctness because it's easy to forget that the global is being shadowed,
  # and reduces expressiveness because whenever the name is referenced it's
  # unclear if the intention is to reference the local variable or the global
  # one, and reduces consistency because it defies the expectation that global
  # objects and identifiers can be referenced anywhere in the project by name.
  no-shadow-restricted-names: error

  # Never declare a variable in an inner scope with the same name as an
  # existing variable in an outer scope (including global variables); it
  # reduces correctness because it's easy to forget that the variable is being
  # shadowed, and reduces expressiveness because whenever the name is
  # referenced it's unclear if the intention is to reference the inner-scoped
  # variable or the outer-scoped one, and reduces debuggability because it's
  # often difficult to recognize that a variable is being shadowed.
  #
  # The `hoist` option is set to `all` because although it's not technically
  # shadowing when the variable in the outer scope is declared after the inner
  # function, and thus the chance of closure-related mistakes is lowered, it
  # still reduces expressiveness and debuggability.
  no-shadow:
  - error
  - builtinGlobals: true
    hoist: all
 
  # When initializing a variable to `undefined`, always do so explicitly
  # instead of implicitly. See the `no-undefined` rule for reasons why.
  #
  # This rule is disabled because it promotes implicitly initializing a
  # variable to `undefined` instead of doing so explicitly.
  #
  # Note that the `init-declarations` rule disallows declaring a variable
  # without explicitly initializing it at the same time.
  no-undef-init: off

  # Never reference a variable that hasn't been declared, not even when using
  # the `typeof` operator; it reduces correctness because it's easy to mistype
  # or misspell a variable name, and reduces expressiveness because it's
  # unclear whether or not it's intentional. If the variable is a global that's
  # not recognized by ESLint for the specified environment, then add the
  # variable to the `globals` section of the local config file.
  no-undef:
  - error
  - typeof: true

  # When referencing `undefined`, always do so explicitly instead of
  # implicitly. Otherwise, it reduces correctness because it's easy to
  # accidentally implicitly initialize a variable to `undefined` by not
  # assigning an initial value, and reduces expressiveness because it's unclear
  # whether or not it's intentional, and reduces accessibility because it's not
  # widely understood that `void` always returns `undefined`. Better yet, use
  # `null` instead of `undefined` whenever possible. Otherwise, it reduces
  # correctness, debuggability, expressiveness, and accessibility due to the
  # ambiguity of `undefined` (which can mean either "undeclared", "declared but
  # unassigned", or "declared and explicitly assigned to `undefined`").
  #
  # This rule is disabled because it promotes referencing `undefined`
  # implicitly instead of explicitly. Some guides recommend only referencing
  # `undefined` implicitly because `undefined` can be redefined or shadowed,
  # thus opening the door for unexpected behavior. But starting with ES5, the
  # global `undefined` can't be redefined, and the `no-shadow-restricted-names`
  # rule disallows shadowing `undefined`.
  # 
  # Note that the `no-void` rule disallows the use of `void`, and the
  # `init-declarations` rule disallows declaring a variable without explicitly
  # initializing it at the same time.
  no-undefined: off

  # Always use every variable and `catch`-block exception argument at least
  # once. Otherwise, it's pointless to declare them. For the same reason, use
  # every function argument at least once unless writing a callback with a
  # predefined argument order when the first argument isn't needed but one or
  # more subsequent ones are, in which case disable this rule via an inline
  # comment. This problem usually happens on accident as a result of
  # refactoring.
  no-unused-vars:
  - error
  - vars: all
    args: all
    caughtErrors: all
    ignoreRestSiblings: false

  # Never reference a variable, function, or class before defining it; it
  # reduces accessibility because it's not widely understood that variables
  # defined via `var` are hoisted and aren't block-scoped, and reduces
  # correctness because it's easy to forget those concepts and make a mistake.
  # In the case of ES6 bindings such as `let`, it throws a `ReferenceError`
  # when executed.
  no-use-before-define:
  - error
  - functions: true
    classes: true
    variables: true

  ########################
  # Node.js and CommonJS #
  ########################

  # When invoking a callback function but not returning immediately thereafter,
  # always express intent by disabling this rule via an inline comment.
  # Otherwise, it reduces correctness because it's easy to accidentally leave
  # out the `return` statement, and reduces expressiveness because it's unclear
  # whether or not it's intentional, and reduces consistency because it defies
  # the expectation that a callback function is invoked after the calling
  # function is finished and thus on the verge of returning.
  #
  # Note that this rule only applies to callback functions assigned to function
  # arguments named "callback", "cb", and "next".
  callback-return: error

  # Feel free to conditionally require a module. It's a normal thing to do.
  #
  # This rule is highly subjective. It's disabled because it protects against
  # something that's not a problem.
  global-require: off

  # When defining a function with `err` as the first argument, always add error
  # handling logic. Otherwise, it reduces correctness because errors are left
  # unhandled. This problem usually happens by accident.
  handle-callback-err: error

  # Never use the `Buffer()` constructor; it reduces security because the
  # behavior differs significantly based on the type of the first argument,
  # which can result in a remote memory disclosure or denial of service when
  # passing unvalidated user input, and reduces correctness because it's easy
  # to make a mistake when passing variables of different types, and reduces
  # expressiveness because it can be unclear what type is being passed in and
  # whether or not it's intentional. Instead, use `Buffer.from`,
  # `Buffer.alloc`, and `Buffer.allocUnsafe`.
  no-buffer-constructor: error

  # Never mix require statements with other variable declarations; it reduces
  # elegance.
  #
  # This rule is highly subjective.
  no-mixed-requires:
  - error
  - grouping: false
    allowCall: true

  # Never use `new` in conjunction with a `require` statement; it reduces
  # accessibility because it's not widely understood that it only works
  # properly if parentheses are added around the full `require` statement, and
  # reduces correctness because it's easy to forget that rule and make a
  # mistake. Instead, assign the result of the `require` statement to a
  # variable, and then use `new` in conjunction with the variable.
  no-new-require: error

  # When combining strings containing parts of a directory or file path, always
  # use Node's `path.join` or `path.resolve` instead of string concatenation.
  # Otherwise, it reduces correctness because different platforms use different
  # path separators, and because it's easy to accidentally add double
  # separators.
  no-path-concat: error

  # When using `process.env`, always create a module wrapper around it, and
  # disable this rule at the top of the module file. Otherwise, it reduces
  # testability because it's more difficult to create a test double of a global
  # than a module.
  no-process-env: error

  # Never use `process.exit`; it reduces testability because it's difficult to
  # test a code path that immediately terminates the application. Instead,
  # throw an error.
  no-process-exit: error

  # This rule is highly subjective. It's disabled because there aren't any
  # modules that are important enough to disallow by default.
  no-restricted-modules: off

  # When using a synchronous I/O function, always express intent by disabling
  # this rule via an inline comment. Otherwise, it reduces performance because
  # synchronous I/O functions are blocking, and reduces expressiveness because
  # it's unclear whether or not the synchronous version is intentionally being
  # used instead of the asynchronous version. If a project exclusively uses
  # synchronous I/O, then disable this rule in the local config file.
  no-sync:
  - error
  - allowAtRootLevel: false

  ####################
  # Stylistic Issues #
  ####################

  # This rule is disabled due to being handled by Prettier.
  array-bracket-newline: off

  # This rule is disabled due to being handled by Prettier.
  array-bracket-spacing: off

  # This rule is disabled due to being handled by Prettier.
  array-element-newline: off

  # This rule is disabled due to being handled by Prettier.
  block-spacing: off

  # This rule is disabled due to being handled by Prettier.
  brace-style: off

  # When naming a non-constant, always use camelcase instead of underscores.
  # Otherwise, it reduces elegance.
  #
  # This rule is highly subjective.
  camelcase:
  - error
  - properties: always
    ignoreDestructuring: true

  # Feel free to start a comment with any character, including an uppercase or
  # lowercase letter.
  #
  # This rule is highly subjective. It's disabled because it protects against
  # something that's not a problem.
  capitalized-comments: off

  # This rule is disabled due to being handled by Prettier.
  comma-dangle: off

  # This rule is disabled due to being handled by Prettier.
  comma-spacing: off

  # This rule is disabled due to being handled by Prettier.
  comma-style: off

  # This rule is disabled due to being handled by Prettier.
  computed-property-spacing: off

  # Always name a variable `self` when it's being used to capture `this`.
  # Otherwise, it reduces consistency by defying the expectation that no
  # variable other than `self` would contain a reference to `this`.
  #
  # This rule is highly subjective.
  consistent-this:
  - error
  - self

  # This rule is disabled due to being handled by Prettier.
  eol-last: off

  # This rule is disabled due to being handled by Prettier.
  func-call-spacing: off

  # When defining a function expression (other than `module.exports`) that's
  # automatically given a name in ES6 based on context, never manually give it
  # a different name; it reduces consistency. Instead, don't manually give it a
  # name at all; the one assigned automatically is sufficient.
  #
  # Note that this rule only disallows manually giving a function expression a
  # different name than the one that's automatically given in ES6 based on
  # context; it doesn't disallow manually giving it the same name.
  func-name-matching:
  - error
  - always
  - includeCommonJSModuleExports: false
    considerPropertyDescriptor: true

  # Always manually give a name to a function expression when it's not
  # automatically given one in ES6 based on context. Otherwise, it reduces
  # debuggability by producing less informative stack traces. Also, never
  # manually give a name to a function expression when it's automatically given
  # one in ES6 based on context; it's pointless.
  #
  # Note that this rule only enforces giving a name to a function expression
  # when it's not automatically given one in ES6 based on context; it doesn't
  # disallow giving a name to a function when it's automatically given one.
  func-names:
  - error
  - as-needed

  # Always use a function expression instead of a function declaration.
  # Function declarations reduce correctness because it's easy to accidentally
  # reassign them since they're not protected via `const`, and reduce
  # expressiveness because when they're reassigned it's unclear whether or not
  # it's intentional.
  #
  # Only use an arrow function when it significantly improves elegance over a
  # function expression, and isn't nested within another arrow function, and
  # fits on a single line so that braces aren't needed, and doesn't involve
  # complex expressions, and is either automatically given a name in ES6 based
  # on context or the risk of it appearing in a stack trace is extremely low.
  # Otherwise, it reduces debuggability by producing less informative stack
  # traces, and reduces correctness because it's easy to get mixed up when
  # nested within another arrow function or when complex expressions are
  # involved, and reduces expressiveness because `=>` isn't as meaningful as
  # `function`.
  func-style:
  - error
  - expression
  - allowArrowFunctions: true

  # This rule is disabled due to being handled by Prettier.
  function-paren-newline: off

  # This rule is highly subjective. It's disabled because there aren't any
  # identifiers that are important enough to disallow by default.
  id-blacklist: off

  # Feel free to use an identifier of any length; even `i` is expressive enough
  # in many situations where iteration is obvious.
  #
  # This rule is highly subjective. It's disabled because it's too arbitrary
  # and protects against something that's not a problem.
  id-length: off

  # This rule is highly subjective. It's disabled because it doesn't add enough
  # value over the `camelcase` rule.
  id-match: off

  # This rule is disabled due to being handled by Prettier.
  implicit-arrow-linebreak: off

  # This rule is disabled due to being handled by Prettier.
  indent: off

  # This rule is disabled due to lack of jsx usage.
  jsx-quotes: off

  # This rule is disabled due to being handled by Prettier.
  key-spacing: off

  # This rule is disabled due to being handled by Prettier.
  keyword-spacing: off

  # Feel free to add a comment anywhere.
  #
  # This rule is highly subjective. It's disabled because it's pointlessly
  # limiting.
  line-comment-position: off

  # This rule is disabled due to being handled by Prettier.
  linebreak-style: off

  # This rule is disabled due to being handled by Prettier.
  lines-around-comment: off

  # This rule is disabled because the use of padding lines between class members
  # is highly subjective and situational.
  lines-between-class-members: off

  # This rule is highly subjective. It's disabled because it's too arbitrary
  # and doesn't add enough value.
  max-depth: off

  # Never exceed 80 characters in a line unless defining a long regex literal
  # or URL. Otherwise, it reduces elegance.
  #
  # This rule is highly subjective. It's enabled because Prettier doesn't
  # actually enforce a max line length. Instead, Prettier only breaks apart
  # long lines that it's able to, and leaves other long lines unaltered. A
  # length of 80 is used here to keep in synch with the default Prettier
  # config, although there would be value in using 79 instead so that the
  # cursor never wraps over to the next line when using a terminal width of 80.
  max-len:
  - error
  - code: 80
    tabWidth: 2
    comments: 80
    ignoreComments: false
    ignoreTrailingComments: false
    ignoreUrls: true
    ignoreStrings: false
    ignoreTemplateLiterals: false
    ignoreRegExpLiterals: true

  # This rule is highly subjective. It's disabled because it's too arbitrary
  # and doesn't add enough value.
  max-lines: off

  # This rule is highly subjective. It's disabled because it's too arbitrary
  # and doesn't add enough value.
  max-lines-per-function: off

  # This rule is highly subjective. It's disabled because it's too arbitrary
  # and doesn't add enough value.
  max-nested-callbacks: off

  # This rule is highly subjective. It's disabled because it's too arbitrary
  # and doesn't add enough value.
  max-params: off

  # This rule is highly subjective. It's disabled because it's too arbitrary
  # and doesn't add enough value.
  max-statements: off

  # This rule is highly subjective. It's disabled because it's too arbitrary
  # and doesn't add enough value.
  max-statements-per-line: off

  # When writing multiline comments, always include a line of either `*` or `//`
  # along the left side. Otherwise, it reduces elegance.
  #
  # This rule is highly subjective. It's disabled because both `starred-block`
  # and `separate-lines` are acceptable styles depending on the situation, but
  # the rule requires that only one be chosen.
  multiline-comment-style: off

  # This rule is disabled due to being handled by Prettier.
  multiline-ternary: off

  # Only use `new` in conjunction with a function that begins with an
  # uppercase, and only invoke a function that begins with an uppercase by
  # using `new`. Otherwise, it reduces consistency by defying the expectation
  # that functions that start with a capital letter are constructors, and ones
  # that don't aren't. If using a 3rd-party library that violates this
  # expectation, then use the `newIsCapExceptions` or `capIsNewExceptions`
  # option to add an exception to this rule in the local config file.
  #
  # Note that builtin globals such as `Symbol` are automatically exempted.
  new-cap:
  - error
  - capIsNew: true
    newIsCap: true
    properties: true

  # This rule is disabled due to being handled by Prettier.
  new-parens: off

  # When chaining multiple method calls, consider putting each one on its own
  # line, especially when passing numerous and/or complex arguments. Otherwise,
  # it reduces maintainability by producing noisy diffs when one of the calls
  # is modified, and sometimes reduces elegance.
  #
  # This rule is disabled because in many situations putting each method call
  # on its own line drastically reduces elegance without sufficiently improving
  # maintainability. The decision to add a new line should be made on a
  # case-by-case basis.
  newline-per-chained-call: off

  # Only use the `Array` constructor when a sparse array is needed, in which
  # case express intent by disabling this rule via an inline comment.
  # Otherwise, it reduces accessibility because it's not widely understood that
  # providing a single argument creates a sparse array of the given size
  # whereas providing multiple arguments creates an array with the given
  # elements, and reduces correctness because it's easy to forget those rules
  # and make a mistake, and reduces expressiveness when providing a single
  # argument because it's unclear whether the intention is to create a sparse
  # array, or a normal array with a single value. Instead, use array literal
  # notation whenever possible. Better yet, don't use sparse arrays at all;
  # they're not widely understood.
  no-array-constructor: error

  # Don't use a bitwise operator (e.g., `&` and `|`) unless necessary for a
  # reason other than elegance, in which case express intent by disabling this
  # rule via an inline comment. Otherwise, it reduces correctness because it's
  # easy to accidentally type `&` instead of `&&`, and reduces expressiveness
  # because it's unclear whether or not it's intentional, and reduces
  # accessibility because bitwise operators aren't widely understood.
  no-bitwise:
  - error
  - int32Hint: false

  # Feel free to use the `continue` statement.
  #
  # This rule is highly subjective. It's disabled because it protects against
  # something that's not a problem.
  no-continue: off

  # Feel free to add a comment anywhere.
  #
  # This rule is highly subjective. It's disabled because it's pointlessly
  # limiting.
  no-inline-comments: off

  # Never nest a lone `if` inside of an `else`'s execution block; it reduces
  # elegance. Instead, use `else if`.
  #
  # This rule is highly subjective.
  no-lonely-if: error

  # This rule is disabled due to being handled by Prettier.
  no-mixed-operators: off

  # This rule is disabled due to being handled by Prettier.
  no-mixed-spaces-and-tabs: off

  # Never chain together multiple assignment expressions; it reduces elegance.
  # Instead, put each assignment on its own line.
  #
  # This rule is highly subjective.
  no-multi-assign: error

  # This rule is disabled due to being handled by Prettier.
  no-multiple-empty-lines: off

  # Never negate a condition when writing an `if`/`else` statement or a ternary
  # expression; it reduces elegance. Instead, invert the condition.
  #
  # This rule is highly subjective.
  no-negated-condition: error

  # Never use a nested ternary expression; it reduces correctness because it's
  # easy to get mixed up.
  no-nested-ternary: error

  # Never create an object using `new Object();`; it reduces elegance. Instead,
  # use an object literal.
  #
  # This rule is highly subjective.
  no-new-object: error

  # Don't use a unary operator such as `++` unless writing the final expression
  # in a `for` statement; it reduces accessibility because it's not widely
  # understood how white space and automatic semicolon injection can change the
  # meaning of expressions that contain unary operators, and reduces
  # correctness because it's easy to forget those concepts and make a mistake.
  # Instead, use `+=`.
  no-plusplus:
  - error
  - allowForLoopAfterthoughts: true

  # This rule is highly subjective. It's disabled because there isn't any
  # syntax that's important enough to disallow by default.
  no-restricted-syntax: off

  # This rule is disabled due to being handled by Prettier.
  no-tabs: off

  # Only use the ternary operator when it significantly improves elegance, and
  # isn't nested within another ternary expression, and doesn't involve complex
  # expressions. Otherwise, it reduces accessibility because it's not widely
  # understood, and reduces correctness because it's easy to get mixed up when
  # nested within another ternary expression or when complex expressions are
  # involved, and reduces expressiveness because `?` and `:` aren't as
  # meaningful as `if` and `else`.
  #
  # This rule is disabled because there are situations in which the ternary
  # operator provides more value than cost. The decision should be made on a
  # case-by-case basis.
  no-ternary: off

  # This rule is disabled due to being handled by Prettier.
  no-trailing-spaces: off

  # Feel free to use dangling underscores in an identifier.
  #
  # This rule is highly subjective. It's disabled because it protects against
  # something that's not a problem.
  no-underscore-dangle: off

  # Never use a ternary expression in a situation that has an easier
  # alternative (e.g., `let foo = bar ? bar : 1;` is better expressed as
  # `let foo = bar || 1;`); it reduces elegance.
  no-unneeded-ternary:
  - error
  - defaultAssignment: false

  # This rule is disabled due to being handled by Prettier.
  no-whitespace-before-property: off

  # This rule is highly subjective. It's disabled because deciding whether a
  # single-line statement should appear beside or below a conditional depends
  # on the complexity of both the conditional and the single-line statement.
  # The decision should be made on a case-by-case basis.
  nonblock-statement-body-position: off

  # This rule is disabled due to being handled by Prettier.
  object-curly-newline: off

  # This rule is disabled due to being handled by Prettier.
  object-curly-spacing: off

  # This rule is disabled due to being handled by Prettier.
  object-property-newline: off

  # When declaring a group of variables, always use a separate declaration for
  # each variable. Otherwise, it reduces maintainability by producing noisy
  # diffs when a variable is added to or removed from the beginning or end of
  # the group.
  one-var:
  - error
  - never

  # This rule is disabled due to being handled by Prettier.
  one-var-declaration-per-line: off

  # Always use a shorthand operator such as `+=` for a simple math operation.
  # Otherwise, it reduces elegance.
  #
  # This rule is highly subjective.
  operator-assignment:
  - error
  - always

  # This rule is disabled due to being handled by Prettier.
  operator-linebreak: off

  # This rule is disabled due to being handled by Prettier.
  padded-blocks: off

  # This rule is disabled because the use of padding lines between different
  # types of statements is highly subjective and situational.
  padding-line-between-statements: off

  # Never pass an object literal as the first argument to `Object.assign`; it
  # reduces elegance. Instead, use object spread syntax.
  #
  # This rule is highly subjective.
  prefer-object-spread: error

  # This rule is disabled due to being handled by Prettier.
  quote-props: off

  # This rule is disabled due to being handled by Prettier.
  quotes: off

  # This rule is disabled due to lack of jsdoc usage.
  require-jsdoc: off
 
  # This rule is disabled due to being handled by Prettier.
  semi: off

  # This rule is disabled due to being handled by Prettier.
  semi-spacing: off

  # This rule is disabled due to being handled by Prettier.
  semi-style: off

  # Feel free to sort object properties in whichever order that makes sense.
  #
  # This rule is highly subjective. It's disabled because it's too limiting.
  sort-keys: off

  # Feel free to sort variable declarations in whichever order that makes
  # sense.
  
  # This rule is highly subjective. It's disabled because it's too limiting.
  sort-vars: off

  # This rule is disabled due to being handled by Prettier.
  space-before-blocks: off

  # This rule is disabled due to being handled by Prettier.
  space-before-function-paren: off

  # This rule is disabled due to being handled by Prettier.
  space-in-parens: off

  # This rule is disabled due to being handled by Prettier.
  space-infix-ops: off

  # This rule is disabled due to being handled by Prettier.
  space-unary-ops: off

  # Always add a space after the opening `//` or `/*` in a comment, and before
  # the closing `*/` when it's on the same line. Otherwise, it reduces
  # elegance.
  #
  # This rule is highly subjective.
  spaced-comment:
  - error
  - always
  - block:
      balanced: true

  # This rule is disabled due to being handled by Prettier.
  switch-colon-spacing: off

  # This rule is disabled due to being handled by Prettier.
  template-tag-spacing: off

  # This rule is disabled due to being handled by Prettier.
  unicode-bom: off

  # Never wrap a regex literal in parentheses; it reduces elegance.
  #
  # This rule is highly subjective. It's disabled because it protects against
  # something that's not a problem.
  wrap-regex: off

  ################
  # ECMAScript 6 #
  ################

  # Only use an arrow function when braces aren't needed (e.g., when returning
  # a single line expression). Otherwise, it reduces elegance. Instead, use a
  # function expression.
  #
  # This rule is highly subjective.
  arrow-body-style:
  - error
  - never

  # This rule is disabled due to being handled by Prettier.
  arrow-parens: off

  # This rule is disabled due to being handled by Prettier.
  arrow-spacing: off

  # Always call `super()` from within the constructor of a derived class.
  # Otherwise, it throws an error upon execution.
  constructor-super: error

  # This rule is disabled due to being handled by Prettier.
  generator-star-spacing: off

  # Never reassign a class; it reduces correctness because it's easy to
  # accidentally reassign a class since it's not protected via `const`, and
  # reduces debuggability because it's sometimes difficult to realize that a
  # class has been reassigned, and reduces consistency by defying the
  # expectation that a class will never be reassigned.
  no-class-assign: error

  # Never define an arrow function in a place where it can be confused with a
  # `>=` comparison operator; it reduces correctness because it's easy to
  # accidentally type `>=` instead of `=>`, and reduces expressiveness because
  # it's unclear whether or not it's intentional. Instead, use a function
  # expression.
  no-confusing-arrow:
  - error
  - allowParens: false

  # Never reassign a variable defined via `const`; it'll throw an error upon
  # execution. Instead, define the variable via `let`. This problem usually
  # happens on accident.
  no-const-assign: error

  # Never define a class that has multiple properties with the same name;
  # it's pointless because the last occurrence shadows the one(s) before it.
  # This problem usually happens on accident.
  no-dupe-class-members: error

  # Always use a single `import` statement per module unless exporting from an
  # imported module, in which case the export should occur in a separate
  # statement. Otherwise, it reduces elegance.
  #
  # This rule is highly subjective.
  no-duplicate-imports:
  - error
  - includeExports: false

  # Never use `new` when creating a `Symbol`; it's designed to be called as a
  # function.
  no-new-symbol: error

  # This rule is highly subjective. It's disabled because there aren't any
  # imports that are important enough to disallow by default.
  no-restricted-imports: off

  # Never reference `this` before `super` in the constructor of a derived
  # class; it throws a `ReferenceError`.
  no-this-before-super: error

  # Never use a computed property when it could be expressed as a non-computed
  # property; it's pointless.
  no-useless-computed-key: error

  # When defining a class, always define a constructor, even if it's identical
  # to the implicit constructor. Otherwise, it reduces correctness because it's
  # easy to forget to define a constructor, and reduces expressiveness because
  # it's unclear whether or not it's intentional.
  #
  # This rule is disabled because it promotes an inexpressive style.
  no-useless-constructor: off

  # When destructuring, importing, or exporting, never rename a reference
  # without actually changing the name; it's pointless.
  no-useless-rename:
  - error
  - ignoreDestructuring: false
    ignoreExport: false
    ignoreImport: false

  # Never use `var` to declare a variable; it reduces accessibility because
  # it's not widely understood that variables defined via `var` are hoisted and
  # aren't block-scoped, and reduces correctness because it's easy to forget
  # those concepts and make a mistake. It also reduces correctness because it's
  # easy to accidentally reassign a variable declared via `var`, and reduces
  # expressiveness because it doesn't convey whether or not the value is
  # intended to be reassigned. Instead, use `let` or `const`.
  no-var: error

  # Always use object shorthand syntax when possible. Otherwise, it reduces
  # elegance. Also, never use arrow functions that explicitly return.
  # Otherwise, it reduces elegance.
  #
  # This rule is highly subjective. Note that the 'arrow-body-style' rule
  # disallows arrow functions being used with braces.
  object-shorthand:
  - error
  - always
  - avoidExplicitReturnArrows: true
    avoidQuotes: false
    ignoreConstructors: false

  # Only use an arrow function when it significantly improves elegance over a
  # function expression, and isn't nested within another arrow function, and
  # fits on a single line so that braces aren't needed, and doesn't involve
  # complex expressions, and is either automatically given a name in ES6 based
  # on context or the risk of it appearing in a stack trace is extremely low.
  # Otherwise, it reduces debuggability by producing less informative stack
  # traces, and reduces correctness because it's easy to get mixed up when
  # nested within another arrow function or when complex expressions are
  # involved, and reduces expressiveness because `=>` isn't as meaningful as
  # `function`.
  #
  # This rule is disabled because in many situations the cost of using an arrow
  # function over a function expression is greater than the benefit. The
  # decision should be made on a case-by-case basis.
  prefer-arrow-callback: off

  # Never use `let` unless the variable is reassigned. Otherwise, it reduces
  # correctness because it's easy to accidentally reassign it, and reduces
  # expressiveness because it doesn't convey whether or not the variable is
  # intended to be reassigned. Instead, use `const`.
  prefer-const:
  - error
  - destructuring: any
    ignoreReadBeforeAssign: false

  # When assigning an object's property to an identically-named variable,
  # always use destructuring. Otherwise, it reduces elegance.
  #
  # This rule is highly subjective. The `array` option is set to `false`
  # because it's only practical to use destructuring with arrays when assigning
  # one or more values sequentially starting from the first element. The
  # `enforceForRenamedProperties` option is set to `false` because the syntax
  # for assigning an object's property to a differently-named variable isn't
  # elegant enough to justify it being required.
  prefer-destructuring:
  - error
  - VariableDeclarator:
      array: false
      object: true
    AssignmentExpression:
      array: false
      object: true
  - enforceForRenamedProperties: false

  # Feel free to use `parseInt` with a radix value of `2`, `8`, or `16`.
  #
  # This rule is disabled because ES6 binary, octal, and hexadecimal literals
  # don't add sufficient expressiveness over `parseInt`.
  prefer-numeric-literals: off

  # When converting a list of arguments into a single variable, always use rest
  # parameters (e.g., `...`) instead of `arguments`. Otherwise, it reduces
  # accessibility because it's not widely understood that `arguments` isn't an
  # actual array, and reduces correctness because it's easy to forget that
  # concept and make a mistake, and reduces elegance because it's not possible
  # to only capture a subset of arguments when using `arguments`.
  prefer-rest-params: error

  # When passing a list of arguments in array form to a function, always invoke
  # the function normally and use the spread operator (e.g., `...vals`) instead
  # of invoking the function via `.apply`. Otherwise, it reduces elegance
  # because it's not possible to only pass a subset of arguments in an array
  # when using `.apply`.
  prefer-spread: error

  # Always use a template literal instead of string concatenation when
  # embedding an expression into a string. Otherwise, it reduces elegance.
  prefer-template: error

  # Never define a generator function that doesn't call `yield`; it's
  # pointless. Instead, use a regular function.
  require-yield: error

  # This rule is disabled due to being handled by Prettier.
  rest-spread-spacing: off

  # Feel free to sort imports in whichever order that makes sense.
  #
  # This rule is highly subjective. It's disabled because it's too limiting.
  sort-imports: off

  # Always provide a description when defining a `Symbol`. Otherwise, it
  # reduces debuggability by producing less informative stack traces.
  symbol-description: error

  # This rule is disabled due to being handled by Prettier.
  template-curly-spacing: off

  # This rule is disabled due to being handled by Prettier.
  yield-star-spacing: off