Codecov Report

Merging #192 into master will increase coverage by 0.01%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master     #192      +/-   ##
==========================================
+ Coverage   96.95%   96.96%   +0.01%     
==========================================
  Files          71       72       +1     
  Lines        2694     2705      +11     
  Branches      435      436       +1     
==========================================
+ Hits         2612     2623      +11     
  Misses         49       49              
  Partials       33       33

Btw, this ended up using the same containsType(ByName) util as #194, so I moved it to utils/types.js.

Apologies for the conflicts, we decided to remove the counts from the ROADMAP here: #225

They are too awkward to maintain manually, so this is the last time you will have to deal with syncing that up!

Awesome, glad the type checker works out that way! That looks like it'll need to be a shared method by this, #194, and other promise-checking functions.

Would you still want the allowedPromiseNames option as part of the rule? I can't think of a way for it to be particularly useful unless folks have improperly written Promise-like typings, so I'll add test cases for definitions mirroring Bluebird's and other popular polyfills.

Would you still want the allowedPromiseNames option as part of the rule?

I don't think so.

And, I think we should rename the rule to require-await-thenable.

• In practice, Rules which disallow arbitary notation if something is lacking have require- prefix.
• Now the rule checks then property rather than Promise.

Turns out tsutils already has a isThenableType method, so I used that one and removed allowedPromiseNames. ✔

require-await-thenable

👍 on promise -> thenable, but I'm still hesitant to sustain the require- prefix tradition for similar reasons to the no- prefix tradition:

• it's rather inconvenient to work with larger eslintrc files when the names' alphabetical ordering isn't very useful
• it's hard to tell when rules will eventually allow the opposite of the require- behavior; for example, if this rule eventually also handles whether we should or shouldn't await values of type any and/or unknown
• require- has a naming relevancy to require() and modules, which is confusing for newcomers to look at

I don't want to bikeshed in your repository (especially if the focus is to adhere to existing ESLint traditions) 😄 so if you'd like I can rename to require-await-thenable in this PR! Just a couple of cents.

Hey guys, is it still blocked? It looks like the TS migration is done.

@mysticatea @j-f1 please can you update your reviews of this PR?

Probably worth just getting it in at this point!

Perfectly understandable @mysticatea! Thanks for looping back to it.

Looks like @JoshuaKGoldberg addressed your most recent feedback, would you agree?