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

Fix NodePath.referencesImport for JSXMemberExpression #14403

Merged
merged 5 commits into from Mar 31, 2022

Conversation

swandir
Copy link
Contributor

@swandir swandir commented Mar 29, 2022

Q                       A
Fixed Issues? Fixes #14375
Patch: Bug Fix?
Major: Breaking Change?
Minor: New Feature?
Tests Added + Pass? Yes
Documentation PR Link
Any Dependency Changes?
License MIT

As described in the issue, NodePath.referencesIssue is only missing a check for JSXMemberExpression to support it.

@babel-bot
Copy link
Collaborator

babel-bot commented Mar 29, 2022

Build successful! You can test your changes in the REPL here: https://babeljs.io/repl/build/51599/

@swandir swandir force-pushed the referencesImport-JSXMemberExpression branch from 43a1eb2 to e072ba9 Compare March 29, 2022 21:24
@swandir swandir changed the title References import jsx member expression Fix NodePath.referencesImport for JSXMemberExpression Mar 29, 2022
this: NodePath<t.Expression>,
this: NodePath,
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Because JSXMemberExpression is not an Expression

Copy link
Member

Choose a reason for hiding this comment

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

We can mark it as NodePath<t.Expression | t.JSXMemberExpression>

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sure, done
Though I wonder what's the point of narrowing the type of this here? all the other methods accept NodePath 🤔

Copy link
Member

Choose a reason for hiding this comment

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

Uhm yes that's a good observation. This method always work, it just return false for other node types.

You are right, NodePath is good enough here. Sorry!

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah, I had a thought that making this type narrower doesn't make it more convenient for the TypeScript user, since they either would already be in a context where the type matches (e.g in a visitor) and won't notice, or would be forced to preclude the call with a manual check, which is performed inside the method anyway.

Sure, done

Reverted 😃

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Although...

function f(path: NodePath) {
  path.referencesImport("moduleSource", "importName");
}

this does not produce a TS error now 🤔

Copy link
Member

Choose a reason for hiding this comment

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

Yeah that's correct, right? It can return false for every unsupported node type, but it always knows what to return.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I mean, if a function is typed to accept only a certain type as this, I'd expect TypeScript to prevent me from calling it on anything incompatible

https://www.typescriptlang.org/play?#code/GYVwdgxgLglg9mABMAFFAFjAzgLkQb0QEM8soAnGMAc0QF8BKAugKBYgTMTkQF4Dk9ANxs4AOlQMRQA

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ah! I forgot that definitions currently are published separately, and they differ. So this function signature does not affect third party usage. Mystery solved 😅

Comment on lines 184 to 189
(this.isMemberExpression() || this.isOptionalMemberExpression()) &&
(this.node.computed
? isStringLiteral(this.node.property, { value: importName })
: (this.node.property as t.Identifier).name === importName)
(this.isJSXMemberExpression() &&
(this.node.property as t.JSXIdentifier).name === importName) ||
((this.isMemberExpression() || this.isOptionalMemberExpression()) &&
(this.node.computed
? isStringLiteral(this.node.property, { value: importName })
: (this.node.property as t.Identifier).name === importName))
Copy link
Contributor Author

Choose a reason for hiding this comment

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

JSXMemberExpression is never computed

@nicolo-ribaudo nicolo-ribaudo added pkg: traverse area: jsx PR: Fixes failing main PR: Bug Fix 🐛 A type of pull request used for our changelog categories and removed PR: Fixes failing main labels Mar 30, 2022
@swandir swandir force-pushed the referencesImport-JSXMemberExpression branch from 49885fa to 1cc2a3e Compare March 30, 2022 22:46
@JLHwung JLHwung merged commit b7a7c65 into babel:main Mar 31, 2022
@swandir swandir deleted the referencesImport-JSXMemberExpression branch March 31, 2022 23:56
@github-actions github-actions bot added the outdated A closed issue/PR that is archived due to age. Recommended to make a new issue label Jul 1, 2022
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Jul 1, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area: jsx outdated A closed issue/PR that is archived due to age. Recommended to make a new issue pkg: traverse PR: Bug Fix 🐛 A type of pull request used for our changelog categories
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Bug]: referencesImport is always false for JSXMemberExpression
4 participants