import/namespace should consider pkg.module

[aladdin-add]

I am using:

• eslint: v7.6.0
• babel-eslint: 11.0.0-beta.2
• eslint-plugin-import: 2.22.0

sourcecode:

import { Provider } from 'react-redux'

output:

  10:26  error  Parse errors in imported module 'react-redux': No Babel config file detected for /Users/weiran/repo/react-app/node_modules/react-redux/es/index.js. Either disable config file checking with requireConfigFile: false, or configure Babel so that it can find the config files. (undefined:undefined)  import/namespace

I've reread the import/namespace docs:

Note: for packages, the plugin will find exported names from jsnext:main, if present in package.json. Redux's npm module includes this key, and thereby is lintable, for example.

but seems react-redux is using pkg.module, instead of jsnext:main. any reasons not to honor pkg.module?

[ljharb]

To be honest, I don't think we should be looking at jsnext:main either. The "module" field is nonstandard, doesn't match what node already ships for ESM support, and packages shouldn't be using it.

That said, since we already support jsnext:main, perhaps this rule, at least, should also support the module field.

[scinos]

@ljharb would you be open to make this configurable?

The reality is that different package bundlers support different fields to point to the package source code (see https://github.com/stereobooster/package.json#package-bundlers). Despite them being nonstandard, there are many packages out there using them.

What do you think about having a setting in eslint-import-resolver-node named mainFields, with the same semantics as webpack? (https://github.com/stereobooster/package.json#package-bundlers)

If you think this is a valid idea I can start working on a PR to support it.

[ljharb]

Any package using those fields should still be using “main” as a fallback, so I’m not sure it adds a lot of value to support them.

[ljharb]

Separately no, it should not be configurable. If we support the module field, it will be by default.

Now that node has shipped ESM, bundlers should never add support for any other nonstandard field beyond the two already mentioned.

[soryy708]

@ljharb so what is actionable here? some parts are not planned but it's unclear to me what is?

[ljharb]

I think it should stay open for now, and be addressed as part of updating resolve when the time comes.