You should alsonode = skipParentheses(node) at the top here

What would be an example we care to test, something likea && (a).b?

Yep,foo && (foo.bar === 1) seems more realistic since the precedence between different binary operators can be hard to remember, but I think if you putskipParentheses in the right places, you can trivially handlefoo && (((foo).bar) === 1) 😁

I think there’s possibly a less efficient but more easily understandable way to write this function by going depth-first, grabbing the left-most name of both the chain and the subchain right away, and walking up their parents. But I couldn’t write an elegant example in a few minutes, so maybe it wouldn’t be as good as I think it would.

I guess the easiest to understand way to break it down, in my mind, would be to have a function that returns the array["a", "b", "c", "d"] for the PropertyAccessExpressiona.b.c.d (it could return strings or Identifiers, either way), then

functionchainStartsWith(chain:EntityNameExpression,subchain:EntityNameExpression){constsubchainIdentifiers=getIdentifiersInEntityName(subchain);constchainIdentifiers=getIdentifiersInEntityName(chain);returnevery(subchain,(identifier,index)=>{returnidentifier.getText()===chainIdentifiers[index]?.getText();});}

This would be a bit more eager than what you have, and would allocate some arrays you don’t strictly need, but is easier to follow to me.

In this example I also presuppose the typesEntityNameExpression to guarantee that you have a string of dot-separated identifiers, because it makes this function easier to reason about and there are alreadyisEntityNameExpression functions you can use, but if you wanted to nitpick on efficiency, you could check on the fly ingetIdentifiersInEntityName, returningundefined if you discover that you don’t actually have an EntityNameExpression.

Would this make other cases we care about easier to implement (maybe optional element access) in addition to making it easier to read? It does feel quite awkward to go through the entirety of both access chains to build the arrays if we would terminate on the first check we would have made otherwise. On the other hand, really long access chains in binary expressions are probably not common anyway?

I think expanding to optional element access should be pretty easy either way.

Would this work as well? Seems easier to read than double!

maybe just change the name tofinalExpression here too?