feat(referencesImport): support named exports accessed via namespace imports

[jeysal]

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

See referenced issue (or tests) for explanation/example.
Not really a bug fix because it was unclear how smart referencesImport is - this makes it a bit less limited.
We could of course go even further, support some cases of computed properties, etc., but I'd argue this is a pretty good line to draw because ns.dep is by far the most common way to access a named import via a namespace import object.
Don't think I have permission to request reviews here so cc @nicolo-ribaudo 😅

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit 191a654:

Sandbox	Source
babel-repl-custom-plugin	Configuration
babel-plugin-multi-config	Configuration

[jeysal]

Only took me 3/4 of a year to follow up on the issue 🙈

[babel-bot]

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

[JLHwung]

I don't think NodePath#referencesImport should extend to named imports because it is mutable, although the imported namespace binding is constant. For example

import * as ns from "some-module";
ns.foo = "foo";

// error: can not reassign "ns"
ns = anotherNs

Should NodePath("ns.foo").referencesImport("some-module", "foo") return true? While we are sure * is a referenced import from "some-module", we don't know if "foo" is exported from "some-module" without looking into the exports of "some-module".

[jeysal]

@JLHwung as far as I know, this is not the case? Maybe I'm missing something.
At least in Node 14.15.1, which I've used to test, trying to override an existing namespace property fails with

TypeError: Cannot assign to read only property 'prop' of object '[object Module]'

and trying to add one fails with

TypeError: Cannot add property prop2, object is not extensible

[jeysal]

I've checked the spec and these 'module namespace exotic objects' are indeed non-extensible, and their [[Set]] does nothing but Returns false. Phew, for a moment I was scared that the spec actually allowed mutating them, which would be terrible for anyone who wants to do some static analysis 😅

[jeysal]

Both done - lmk if this needs anything else

[nicolo-ribaudo]

The failing e2e tests are not related, and are probably caused by a slightly old base branch.

[jeysal]

Would you like me to rebase?

[nicolo-ribaudo]

Yes please!

[jeysal]

Done, it seems this was because it was based off of master, because my repo was from before the main branch name change