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

feat: add support for resolves/rejects matchers in async queries #64

Merged
merged 3 commits into from
Jan 22, 2020

Conversation

thomaslombart
Copy link
Collaborator

Closes #51

@thomaslombart thomaslombart self-assigned this Jan 20, 2020
Copy link
Member

@Belco90 Belco90 left a comment

Choose a reason for hiding this comment

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

Awesome! Just one small thing: can you add some examples using resolves and rejects to await-async-query valid examples within its doc?

Btw those util methods you added for checking this look like could be extracted in the future for checking proper resolves/rejects in other rules, so let's keep an eye on that in case we can reuse it in the future 💪

@@ -101,3 +105,18 @@ function isPromiseResolved(node) {
// promise.then(...)
return hasAThenProperty(parent);
}

function hasClosestExpectResolvesRejects(node) {
if (!node.parent) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Is this necessary? Because on L34 the function is called with isAwaited(node.parent.parent), which implies that node.parent cannot be undefined.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Good catch. I initially wrote a utility function called findClosestExpectCallthat was supposed to be reusable. At that time the node.parent thing was necessary because the function was recursive. Then I refactored it and indeed, it's not necessary.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I tried to remove the node.parent check and test broke which is, in the end, logical. While isAwaited(node.parent.parent) implies node.parent cannot be undefined, it's very possible that hasClosestExpectResolvesRejects goes beyond node.parent.parent (until the Program node) in case you're not using an expect statement.

@thomaslombart
Copy link
Collaborator Author

thomaslombart commented Jan 20, 2020

Awesome! Just one small thing: can you add some examples using resolves and rejects to await-async-query valid examples within its doc?

Btw those util methods you added for checking this look like could be extracted in the future for checking proper resolves/rejects in other rules, so let's keep an eye on that in case we can reuse it in the future 💪

I'll add the examples 😉

About the util methods, we could look into converting the codebase to typescript, especially this package: typescript-eslint/experimental-utils!

@emmenko
Copy link
Contributor

emmenko commented Jan 20, 2020

About the util methods, we could look into converting the codebase to typescript, especially this package

I would also be in favor of that, as it makes working with the AST much easier and safer with the type declarations.

Copy link
Member

@Belco90 Belco90 left a comment

Choose a reason for hiding this comment

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

lgtm

@thomaslombart
Copy link
Collaborator Author

Can we merge it then @Belco90 ?

@Belco90
Copy link
Member

Belco90 commented Jan 22, 2020

Sure! On it, sorry.

@Belco90 Belco90 merged commit d0a1585 into master Jan 22, 2020
@Belco90 Belco90 deleted the feat/support-resolves-rejects-matchers branch January 22, 2020 14:52
@Belco90
Copy link
Member

Belco90 commented Jan 22, 2020

🎉 This PR is included in version 1.5.0 🎉

The release is available on:

Your semantic-release bot 📦🚀

@Belco90
Copy link
Member

Belco90 commented Jan 23, 2020

About the util methods, we could look into converting the codebase to typescript, especially this package

I would also be in favor of that, as it makes working with the AST much easier and safer with the type declarations.

I think I'll create a project within this github repo so we can discuss which things we need to address to migrate the plugin to TS and split proper work.

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

Successfully merging this pull request may close these issues.

Support resolves/rejects matchers for asynchronous queries
3 participants