4 ms·

How is that different than: // Here's a description about why this configuration is necessary. // eslint-disable-next-line no-console console.log('hello'

• httgp 6y ago
  You could be commenting functions too (day JSDoc it TSDoc) but also want to do an eslint-ignore. It looks better then, IMO.
• jrrrr 6y ago
  Well, it's on one line for starters ;) Looking at one suppression in one place it doesn't make a big difference. It will help a lot with whole-project search results, though, if you're trying to e.g. fix all the places you had to suppress X because of Y.
• tuukkah 6y ago
  In short: it's more comfortable and more versatile. 1. Sometimes there's already a comment on the preceding line commenting the logic, and the new comment explaining ESLint would have to go awkwardly in-between. 2. Sometimes it's just complicated to word the comment if it can't be on the same line. 3. Sometimes eslint-disable-line is in a place where it would be ugly to have a comment above. Here are two examples from my current project, both from cases where the disable is right after a closing curly brace: } as any // eslint-disable-line @typescript-eslint/no-explicit-any }, [map]); // eslint-disable-line react-hooks/exhaustive-deps Other cases can be found in the issues: Feature request #1: https://github.com/eslint/eslint/issues/11298 https://github.com/eslint/eslint/issues/11298 Feature request #2: https://github.com/eslint/eslint/issues/11806 https://github.com/eslint/eslint/issues/11806 RFC: https://github.com/eslint/rfcs/tree/master/designs/2019-description-in-directive-comments https://github.com/eslint/rfcs/tree/master/designs/2019-desc... Next up: an ESLint rule that makes the comment obligatory for disable directives.