Hacker News Reader

Comment by tuukkah | Hacker News Reader

I have been waiting for this release for the new possibility to include a comment in eslint-disable-{next-}line:

  // eslint-disable-next-line no-console -- Here's a description about why this configuration is necessary.
  console.log('hello');

https://eslint.org/docs/user-guide/configuring#disabling-rul...

View on HN

How is that different than:

  // Here's a description about why this configuration is necessary.
  // eslint-disable-next-line no-console
  console.log('hello');

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

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.

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.

Yo dawg, heard you like comments

Reply on news.ycombinator.com