Skip to content

The banned-patterns rule

This document is the reference of the banned-patterns rule: its options, the way patterns match, and the diagnostics it produces.

Reference


Configuration

The rule id is banned-patterns. It is off until a project configures patterns and turns it on:

json
{
  "plugins": [
    "@vibator/recommended"
  ],
  "rules": {
    "banned-patterns": {
      "severity": "error",
      "options": {
        "patterns": [
          {
            "pattern": "from \"axios\"",
            "message": "Imports axios directly",
            "expected": "HTTP goes through the shared client",
            "fix": "Import the client from the api module instead"
          }
        ]
      }
    }
  }
}
OptionDescription
include / excludeThe shared vibator scope globs selecting the files the rule judges.
patternsThe patterns to ban. Each entry carries pattern, flags, and its own diagnostic text.
Pattern fieldDescription
patternJavaScript regular expression source, matched against each line.
flagsRegular expression flags, such as i. Defaults to none.
messageWhat is wrong when the pattern matches.
expectedThe standard, positively stated.
fixThe concrete next action.

Detection

Each pattern is compiled once per run and tested against every line of every file in scope, comments included. Binary files are skipped, and vibator-ignore banned-patterns markers are honored at file and line level.

Diagnostics

One diagnostic per matching line. The message, expected, and fix fields come verbatim from the matching pattern, so the finding reads like any other rule's.

Errors

A pattern that is not a valid regular expression produces one project-level diagnostic instead of a crash.

Fix

Each pattern's fix field already states the concrete action, and applying it means editing code the way the project prescribes. The rule implements no fix hook.

Released under the MIT License.