fix: handle property accesses cases on resolve-binding-path

[brunocroh]

When a module is imported with property access after require

const bind = require("module").a.b.c
const result = resolveBindingPath(node, "$.a.b.c")

It resolve as bind.a.b.c However, since the property is accessed immediately after require, it should instead resolve as bind, because the value of c is directly assigned to the bind constant.

This changes fixes that behavior.

[AugustinMauroy]

is it possible to have handling something like :

import foo from 'node:foo'

foo.bar.functionToModify();

[brunocroh]

is it possible to have handling something like :

import foo from 'node:foo'

foo.bar.functionToModify();

I think this test already covers this scenario, doesn’t it?

userland-migrations/utils/src/ast-grep/resolve-binding-path.test.ts

Lines 26 to 41 in 485cdc1

	it("should be able to solve binding path when destructuring happen", () => {
	const code = dedent`
	const { types } = require('node:util');
	`;
	const rootNode = astGrep.parse(astGrep.Lang.JavaScript, code);
	const importStatement = rootNode.root().find({
	rule: {
	kind: "variable_declarator",
	},
	});
	const bindingPath = resolveBindingPath(importStatement!, "$.types.isNativeError");
	assert.strictEqual(bindingPath, "types.isNativeError");
	});

[AugustinMauroy]

is it possible to have handling something like :

import foo from 'node:foo'

foo.bar.functionToModify();

I think this test already covers this scenario, doesn’t it?

userland-migrations/utils/src/ast-grep/resolve-binding-path.test.ts

Lines 26 to 41 in 485cdc1

	it("should be able to solve binding path when destructuring happen", () => {
	const code = dedent`
	const { types } = require('node:util');
	`;
	const rootNode = astGrep.parse(astGrep.Lang.JavaScript, code);
	const importStatement = rootNode.root().find({
	rule: {
	kind: "variable_declarator",
	},
	});
	const bindingPath = resolveBindingPath(importStatement!, "$.types.isNativeError");
	assert.strictEqual(bindingPath, "types.isNativeError");
	});

Yeah but for esm

[brunocroh]

is it possible to have handling something like :

import foo from 'node:foo'

foo.bar.functionToModify();

Done

[AugustinMauroy]

LGMT ! Thanks bruno

[JakobJingleheimer]

nit: I think newPath is actually constant?

[JakobJingleheimer]

i will actually be scoped to the parent of for automatically, so extracting it like this is unnecessary, but perhaps you did it to make it more obvious that the parent scoping is necessary/intended?