feat(eslint-plugin): add rule [strict-void-return] by phaux · Pull Request #9707 · typescript-eslint/typescript-eslint

phaux · 2024-08-02T16:47:45Z

PR Checklist

Addresses an existing open issue:
- fixes Rule proposal: warn against passing a non-void returning callback in a position accepting a void returning callback #2988
- fixes Rule proposal check void-covariant return types of implemented interfaces and extended classes #1744
That issue was marked as accepting prs
Steps in Contributing were taken

Overview

So basically I implemented the void checking as requested by #2988. For every checked node (arguments, assignments, returns, etc) I take the actual function type and the contextual function type and compare return types. Only object method shorthand required slightly different logic.

That already worked pretty well, but I also found #1744 and decided to include it in this rule as well, since I already had a similar thing implemented for object shorthand methods. ~~I added this as an option considerBaseClass and considerImplementedInterfaces, enabled by default.~~

Then I noticed that callback for addEventListener is not detected as void context. That's because it has another signature where the callback can return any. I was stuck on this for a long time. Ultimately I looked at how no-misused-promises does this and implemented something similar ~~as considerOtherSignatures option, enabled by default.~~

At this point this rule already did everything no-misused-promises's checkVoidReturn did, but better. It doesn't have problems like #8054 or #8739. Maybe it's worth splitting no-misused-promises into 3 separate rules in the future? (this one being one of them)

EDIT: autofixes removed for now

I also added many autofixes and suggestions. They are possible when the provided function is a function literal and we can inspect its body. Some of them are the same as in no-confusing-void-expression so I moved them into utils. It might make sense to change some autofixes into suggestions instead so they don't accidentally remove a big chunk of code. Let me know if that's a good idea.

The biggest feature is automatic suggestions which I and probably others had to type manually a thousand of times:

takesCallback(async () => {
  block;
});

into

takesCallback(() => {
  (async () => {
    block;
  })().catch(err => {});
});

or

// eslint-disable-next-line @typescript-eslint/no-misused-promises
takesCallback(async () => {
  try {
    block;
  } catch {}
});

To allow the second suggestion without the need of ignoring the line I added the option allowReturnPromiseIfTryCatch. It's just a simple extra if near the end of the long routine that checks everything that could be wrong in the function body. I hope it can stay.

typescript-eslint · 2024-08-02T16:47:48Z

Thanks for the PR, @phaux!

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 on https://opencollective.com/typescript-eslint.

netlify · 2024-08-02T16:48:03Z

✅ Deploy Preview for typescript-eslint ready!

Name	Link
🔨 Latest commit	`cf78bd7`
🔍 Latest deploy log	https://app.netlify.com/projects/typescript-eslint/deploys/6964f5685e1e810008a55e7a
😎 Deploy Preview	https://deploy-preview-9707--typescript-eslint.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.
Lighthouse	1 paths audited Performance: 99 (🟢 up 9 from production) Accessibility: 97 (no change from production) Best Practices: 100 (no change from production) SEO: 92 (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 your Netlify project configuration.

nx-cloud · 2024-08-02T16:48:42Z

View your CI Pipeline Execution ↗ for commit cf78bd7

Command	Status	Duration	Result
`nx run-many -t lint`	✅ Succeeded	3m 19s	View ↗
`nx run-many -t typecheck`	✅ Succeeded	2m 5s	View ↗
`nx test eslint-plugin-internal --coverage=false`	✅ Succeeded	2s	View ↗
`nx run generate-configs`	✅ Succeeded	8s	View ↗
`nx test typescript-estree --coverage=false`	✅ Succeeded	2s	View ↗
`nx run types:build`	✅ Succeeded	1s	View ↗
`nx run integration-tests:test`	✅ Succeeded	3s	View ↗
`nx run-many --target=build --parallel --exclude...`	✅ Succeeded	17s	View ↗
`Additional runs (28)`	✅ Succeeded	...	View ↗

☁️ Nx Cloud last updated this comment at 2026-01-12 13:35:12 UTC

codecov · 2024-08-05T14:22:42Z

Codecov Report

❌ Patch coverage is 98.22335% with 7 lines in your changes missing coverage. Please review.
✅ Project coverage is 90.79%. Comparing base (f7ddd95) to head (cf78bd7).
⚠️ Report is 50 commits behind head on main.

Files with missing lines	Patch %	Lines
...slint-plugin/src/util/getBaseTypesOfClassMember.ts	78.78%	7 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #9707      +/-   ##
==========================================
+ Coverage   90.65%   90.79%   +0.14%     
==========================================
  Files         524      530       +6     
  Lines       53387    54345     +958     
  Branches     8916     9178     +262     
==========================================
+ Hits        48396    49343     +947     
- Misses       4978     4989      +11     
  Partials       13       13

Flag	Coverage Δ
unittest	`90.79% <98.22%> (+0.14%)`	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
packages/eslint-plugin/src/configs/eslintrc/all.ts	`100.00% <100.00%> (ø)`
...lugin/src/configs/eslintrc/disable-type-checked.ts	`100.00% <100.00%> (ø)`
packages/eslint-plugin/src/configs/flat/all.ts	`100.00% <100.00%> (ø)`
...nt-plugin/src/configs/flat/disable-type-checked.ts	`100.00% <100.00%> (ø)`
...ages/eslint-plugin/src/rules/strict-void-return.ts	`100.00% <100.00%> (ø)`
packages/eslint-plugin/src/util/walkStatements.ts	`100.00% <100.00%> (ø)`
...slint-plugin/src/util/getBaseTypesOfClassMember.ts	`78.78% <78.78%> (ø)`

... and 27 files with indirect coverage changes

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

JoshuaKGoldberg · 2024-08-10T02:49:33Z

👋 Exciting PR, really looking forward to the rule! Just marking as a draft because there are unit test failures. This keeps getting me excited when it pops up in my notifications 😄. Let us know if you want to talk or ask questions about any of them.

Edit: ACK on the questions in the OP, I don't have the bandwidth to answer just now, but hopefully someone else does. Please ping us if those are blocking progress!

phaux · 2024-08-10T15:48:22Z

Fixed and I'm not planning any more changes so I'm undrafting it I guess.

JoshuaKGoldberg

OK! Very happy to have finally made it to this PR: it's a great piece of work. As you said, it covers a heck of a lot of functionality, and does so in ways that are really solid compared to previous approaches. Fantastic! 👏

It's also a lot of code that was hard to read through. For an initial version of the rule, I think nuance around suggestions aren't necessary. And the fixers would need to be suggestions given they change code behavior.

I left requests for simplification through the code: for messages, options, and the suggestions.

But, my advice would be to hold off applying that large set of removals until the conversation in https://github.com/typescript-eslint/typescript-eslint/pull/9707/files#r1741336663 is resolved. The consensus might end up being that the options are good and useful after all.

JoshuaKGoldberg · 2024-09-03T01:43:38Z

At this point this rule already did everything no-misused-promises's checkVoidReturn did, but better. It doesn't have problems #8054 or #8739. Maybe it's worth splitting no-misused-promises into 3 separate rules in the future? (this one being one of them)

This is a great question. no-misused-promises was already largely overlapped by no-unnecessary-condition. This new strict-void-return pretty much takes on the rest of no-misused-promises, making no-misused-promises redundant if you have both no-unnecessary-condition and strict-void-return...

I'd be in favor of deprecated no-misused-promises in favor of using no-unnecessary-condition + strict-void-return. The only benefit I can think of for no-misused-promises would be projects that want to only apply the checks for Promises... Maybe these two rules could each be given some kind of "only check Promises" option?

Also of note is that no-misused-promises's checkVoidReturns is pretty configurable. Maybe, if this rule is to replace no-misused-promises, it'd be useful to have each of those configurable options? Or, on the other hand, maybe those options are holdovers that real-world don't generally use? Investigation needed. I think those options can be a followup & shouldn't block this PR.

What do you think?

Also cc: @typescript-eslint/triage-team in general, and @kirkwaiblinger + @alythobani from #8765.

no-misused-promises was already largely overlapped by no-unnecessary-condition. This new strict-void-return pretty much takes on the rest of no-misused-promises, making no-misused-promises redundant if you have both no-unnecessary-condition and strict-void-return...

Yeah the only thing left I think would be the checksSpreads option:

const myPromise = Promise.resolve({num: 2, str: "2"}); const myObject = {...myPromise}; // Expected a non-Promise value to be spreaded in an object. eslint(@typescript-eslint/no-misused-promises)

I do agree it could make sense to replace checksVoidReturn with strict-void-return. Although there may be tradeoffs in terms of eng effort and/or UX complexity if we wanted to retain all the configurability on top of having an onlyChecksPromises option.

As for checksConditionals, I actually just found microsoft/TypeScript#34717 and microsoft/TypeScript#39175—looks like checkConditionals has been covered by TypeScript for a couple years now :)

The only benefit I can think of for no-misused-promises would be projects that want to only apply the checks for Promises

Yeah e.g. one example I've seen when looking into this topic (void function assignability), is using push with forEach:

declare function forEach<T>(arr: T[], callback: (el: T) => void): void; let target: number[] = []; forEach([1, 2, 3], el => target.push(el)); // OK

It's possible some users would prefer to only check Promises so they can still use shorthands like the above without linter errors (and/or just mainly care about forgetting to await Promises), in which case an onlyChecksPromises option would be useful if we did replace checksVoidReturn with strict-void-return.

Maybe, if this rule is to replace no-misused-promises, it'd be useful to have each of those configurable options? Or, on the other hand, maybe those options are holdovers that real-world don't generally use?

It looks like #4619 was originally the impetus for adding the options (#4623); and based on the thread it looks like there are at least a few people who find the configurability you added very helpful!

Maybe a lame response, but is there a compelling reason not to land this first, then consider the no-misused-promises deprecation, and which options we might need to port or create in order to do so, afterwards?

Just thinking, deprecating no-misused-promises might have some strings attached, such as some nontrivial updating of the docs in no-floating-promises that explain how to lint against promise antipatterns outside of ExpressionStatements.

Agreed with landing this first, then considering a deprecation as a followup.

In fact, this rule is pretty big and scary. We don't really have a process for declaring rules as "canary" or "experimental". #8676 is the closest we have to a feature request. Maybe we should set a precedent?

(I don't think this PR should be blocked on that)

alythobani

Very cool PR, great job sticking it out and a lot of thought put into things!

Left some thoughts/questions, hope they're helpful 🌅

alythobani · 2024-09-06T05:33:47Z

no-misused-promises was already largely overlapped by no-unnecessary-condition. This new strict-void-return pretty much takes on the rest of no-misused-promises, making no-misused-promises redundant if you have both no-unnecessary-condition and strict-void-return...

Yeah the only thing left I think would be the checksSpreads option:

const myPromise = Promise.resolve({num: 2, str: "2"}); const myObject = {...myPromise}; // Expected a non-Promise value to be spreaded in an object. eslint(@typescript-eslint/no-misused-promises)

I do agree it could make sense to replace checksVoidReturn with strict-void-return. Although there may be tradeoffs in terms of eng effort and/or UX complexity if we wanted to retain all the configurability on top of having an onlyChecksPromises option.

As for checksConditionals, I actually just found microsoft/TypeScript#34717 and microsoft/TypeScript#39175—looks like checkConditionals has been covered by TypeScript for a couple years now :)

The only benefit I can think of for no-misused-promises would be projects that want to only apply the checks for Promises

Yeah e.g. one example I've seen when looking into this topic (void function assignability), is using push with forEach:

declare function forEach<T>(arr: T[], callback: (el: T) => void): void; let target: number[] = []; forEach([1, 2, 3], el => target.push(el)); // OK

It's possible some users would prefer to only check Promises so they can still use shorthands like the above without linter errors (and/or just mainly care about forgetting to await Promises), in which case an onlyChecksPromises option would be useful if we did replace checksVoidReturn with strict-void-return.

Maybe, if this rule is to replace no-misused-promises, it'd be useful to have each of those configurable options? Or, on the other hand, maybe those options are holdovers that real-world don't generally use?

It looks like #4619 was originally the impetus for adding the options (#4623); and based on the thread it looks like there are at least a few people who find the configurability you added very helpful!

kirkwaiblinger · 2024-09-12T01:17:25Z

Maybe a lame response, but is there a compelling reason not to land this first, then consider the no-misused-promises deprecation, and which options we might need to port or create in order to do so, afterwards?

Just thinking, deprecating no-misused-promises might have some strings attached, such as some nontrivial updating of the docs in no-floating-promises that explain how to lint against promise antipatterns outside of ExpressionStatements.

JoshuaKGoldberg · 2025-09-08T14:02:32Z

Hi, sorry for the delay! I'll try to get to this Soon ™️

JoshuaKGoldberg

Ok! I must apologize for another long gap in reviewing. This rule intimidated me and I procrastinated on it far too long. Again, sorry.

I think it's roughly ready for merge. It's big and intricate enough that I'm positive we'll get a bunch of issues filed once people start using it. But I think a gradual rollout to let folks try it will make sense:

Merge roughly as-is, not in any preset configs
We can put a call out on social media for folks to try the rule
Eventually we can add it to strictTypeChecked - which'll get a lot of additional testing (recent prior art: no-useless-default-assignment)

I left some comments on things I think should block merge, but I feel comfortable applying them myself to save you the time (especially the unit tests splitting-up request). I'll just wait for another review from @typescript-eslint/triage-team.

Thanks again! ❤️

JoshuaKGoldberg · 2025-12-27T17:51:03Z

+      },
+      ObjectExpression: (node): void => {
+        for (const propNode of node.properties) {
+          if (propNode.type !== AST_NODE_TYPES.SpreadElement) {


@phaux this is still the case - removing the if and leaving the checkObjectPropertyNode(propNode) still doesn't fail unit tests.

JoshuaKGoldberg · 2025-12-27T17:51:37Z

+      },
+      PropertyDefinition: checkClassPropertyNode,
+      ReturnStatement: (node): void => {
+        if (node.argument != null) {


[Testing] Removing this if and just calling checkExpressionNode(node.argument); doesn't fail any unit tests. Unnecessary code, or missing tests?

JoshuaKGoldberg · 2025-12-27T17:52:14Z

+        }
+      },
+      VariableDeclarator: (node): void => {
+        if (node.init != null) {


[Testing] Removing this if and just calling checkExpressionNode(node.init) doesn't fail any unit tests. Unnecessary code, or missing tests?

It was harder than I thought to get a failing test case around null variable inits. These are directly passed to checker.getContextualType(), which returns undefined in the case of an unknown/missing node. Ah well.

JoshuaKGoldberg · 2025-12-27T17:57:34Z

+        if (argNode.type === AST_NODE_TYPES.SpreadElement) {
+          continue;
+        }


[Testing] Removing this if altogether doesn't fail any unit tests. Unnecessary code, or missing tests?

Heh, I tried for 10 minutes and couldn't get this to work either. Tricky!

bradzacher · 2026-01-12T06:02:06Z

@JoshuaKGoldberg / @phaux whoever wants to get to it first -- once the comment are resolved we can get this landed.

JoshuaKGoldberg · 2026-01-12T13:18:12Z

I'll start work on them now, to get them ready in time for today's release. 🚀

JoshuaKGoldberg

I ran out of personal timebox time to work on the last few "not tests fail when this is removed" points. I don't think those are critical; we'll likely figure them out over time as edge cases get discovered.

💯 time to ship! Thanks again for your patience & persistence on this one @phaux, it's a really solid rule and I'm looking forward to evolving no-misused-promises-style checks over time with it.

@bradzacher

| datasource | package | from | to | | ---------- | -------------------------------- | ------ | ------ | | npm | @typescript-eslint/eslint-plugin | 8.52.0 | 8.53.0 | | npm | @typescript-eslint/parser | 8.52.0 | 8.53.0 | ## [v8.53.0](https://github.com/typescript-eslint/typescript-eslint/blob/HEAD/packages/eslint-plugin/CHANGELOG.md#8530-2026-01-12) ##### 🚀 Features - **eslint-plugin:** add rule \[strict-void-return] ([#9707](typescript-eslint/typescript-eslint#9707)) - **eslint-plugin:** \[no-unused-vars] add a fixer to remove unused imports ([#11922](typescript-eslint/typescript-eslint#11922)) ##### 🩹 Fixes - **eslint-plugin:** \[no-useless-default-assignment] fix false positive for parameters corresponding to a rest parameter ([#11916](typescript-eslint/typescript-eslint#11916)) - **eslint-plugin:** replace unclear "`error` typed" with more helpful description ([#11704](typescript-eslint/typescript-eslint#11704)) - **typescript-estree:** forbid invalid `extends` and `implements` in interface declaration ([#11935](typescript-eslint/typescript-eslint#11935)) - **typescript-estree:** forbid invalid class implements ([#11934](typescript-eslint/typescript-eslint#11934)) - **typescript-estree:** forbid type-only import with both default and named specifiers ([#11930](typescript-eslint/typescript-eslint#11930)) ##### ❤️ Thank You - Brad Zacher [@bradzacher](https://github.com/bradzacher) - fisker Cheung [@fisker](https://github.com/fisker) - Josh Goldberg - Josh Goldberg ✨ - Kirk Waiblinger - Niki [@phaux](https://github.com/phaux) - Nikita - SungHyun627 [@SungHyun627](https://github.com/SungHyun627) - Will Harney [@wjhsf](https://github.com/wjhsf) You can read about our [versioning strategy](https://typescript-eslint.io/users/versioning) and [releases](https://typescript-eslint.io/users/releases) on our website.

@bradzacher

| datasource | package | from | to | | ---------- | -------------------------------- | ------ | ------ | | npm | @typescript-eslint/eslint-plugin | 8.52.0 | 8.53.0 | | npm | @typescript-eslint/parser | 8.52.0 | 8.53.0 | ## [v8.53.0](https://github.com/typescript-eslint/typescript-eslint/blob/HEAD/packages/eslint-plugin/CHANGELOG.md#8530-2026-01-12) ##### 🚀 Features - **eslint-plugin:** add rule \[strict-void-return] ([#9707](typescript-eslint/typescript-eslint#9707)) - **eslint-plugin:** \[no-unused-vars] add a fixer to remove unused imports ([#11922](typescript-eslint/typescript-eslint#11922)) ##### 🩹 Fixes - **eslint-plugin:** \[no-useless-default-assignment] fix false positive for parameters corresponding to a rest parameter ([#11916](typescript-eslint/typescript-eslint#11916)) - **eslint-plugin:** replace unclear "`error` typed" with more helpful description ([#11704](typescript-eslint/typescript-eslint#11704)) - **typescript-estree:** forbid invalid `extends` and `implements` in interface declaration ([#11935](typescript-eslint/typescript-eslint#11935)) - **typescript-estree:** forbid invalid class implements ([#11934](typescript-eslint/typescript-eslint#11934)) - **typescript-estree:** forbid type-only import with both default and named specifiers ([#11930](typescript-eslint/typescript-eslint#11930)) ##### ❤️ Thank You - Brad Zacher [@bradzacher](https://github.com/bradzacher) - fisker Cheung [@fisker](https://github.com/fisker) - Josh Goldberg - Josh Goldberg ✨ - Kirk Waiblinger - Niki [@phaux](https://github.com/phaux) - Nikita - SungHyun627 [@SungHyun627](https://github.com/SungHyun627) - Will Harney [@wjhsf](https://github.com/wjhsf) You can read about our [versioning strategy](https://typescript-eslint.io/users/versioning) and [releases](https://typescript-eslint.io/users/releases) on our website.

phaux added 5 commits August 2, 2024 03:13

feat(eslint-plugin): add rule [strict-void-return]

76c295b

chore: generate configs

5454727

better handling of base class/interfaces

38e2d18

update docs

cb58ccc

restructure some code

75da13d

Merge branch 'main' into strict-void-return

db1bc42

kirkwaiblinger added the enhancement: new plugin rule New rule request for eslint-plugin label Aug 5, 2024

phaux added 2 commits August 5, 2024 15:30

Merge branch 'main' into strict-void-return

e0ef02d

update to new RuleTester

2d82282

phaux added 3 commits August 9, 2024 14:01

more detailed messages

8cea97b

Merge branch 'main' into strict-void-return

c16c874

more coverage

d8f2b03

JoshuaKGoldberg marked this pull request as draft August 10, 2024 02:49

phaux added 2 commits August 10, 2024 12:50

lint fix

b353dc9

fix addEventListener test

3de72ca

phaux marked this pull request as ready for review August 10, 2024 15:48

phaux added 2 commits August 15, 2024 13:16

Merge branch 'main' into strict-void-return

ae1fd10

fix node imports

cc7a23e

JoshuaKGoldberg requested changes Sep 3, 2024

View reviewed changes

JoshuaKGoldberg added the awaiting response Issues waiting for a reply from the OP or another party label Sep 3, 2024

alythobani reviewed Sep 9, 2024

View reviewed changes

kirkwaiblinger reviewed Sep 12, 2024

View reviewed changes

phaux added 2 commits September 14, 2024 13:00

Merge branch 'main' into strict-void-return

fe7a62e

simplify options

a335f3c

JoshuaKGoldberg added 3 commits December 27, 2025 12:05

Merge branch 'main' into strict-void-return

b7972bc

yarn test -u

cc4f08c

Use createRuleTesterWithTypes

bc5101f

JoshuaKGoldberg previously approved these changes Dec 27, 2025

View reviewed changes

JoshuaKGoldberg added the 1 approval >=1 team member has approved this PR; we're now leaving it open for more reviews before we merge label Dec 27, 2025

JoshuaKGoldberg requested a review from kirkwaiblinger December 27, 2025 18:22

github-actions bot removed the 1 approval >=1 team member has approved this PR; we're now leaving it open for more reviews before we merge label Dec 27, 2025

JoshuaKGoldberg added the 1 approval >=1 team member has approved this PR; we're now leaving it open for more reviews before we merge label Dec 29, 2025

bradzacher previously approved these changes Jan 12, 2026

View reviewed changes

Apply suggestions from code review

cf78bd7

JoshuaKGoldberg dismissed stale reviews from bradzacher and themself via cf78bd7 January 12, 2026 13:21

JoshuaKGoldberg approved these changes Jan 12, 2026

View reviewed changes

JoshuaKGoldberg merged commit 92fcf3e into typescript-eslint:main Jan 12, 2026
67 of 77 checks passed

chrisbbreuer mentioned this pull request Jan 12, 2026

chore(deps): update all non-major dependencies stacksjs/eslint-plugin#67

Closed

1 task

daogrady mentioned this pull request Feb 11, 2026

fix: Change return type of ResultsHandler to unknown cap-js/cds-types#529

Merged

phaux mentioned this pull request Feb 25, 2026

feat(eslint-plugin): [strict-void-return] add fixer for async functions #12086

Open

Uh oh!

Conversation

phaux commented Aug 2, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

PR Checklist

Overview

Uh oh!

typescript-eslint bot commented Aug 2, 2024

Uh oh!

netlify bot commented Aug 2, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

✅ Deploy Preview for typescript-eslint ready!

Uh oh!

nx-cloud bot commented Aug 2, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

codecov bot commented Aug 5, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

JoshuaKGoldberg commented Aug 10, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

phaux commented Aug 10, 2024

Uh oh!

JoshuaKGoldberg left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

alythobani Sep 6, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

alythobani left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

alythobani Sep 6, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

JoshuaKGoldberg commented Sep 8, 2025

Uh oh!

JoshuaKGoldberg left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

JoshuaKGoldberg Jan 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

phaux commented Aug 2, 2024 •

edited

Loading

netlify bot commented Aug 2, 2024 •

edited

Loading

nx-cloud bot commented Aug 2, 2024 •

edited

Loading

codecov bot commented Aug 5, 2024 •

edited

Loading

JoshuaKGoldberg commented Aug 10, 2024 •

edited

Loading

JoshuaKGoldberg left a comment •

edited

Loading

alythobani Sep 6, 2024 •

edited

Loading

alythobani left a comment •

edited

Loading

alythobani Sep 6, 2024 •

edited

Loading

JoshuaKGoldberg left a comment •

edited

Loading

JoshuaKGoldberg Jan 12, 2026 •

edited

Loading