No default export provided

Describe the bug

Many packages import uuid as:

const uuid = require('uuid');

When converted into ES modules, this would correspond to:

import uuid from 'uuid';

When running the browser though, the browser ES module build does not support a “default” export and as a result packages on jspm using UUID are currently breaking.

How to reproduce

Try, for example, import('https://jspm.dev/@google-cloud/bigquery')

Expected behavior

UUID should be configured such that the shape of the module between browsers and Node.js remains the same - the default export should exist for both. Node.js CommonJS modules are always represented by a default export, see https://nodejs.org/dist/latest-v15.x/docs/api/esm.html#esm_commonjs_namespaces for more info.

Additional information

The suggested fix would be to add an export default uuid to the ES module namespace.

[guybedford]

I wanted to follow up on this issue - I’ve come around to the view of @sokra and @lukastaegert that allowing ES module imports into CommonJS should support different shapes than just { default }.

I’ve since implemented something similar to the requireReturnsDefault: 'preferred' option in RollupJS for JSPM (https://github.com/rollup/plugins/tree/master/packages/commonjs#requirereturnsdefault). And cases like import('https://jspm.dev/@google-cloud/bigquery') are working now with uuid being required as an ES module as require('uuid') being rewritten into:

import * as _uuid from 'uuid';
var uuid = 'default' in _uuid ? _uuid.default : _uuid.

I think there is still some clear incompatibility on these paths between tools as Webpack has one way, RollupJS has a default and lots of options, and I’m not sure what esbuild does. A clear investigation into these cases may be found in Tobias’s compat table where the risks can be assessed but I haven’t been able to fully check that.

Hopefully we can work towards this case being very clearly supported between tools, or at least have a very clear subset for it.

As to whether the PR should be merged, it would likely be a safer compatibility to still merge it, but could be fine to leave as well now.

I’m closing this issue as resolved since I believe it seems tools will ensure library authors shouldn’t have to be too concerned about this, but let’s continue discussion if anyone is interested too.

[guybedford]

Seriously though, the fix looks good, and just requires the single require wrapper doing:

export * from './index-browser.mjs';
import * as m from './index-browser.mjs';
export default m;

then the exports in order as you have on the default with the others pointing to the current browser index.