Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

refactor: strict typing and deprecation fix in type definitions #1573

Closed
wants to merge 3 commits into from

Conversation

y-hsgw
Copy link
Contributor

@y-hsgw y-hsgw commented Apr 29, 2024

I apologize for the sudden PR, but I'd like to propose some strict typing enhancements.
Please consider the following changes:

  • Updated deprecated type definitions for TSESLint.Linter.Config.
  • Removed unnecessary type assertions and enhanced strict typing.

Note: As this is the first PR for this repository, please feel free to provide any feedback or suggestions if there are any deficiencies.

@G-Rath
Copy link
Collaborator

G-Rath commented Apr 29, 2024

I'll review this in more detail tomorrow when I'm at my laptop, but I don't see anything here that I'd call strictly better - can you describe what problem you're seeing that you're trying to solve?

@@ -113,33 +113,37 @@ const invalidTestCases: Array<TSESLint.InvalidTestCase<MessageIds, Options>> = [
],
},
// toThrow matchers call the expected value (which is expected to be a function)
...toThrowMatchers.map(matcher => ({
code: dedent`
...toThrowMatchers.map<TSESLint.InvalidTestCase<MessageIds, Options>>(
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We purposely don't define this as it's a complicated type so it's preferred to let typescript infer it

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Got it. I've addressed it in commit b030cc7.

// toThrow matchers call the expected value (which is expected to be a function)
...toThrowMatchers.map(matcher => ({
code: dedent`
...toThrowMatchers.map<TSESLint.InvalidTestCase<MessageIds, Options>>(
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ditto for this

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Got it. I've addressed it in commit b030cc7.

@@ -39,9 +39,11 @@ const shouldBeInHook = (
case AST_NODE_TYPES.ExpressionStatement:
return shouldBeInHook(node.expression, context, allowedFunctionCalls);
case AST_NODE_TYPES.CallExpression:
const nodeName = getNodeName(node);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a runtime de-optimization - previously we'd only determine the node name if the other condition hasn't matched; now we'll always be getting the node name even if we don't need it

@@ -110,7 +110,8 @@ const isPromiseMethodThatUsesValue = (
}

if (
['Promise.resolve', 'Promise.reject'].includes(nodeName as string) &&
nodeName &&
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This check is arguably more expensive at runtime - it's very minor, but I'd rather keep the cast

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Got it. I realized I missed considering performance aspects 🙇‍♂️
I've addressed it in commit b030cc7.

type: 'array',
items: { type: 'string' },
minItems: 1,
maxItems: 2,
additionalItems: false,
} as const;
} as const satisfies JSONSchema.JSONSchema4;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not strictly better than setting the type - there's no need to change this

@y-hsgw
Copy link
Contributor Author

y-hsgw commented Apr 29, 2024

I'll review this in more detail tomorrow when I'm at my laptop, but I don't see anything here that I'd call strictly better - can you describe what problem you're seeing that you're trying to solve?

Here are the two points:

  • Updated due to deprecation of TSESLint.Linter.Config.
  • Removed unnecessary type assertions. I would suggest that type assertions should be avoided as much as possible from a conservatism standpoint.

I submitted the proposed changes with the hope of contributing in any way possible. There might be some areas where I lack understanding, so I would greatly appreciate any feedback or guidance you could provide 🙇‍♂️

@G-Rath
Copy link
Collaborator

G-Rath commented Apr 29, 2024

But you're not removing any unneeded type assertions? I appreciate your enthusiasm but I'm not seeing anything here that I'd say is a strong improvement and worth the git churn.

The deprecated type is deliberate for now as we're in the middle of supporting both legacy and flat config, and different versions of @typescript-eslint (which still don't support ESLint v9 officially, so they might have further type changes for that) - I've got a branch locally for this that I'm hoping to get pushed up in the next couple of days.

Since we currently don't publish types, none of this should impact downstream consumers either

@y-hsgw
Copy link
Contributor Author

y-hsgw commented Apr 29, 2024

Thank you for your explanation. Indeed, as you mentioned, this PR was a minor adjustment. I will close this PR now. You have my apologies for any inconvenience caused 🙇‍♂️

@y-hsgw y-hsgw closed this Apr 29, 2024
@y-hsgw y-hsgw deleted the strict-typing branch April 29, 2024 08:50
@G-Rath
Copy link
Collaborator

G-Rath commented Apr 29, 2024

No worries - as I said I appreciate the enthusiasm; feel free to have a look over some of our issues and have a go at tackling one of them if you want to help out :)

@G-Rath
Copy link
Collaborator

G-Rath commented May 2, 2024

@y-hsgw just catching up on my general todo list of which re-reviewing this was one as I think there are a couple of interesting possible changes highlighted (#1577 being one).

It does look like some of our as const's are not needed - I'm not sure if that's because TypeScript has gotten better, the types have changed, or there's some footgun awaiting us, but if you want to do a refactoring PR that only removes as consts that don't result in type errors, that'd be cool.

@y-hsgw
Copy link
Contributor Author

y-hsgw commented May 2, 2024

It does look like some of our as const's are not needed - I'm not sure if that's because TypeScript has gotten better, the types have changed, or there's some footgun awaiting us, but if you want to do a refactoring PR that only removes as consts that don't result in type errors, that'd be cool.

@G-Rath Thanks! I've created a PR at #1578! Please review it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants