eslint-plugin-unicorn: Rule proposal: Expiring TODO comments

Continuing the idea about semver, should be doable to require a version of a dependency? E.g.,

// TODO [react@>=16.8]: refactor to hooks

I disagree that it has no place in a linting rule, as some to-dos are helpful to be discoverable during the linting process. Whether it has a place in this project is not my call.

I think the current scope is suitable for the first pass on this rule. My recommendation is to focus on the current PR by @lubien. That work would be necessary to support what you are proposing anyway. Once that PR is in, this issue should be closed.

If you want to continue championing these ideas, let’s split them off into a different issue so we can discuss them in more detail without conflating them with the scope in @lubien’s PR.

Support to-do scopes and priorities. […]

Todos in comments are not a particularly great way to organize things – if someone needs things like priorities than they should move the todos to an issue tracker and reference the issue number in the todo.

Allow rule options that can be used as queries. […]

All of the possible intent you discuss should be “encoded” in the expiration syntax by the person writing the todo. The warning check should stay simple enough to provide an unambiguous warning.

Taking a big step back: The point of a lint rule is to enforce code style and standards. Todos are generally bad for code health. The premise of this rule is to allow todos for a short period of time with a trigger for when they should be removed. Expanding beyond that purpose sounds too complicated and too much of an opinion farm around what configurations should or should not exist.

Draw attention in the docs to the fact that some queries […] can be useful through using the eslint command line to mine information out of one’s to-dos.

This is what issue trackers are for. I would heavily discourage trying to maintain this kind of information in the code base itself and definitely not via a lint rule.

Or, even better, a binary could be shipped to simplify this[…]

A todo tool that just managed todos on their own is a pretty good idea. It is far, far beyond the scope of a lint rule.

Conditions based on the engines field from package.json may be handy.

// TODO [engines node>=10]: Use named capture groups

Inspired by this comment https://github.com/sindresorhus/eslint-plugin-unicorn/pull/244#discussion_r267885475

Also consider TODOs that pop up when a dependency is removed or added (in case you are migrating between substitute packages like lodash/ramda, preact/react etc.)

Not sure which syntax will be best:

// TODO [-lodash]: A workaround for lodash#12345
// TODO [+react]: After switching to react, we will not need this hack

or

// TODO [npm r lodash]: A workaround for lodash#12345
// TODO [npm i react]: After switching to react, we will not need this hack

Should they be warnings before the date/version and errors after, or not reported before and reported as warnings after?

Is it ok for a random contributor to get a TODO he has no idea about reported, just because he happen to contribute at the time of it’s expiry?

Sorry, I squeezed in an item #2 before your comments… (Plan to respond shortly.)

Updated and added a question.

@zeorin got your back:

https://github.com/sindresorhus/eslint-plugin-unicorn/pull/302/files#diff-0765ede6250731541d69a380accdc19cR20

There are also some other commonly-used comments like FIXME and XXX that I’ve seen around. Should probably include those.

👍 FIXME. For additional ones, we could allow specifying a list of keywords.

The other thing one could optionally require in a TODO is an identifier for the author, like a name, username/handle, initials, or email address.

👍 The common syntax I have seen for this is // TODO(sindresorhus): Lorem ipsum..