Option to disable key-spacing for singleLine

What rule do you want to change?

key-spacing

Does this change cause the rule to produce more or fewer warnings?

Fewer.

How will the change be implemented? (New option, new default behavior, etc.)?

The singleLine and multiLine options would gain a new valid setting, "off" (or alternatively, false). e.g.

"key-spacing": ["error", {
    singleLine: "off",
    multiLine: {
        beforeColon: false,
        afterColon: true,
        mode: 'strict',
    }
}],

Please provide some example code that this change will affect:

This would disable the inspection for single-line objects:

// correct
<BlueBox className="cr-form" style={{minWidth:'500px'}}>

// correct
<BlueBox className="cr-form" style={{minWidth: '500px'}}>

While still enforcing spacing on multi-line objects such as:

// correct
call({
    foobar: 42,
    bat: 2 * 2
});

// incorrect
call({
    foobar:42,
    bat:2 * 2
});

What does the rule currently do for this code?

Prevents spaceless single-line objects from being valid.

What will the rule do after it’s changed?

Allow you to enable/disable singleLine and multiLine settings independently.

---

Alternatively, if we could specify that 0 or 1 space is allowed after the colon, that would also work even better than disabling it completely. You could implement this as mode: "loose".

Version: 3.7.1

[btmills]

I like that “off” is explicit. I’ll give a 👍 for it. @mnpenner would you be willing to send a PR to implement this if it’s accepted?

[not-an-aardvark]

Thanks for your interest in improving ESLint. Unfortunately, it looks like this issue didn’t get consensus from the team, so I’m closing it. We define consensus as having three 👍s from team members, as well as a team member willing to champion the proposal. This is a high bar by design – we can’t realistically accept and maintain every feature request in the long term, so we only accept feature requests which are useful enough that there is consensus among the team that they’re worth adding.

Since ESLint is pluggable and can load custom rules at runtime, the lack of consensus among the ESLint team doesn’t need to be a blocker for you using this in your project, if you’d find it useful. It just means that you would need to implement the rule yourself, rather than using a bundled rule that is packaged with ESLint.