mysticatea/eslint-plugin-eslint-comments

Additional ESLint rules for directive comments of ESLint.

eslint-plugin-eslint-comments

Additional ESLint rules for ESLint directive comments (e.g. //eslint-disable-line).

📖 Usage

• Documentation

🚥 Semantic Versioning Policy

eslint-plugin-eslint-comments follows semantic versioning and ESLint's Semantic Versioning Policy.

📰 Changelog

• GitHub Releases

🍻 Contributing

Welcome contributing!

Please use GitHub's Issues/PRs.

Development Tools

• npm test runs tests and measures coverage.
• npm run build updates README.md, index.js, and the header of all rule's documents.
• npm run clean removes the coverage of the last npm test command.
• npm run coverage shows the coverage of the last npm test command.
• npm run lint runs ESLint for this codebase.
• npm run watch runs tests and measures coverage when source code are changed.

eslint-plugin-eslint-comments's Issues

eslint-comments/require-description comment above?

Hi! Is it possible to have a comment above the rule work? I've not done a lot of eslint work, but happy to fix this if you think its possible.

"total-functions/no-unsafe-type-assertion' rule is disabled but never reported" false error in terminal

the rule actually works correctly, and in vscode it is not highlighted, but in termital eslint shows an error "total-functions/no-unsafe-type-assertion' rule is disabled but never reported"

linked issue: danielnixon/eslint-plugin-total-functions#38 (comment)

Quickfix of `eslint-comments/no-unused-disable` should not leave empty lines

The fix of eslint-comments/no-unused-disable should remove line enterily.

Rule proposal: disallow usage of eslint-disable-line in favor of eslint-disable-next-line

I'm duplicating this issue from eslint/eslint#11247 because it was suggested that this rule could be a better fit here

Please describe what the rule should do:

The rule should enforce using eslint-disable-next-line instead of using eslint-disable-line. This requirement comes about because of issues when integrating eslint with prettier, as discussed here:

prettier/prettier#1267
prettier/prettier#2273
prettier/prettier#3011

Running prettier together with eslint can cause issues when prettier moves eslint-disable-line comments to the previous line, thus breaking its' intended behaviour. This can easily be solved by making sure that only the eslint-disable-next-line style is used, but there is no way for us to enforce this behaviour.

What category of rule is this? (place an "X" next to just one item)

[ ] Warns about a potential error (problem)
[ ] Suggests an alternate way of doing something (suggestion)
[X] Enforces code style (layout)
[ ] Other (please specify:)

Provide 2-3 code examples that this rule will warn about:

Bad code

alert('foo'); // eslint-disable-line

alert('foo'); /* eslint-disable-line */

alert('foo'); // eslint-disable-line no-alert

alert('foo'); /* eslint-disable-line no-alert */

Good code

// eslint-disable-next-line
alert('foo');

/* eslint-disable-next-line */
alert('foo');

// eslint-disable-next-line no-alert
alert('foo');

/* eslint-disable-next-line no-alert */
alert('foo');

`no-restricted-disable`: un-disabling rules with slashes

Hi,
I was following the examples for https://mysticatea.github.io/eslint-plugin-eslint-comments/rules/no-restricted-disable.html and noticed that the underlying ignore package handles un-ignores after '*' strangely.

When you lock down disabling of all rules with '*', you can't allow scope/rule-type rules later, unless you explicitly allow '*/'.

I finally found my answer in the fixtures of https://github.com/kaelzhang/node-ignore 😆

Here's a snippet to recreate:

#!/usr/bin/env node

const ignore = require('ignore');

const rules = ignore();

// set up
rules.add([
    // ignore all:
    '*',
    '!*/', // (undocumented hack found in https://github.com/kaelzhang/node-ignore/blob/master/test/fixtures/cases.js#L276)
    // un-ignore these:
    '!no-console',
    '!react/boolean-prop-naming',
]);

// test
[
    'no-console', // false ✅
    'react/boolean-prop-naming', // false ✅
    'boolean-prop-naming', // true ✅
    'something-else', // true ✅
    'something/else', // true ✅
    'another/thing-with-hyphens', // true ✅
].forEach(rule => {
    // eslint-disable-next-line no-console
    console.log(rule, rules.ignores(rule));
});

Support ESLint 6

Linter#verify(text, config, options) method accepts a ConfigArray object as the second argument config since ESLint 6. The monkeypatch of eslint-comments/no-unused-disable rule doesn't recognize that currently.

[require-description] Add rule to require minimum description length

In typescript-eslint, you can require a minimum description length to avoid someone doing -- a. typescript-eslint/typescript-eslint#2099

It would be nice to have similar functionality here.

Allow requiring collapsed blocks for directive comments

I would like to enforce directive comments to use block comment syntax on a single line, such as the following:

/* eslint-disable no-undef */

The following styles should be disallowed:

// eslint-disable no-undef
/*
  eslint-disable no-undef
*/

Comments that are not directive comments should not be affected.

Make the `no-unused-disable` rule auto-fixable

It's a chore having to remove all the moot eslint-disable comments manually.

can't disable multiple rules with disable-enable-pair.allowWholeFile

source

/*eslint-disable no-unused-var, no-undef */
var foo = bar()

output

1:33  error  Requires 'eslint-enable' directive for 'no-undef'  eslint-comments/disable-enable-pair

repro
https://github.com/teppeis-sandbox/eslint-comments-repro

Support ESlint 4.0

Looks like 4.0 has some breaking changes as it no longer supports LineComment and BlockComment events. Any plans on supporting 4.0?

[no-restricted-disable] should `rule: off` be reported as error?

When enabling the no-restricted-disable rule, I guess both the following statements should be reported as errors:

/* eslint-disable max-lines */ 
/* eslint max-lines: off */

But only the first one is reported. Shouldn't the second statement be an error as well?

Thanks!

`no-unused-disable` rule breaks with ESLint 5.0.0-alpha.1

The rule throws:

Error while loading rule 'eslint-comments/no-unused-disable': Cannot read property 'report' of undefined
TypeError: Error while loading rule 'eslint-comments/no-unused-disable': Cannot read property 'report' of undefined
    at Object.create (.../node_modules/eslint-plugin-eslint-comments/lib/rules/no-unused-disable.js:33:39)
    at createRuleListeners (.../node_modules/eslint/lib/linter.js:676:21)
    at Object.keys.forEach.ruleId (.../node_modules/eslint/lib/linter.js:830:31)
    at Array.forEach (<anonymous>)
    at runRules (.../node_modules/eslint/lib/linter.js:788:34)
    at Linter._verifyWithoutProcessors (.../node_modules/eslint/lib/linter.js:981:31)
    at preprocess.map.textBlock (.../node_modules/eslint/lib/linter.js:1032:35)
    at Array.map (<anonymous>)
    at Linter.verify (.../node_modules/eslint/lib/linter.js:1031:42)
    at localVerify (.../node_modules/eslint-plugin-html/src/index.js:92:14)

The faulty source code is:

create(context) {
    const linter = context.eslint || context._linter
    const originalReport = linter.report

ESLint 5.0.0-alpha.1 removed context._linter being it considered it being a hack.

`disable-enable-pair` option allowWholeFile should be the default

I propose that the allowWholeFile should be set to true by default if it is not specified by the end-user.

Setting up this plugin for the first time was frustrating, because I got a lot of false positives. I then assumed that this plugin was bugged, and eventually found out that this option existed.

I think that it is pretty standard in the JavaScript/TypeScript ecosystem to disable a while file like this, so I don't see any compelling reasons for the current behavior of allowWholeFile being set to false by default.

Thank You 🙌🏻

I was directed to your plugin through this question: https://stackoverflow.com/questions/50923949/throwing-an-eslint-error-if-disabling-a-rule-that-is-not-triggered/51072005#51072005

Thank you for making this great plugin. Hard to believe it only has 57 stars, should be used by default in every projects :)

You rock 🎸

Allow providing an explanation message for no-restricted-disable

It can be unclear to people why a rule should not be disabled. The only way to know is to look for a comment in the ESLint config where the rule is configured.

Unfortunately this can lead them to disabling that rule and no-restricted-disable itself:

// eslint-disable-next-line eslint-comments/no-restricted-disable
// eslint-disable-next-line some-rule

I propose that a message can be optionally provided, like https://eslint.org/docs/rules/no-restricted-imports allows:

"no-restricted-disable": ["error", {
    "name": "some-rule",
    "message": "Do not disable this, it has consequences XYZ. Do ABC instead."
}]

Merge this with eslint-plugin-canonical

Hey @mysticatea,

Would you be oppose if the rules in this plugin were merged into https://github.com/gajus/eslint-plugin-canonical this plugin?

I am trying to consolidate efforts around some of the more niche plugin maintenance to make it easier to handle upgrades such as the requirements moving from ESLint v7 to v8 support.

I would do all the work.

Rule proposal: require-description

Please describe what the rule should do:

This rule reports directive comments without description.

What category of rule is this? (place an "X" next to just one item)

[ ] Warns about a potential error (problem)
[ ] Suggests an alternate way of doing something (suggestion)
[ ] Enforces code style (layout)
[X] Other (please specify:)

Provide 2-3 code examples that this rule will warn about:

/* eslint-disable */
/* eslint-disable rule-name */
/* global _ */
/* eslint-env node */

No warning is given if the directive comment contains an description.

/* eslint-disable -- description */
/* eslint-disable rule-name -- description */
/* global _ -- description */
/* eslint-env node -- description */

May need an option to set whether or not to warn depending on the type of directives.

Allow `disable` without `enable` when disable covers the whole file

Use case is that one may want to allow disabling a rule for the whole file but still catch accidentally not closed eslint-disable in the middle of a file.

With something like "eslint-comments/disable-enable-pair":·["error", {"allowWholeFile": true}]

This should be allowed:

// @flow
/* eslint-disable no-unused-expressions */

import { Error } from '.';

const e = new Error();

e.name;
e.message;
e.stack;

e.id;

console.log(new Error('ooops'));

// $ExpectError
console.log(new Error(3));

// $ExpectError
e.topkek;

But this should be an error:

// @flow

import { Error } from '.';

const e = new Error();

/* eslint-disable no-unused-expressions */
e.name;
e.message;
e.stack;

e.id;

console.log(new Error('ooops'));

// $ExpectError
console.log(new Error(3));

// $ExpectError
e.topkek;

Similar rule to eslint-comments/no-use but only preventing non-restricted version

Howdy 👋

We have just come across the need to prevent developers from willy-nilly turning off all eslint-rules, but want to allow them to specify the rules they want to turn off. Our specific use case would be to disable using eslint-disable-next-line without the rule qualifiers but I would imagine that it might be a more generic implementation that might apply across all the comment types.

Is this something that would make sense to add to your repo? If so I wouldn't mind contributing with a bit of guidance.

`no-unused-disable` autofixing does not properly work

This problem appeared in 3.1.0, i.e. was introduced by #13.

Input:

'use strict'

var values = [1, 2]

/* eslint-disable max-nested-callbacks */
values.map(function(value) {
  return values.map(function(otherValue) {
    return value + otherValue
  })
})
/* eslint-enable max-nested-callbacks */

Then eslint --fix file.js. Output:

'use strict'

var values = [1, 2]


values.map(function(value) {
  return values.map(function(otherValue) {
    return value + otherValue
  })
})
/* eslint-enable max-nested-callbacks */

Note that the following works:

'use strict'

var values = [1, 2]

// eslint-disable max-nested-callbacks
values.map(function(value) {
  return values.map(function(otherValue) {
    return value + otherValue
  })
})

.eslintrc.yml:

plugins: [eslint-comments]

rules:
  eslint-comments/no-unused-disable: 2

Versions:

$ eslint --version
v5.13.0
$ npm ls eslint-plugin-eslint-comments
[email protected] /home/me/my-package
└── [email protected]
$ node --version
v11.9.0 

Support ESLint 8.x

ESLint v8.0.0 is released 🎉

It would be awesome to have official ESLint 8 support. 👊
I'm happy to help where I can of course 🙂

[eslint-comments/no-use]: Allow "eslint-disable" only for selected rules (feature request)

Thx for the plugin.

Is it possible to add "allowEslintDisable" setting that will accept an array of rule names?

Motivation:
Consider "vue/no-bare-strings-in-template" rule that requires that all strings inside template are taken from language file.
Imagine that you have a static untranslated page (e.g. privacy, etc).
In this case, you want to disable "vue/no-bare-strings-in-template" rule for the entire file.
However you may not want to allow global disabling for all other rules.
In this case "allowEslintDisable" option may be helpful.

Similar settings may be added for other allowed syntaxes (e.g. eslint-disable-next-line)

Cannot disable eslint-comments/no-unused-disable with comment

Thanks for the awesome plugin! We're running into a bit of a tricky issue in our repo. We have some files with certain lint rules that are expected to sometimes fail and sometimes not. Specifically, we have files in the root of our repo that re-export transpiled files from dist:

module.exports = require('./dist/transpiled-file');

Depending on if the build process has been run or not, ./dist/transpiled-file may or may not exist, and we don't want the non-existence of it at that particular moment to be an error in the import/no-unresolved rule. Before adopting this plugin, we had the following to ensure import/no-unresolved wouldn't error:

// eslint-disable-next-line import/no-unresolved
module.exports = require('./dist/transpiled-file');

However, with this plugin, that eslint-disable-next-line directive is itself reported as failing if the build process was run already (and thus ./dist/transpiled-file exists). I tried to disabled the eslint-comments/no-unused-disable rule itself as follows:

/* eslint-disable eslint-comments/no-unused-disable */
// eslint-disable-next-line import/no-unresolved
module.exports = require('./dist/transpiled-file');

However, disabling that rule doesn't disable it for either the line itself, or for the following line that it should actually apply to:

file.js
  1:19  error  'eslint-comments/no-unused-disable' rule is disabled but never reported  eslint-comments/no-unused-disable
  2:29  error  'import/no-unresolved' rule is disabled but never reported               eslint-comments/no-unused-disable

The first error is incorrect, because the rule is reported on the next line, and the second error is also incorrect, because the first line should be disabling that rule for the file.

I understand this is a bit of a weird case, but for this specific file I want to be able to opt out of both rules entirely in this file because I know what I'm doing, and I don't even have the ability to do that at the moment.

no-restricted-disable breaks on allowing non-core rules

I'm not allowing any rules to be disabled by default ('*'), then adding specific rules that have to be disabled because they have no workaround. This works for core rules with '!corerule', but it breaks for all plugin rules '!plugin/rule', presumably because under the hood this uses the ignore package, which is built on recognizing directories. I tried escaping the / with both / and //, using * instead of /, using . instead of /, nothing works. If ignore is the issue, then probably this needs to be redone using regex patterns instead of glob patterns to support plugin rules. As of right now I have to turn this rule off because it's always erroring for those plugin rules.

should not auto fix when configured to warn

Was surprised to find that setting this to warn still results in auto fix, unfortunately that makes this library unusable when a disable directive is being used for an autogenerated file that may not always be present.

Check the behavior of eslint/eslint#9216

eslint/eslint#9216

New rule idea: Warn when a disable is unnecessary

For example:

var x = 2;
/* eslint-disable no-undef */ // Error: `no-undef` rule is not triggered in this section.
x = 3
/* eslint-enable no-undef */

This verifies that you actually need all of your eslint-disable* comments.

[no-unused-disable] incorrect reporting on single line with multi disable rules

export const getAvailableIPs = (subnet: Subnet) => {
  const protocol = subnet?.spec?.protocol;
  const { availableIPs, v4availableIPs, v6availableIPs } = subnet?.status || {};
  switch (protocol) {
    case 'IPv4':
    // eslint-disable-next-line default-case-last, no-fallthrough
    default: {
      return v4availableIPs ?? availableIPs;
    }
    case 'IPv6':
      return v6availableIPs ?? availableIPs;
    case 'Dual': {
      if (v4availableIPs == null) {
        return v4availableIPs ?? availableIPs;
      }

      if (v6availableIPs == null) {
        return v4availableIPs ?? availableIPs;
      }

      return Math.min(v4availableIPs, v4availableIPs);
    }
  }
};

✘  eslint-comments/no-unused-disable

     'no-fallthrough' rule is disabled but never reported

Of course, it helps me to move 'IPv4' and 'default' to the last case. 🤣

But it indeed a bug of this rule.

---

Additionally, this rule seems unsafe to use, because we can not disable this rule itself inline.

related #50

False positives for directive comment with description added in ESLint v7.x.

ESLint v7.x supports /* eslint-disable -- description */ comments, but some rules in this plugin do not support this comments.

e.g.

/*eslint eslint-comments/disable-enable-pair: error */

/*eslint-disable no-undef, no-unused-vars -- description */
var foo = bar()

Rule proposal: disallow disabling some rules

I'd like to propose a rule that would disallow disabling some specific rules. This would allow to specify some rules that always should be resolved correctly instead of just being disabled. For example it would be useful for no-fallthrough rule, since it can be resolved just by adding a comment.

allow no-restricted-disable to display customize message

It would be helpful if we can customize the error message of no-restricted-disable

Right now the error message is:
Disabling '{{ruleId}}' is not allowed.
Instead we can have something such as
Disabling '{{ruleId}}' is not allowed. (https://typescript-eslint.io/rules/no-explicit-any)

`require-description` shouldn't require a description for `eslint-enable`

when using eslint-enable, there's already an eslint-disable comment with the description on it so there's no reason to provide another description when re-enabling it.

describe('any', () => {
    /* eslint-disable @typescript-eslint/no-explicit-any -- testing the any type */
    test('pass', () => {
        exactly<any>()(any)
    })
    test('fail', () => {
        // @ts-expect-error doesn't match
        exactly<any>()(number)
        // @ts-expect-error doesn't match
        exactly<number>()(any)
    })
    /* eslint-enable @typescript-eslint/no-explicit-any -- testing the any type */
})

rule should not lint itself

disabling eslint-comments/no-unused-disable for the next line fails because it reports itself as its own failure. Autofix would result in removing the disable directive and the next line's disable directive as well.

no-restricted-disable - whitelist/blacklist based on error level

From the docs for no-restricted-disable, it doesn't look like it's possible to do something like this:

{
  "eslint-comments/no-restricted-disable": ["warn", { "level": "error" }]
}

This would allow disabling warnings, but not errors (in the above setup, no-restricted-disable itself is a warning, so errors could still be disabled in exceptional circumstances, but we'd be forced to be very explicit, with something like

// eslint-disable-next-line eslint-comments/no-restricted-disable
// eslint-disable-next-line no-undef
console.log(someUndefinedVariable)

This would make the difference between warnings and errors meaningful in setups that use --max-warnings 0.

Error with `eslint-comments/no-unused-disable` alongside `no-console` rule

Over in stylelint #4196 we have an issue where we are using:

"eslint-plugin-eslint-comments": "^3.1.2",

Via https://travis-ci.com/stylelint/stylelint/jobs/223902356#L231

/Users/netweb/Code/stylelint/stylelint/lib/getPostcssResult.js
  116:39  error  'no-console' rule is disabled but never reported  eslint-comments/no-unused-disable

/Users/netweb/Code/stylelint/stylelint/lib/rules/declaration-block-no-shorthand-property-overrides/index.js
  42:29  error  Do not access Object.prototype method 'hasOwnProperty' from target object  no-prototype-builtins

/Users/netweb/Code/stylelint/stylelint/lib/testUtils/createRuleTester.js
  212:71  error  'no-console' rule is disabled but never reported  eslint-comments/no-unused-disable
  293:71  error  'no-console' rule is disabled but never reported  eslint-comments/no-unused-disable

/Users/netweb/Code/stylelint/stylelint/lib/utils/__tests__/nodeContextLookup.test.js
  71:67  error  'no-console' rule is disabled but never reported  eslint-comments/no-unused-disable

/Users/netweb/Code/stylelint/stylelint/scripts/benchmark-rule.js
  3:19  error  'no-console' rule is disabled but never reported  eslint-comments/no-unused-disable

/Users/netweb/Code/stylelint/stylelint/system-tests/004/004.test.js
  20:70  error  'no-console' rule is disabled but never reported  eslint-comments/no-unused-disable

For example, the last error from above for system-tests/004/004.test.js#L20

function handleError(err /*: { stack: any, code: any }*/) /*: void */ {
  console.log(err.stack); // eslint-disable-line no-console
  const exitCode = typeof err.code === "number" ? err.code : 1;

  process.exit(exitCode); // eslint-disable-line no-process-exit
}

So, console.log is only triggered on error, the no-console ESLint rule here works as expected, but eslint-plugin-eslint-comments

Enable/Disable pair not working

Tell us about your environment

Wrongly assigned this to eslint first (eslint/eslint#12125)

• ESLint Version: 6.1.0
• Node Version: v11.13.0
• npm Version: 6.7.0

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

• babel-eslint: 10.0.2

Please show your full configuration:

Configuration

{
  parser: '@typescript-eslint/parser',
  env: {
    "browser": true,
    "node": true
  },
  plugins: ['@typescript-eslint', 'jest', 'hapi', 'import', 'cypress',],
  extends: [
    'airbnb',
    'plugin:eslint-comments/recommended',
    'plugin:@typescript-eslint/recommended',
  ],
  parserOptions: {
    ecmaFeatures: {
      jsx: true,
    },
    ecmaVersion: 2018,
    useJSXTextNode: true,
    project: './tsconfig.json',
    tsconfigRootDir: './',
    extraFileExtensions: ['.tsx'],
  },
  overrides: [
    {
      files: [
        'src/**/*.story.js',
        'packages/**/*.story.js',
        '**/*.stories.ts',
        '**/*.stories.tsx',
        '**/setupTests.ts',
      ],
      rules: {
        'import/no-extraneous-dependencies': [
          'error',
          {
            devDependencies: true,
          },
        ],
        'react/jsx-no-literals': 0,
      },
    },
    {
      files: [
        '**/*.spec.tsx',
        '**/*.spec.ts',
      ],
      plugins: [
        'jest',
      ],
      env: {
        jest: true,
      },
      rules: {
        'jest/no-disabled-tests': 'warn',
        'jest/no-focused-tests': 'error',
        'jest/no-identical-title': 'error',
        'jest/prefer-to-have-length': 'warn',
        'jest/valid-expect': 'error',
        'react/react-in-jsx-scope': 0,
        'import/no-extraneous-dependencies': [
          'error',
          {
            devDependencies: true,
          },
        ],
      },
    },
    {
      files: ['*.ts', '*.tsx'],
      rules: {
        '@typescript-eslint/camelcase': [2, { ignoreDestructuring: true }],
        'lines-between-class-members': [0],
        '@typescript-eslint/no-unused-vars': [2, { args: 'none' }],
        'react/jsx-curly-spacing': [2, "always"],
        'padded-blocks': [0],
        'import/no-extraneous-dependencies': [
          1,
        ],
      },
    },
    {
      files: [
        '**/*.definitions.ts'
      ],
      rules: {
        'import/prefer-default-export': 0
      }
    },
    {
      files: [
        '**/setup-tests.ts',
        '**/*.spec.ts',
        '**/*.spec.tsx',
        '**/*.stories.tsx',
      ],
      rules: {
        '@typescript-eslint/no-explicit-any': [0],
        'react/jsx-no-literals': [0],
        '@typescript-eslint/explicit-function-return-type': [
          2,
          {
            allowExpressions: true,
          },
        ],
        'import/no-extraneous-dependencies': [
          2,
          {
            devDependencies: true,
          },
        ],
      },
    },
    {
      files: ['**/*.tsx'],
      rules: {
        'react/jsx-filename-extension': [
          1,
          {
            extensions: ['.tsx'],
          },
        ],
      },
    },
    {
      files: ['config/**', 'scripts/**', '.takeoff/**'],
      rules: {
        'import/no-extraneous-dependencies': 0,
        'react/no-array-index-key': 0,
        '@typescript-eslint/no-var-requires': 0,
        'no-console': 0,
      },
    },
  ],
  rules: {
    '@typescript-eslint/indent': 0,
    'max-len': [
      0,
      {
        code: 120,
        ignoreComments: true,
        ignoreTralingCommas: true,
        ignoreUrls: true,
        ignoreStrings: true,
        ignoreTemplateLiterals: true,
      }
    ]
  },
  settings: {
    'import/extensions': ['.ts', '.tsx'],
    'import/parsers': {
      '@typescript-eslint/parser': ['.ts', '.tsx'],
    },
    'import/resolver': {
      typescript: {},
      node: {
        extensions: ['.ts', '.tsx'],
      },
    },
    'import/ignore': ['utils'],
  },
}

What did you do? Please include the actual source code causing the issue, as well as the command that you used to run ESLint.

function Checkbox({
  isChecked = false,
  onChange,
}: CheckboxProps): FunctionComponentElement<CheckboxProps> {
  const [internalCheckedState, setInternalCheckedState] = useState(isChecked);

  const classNames = cn(styles.root, {
    [styles.isChecked]: internalCheckedState,
  });

  function toggle(): void {
    const state = !internalCheckedState;
    setInternalCheckedState(state);
    if (onChange) onChange(state);
  }

  /* eslint-disable jsx-a11y/no-static-element-interactions */
  /* eslint-disable jsx-a11y/click-events-have-key-events */
  return (
    <div className={ classNames } onClick={ toggle } />
  );
  /* eslint-enable jsx-a11y/no-static-element-interactions */
  /* eslint-enable jsx-a11y/click-events-have-key-events */
}

eslint './src/**/*.{ts,tsx}'

What did you expect to happen?
The enable/disable pair should work properly

What actually happened? Please include the actual, raw output from ESLint.
It does not : /

./src/components/form/checkbox/checkbox.tsx
  Line 1:  Requires 'eslint-enable' directive for 'jsx-a11y/no-static-element-interactions'  eslint-comments/disable-enable-pair
  Line 2:  Requires 'eslint-enable' directive for 'jsx-a11y/click-events-have-key-events'    eslint-comments/disable-enable-pair

I played around a bit and found out that this only happens when the element inside of the JSX/HTML part is self closing, so i guess it's kind of a parsing error?
It also seems to be irrelevant what rule you want to enable/disable.

Tried @platinumazure 's suggestion and also your recommended way of disabling multiple rules but this did not work either.

Are you willing to submit a pull request to fix this bug?

I would need to dig into the source code which i do not not have the time to do right now due to project pressure. If this issue is still present in never versions and does affect many people i would try to investigate and open a pr in my spare time

TypeError: Error while loading rule 'eslint-comments/no-unused-disable': Cannot read property 'report' of undefined

Connect to userdive/agent.js#122

https://travis-ci.org/userdive/agent.js/jobs/264210941#L462

Started a new flow server: \Error while loading rule 'eslint-comments/no-unused-disable': Cannot read property 'report' of undefined

TypeError: Error while loading rule 'eslint-comments/no-unused-disable': Cannot read property 'report' of undefined
    at Object.create (/home/travis/build/[secure]/agent.js/node_modules/eslint-plugin-eslint-comments/lib/rules/no-unused-disable.js:31:46)
    at Object.keys.filter.forEach.key (/home/travis/build/[secure]/agent.js/node_modules/eslint/lib/linter.js:874:67)
    at Array.forEach (<anonymous>)
    at Linter.verify (/home/travis/build/[secure]/agent.js/node_modules/eslint/lib/linter.js:847:93)
    at processText (/home/travis/build/[secure]/agent.js/node_modules/eslint/lib/cli-engine.js:203:31)
    at processFile (/home/travis/build/[secure]/agent.js/node_modules/eslint/lib/cli-engine.js:245:18)
    at executeOnFile (/home/travis/build/[secure]/agent.js/node_modules/eslint/lib/cli-engine.js:585:25)
    at fileList.forEach.fileInfo (/home/travis/build/[secure]/agent.js/node_modules/eslint/lib/cli-engine.js:622:13)
    at Array.forEach (<anonymous>)
    at CLIEngine.executeOnFiles (/home/travis/build/[secure]/agent.js/node_modules/eslint/lib/cli-engine.js:621:18)

Please help.

New rule no-uneccessary-globals

We do have a lot of /* globals window / or / globals require */ in ourcode despite those being recognized as globals from eslints env and globals config. I suggest having a rule that reports on already existing globals in comments.

Linting broken in Webstorm

Hello,

After updating to [email protected] I have a problem in Webstorm 2018.1.5

Error: Cannot find module '/Applications/WebStorm.app/Contents/plugins/JavaScriptLanguage/languageService/eslint/'
Referenced from: /Users/akopersky/WebstormProjects/WebCC/tools/eslint-config-base/index.js
Referenced from: /Users/akopersky/WebstormProjects/WebCC/tools/eslint-config-web/index.js
Referenced from: /Users/akopersky/WebstormProjects/WebCC/tools/eslint-config-react/index.js
Referenced from: /Users/akopersky/WebstormProjects/WebCC/applications/alta-go-cc/src/main/.eslintrc.js
    at Function.Module._resolveFilename (internal/modules/cjs/loader.js:571:15)
    at Function.Module._load (internal/modules/cjs/loader.js:497:25)
    at Module.require (internal/modules/cjs/loader.js:626:17)
    at require (internal/modules/cjs/helpers.js:20:18)
    at Array.from.map.eslintPath (/Users/akopersky/WebstormProjects/WebCC/node_modules/eslint-plugin-eslint-comments/lib/internal/get-linters.js:18:54)

I dont know if this problem on Webstorm side. But temporary I fix it wit this code in https://github.com/mysticatea/eslint-plugin-eslint-comments/blob/master/lib/internal/get-linters.js#L13

.filter(id => !id.includes('WebStorm.app'))

`no-unused-disable` does not work within Markdown files

README.md:

<!-- eslint-disable no-inline-comments -->

```js
var aa = true
```

.eslintrc.yml:

plugins:
  - eslint-comments
  - markdown
rules:
  no-inline-comments: 2
  eslint-comments/no-unused-disable: 2

In the terminal:

$ eslint README.md

The command does not report any errors. However no-unused-disable should be reported.

Versions:

• eslint: 5.16.0 (also fails with 6.0.0-alpha.0)
• eslint-plugin-eslint-comments: 3.1.1
• eslint-plugin-markdown: 1.0.0

I am not sure whether the issue comes from eslint-plugin-eslint-comments or eslint-plugin-markdown, so I decided to report this bug here.

Simple usage in README

Hi! I think more useful if there would be a simple usage of this plugin in README.

The reasons:

• Users can see node_modules/eslint-plugin-eslint-comments/README.md on their local machines
  even if they are off-line.
• Uses can see a simple usage on this repository's top page without one extra click

This is the usage section in the current README:

https://github.com/mysticatea/eslint-plugin-eslint-comments/blob/c427c1c0577fab56f2ff0919053d249938507c83/README.md#-usage

For example:

---

📖 Usage

Configure your .eslintrc.* file. For example:

{
  "extends": "plugin:eslint-comments/recommended"
}

---

What about this suggestion? I would be happy if you would reply. 😃

False negatives for disable-line block comments.

ESLint>=v4.18.0 supports /* eslint-disable-line */ comments, but some rules in this plugin do not support this comments.

e.g.

/*eslint eslint-comments/no-unlimited-disable: error */

/* eslint-disable-line */

/*eslint eslint-comments/no-use: error */

/* eslint-disable-line */
/* eslint-disable-next-line */

Support ESLint 7.x

ESLint v7.0.0 is released 🎉

It would be awesome to have official ESLint 7 support. 👊
I'm happy to help where I can of course 🙂

new rule: require an explanation comment for all disable directives

It's way too easy to disable eslint rules. I don't want to disable them completely though, because sometimes you need to work around a rule.

I'd love to raise the bar so that there must be an explanation comment with the disable.

This makes it easier to review PRs, and means that people can remember why a rule was disabled "way back when" instead of potentially being fixed.

Rule proposal: forced disabling reason

copy from the main repository (eslint/eslint#13338)

Please describe what the rule should do:

oblige the developer to explain the reason for disconnecting the linter

What category of rule is this? (place an "X" next to just one item)

[ ] Warns about a potential error (problem)
[ ] Suggests an alternate way of doing something (suggestion)
[ ] Enforces code style (layout)
[x] Other (please specify:) — reduce the number of thoughtless shutdowns of the linter; Improve code reading speed by other developers.

Provide 2-3 code examples that this rule will warn about:

// fail
// eslint-disable-next-line no-new
new Swiper(slider);

// ok
// eslint-disable-next-line no-new -- saving the instance is not necessary, since subsequent control of the slider is not needed
new Swiper(slider);

Why should this rule be included in ESLint (instead of a plugin)?

I'm not sure, but it seems to me that this will reduce the number of incorrect, incomprehensible and lazy shutdowns of the linter

Are you willing to submit a pull request to implement this rule?

I doubt my competence, this rule does not look banal.

`no-unused-disable` missing in recommended

while the documentation lists no-unused-disable in the recommended section, it is not activated by just using extends: ['plugin:eslint-comments/recommended']

Not sure which behaviour is favourable, but config and documentation should match.

Make require-description message clear about the format

That the rule expects a specific format makes it uncomfortable to use when you see it the first time, as opposed to e.g. TS @ts-ignore directive that allows to provide a description in free form.

The message is already verbose enough:

Unexpected undescribed directive comment. Include descriptions to explain why the comment is necessary.

Could be more friendly:

Unexpected undescribed directive comment. Include a description separated with -- to explain why the comment is necessary.

[require-description] duplicated description UX for use with disable-enable-pair

consider the following example:

/*eslint eslint-comments/disable-enable-pair: error */
/*eslint eslint-comments/require-description: error */

/*eslint-disable no-undef, no-unused-vars -- My reason for doing this is XYZ */
var foo = bar()
/*eslint-enable no-undef, no-unused-vars -- see above */

I love the new require-description rule, but I find that in practice, when it's used for disable-enable-pair enables... it can be a little clunky. Any ideas on how to improve the user experience in this case? Maybe we can give require-description an option to not require descriptions on eslint-enable lines? Personally, turning a rule back on isn't something I really need a description for so this would work for me. Any other ideas?

I'm happy to make a PR - just lemme know.

Disabling linting errors for comments isn't working

This issue was opened (I think incorrectly) in eslint/eslint#12548 but it seems the problem comes from this plugin. I would be willing to try replicate a test for this and fix in a PR over the weekend.