Hacker News new | ask | show | jobs
by mikewhy 2232 days ago
How is that different than:

  // Here's a description about why this configuration is necessary.
  // eslint-disable-next-line no-console
  console.log('hello');
3 comments
tuukkah 2232 days 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

Feature request #2: https://github.com/eslint/eslint/issues/11806

RFC: https://github.com/eslint/rfcs/tree/master/designs/2019-desc...

Next up: an ESLint rule that makes the comment obligatory for disable directives.

link
jrrrr 2232 days 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.

link
httgp 2232 days ago
You could be commenting functions too (day JSDoc it TSDoc) but also want to do an eslint-ignore. It looks better then, IMO.
link