[Fix] named/ExportMap: handle named imports from CJS modules that use dynamic import

[ludofischer]

Fix #2294

• Modify ExportMap to track whether the module is unambiguously ES6
• Add tests for named import with import as require()

Proposed solution

Mark ambiguous (i.e. not unambiguously ESM) modules that contain dynamic import()
so that they can be ignored like other ambiguous modules when analysing named imports.

Previous to 7c382f0 this was not necessary because a null ExportMap was returned for all ambiguous modules.

Alternatives

Parse the CommonJS exports instead of ignoring the CommonJS modules. Rejected because analysingg CommonJS exports seems out of scope of this plugin.

[ljharb]

Tests look good!

[codecov]

Codecov Report

Merging #2341 (56b6838) into main (ef980d4) will increase coverage by 0.07%.
The diff coverage is 100.00%.

❗ Current head 56b6838 differs from pull request most recent head e3ca68e. Consider uploading reports for the commit e3ca68e to get more accurate results

@@            Coverage Diff             @@
##             main    #2341      +/-   ##
==========================================
+ Coverage   94.64%   94.72%   +0.07%     
==========================================
  Files          65       65              
  Lines        2691     2690       -1     
  Branches      891      893       +2     
==========================================
+ Hits         2547     2548       +1     
+ Misses        144      142       -2     

Impacted Files	Coverage Δ
src/ExportMap.js	100.00% <ø> (+7.14%)	⬆️
src/rules/named.js	84.90% <100.00%> (+2.21%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update ef980d4...e3ca68e. Read the comment docs.

[ludofischer]

I've applied your suggestion of turning maybeNotEsm into a parseGoal field. Is there another refactor you had in mind where this parseGoal should be used? Another thing that was on my mind is that the default rule might also fail in a similar case.

[ljharb]

I'm mainly hoping that we can get these kinds of helpers in a place where it becomes trivial to support CJS files as well as ESM files.

What are your thoughts about having an "empty" ExportsMap instead of null for a CJS file without dynamic imports?

[ludofischer]

What are your thoughts about having an "empty" ExportsMap instead of null for a CJS file without dynamic imports?

I need to take a longer look at the code. My instinct would be that it increases the risk of breaking something else as we'll miss one spot that's relying on the ExportsMap being null.

[ljharb]

Fair enough, let's do that in a follow-up PR then.

[ludofischer]

Fair enough, let's do that in a follow-up PR then.

I feel like I am missing some context to make a follow-up. I've looked at the implementation for the rules some more and I've also looked at the issues. I cannot find case where returning empty ExportMap from a CJS file would make a difference:

1. it would not get rid of returned null since ExportMap.get() returns null when the file is ignored or has an invalid extension according to the config
2. all of dependencies, imports, errors would be empty, it would be the same as skipping processing completely, which already happens when ExportMap is null

On an unrelated note, have you thought about using issue templates to require a link to a reproduction? I've got the impression that a lot of open issues are unactionable because they lack a reproduction.

[ljharb]

@ludofischer i'm mainly thinking that it'd make it clearer for rules to use ExportsMap - since CJS Scripts have a dep graph too, and this plugin should support them.

As for an issue template, I'd be happy to look at a PR that added one :-)