Bug: conflict between space-before-blocks and switch-colon-spacing

[morganbarrett]

Environment

Node version: 16.0.0
npm version: 7.10.0
Local ESLint version: 7.32.0
Global ESLint version: 7.32.0
Operating System: osx 11.4

What parser are you using?

@typescript-eslint/parser

What did you do?

Configuration

{
    "switch-colon-spacing": "error",
    "space-before-blocks": ["error", "never"]
}

switch(x){
    case 9: {
        break;
    }
}

What did you expect to happen?

For space-before-blocks to acknowledge the rule settings of switch-colon-spacing and behave accordingly.

What actually happened?

The two rules conflicted leaving no state where there was not an error.

Participation

• I am willing to submit a pull request for this issue.

Additional comments

No response

[mdjermanovic]

Hi @morganbarrett, thanks for the issue!

I can reproduce this, it seems that those two rules are indeed conflicting:

 /* eslint 
    "switch-colon-spacing": "error",
    "space-before-blocks": ["error", "never"]
*/

switch(x){
    case 9: { // space-before-blocks error
        break;
    }
}

switch(x){
    case 9:{ // switch-colon-spacing error
        break;
    }
}

Online Demo

Since switch-colon-spacing looks more specific for this code, we should probably update space-before-blocks to ignore blocks in this position. It already ignores blocks after => and after keywords to avoid conflicts with other rules, as documented in rule details.

That might be a breaking change, though.

@eslint/eslint-tsc thoughts about this? If updating space-before-blocks to ignore these blocks looks like the right solution, shall we plan that change for ESLint v8.0.0?

[btmills]

Since switch-colon-spacing looks more specific for this code, we should probably update space-before-blocks to ignore blocks in this position.

I concur. Since that change would a) resolve an unintentional incompatibility between two rules and b) report fewer errors, I don’t see it as a breaking change.

[nzakas]

I concur. Since that change would a) resolve an unintentional incompatibility between two rules and b) report fewer errors, I don’t see it as a breaking change.

Agree. 👍

[mdjermanovic]

I'm working on this.