Allow aliases for rules (with configuration)

[ajafff]

Add an optional field alias per rule. This allows you to use a rule with a specific configuration under another name. That name is then used for error reporting, disable comments and extending configs.

This enables extending rules like ESLint's no-resticted-syntax. Normally extending this rule overrides all config options defined in the base config. This is not really the desired behavior. Now you can create an alias for a specific rule configuration. By overriding the original rule, you don't alter the alias. By overriding the alias, you don't alter the original rule's config.

How it used to be:

# bad/base.yaml
rules:
  no-restricted-syntax:
    - error
    - WithStatement

# bad/extending.yaml
extends: ./bad/base.yaml
rules:
  no-restricted-syntax:
    - error
    - DeleteExpression
    - WithStatement # the base config is completely overridden, so we need to specify WithStatement here again

Adding to the existing config is very cumbersome. Even worse: if you extend a shareable config, you don't necessarily (want to) know the base config.

How it can be improved:

# good/base.yaml
rules:
  ban-with-statement: # same as above, but introduces an alias
    severity: error
    options: WithStatement
    alias: no-restricted-syntax

# good/extending.yaml
extends: ./good/base.yaml
rules:
  ban-delete-expression: # Introduces another name
    severity: error
    options: DeleteExpression
    alias: no-restricted-syntax

Using aliases configures no-restricted-syntax twice, indenpendently. You can even disable one of them without interfering with the other.

The good parts:

• alias names are used for error reporting
  • hopefully more descriptive name
• aliases are used in disable comments
  • fine grained control which option is disabled
• aliases are inherited
  • allows shareable configs to provide aliases for rules with configurations, that you can simply enable or are enabled by default
  • this makes it completely transparent which rule is used behind the scenes

The bad parts:

• executes the rule once per alias, potentially causing performance problems if used excessively.
• you can use an alias as rule for another alias, that overrides the config like it used to happen for regular rules.

TBD

• can aliases be reconfigured? Probably yes, to be consistent with regular rules
• put aliases in a separate section of the config?
  • needs to explicitly enable the alias like any other rule
  • could be used to enforce a prefix
  • makes intent clearer
  • avoids adding disabled aliases, that could be enabled in extending configs, as they are disabled by default
  • should not have a severity then
  • enforces overriding the config when overriding the rule
• enforce a special name (or sigil) for aliases?
  • Otherwise: rule names resolve either to a rule or to an alias depending on the inheritance hierarchy
  • aliases can shadow rules
  • rules in child configs can shadow aliases from base config
• the alias name has no restrictions
  • an alias can override a core rule (is that a good thing?)
  • package authors can freely choose their prefix (same as rulesDirectories)

[ajafff]

Regarding the open design decisions:

• aliases get their own top level key
  • config authors are forced to choose a prefix (same as rulesDirectory)
  • for the time being, aliases are not allowed in overrides (no specific reason other than complexity)
• aliases need to be enabled like all other rules
  • they are identified by prefix/name just like rules
• aliases can shadow custom rules and custom rules can shadow aliases
• an alias always refers to the rule that is accessible in the containing config (or its parents). It does not automagically use a rule declared in a child config

Updated example:

# base.yaml
aliases:
  my:
    ban-with-statement:
      options: WithStatement
      rule: no-restricted-syntax
rules:
  my/ban-with-statement: error

# extending.yaml
extends: ./base.yaml
aliases:
  my:
    ban-delete-expression:
      options: DeleteExpression
      rule: no-restricted-syntax
rules:
  my/ban-delete-expression: error

[ajafff]

aliases can shadow custom rules ~and custom rules can shadow aliases~

If there is an alias in scope, it is always preferred. You can explicitly reset aliases by setting it to a falsy value.

# child.yaml
extends: ./extending.yaml
rulesDirectories:
  my: ./rules
aliases:
  my:
    ban-with-statement: # clear alias
rules:
  my/ban-with-statement: # use rule from rulesDirectory

The example above clears the alias. It also needs to explicitly list the rule again. Otherwise it will still reference the alias as this was the valid reference where the rule was enabled in the base config. This allows the rule to be loaded from the corresponding rulesDirectory