Support block-comment version of eslint-disable-line

Tell us about your environment

• ESLint Version: master
• Node Version: any
• npm Version: any

What parser (default, Babel-ESLint, etc.) are you using? default

Please show your full configuration:

{ "rules": { "no-alert": [1] } }

What did you do? Please include the actual source code causing the issue.

/* eslint-disable-line */ alert(1);

What did you expect to happen?

It should work like in JSCS:

/* jscs:ignore */ alert(1)

What actually happened? Please include the actual, raw output from ESLint.

Error reported.

[not-an-aardvark]

1. How should it do on block comments which have line break? I think it should ignore those or throw an error to avoid confusing.

   /* eslint-disable-line
    *
    */ var foo
   

   /* eslint-disable-next-line
    *
    */
   var foo
   

I think it would be best to report a problem at that location, and ignore the comment. However, it might be a breaking change to start reporting a problem for those cases, since we previously always ignored them.

We could ignore them for now, then start reporting a problem for them in the next major release.

1. How should it handle block comments which are in middle of a line? I think the following code is confusing, so I’d like to ignore those or throw an error. However, it has to allow those to address the cases that the feature wants to support such as JSX case. It’s my concern.

   var /* eslint-disable-line */ foo
   

I think it’s fine to just ignore disable the entire line in that case. We already do that with // eslint-disable-line at the end of a line, so in my opinion it’s not too confusing to to also ignore the entire line if there is a block comment in the middle.

1. How should it handle multiple block comments which are on a line? I think those are merged, but I’m OK if it ignores those or throw an error.

   /* eslint-disable-line no-shadow */ /* eslint-disable-line no-unused-vars */ var foo
   

I think this should disable both rules, by just processing the comments separately.

We already do the same thing in a similar case:

// eslint-disable-next-line no-shadow
var foo // eslint-disable-line no-unused-vars

1. How should it handle a mix of eslint-enable and eslint-disable-line In the following case, I’m not sure how it should behave for errors at the foo. I guess it should be disabled.

   /* eslint-disable-line */ var /* eslint-enable */ foo
   

   If it’s /* eslint-disable */ var /* eslint-enable */ foo, the errors at the foo are reported because the foo is after /* eslint-enable */. Above sample is similar to this. If it’s var /* eslint-enable */ foo //eslint-disable-line, the errors at the foo are not reported because the foo is on the line which has //eslint-disable-line. I think that //eslint-disable-line and /* eslint-disable/enable */ are different type of comments to help avoiding confusion.

We already handle similar cases:

// eslint-disable-next-line
foo; /* eslint-enable */ bar

foo; /* eslint-enable */ bar // eslint-disable-line

With the current behavior, reporting is disabled for foo, but enabled for bar.

---

Right now, we preprocess all disable-line and disable-next-line directives into regular disable and enable directives:

// eslint-disable-next-line
foo;

// is processed the same way as ↓

/* eslint-disable */foo;
/* eslint-enable */

So I think we could just do the same thing here regardless of whether the disable-line comment is a block.

[kaicataldo]

Would it make sense to also make eslint-disable-next-line also available in block comments to fix this issue?