Add third, no-op option accepted in places where only "always" and "never" are accepted

[pineapplemachine]

I believe that there would be value in adding a third, "off" or similar option to places that currently accept only "always" and "never". Where "always" requires that a condition always be met, and "never" requires that it never be met, "off" (or a similar setting) would ignore that condition and not enforce the condition either way.

The space-before-blocks rule is what prompts me to post this. I and another dev have been discussing code style and enforcing this with eslint, and while we both agree that there should be spaces before function and class blocks we feel less decisive regarding spaces between other blocks, such as if and for code blocks. At least for the time being, we want to use the formatter to enforce space before function and class blocks only. We do not want eslint to produce warnings for either style (space or no-space) for other blocks.

I expected to be able to write this:

"space-before-blocks": ["warn", {
    "functions": "always",
    "classes": "always",
    "keywords": "off",
}],

Which did not work as I hoped.

I also tried omitting the "keywords" property, but in this case eslint behaves as though I wrote "always".

This is an example of the behavior I would expect given the aforementioned space-before-blocks rule.

// OK
function myFunction() {
    ...
}
// NOT OK
function myFunction(){
    ...
}

// OK
class MyClass {
    ...
}
// NOT OK
class MyClass{
    ...
}

// OK
if(x) {
    ...
}
// OK
if(x){
    ...
}
// OK
for(x of y) {
    ...
}
// OK
for(x of y){
    ...
}

[nzakas]

Thanks for the issue. It sounds like you are proposing a change to space-before-blocks. Can you please update this issue using the correct template for this request?

[pineapplemachine]

@nzakas I did not feel that the template was a good fit because I am proposing a change that might affect any rules which currently accept only "always" and "never" values, though the rule where not having any third no-op option is affecting me right now is in fact space-before-blocks. Unfortunately, I do not have a thorough enough knowledge of eslint and its rules to enumerate all of the rules that would benefit from such a change.

[nzakas]

Thanks for explaining. We typically do not accept changes that span multiple rules at once because it requires a lot of coordination and research. As it is, this request isn’t specific enough for us to consider. If you are willing to do the research to determine which rules would fall under your proposal and how a change would affect each rule’s behavior, then we can certainly consider it. Otherwise, you are welcome to suggest a change to just one rule for us to consider.

…

On Tue, Oct 2, 2018 at 12:53 AM Sophie Kirschner ***@***.***> wrote: @nzakas <https://github.com/nzakas> I did not feel that the template was a good fit because I am proposing a change that might affect any rules which currently accept only "always" and "never" values, though the rule where not having any third no-op option is affecting me right now is in fact space-before-blocks. Unfortunately, I do not have a thorough enough knowledge of eslint and its rules to enumerate all of the rules that would benefit from such a change. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#10906 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AACWkiSUpg0DS-YaOW55LHgCMklaIHYWks5ugxtpgaJpZM4XB_Kt> .

[pineapplemachine]

Ok, I understand. Note that I do currently have a PR open for adding this functionality to space-before-blocks specifically, here: #10907

[eslint-deprecated]

Unfortunately, it looks like there wasn't enough interest from the team
or community to implement this change. While we wish we'd be able to
accommodate everyone's requests, we do need to prioritize. We've found
that issues failing to reach accepted status after 21 days tend to
never be accepted, and as such, we close those issues.
This doesn't mean the idea isn't interesting or useful, just that it's
not something the team can commit to.

Thanks for contributing to ESLint and we appreciate your understanding.