Disable next line should disable the next effective line

What rule do you want to change?

eslint-disable-next-line

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

Unchanged

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

New default behavior

Please provide some example code that this change will affect:

const DEFAULT = {


  // eslint-disable-next-line id-length

  MAX_MSG_PER_TEST: 100,

  
  SAMPLE_MS: 500
};

What does the rule currently do for this code?

Disable the literal next line. With an id-length of 5 <= length <= 12, MAX_MSG_PER_TEST is invalid.

What will the rule do after it’s changed?

Disable the next line of code. With an id-length of 5 <= length <= 12, MAX_MSG_PER_TEST is valid.

[kaicataldo]

First of all, thanks for contributing! I’m 👎 to this proposal. While I understand the desire to pad comments with blank newlines for readability’s sake, this feels like it would add a lot of complexity (both in behavior and maintainability) to what is currently a very predictable and straightforward behavior. This would also be a breaking change.

If you’re worried about the comment being directly above it, have you considered using eslint-disable-line line comments at the end of the line in question?

Since the rule being disabled isn’t about the blank spaces, it’s fine for disable to skip checking if the blank spaces meet the id-length rule, until there’s actual code to check. Just like you would if you were making the check by hand.

No. Any event or rule, happening outside the rule context of the eslint-disable-next-line rule instance, should not affect that instance of eslint-disable-next-line rule.

Given the above two comments, Ii sounds like making this change would require for rules to have some kind of metadata declaring whether they involve whitespace or not, so that ESLint can know if the whitespace around eslint-disable-next-line comments can safely be ignored. This would also require that all plugins with custom rules specify this metadata.

Between it being a breaking change (and one that would potentially require all plugin authors to update their plugins), the increase in complexity of the implementation and maintainability (with less-straightforward behavior), and that there are already two other ways to solve this (that seem to stick to the style you’re discussing here, though please correct me if I’m wrong!), I’m not currently convinced this should be included in core.

A new kind of eslint-disable-* comment would alleviate some of my concerns, but I think I would need to be convinced of the value of introducing more options when we already have a number of ways to solve this in our current API.

Some related issues:

• https://github.com/eslint/eslint/issues/5206
• https://github.com/eslint/eslint/issues/6903

[andrewmiller1]

That’s understandable. I put my hacker pants on and found I could simply edit ./lib/util/apply-disable-directives.js

from

case "disable-next-line":
    return [
        { type: "disable", line: directive.line + 1, column: 1, ruleId: directive.ruleId, unprocessedDirective: directive },
        { type: "enable", line: directive.line + 2, column: 0, ruleId: directive.ruleId, unprocessedDirective: directive }
    ];

to

case "disable-next-line":
    return [
        { type: "disable", line: directive.line + 2, column: 1, ruleId: directive.ruleId, unprocessedDirective: directive },
        { type: "enable", line: directive.line + 3, column: 0, ruleId: directive.ruleId, unprocessedDirective: directive }
    ];

vscode-eslint simply followed with the new logic as well. Which honestly was a fear that deterred me from jumping into the rabbit hole of fixing it myself first thing. I’m glad it was a simple fix.

I’ll also look into language agnostic linting tools to see if I can integrate them into any custom solutions here.

Thanks!