[import/named] fails to track deep exports when re-exporting from a module in node_modules

[kentcdodds]

Here's a reproduction: https://github.com/kentcdodds/eslint-export-named-issue

// exporter.js
// NOTE: I observed that it's only a problem if you export * from a file in node_modules
// and it doesn't matter module it is. In my case, I'm trying to re-export from `@testing-library/react`.
// here I'll just use eslint-plugin-import so we don't need to install anything else.

import {config} from 'eslint-plugin-import' // <-- no error here (so it definitely exports `config`)

export * from 'eslint-plugin-import'

// importer.js

import {configs} from './exporter' // <-- import/named fails

I'm not sure why this is an issue, but like I said, it appears to only happen when you re-export from a node_modules module. Seems to work fine if you re-export from one of your own files.

[redbugz]

We have the same problem, and I started poking around. Not entirely familiar with the code, but it seems to be the module is ignored due the unambiguous check. When importing the node_module module, it gets the compiled es5 source code, which fails the unambiguous test. So hasDeep has a null innerMap, and returns no exports, so the import is not found.

It seems possibly to be a similar condition to #1460.

We have gotten some modules do work with export * from 'modulename', and I'm guessing they are resolving to the es6 module source instead of the es5.

Using Kent's repo, here is the log output:

% DEBUG=eslint-plugin-import* npm run lint    

> @ lint /Users/me/dev/sandbox/eslintexport2
> eslint .

  eslint-plugin-import:resolver:node Resolving: eslint-plugin-import from: /Users/me/dev/sandbox/eslintexport2/exporter.js +0ms
  eslint-plugin-import:resolver:node Resolved to: /Users/me/dev/sandbox/eslintexport2/node_modules/eslint-plugin-import/lib/index.js +3ms
  eslint-plugin-import:ExportMap ignored path due to unambiguous regex: /Users/me/dev/sandbox/eslintexport2/node_modules/eslint-plugin-import/lib/index.js +0ms
  eslint-plugin-import:resolver:node Resolving: ./exporter from: /Users/me/dev/sandbox/eslintexport2/importer.js +6ms
  eslint-plugin-import:resolver:node Resolved to: /Users/me/dev/sandbox/eslintexport2/exporter.js +1ms
  eslint-plugin-import:ExportMap cache miss e4390246ed48adc78ea6b4ca0d8aadeedb549dccd99cb9178c4f72a69f41013f for path /Users/me/dev/sandbox/eslintexport2/exporter.js +6ms

/Users/me/dev/sandbox/eslintexport2/importer.js
  1:9  error  configs not found in './exporter'  import/named

✖ 1 problem (1 error, 0 warnings)

[JounQin]

I think this is because the final outputs are commonjs: https://unpkg.com/eslint-plugin-import@2.19.1/lib/index.js

[redbugz]

Looking at our project, most everything in node_modules is skipped because of ignore rules, but when it's ignored, it appears to just silently accept whatever I import without checking.

In Kents repo, and for dependencies where you have a local file re-exporting from node_modules, it gets the es5 from node_modules, and reports the re-exports as failures because it doesn't parse es5 even though the exports are in there. So named cannot accurately determine if an import is valid or not, but for ignored modules it silently accepts anything, but for re-exported unparseable es5 it reports a failure. Should it detect the condition where you are re-exporting es5 and also just silently accept any import from that file?
Is this todo relevant? https://github.com/benmosher/eslint-plugin-import/blob/master/src/ExportMap.js#L68