Bug: require() doesn't support default exports in ES Modules

[fregante]

✅ ➡️ Edit 2020 for Webpack users:

• always prefer import nowadays. Only use require if the package is not an ES Module.

---

Do you want to request a feature or report a bug?

Bug

What is the current behavior?

const ofi = require('object-fit-images');

In webpack 1.x, this picks up the CommonJS file defined in main.

In webpack 2.x, this loads the module file and sets ofi = {default: realOfi}, which means that users have to use the unnatural const ofi = require('object-fit-images').default. Example

If the current behavior is a bug, please provide the steps to reproduce.

npm i object-fit-images@3.1.3
npm i webpack@2.4.1 --global
echo 'var ofi = require("object-fit-images"); ofi()' > src.js; webpack src.js errors.js
echo 'var ofi = require("object-fit-images").default; ofi()' > src.js; webpack src.js works.js
echo 'import ofi from "object-fit-images"; ofi()' > src.js; webpack src.js works-esm.js

What is the expected behavior?

import is for ES Modules and it should try to read the module file if it exists. This works correctly.

require is for CJS files and it should only read the main entry point, not the module one. If it does, it should at least flatten default wherever possible.

Please mention other relevant information such as the browser version, Node.js version, webpack version and Operating System.

node 7.8.0
webpack 2.4.1
OSX 10.11.6

[sokra]

Packages should not export different things from module and main.

The main/module fields in the package.json describe the entrypoint of the package in ESM and CJS. It doesn't depend on the way you require/import it.

If if would depend on it, it would cause duplication i. e. if you require a module in one file and import it in another file.

So in my opinion this is working correctly. But like to hear more opinions...

---

I know this is bad for package author because this could mean they need to break the API when adding a ESM export. i. e. when previously exporting a function with module.exports = function objectFitImages() {} they need to change their API to exports.objectFitImages = function() {} or default. objectFitImages = require("object-fit-images") -> objectFitImages = require("object-fit-images").objectFitImages or objectFitImages = require("object-fit-images").default.

[fregante]

Packages should not export different things from module and main.

That makes sense, but in reality neither of those options is ideal. You wouldn't expect anyone to use something like this:

var webpack = require('webpack').default; //<--
webpack(...);
//or
var webpack = require('webpack');
webpack.webpack(...); //<-- almost ok, but awkward

It defeats the purpose of having a separate module file at all since it only complicates things when using default exports. Without module both of these work as expected:

echo 'var ofi = require("object-fit-images"); ofi()' > src.js; webpack src.js dist.js
echo 'import ofi from "object-fit-images"; ofi()' > src.js; webpack src.js dist.js

[fregante]

If if would depend on it, it would cause duplication i. e. if you require a module in one file and import it in another file.

You're perfectly right here, always read one file regardless of which import/require method is used.

So how about flattening the default export with interopDefault like babel and rollup do?

webpack could automatically change this:

var ofi = require("object-fit-images");
ofi();

into:

var ofi = require("object-fit-images");
ofi = 'default' in ofi ? ofi['default'] : ofi;
ofi();

[sokra]

interopDefault happens when importing a CommonJs module. webpack does the same. No other CommonJs impl does something like you proposed and it doesn't make sense. You won't be able to access other exports except the default export.

---

The purpose of the module field is to offer the same package content with ESM instead of CJS. You are using it wrong if you put different APIs behind the module field. Exports should match.

export default <=> exports.default =
export function test() <=> exports.test = function()
N/A <=> module.exports

[fregante]

No other CommonJs impl does something like you proposed and it doesn't make sense.

1. It makes sense to me since both a = require() and import a from mean get the default export ("default" in the classical sense, not how it's described by the ESM spec)

2. rollup does that when requiring es modules:

   $ cat module.js 
   export default function foo () {}
   
   $ cat requirer.js 
   const test = require('./module.js');
   console.log(test)
   
   $ cat rollup.config.js 
   export default {
     format: 'cjs',
     plugins: [ require('rollup-plugin-commonjs')() ]
   };
   
   $ rollup requirer.js --config | node
   [Function: foo] # this is console.log(test)

3. rollup does that when bundling exporting modules, export default X becomes module.exports = X, demo

The purpose of the module field is to offer the same package content

I already agreed with that in my previous comment.

What I'm suggesting is the equivalent of interopDefault when requiring ES default imports. Would you ever suggest using this API for your own modules?

const webpack = require('webpack').default;

.default should never be part of an API.

---

Now we could even agree that the current situation makes perfect technical sense, but this kills interoperability: it either results in poor APIs (.default) or into the unusability of the module field for default-exporting modules.

[tivac]

I just ran into this with modular-css after trying to offer named ES2015 exports. Some CSS classnames aren't valid JS identifiers, so they can't be part of the named exports. Now uses will have to use require("./file.css").default if they want access to all exported classnames.

I'm considering reverting the change to use ES2015 exports because of this, it's now a bad experience for end-users. 😓

[fregante]

More context: http://2ality.com/2017/01/babel-esm-spec-mode.html#an-es-module-can-only-default-import-commonjs-modules

For library authors: As a workaround, you could:

• offer a separate package like lodash does (lodash-es), or
• skip the module field and use a es-specific entry point, like import a from 'yourpkg/es'
• skip the module field, avoid es modules (my preferred solution for most of my modules)

The first two choices will be explicit and won't depend on tooling (but they'll need to be documented)
The last choice just works with all CommonJS loaders/tools.

[lygstate]

anyway to fixes this in webpack???
too much packages have such issues, broken again and again.

[lygstate]

There is objection, https://www.bignerdranch.com/blog/default-exports-or-named-exports-why-not-both/
I am bitten by these things.

maybe webpack better to provide a optionMap to config each node module are default export or named export.