Thanks for the PR,@JoshuaKGoldberg!

typescript-eslint is a 100% community driven project, and we are incredibly grateful that you are contributing to that community.

The core maintainers work on this in their personal time, so please understand that it may not be possible for them to review your work immediately.

Thanks again!

🙏Please, if you or your company is finding typescript-eslint valuable, help us sustain the project by sponsoring it transparently onhttps://opencollective.com/typescript-eslint.

✅ Deploy Preview fortypescript-eslint ready!

Name	Link
🔨 Latest commit	dac381c
🔍 Latest deploy log	https://app.netlify.com/sites/typescript-eslint/deploys/668996765b425e00089b41b5
😎 Deploy Preview	https://deploy-preview-9263--typescript-eslint.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.
Lighthouse	1 paths audited Performance: 96 (🟢 up 2 from production) Accessibility: 100 (no change from production) Best Practices: 92 (no change from production) SEO: 90 (no change from production) PWA: 80 (no change from production) View the detailed breakdown and full score reports

To edit notification comments on pull requests, go to yourNetlify site configuration.

☁️ Nx Cloud Report

CI is running/has finished running commands for commitdac381c. As they complete they will appear below. Click to see the status, the terminal output, and the build insights.

📂 See all runs for this CI Pipeline Execution

Sent with 💌 fromNxCloud.

I don't get the motivation for this, TBH. How can something "happen to be thenable" without noticing? Doesthen have any other meaning other than interoperating with promises? JavaScript itself resolves thenables, so if your thenable is not supposed to quack like a promise you will shoot yourself in the foot everywhere, like returning it from an async function, etc.

How can something "happen to be thenable" without noticing?

https://github.com/DefinitelyTyped/DefinitelyTyped/blob/e40cab53d9971a3e0b34e8fb18ece74240d9425d/types/bluebird/index.d.ts#L59: older projects that have polyfills which generally intentionally match something like Promises/A+.

Why would one expect a polyfill tonot be checked like a real promise?

One example I've believe I've been told is that if a framework implements its own classes that happen to have a similar API to Promises, it's inconvenient to have the rule fire on them by default.

cc@mcollina as I think this was from you and Fastify, but I might be mistaken / mistinterpreting.

The issue mentionsnode:test, but doesn'ttest() return a real promise?

@Josh-Cena the Node issue does, but our#8433 -> this PR isn't around that I don't think.

That issue doesn't mention a valid use case where you want a thenable to not be checked like a promise though. It just mentions polyfills but those arewhy we check thenables.

Great points. Putting into draft per#8433 (comment). Thanks!

#8433 was confirmed as good to go, so un-drafting. 👍

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 88.24%. Comparing base(dfae228) to head(6078b07).
Report is 111 commits behind head on main.

❗Current head6078b07 differs from pull request most recent headdac381c

Pleaseupload reports for the commitdac381c to get more accurate results.

@@            Coverage Diff             @@##             main    #9263      +/-   ##==========================================+ Coverage   87.42%   88.24%   +0.81%==========================================  Files         261      416     +155       Lines       12724    14380    +1656       Branches     3975     4195     +220     ==========================================+ Hits        11124    12689    +1565- Misses       1319     1372      +53- Partials      281      319      +38

Confirmed with@Josh-Cena that we're good to merge with those docs suggestions. 🚀!