Codecov Report

Merging#192 intomaster willincrease coverage by0.01%.
The diff coverage is100%.

@@            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 samecontainsType(ByName) util as#194, so I moved it toutils/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 theallowedPromiseNames 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 theallowedPromiseNames option as part of the rule?

I don't think so.

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

• In practice, Rules which disallow arbitary notation if something is lacking haverequire- prefix.
• Now the rule checksthen property rather thanPromise.

Turns outtsutils already has aisThenableType method, so I used that one and removedallowedPromiseNames. ✔

require-await-thenable

👍 onpromise ->thenable, but I'm still hesitant to sustain therequire- prefix tradition for similar reasons to theno- prefix tradition:

• it's rather inconvenient to work with largereslintrc files when the names' alphabetical ordering isn't very useful
• it's hard to tell when rules will eventually allow the opposite of therequire- behavior; for example, if this rule eventually also handles whether we should or shouldn'tawait values of typeany and/orunknown
• require- has a naming relevancy torequire() 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 torequire-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?