"No default export found in module" when mixing ES5 and ES6

[JasperH8g]

When importing a module that exports an object the old way:

// a.js
module.exports = {};

// b.js
import A from './a';

This results in:

No default export found in module

When the module you're trying to import is updated to the new syntax, it seems to be valid:

// a.js
export default {};

// b.js
import A from './a';

Unfortunately this is not possible in my case. I can disable the rule for this file as a workaround, but this should be possible right?

[benmosher]

This is a weird case (albeit, not an uncommon one) that is only really reachable due to transpiler pipelines compiling down to CJS, so tools like Babel allow you to import default and get the module.exports object, iff there is no exports.default and no exports.__esModule = true (generally).

You can set import/ignore to include a.js--it's a regex field, ATM--and then none of the ES6 import rules (default, named, namespace) will attempt to look up named imports in there.

In v2 (coming soon... probably), if a.js is not unambiguously a module, it will be auto-ignored. See #270 for additional details. I think that will solve this somewhat permanently, but for now, yeah, you'll have to explicitly ignore it. 😅

[JasperH8g]

Alright, I didn't know you can ignore the imported files explicitly. This is a good enough workaround for now, thanks.

[JasperH8g]

@benmosher in the meantime, we decided to share more code between our api and client in our project. This means that a lot more code exports the old way, so it would be great if we don't have to ignore these imports..

Can't we get it so that the webpack-resolver would first try to load the module the old way, and if that fails use the webpack-pipeline to load it the way it does now?

[benmosher]

v2 should be coming soon! 😅 going to merge it to master as soon as 1.16 ships

[dawsbot]

Still an issue for me, is this being worked on?

[benmosher]

Ignoring files like this is still the right answer IMO