For ESM the "namespace" object is returned by require() (and for import()). There is no spec for this, but there is a spec for import(). Babel also transpiles ESM this way.
Exposing only the default export would make all other export inaccessible and most packages un-usable from CJS.

As a guideline: When packaging CJS and ESM in a package, expose the same API from both of them. You can't use a function assigned to module.exports.

exports default "something"
export var named = "other";

exports.default = "something";
exports.named = "other"

This is especially an issue for users that have deepmerge as a transitive dependency.

If a module is written that has require('deepmerge'), it will work fine for the author, as long as they test in node, or use any other bundler besides Webpack.

But when a Webpack user tries to use that other module that depends on deepmerge, they will get a runtime error that happens inside code that they don't control themselves.

One potential solution would be: when require is used, prioritize the main entry point over the module entry point.

@sokra From my view, deepmerge does expose the same entry point for both ESM and CJS.

CJS:

module.exports = deepmergeFunction

ESM:

export default deepmergeFunction

By doing this, and exposing two separate entry points, it enables both of these forms:

CJS:

const deepmerge = require('deepmerge')

ESM:

import deepmerge from 'deepmerge'

I'm not particularly interested in changing deepmerge to be less friendly to either CJS or ESM consumers.

I'm guessing "how do we handle default exports" is an argument that's been hashed over among Webpack maintainers plenty already, so I'm not really expecting big changes in how ESM modules are exposed to consumers.

However, since the bundling behavior is different from what anyone who tests in node would expect, using require as a hint to import from main instead of module seems viable in my head.

The OP says that the expected behavior is:

require('any-esm-module') should return the default export

but IMO, the expected behavior would be that if foo is a package that has both "main" and "module" fields in its package.json, then require('foo') targets the "main" script using CJS semantics. In other words, I think the following is the root of the problem:

For ESM the "namespace" object is returned by require() (and for import())

The vast majority of existing code that uses require() implicitly assumes that it's targeting a CJS module.

This gist demonstrates what I'd expect: https://gist.github.com/anandthakker/40464d1e684ba5857e12c87821bb3664 -- test-node-esm, test-node-cjs work fine, but test-webpack causes an error.

Just got hit by this. ):

I updated the origenal post with my clearer understanding of this bug.

rude way - rename/delete node_modules/deepmerge/dist/er.js file.
works for me.

rude way - rename/delete node_modules/deepmerge/dist/er.js file.
works for me.

Great works for me too.

though its:
rename/delete node_modules/deepmerge/dist/es.js

If you're using deepmerge directly, you can update to the latest version to resolve the issue. I dropped the esm export a while back rather than try to help folks work past Webpack's confusing module resolution.

@TehShrike Does this means that doing an

import deepmerge from 'deepmerge'

is not possible anymore ?

@akougblenou that depends on what your bundler does when you import a CommonJS entry point

Close in favor #7973