fix(eslint-plugin): [no-invalid-void-type] don't flag function overloading with `void` in return type annotation #10422

ronami · 2024-11-29T21:51:52Z

PR Checklist

Addresses an existing open issue: fixes Bug: [no-invalid-void-type] Can't use void in return type union for overloaded function #5752
That issue was marked as accepting prs
Steps in Contributing were taken

Overview

This PR addresses #5752 and adjusts the rule so it doesn't report on void that's used as part of the return type of a function overload implementation:

function f(): void;
function f(x: string): string;
function f(x?: string): void | string {
  if (x !== undefined) {
    return x;
  }
}

typescript-eslint · 2024-11-29T21:51:54Z

Thanks for the PR, @ronami!

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-11-29T21:52:06Z

✅ Deploy Preview for typescript-eslint ready!

Name	Link
🔨 Latest commit	`7887cc9`
🔍 Latest deploy log	https://app.netlify.com/sites/typescript-eslint/deploys/679fadc5f106910007f706b8
😎 Deploy Preview	https://deploy-preview-10422--typescript-eslint.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.
Lighthouse	1 paths audited Performance: 92 (🔴 down 6 from production) Accessibility: 100 (no change from production) Best Practices: 92 (no change from production) SEO: 98 (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 site configuration.

nx-cloud · 2024-11-29T21:53:05Z

View your CI Pipeline Execution ↗ for commit 7887cc9.

Command	Status	Duration	Result
`nx test eslint-plugin --coverage=false`	✅ Succeeded	7m 27s	View ↗
`nx test eslint-plugin`	✅ Succeeded	5m 57s	View ↗
`nx test visitor-keys`	✅ Succeeded	<1s	View ↗
`nx test visitor-keys --coverage=false`	✅ Succeeded	<1s	View ↗
`nx run types:build`	✅ Succeeded	<1s	View ↗
`nx run-many --target=build --exclude website --...`	✅ Succeeded	24s	View ↗
`nx test type-utils`	✅ Succeeded	<1s	View ↗
`nx test utils`	✅ Succeeded	<1s	View ↗
`Additional runs (24)`	✅ Succeeded	...	View ↗

☁️ Nx Cloud last updated this comment at 2025-02-02 17:54:57 UTC

codecov · 2024-11-29T22:18:32Z

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 87.30%. Comparing base (1c73754) to head (7887cc9).
Report is 65 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #10422      +/-   ##
==========================================
+ Coverage   87.26%   87.30%   +0.03%     
==========================================
  Files         450      451       +1     
  Lines       15715    15750      +35     
  Branches     4601     4615      +14     
==========================================
+ Hits        13714    13750      +36     
  Misses       1645     1645              
+ Partials      356      355       -1

Flag	Coverage Δ
unittest	`87.30% <100.00%> (+0.03%)`	⬆️

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

Files with missing lines	Coverage Δ
...es/eslint-plugin/src/rules/no-invalid-void-type.ts	`100.00% <100.00%> (+2.17%)`	⬆️
...es/eslint-plugin/src/util/hasOverloadSignatures.ts	`100.00% <100.00%> (ø)`

... and 1 file with indirect coverage changes

ronami · 2024-11-30T13:50:03Z

packages/eslint-plugin/src/rules/no-invalid-void-type.ts

+      /* istanbul ignore next */
+      return [];


Is there a preferred way to tackle this? I think this is currently an unreachable line.

#10388 - either it's reachable or it's not.

If it's not actually reachable then I'd say use type assertion(s) to tell TypeScript why it's wrong.

There might be opportunities to suggest improvements to AST types too. Example: the getMembers(node.parent.parent) later on has the provided type as TSESTree.Node. But maybe somewhere in there a type could be made more specific? Is TSESTree.ExportDefaultDeclaration's .parent always a TSESTree.BlockStatement | TSESTree.Program, rather than the catch-all TSESTree.Node?

Interesting! I didn't consider proposing changes/improvements to the AST types. I've found #9560, and I think it would be a good option if I could be sure the changes are correct.

To my understanding, TypeScript's AST doesn't even have an actual AST node for ExportDefaultDeclaration or ExportNamedDeclaration as they're expressed as modifiers.

I've looked into @babel/parser, @swc/types, and @oxc-project/types (also the more technical 1, 2), but I didn't find anything that makes me confident this is valid in every case. I did verify @typescript-eslint itself is type-checked successfully with these assumptions.

The stricter parent types for the AST I'd like to propose:

ExportDefaultDeclaration and ExportNamedDeclaration should have the stricter parent type of TSESTree.BlockStatement | TSESTree.Program | TSESTree. TSModuleBlock (I'm not sure if TSESTree.BlockStatement is an option).

FunctionDeclaration should have the stricter parent type of TSESTree.BlockStatement | TSESTree.ExportDefaultDeclaration | TSESTree.ExportNamedDeclaration | TSESTree.Program.

TypeScript itself doesn't have a specific parent for FunctionDeclaration (it falls back to the generic ts.Node), although they do have stricter parent types for some other nodes.

How did we verify the correctness of the proposals in #6225? Also, would this type of change be considered a breaking change? I noticed that #9560 was released in v8, but it wasn't marked as a breaking change.

I'm a bit hesitant to change the AST's types, as it can potentially lead to bugs, and I would love to hear opinions on this.

I updated the PR with these changes, so it's easier to discuss them.

The stricter parent types for the AST I'd like to propose:

I'd say those proposals should be a separate issue. I'm generally in favor of stricter parent types in general but we should discuss.

So I think how to handle that in this PR is up to you. Maybe either:

Link to the issue with an as

Draft this PR and mark it blocked till that's resolved

How did we verify the correctness of the proposals in #6225?

Other than yarn build and yarn typecheck, pretty much just manual knowledge and testing.

breaking change?

I don't think improving the types of the AST to better reflect reality is breaking. In that sense it's a "feature".

Changing the runtime value would IMO be a breaking change.

That sounds good; I'm not sure why I mixed both on the same PR; thanks! 👍

I've opened #10682, drafted this PR, and marked it as blocked.

If the issue is accepted, I'll create a new PR with the stricter parent node changes and eventually re-open this PR for review with only the relevant changes.

ronami · 2024-11-30T13:50:52Z

packages/eslint-plugin/src/rules/no-invalid-void-type.ts

+        const id = nullThrows(
+          node.id,
+          'This may be null if and only if the parent is an `ExportDefaultDeclaration`.',
+        );
+
+        return id.name;


This currently only gets called for nodes whose parents aren't ExportDefaultDeclaration, and so this can never be null. If this code gets refactored, it may change, and this can throw.

I can change this to a chain-expression, though this will show up as a partially covered line by codecov.

Suggested change

const id = nullThrows(

node.id,

'This may be null if and only if the parent is an `ExportDefaultDeclaration`.',

);

return id.name;

return node.id?.name;

Similar to the other comment, my fallback would be to use a ! with a disable comment explaining why the types are wrong. If possible, fixing up the types to be correct would be even better.

You might find the existing uses of the MakeRequired utils type interesting. Some places in code use for node types in similar situations. E.g. no-confusing-void-expression has handling for return statements that must have an argument. Maybe there's a similar flow here for functions that must have an id?

I'm not worried about refactors. Our test coverage is so high that the cost of unnecessary safety precautions in code is IMO higher than the cost of the brittleness.

I'm confident the only possibility of node.id being null (for FunctionDeclaration or TSDeclareFunction) is in cases where the parent node is an ExportDefaultDeclaration (also according to JavaScript's spec):

typescript-eslint/packages/ast-spec/src/base/FunctionBase.ts

Lines 51 to 58 in d24a828

/**

* The function's name.

* - For an `ArrowFunctionExpression` this is always `null`.

* - For a `FunctionExpression` this may be `null` if the name is omitted.

* - For a `FunctionDeclaration` or `TSDeclareFunction` this may be `null` if

* and only if the parent is an `ExportDefaultDeclaration`.

*/

id: Identifier | null;

I think that updating the types to be stricter here would be more challenging. I've resorted to using a ! with a disable comment and explaining why this is necessary.

JoshuaKGoldberg

LGTM overall! Just requesting touchups around the types / istanbul ignores. 🚀

JoshuaKGoldberg · 2024-12-14T14:56:35Z

packages/eslint-plugin/src/rules/no-invalid-void-type.ts

+      /* istanbul ignore next */
+      return [];


#10388 - either it's reachable or it's not.

If it's not actually reachable then I'd say use type assertion(s) to tell TypeScript why it's wrong.

There might be opportunities to suggest improvements to AST types too. Example: the getMembers(node.parent.parent) later on has the provided type as TSESTree.Node. But maybe somewhere in there a type could be made more specific? Is TSESTree.ExportDefaultDeclaration's .parent always a TSESTree.BlockStatement | TSESTree.Program, rather than the catch-all TSESTree.Node?

JoshuaKGoldberg · 2024-12-14T15:02:18Z

packages/eslint-plugin/src/rules/no-invalid-void-type.ts

+        const id = nullThrows(
+          node.id,
+          'This may be null if and only if the parent is an `ExportDefaultDeclaration`.',
+        );
+
+        return id.name;


Similar to the other comment, my fallback would be to use a ! with a disable comment explaining why the types are wrong. If possible, fixing up the types to be correct would be even better.

You might find the existing uses of the MakeRequired utils type interesting. Some places in code use for node types in similar situations. E.g. no-confusing-void-expression has handling for return statements that must have an argument. Maybe there's a similar flow here for functions that must have an id?

I'm not worried about refactors. Our test coverage is so high that the cost of unnecessary safety precautions in code is IMO higher than the cost of the brittleness.

ronami · 2024-12-19T18:10:36Z

packages/eslint-plugin/tests/rules/no-invalid-void-type.test.ts

+    {
+      code: 'type invalidVoidUnion = void | Map;',
+      errors: [
+        {
+          column: 25,
+          line: 1,
+          messageId: 'invalidVoidUnionConstituent',
+        },
+      ],
+    },


This test is unrelated to the PR, but it adds coverage to part of the code that is currently uncovered (it seemed small enough to be part of the PR, even if it's unrelated).

Please let me know if I should revert this part.

ronami · 2024-12-20T13:42:51Z

packages/eslint-plugin/src/rules/no-invalid-void-type.ts

+      return getStaticMemberAccessValue(node, context);
+    }
+
+    function hasOverloadMethods(


I think this may be useful as a shared utility function for different rules. Re-using this function (pretty much as is) simplifies tackling #4586 (which I'll be happy to push a PR for), for example.

Adding that this attempts to emulate checker.isImplementationOfOverload() for rules which aren't type-aware.

The no-invalid-void-type issue is being fixed: typescript-eslint/typescript-eslint#10422

JoshuaKGoldberg

Commented inline. Exciting! 🚀

I think just #10422 (comment) is left.

…overloading

…ith a body" This reverts commit 8dd4707.

…ith a body" This reverts commit 350e82f.

ronami · 2025-02-02T17:52:14Z

Opening for re-review, please note:

I've renamed and extracted hasOverloadSignatures to a separate utility because I think it may be useful in other places (e.g. [explicit-module-boundary-types] New option to allow unspecified return type if there are overload signatures #4586).
Unlike FunctionDeclaration, which has a different type of node for its definition (TSDeclareFunction), MethodDefinition doesn't. MethodDefinition seems to either have its value be a FunctionExpression for implementations or TSEmptyBodyFunctionExpression in case of overloading (ignoring type/interface's TSMethodSignature, which seems like it cannot be part of a class's body).

hasOverloadSignatures currently requests a node of type TSESTree.FunctionDeclaration | TSESTree.MethodDefinition, which means that it's possible to pass an overload method definition, for which the function will wrongly return true:
```
class T {
  // compiles, even though this is a type error
  foo(): string;
}
```
This doesn't affect the no-invalid-void-type rule, as it only passes function/method implementations, but it may be an issue for future rules that use this. This can have a stricter type, but it does add a bit of complexity (see 350e82f).

I'm not sure if this is worth the extra complexity, would love to hear another opinion on this 🙃

JoshuaKGoldberg

Yeah I think this is great as-is. The utility has no known issues as used right now so we can cross that bridge when we get to it IMO. Awesome stuff! 🙌

ronami added 5 commits November 29, 2024 23:33

initial implementation

470cb5b

add block test

99d697b

refactor

b300731

refactor

abe451e

use a recursive function to handle wrapped return types

66d15f4

report on method definitions that aren't overloads

55cd442

ronami added 5 commits November 30, 2024 10:33

handle export default declaration

4448e4b

handle named export declaration

8b04386

refactor

d5aa7d9

fix test

2b5137d

use nullThrows instead of non-null assertions

ebbc79c

ronami marked this pull request as ready for review November 30, 2024 13:43

ronami commented Nov 30, 2024

View reviewed changes

JoshuaKGoldberg requested changes Dec 14, 2024

View reviewed changes

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

ronami added 2 commits December 19, 2024 17:52

add stricter parent types for various ast nodes and refactor accordingly

8819270

fix existing missing code coverage

b3f79c3

ronami commented Dec 19, 2024

View reviewed changes

ronami requested a review from JoshuaKGoldberg December 19, 2024 18:12

github-actions bot removed the awaiting response Issues waiting for a reply from the OP or another party label Dec 19, 2024

ronami commented Dec 20, 2024

View reviewed changes

tommie added a commit to tommie/stm-ts that referenced this pull request Dec 23, 2024

Adds eslint.

2e9a727

The no-invalid-void-type issue is being fixed: typescript-eslint/typescript-eslint#10422

JoshuaKGoldberg requested changes Jan 7, 2025

View reviewed changes

JoshuaKGoldberg added the awaiting response Issues waiting for a reply from the OP or another party label Jan 7, 2025

ronami mentioned this pull request Jan 19, 2025

Enhancement: add strict parent types for nodes that have well-defined parents #10682

Closed

4 tasks

ronami added blocked by another issue Issues which are not ready because another issue needs to be resolved first and removed awaiting response Issues waiting for a reply from the OP or another party labels Jan 19, 2025

ronami marked this pull request as draft January 19, 2025 18:17

ronami added 4 commits January 28, 2025 23:05

Merge remote-tracking branch 'origin/main' into no-invalid-void-type-…

5e6d8ca

…overloading

refactor

ab702cd

move and rename hasOverloadSignatures

ca90a4f

test void in non-implementation position

a7ba129

ronami removed the blocked by another issue Issues which are not ready because another issue needs to be resolved first label Jan 29, 2025

ronami added 7 commits February 1, 2025 13:30

adjust hasOverloadSignatures to require a method definition with a body

8dd4707

expand comment a bit

f240e23

Revert "adjust hasOverloadSignatures to require a method definition w…

6d64631

…ith a body" This reverts commit 8dd4707.

remove unnecessary comment

7e1f342

adjust hasOverloadSignatures to require a method definition with a body

350e82f

Revert "adjust hasOverloadSignatures to require a method definition w…

dafd33c

…ith a body" This reverts commit 350e82f.

refactor

7887cc9

ronami marked this pull request as ready for review February 2, 2025 17:52

ronami requested a review from JoshuaKGoldberg February 2, 2025 17:52

JoshuaKGoldberg approved these changes Feb 24, 2025

View reviewed changes

JoshuaKGoldberg merged commit b688380 into typescript-eslint:main Feb 24, 2025
63 checks passed

ronami deleted the no-invalid-void-type-overloading branch February 24, 2025 17:48

github-actions bot locked as resolved and limited conversation to collaborators Mar 4, 2025

	/**
	* The function's name.
	* - For an `ArrowFunctionExpression` this is always `null`.
	* - For a `FunctionExpression` this may be `null` if the name is omitted.
	* - For a `FunctionDeclaration` or `TSDeclareFunction` this may be `null` if
	* and only if the parent is an `ExportDefaultDeclaration`.
	*/
	id: Identifier \| null;

Uh oh!

fix(eslint-plugin): [no-invalid-void-type] don't flag function overloading with void in return type annotation #10422

fix(eslint-plugin): [no-invalid-void-type] don't flag function overloading with void in return type annotation #10422

Uh oh!

Conversation

ronami commented Nov 29, 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 Nov 29, 2024

Uh oh!

netlify bot commented Nov 29, 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 Nov 29, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

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

Uh oh!

Codecov Report

Uh oh!

ronami Nov 30, 2024

Choose a reason for hiding this comment

Uh oh!

JoshuaKGoldberg Dec 14, 2024

Choose a reason for hiding this comment

Uh oh!

ronami Dec 19, 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!

JoshuaKGoldberg Jan 7, 2025

Choose a reason for hiding this comment

Uh oh!

ronami Jan 19, 2025 • 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!

ronami Nov 30, 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!

JoshuaKGoldberg Dec 14, 2024

Choose a reason for hiding this comment

Uh oh!

ronami Dec 19, 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!

JoshuaKGoldberg left a comment

Choose a reason for hiding this comment

Uh oh!

JoshuaKGoldberg Dec 14, 2024

Choose a reason for hiding this comment

Uh oh!

JoshuaKGoldberg Dec 14, 2024

Choose a reason for hiding this comment

Uh oh!

ronami Dec 19, 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!

ronami Dec 20, 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!

ronami Dec 20, 2024

Choose a reason for hiding this comment

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!

ronami commented Feb 2, 2025

Uh oh!

JoshuaKGoldberg left a comment

Choose a reason for hiding this comment

Uh oh!

fix(eslint-plugin): [no-invalid-void-type] don't flag function overloading with `void` in return type annotation #10422

fix(eslint-plugin): [no-invalid-void-type] don't flag function overloading with `void` in return type annotation #10422

ronami commented Nov 29, 2024 •

edited

Loading

netlify bot commented Nov 29, 2024 •

edited

Loading

nx-cloud bot commented Nov 29, 2024 •

edited

Loading

codecov bot commented Nov 29, 2024 •

edited

Loading

ronami Dec 19, 2024 •

edited

Loading

ronami Jan 19, 2025 •

edited

Loading

ronami Nov 30, 2024 •

edited

Loading

ronami Dec 19, 2024 •

edited

Loading

ronami Dec 19, 2024 •

edited

Loading

ronami Dec 20, 2024 •

edited

Loading

JoshuaKGoldberg left a comment •

edited

Loading