Because JSXMemberExpression is not an Expression

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

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

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!

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 😃

Although...

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

this does not produce a TS error now 🤔

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

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

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

JSXMemberExpression is never computed