0

I am trying to configure rollup to build commonjs module from existing esm. I have set of separate standalone methods, exported with default and available to import directly from package like:

import method1 from 'lib/method1'

And I have single entry point for all of them standalone.js to let user code import them separately using destructuring or at once as lib.

import _method1 from './method1'
import _method2 from './method2'
import _method3 from './method3'

export const method1 = _method1;
export const method2 = _method2;
export const method3 = _method3;

export default {method1,method2,method3};

So this is usage example:

import method1 from 'lib/method1'
//or
import { method1 } from 'lib/standalone'
//or
import standalone from 'lib/standalone'
//standalone.method1();

All this works fine for esm and I want similar experience for cjs. Rollups do everything almost correct but it's complaining about mixed named/default export and adding extra module.exports.default field:

'use strict';

Object.defineProperty(exports, '__esModule', { value: true });

var condense$1 = require('./condense.js');
var condenseDeep$1 = require('./condenseDeep.js');
var eachDeep$1 = require('./eachDeep.js');
// ...


var condense = condense$1;
var condenseDeep = condenseDeep$1;
var eachDeep = eachDeep$1;
//...

var standalone = {
  condense: condense$1,
  condenseDeep: condenseDeep$1,
  eachDeep: eachDeep$1,
  //...
};

exports.condense = condense;
exports.condenseDeep = condenseDeep;
exports.default = standalone; // <-- this one, how to remove it?
exports.eachDeep = eachDeep;
//...

so in commionjs usage looks like:

const method1 = require('lib/method1');
//or
const { method1 } = require ('lib/standalone');
//or
const standalone = require('lib/standalone');
//standalone.method1();
//standalone.default <--- this is redundant and confusing

I tried output.exports: 'named' rollup option - other entry points which are using default only also started having module.exports.default = .. instead of expected module.exports = ..

I tried output.exports: 'default' - it's not working with mixed default/named exports, throwing error.

Yuri Gor
  • 1,353
  • 12
  • 26

1 Answers1

2

A default export is a named export, it's just named default. ESM is built so that if you don't specify a name, it uses the export named default from the JS file.

Using CJS, there's no concept of default exports, everything is named.

The point is, nothing is wrong here. You can't mix named and default exports and use them without specifying .default in CJS.

Maybe this gist thread will help you out.

EDIT: You could always hack it as this answer suggests, but it is a hack, and then you'll lose named exports.

Adam Jenkins
  • 51,445
  • 11
  • 72
  • 100
  • Thank you for reply //Using CJS, there's no concept of default exports Yes, but it's comon practice in cjs to just require the whole module, if it's just function for example, or whole lib with methods. I thought about some post-processing of compiled cjs and just commenting this 'default', but by reading your links it seems like a bad design for ES module - tree shaking will not work? So maybe it's fine to have no default export in esm, then for cjs it will be as expected, and in esm you will always have to import methods explicitly, and it's a benefit of esm actually. – Yuri Gor Apr 19 '21 at 09:44