import/named falsely reports import as not found (regression in 2.25)

[ludofischer]

eslint-plugin-import version: 2.25.0 and 2.25.2
eslint version: 7.32 and 8.1
Reproduction repo: https://github.com/ludofischer/eslint-plugin-import-error-demo

When using the optimize named import from the svgo 2.8 library, since 2.25 eslint-plugin-import reports

error  optimize not found in 'svgo'  import/named

while the import was correctly handled as valid in eslint-plugin-import 2.24. svgo uses CommonJS with just a main package.json field that points to this file: https://github.com/svg/svgo/blob/master/lib/svgo-node.js

[ludofischer]

With 2.25.2, even the default import triggers a false positive:

import svgo from 'svgo';

yields

error  No default export found in imported module "svgo"  import/default

But it works with eslint-plugin-import 2.24

[ludofischer]

I've also found a simpler way to reproduce the error: (new commit in same repo https://github.com/ludofischer/eslint-plugin-import-error-demo).
Use an ES import from a CommonJS module when the CommonJS module contains an ES-style dynamic import. In that case, eslint-plugin-import will:

1. try to analyze the CommonJS module
2. fail to understand to recognize either a default import or named import from the CommonJS module

Removing the dynamic import from the code of the CommonJS module removes the eslint warning.
If I understand the docs correctly, eslint-plugin-import should not even attempt to analyze imports from svgo, since the svgo package does not contain a module field. Also a CommonJS module with a dynamic import in it is likely not 'unambiguously an ES', so I think eslint import plugin should not attempt to analyze it.

[ljharb]

A module field shouldn't be required - it's not even a standard field. It's just something we support for convenience.

https://unpkg.com/browse/svgo@2.8.0/package.json does indeed point to https://unpkg.com/browse/svgo@2.8.0/lib/svgo-node.js.

Thanks for the repro repo; I'll check it out.

[ludofischer]

Wouldn't the expected behaviour to avoid analysing SVGO by default since it's not ESM? In the second commit of repro repo you should see that removing the dyanmic import() in the imported test.js makes the linting pass.

[ljharb]

There's a commonjs: true rule option, so we need the capability anyways, but also CJS is just as statically analyzeable as ESM, so we should be able to handle it.

I see that removing the import() makes the linting pass, but its presence shouldn't cause a passing test to fail - it should either have no impact, or should cause a failing test to pass, by "using" more imports.

[ludofischer]

The named rule docs say

A module path that is ignored or not unambiguously an ES module will not be reported when imported

That made me think the issue in 2.25 is not ignoring the import from a CJS module.

[shamilovtim]

Also experiencing this false positive:

The file and typedef exists:

[ljharb]

@shamilovtim have you tried import type to import that type?

[shamilovtim]

yes that fixes it! thank you!

[BalzGuenat]

This is still an issue for us after we tried to update the dependencies of our React app. The workaround of using a type import worked when linting via yarn eslint but did not work when compiling/linting via react-scripts start. We had to downgrade to 2.24.2 for it to work.

[ljharb]

@BalzGuenat please file a bug on CRA if it doesn't support import type.

[BalzGuenat]

To be clear: react-scripts start fails because of this regression. We could work around it for yarn eslint but the same workaround does not work for the linting that happens as part of react-scripts start.

[ljharb]

I continue to be happy to review a PR that fixes the regression - that "use import type" is the best practice and will help you in the long run doesn't change that it's still a bug.

[ludofischer]

In the case I posted the reason it works in 2.24 is because 2.24 constructs a null ExportMap. So in a sense 2.25 is an improvement in that at least it manages to construct the ExportMap, unfortunately it seems the wrong one.