Option to complexity to reduce impact of switch statements

What rule do you want to change? complexity Does this change cause the rule to produce more or fewer warnings? yes How will the change be implemented? (New option, new default behavior, etc.)? A boolean option (optional) to complexity that changes switch statements from incrementing complexity by n number of cases to just incrementing it one Please provide some example code that this change will affect:

switch(expression) {
  case x:
    // code block
    break;
  case y:
    // code block
    break;
  default:
    // code block
}

What does the rule currently do for this code? returns a complexity of 3 What will the rule do after it’s changed? Return a complexity of 1 Are you willing to submit a pull request to implement this change? Yes

[mdjermanovic]

Are rules extensible? Such that I am able to tweak the functionality of complexity without completely copy pasting the whole file?

It’s technically possible to directly extend a core rule, but we do not recommend that approach. Rule implementations are not public API, so an extension rule that relies on the current interface of the core rule (e.g., on the set of listeners returned by create()) might break without notice.

For example, these are listeners in the current version of the complexity rule: https://github.com/eslint/eslint/blob/4338b74767fa71e4e8d171f8503aa33d970e509f/lib/rules/complexity.js#L137-L161

and this is how they might look like after an upcoming change (https://github.com/eslint/eslint/pull/14957): https://github.com/eslint/eslint/blob/551e613986fc462120f8363eb00099d8929ff50f/lib/rules/complexity.js#L93-L153

This change is scheduled for a major release, but the same kind of changes can happen in semver-minor or even semver-patch upgrades.

Therefore, we recommend copy & paste & modify OR copy & paste & extend from the copy. The latter approach seems like a bit more work, but it could make synchronizing the extension rule with the original rule easier.

[nzakas]

I’m in agreement with @mdjermanovic — I don’t think it makes sense to alter the meaning of cyclomatic complexity in this rule. Creating a custom rule to cover your case is the best approach.