New Feature/Rule: Consistent formatting of multiline eslint-disable descriptions

[Samuel-Therrien-Beslogic]

See the following multiline comment. There are no rule that I know of which can enforce consistent formatting for it. Neither https://eslint.org/docs/latest/rules/multiline-comment-style , nor https://github.com/dprint/dprint-plugin-typescript (I've open the same issue there: https://github.com/dprint/dprint-plugin-typescript/issues/591 )

/*eslint-disable-next-line some-linter/some-very-long-rule-name -- This
  disable requires an explanation that can easily be made so consise that
    it would fit under a limit of 80 chars. Triggering eslint(max-len) in the
process*/

This leads to eslint-disable-next-line multiline comment that can vary wildly in style and format. Some things to consider:

• Spacing around start/end markers
• indentation of newlines
• Whether comment should start on the second line
• Newline after start marker / before end marker?

Atm, with manual formatting, I try to aim for a concise but consistent

/* eslint-disable-next-line some-linter/some-very-long-rule-name --
This disable requires an explanation that can easily be made so consise
that it would fit under a limit of 80 chars. Triggering eslint(max-len) in
the process */

(I don't expect an autofixer to word-wrap, line-length rule and manual fixes already take care of that)

An HTML example I just landed on:

<!-- eslint-disable @angular-eslint/template/no-call-expression --
FIXME: I could not fix all of them immediatly. Further refactoring is required.
Data table row actions (clickable, external route, angular route, empty link) -->

[github-actions[bot]]

This issue has been automatically closed because we haven't received a response from the original author 🙈. This automation helps keep the issue tracker clean from issues that aren't actionable. Please reach out if you have more information for us! 🙂