Feature/make severity for allowed rules configurable

[sverweij]

Description

Adds an allowedSeverity attribute to the rule set format to so you can set the severity of the allowed rule (which was hitherto fixed to "warn")

Example dependency-cruiser.json (adapted from fimbullinter/wotan/.dependency-cruiser.json):

{
  "allowedSeverity": "error",
  "allowed": [
    {
      "from": {
        "path": "^packages/[^/]+/(src/|bin/|index.[jt]s$)"
      },
      "to": {
        "dependencyTypes": ["local", "npm", "npm-optional", "npm-peer", "core"]
      }
    },
    {
      "from": {
        "path": "^(packages/[^/]+/test|scripts)/"
      },
      "to": {
        "dependencyTypes": ["local", "npm", "npm-optional", "npm-dev", "core"]
      }
    },
    {
      "from": {
        "path": "^packages/[^/]+/test/"
      },
      "to": {
        "path": "^(node_modules/(typescript|ava|tslint)|packages)/"
      }
    }
  ],
  "options": {
    "doNotFollow": "(^|/)node_modules/",
    "moduleSystems": ["cjs", "es6"]
  }
}

Motivation and Context

fixes #34

There's a few options configuring the severity of 'allowed' rules could've gone:

• in the options section
  Not the best one; it's actually a property of a rule (/ group of rules) and not a general rule.
• in the allowed section
  Semantically correct and I'm still tempted to do this, but it's backward incompatible - every ruleset with an allowed section should be transformed from this

"allowed": [
    {"from": {"path": "something"}, "to": {"path": "somethingElse"}},
    {"from": {"path": "somethingElse},"to": {"dependencyTypes": ["local", "npm", "core"]}}
]

to this:

"allowed": {
    "severity": "error",
    "rules": [
        {"from": {"path": "something"}, "to": {"path": "somethingElse"}},
        {"from": {"path": "somethingElse}, "to": {"dependencyTypes": ["local", "npm", "core"]}}
    ]
}

(which could be (semi) automated with a utility b.t.w.)

• in the rules part add a allowedSeverity attribute
  Not as clean, but less of a pain to migrate to.

How Has This Been Tested?

• unit tests
• the fimbullinter/wotan repo

Types of changes

• New feature (non-breaking change which adds functionality)

Checklist:

• The code I add will be subject to The MIT license, and I'm OK with that.
• The code I've added is my own original work.
• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.

[ajafff]

I just tried it and it works as expected.

[ajafff]

something is missing at the end of this line

[sverweij]

good catch!