Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Support block-comment version of eslint-disable-line

See original GitHub issue

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.

Issue Analytics

  • State:closed
  • Created 6 years ago
  • Reactions:14
  • Comments:47 (45 by maintainers)

github_iconTop GitHub Comments

not-an-aardvarkcommented, Sep 12, 2017
  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

// 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.

kaicataldocommented, Jun 22, 2017

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

Read more comments on GitHub >

github_iconTop Results From Across the Web

Is there any syntax to add additional info to an eslint-disable ...
Is there any syntax we can add a description or explanation for why we're disabling the rule, on the same line, without triggering...
Read more >
multiline-comment-style - ESLint - Pluggable JavaScript Linter
"separate-lines" : Disallows block comments in favor of consecutive line comments. The rule always ignores directive comments such as /* eslint-disable */ ....
Read more >
eslint-plugin-no-comments - npm
Prevents leaving comment blocks in the file. This plugin will ignore all comments starting from string global or eslint in order to keep...
Read more >
User Guide | eslint-plugin-vue
Official ESLint plugin for Vue.js. ... Status of Vue.js 3.x supports ... comment // @vue/component that marks an object in the next line...
Read more >
Sole purpose of this rule is to provide eslint-disable functionality in the template HTML. It supports usage of the following comments: ... We...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Post

No results found

github_iconTop Related Hashnode Post

No results found