Asked  7 Months ago    Answers:  5   Viewed   84 times

I am trying to determine if there are any big differences between these two, other than being able to import with export default by just doing:

import myItem from 'myItem';

And using export const I can do:

import { myItem } from 'myItem';

Are there any differences and/or use cases other than this?



It's a named export vs a default export. export const is a named export that exports a const declaration or declarations.

To emphasize: what matters here is the export keyword as const is used to declare a const declaration or declarations. export may also be applied to other declarations such as class or function declarations.

Default Export (export default)

You can have one default export per file. When you import you have to specify a name and import like so:

import MyDefaultExport from "./MyFileWithADefaultExport";

You can give this any name you like.

Named Export (export)

With named exports, you can have multiple named exports per file. Then import the specific exports you want surrounded in braces:

// ex. importing multiple exports:
import { MyClass, MyOtherClass } from "./MyClass";
// ex. giving a named import a different name by using "as":
import { MyClass2 as MyClass2Alias } from "./MyClass2";

// use MyClass, MyOtherClass, and MyClass2Alias here

Or it's possible to use a default along with named imports in the same statement:

import MyDefaultExport, { MyClass, MyOtherClass} from "./MyClass";

Namespace Import

It's also possible to import everything from the file on an object:

import * as MyClasses from "./MyClass";
// use MyClasses.MyClass, MyClasses.MyOtherClass and MyClasses.default here


  • The syntax favours default exports as slightly more concise because their use case is more common (See the discussion here).
  • A default export is actually a named export with the name default so you are able to import it with a named import:

    import { default as MyDefaultExport } from "./MyFileWithADefaultExport";
Tuesday, June 1, 2021
answered 7 Months ago

The issue is with

  • how ES6 modules are emulated in CommonJS
  • how you import the module

ES6 to CommonJS

At the time of writing this, no environment supports ES6 modules natively. When using them in Node.js you need to use something like Babel to convert the modules to CommonJS. But how exactly does that happen?

Many people consider module.exports = ... to be equivalent to export default ... and ... to be equivalent to export const foo = .... That's not quite true though, or at least not how Babel does it.

ES6 default exports are actually also named exports, except that default is a "reserved" name and there is special syntax support for it. Lets have a look how Babel compiles named and default exports:

// input
export const foo = 42;
export default 21;

// output
"use strict";

Object.defineProperty(exports, "__esModule", {
  value: true
var foo = = 42;
exports.default = 21; 

Here we can see that the default export becomes a property on the exports object, just like foo.

Import the module

We can import the module in two ways: Either using CommonJS or using ES6 import syntax.

Your issue: I believe you are doing something like:

var bar = require('./input');
new bar();

expecting that bar is assigned the value of the default export. But as we can see in the example above, the default export is assigned to the default property!

So in order to access the default export we actually have to do

var bar = require('./input').default;

If we use ES6 module syntax, namely

import bar from './input';

Babel will transform it to

'use strict';

var _input = require('./input');

var _input2 = _interopRequireDefault(_input);

function _interopRequireDefault(obj) { return obj && obj.__esModule ? obj : { default: obj }; }


You can see that every access to bar is converted to access .default.

Monday, June 7, 2021
answered 7 Months ago

2018 Update: The module loader spec is now a part of the ES Spec - what you are describing is allowed and possible with <script type="module"> in browsers and with a custom --loader with Node.js as well as with Deno if you're into that.

The module loader spec and the import/export syntax are separate. So this is a property of the module loader (not a part of the ES spec). If you use a module loader that supports plugins like SystemJS.

Saturday, June 12, 2021
answered 6 Months ago

From your example:

Case A:

export function doSomething()

Case B:

export function doSomething()
export default function doSomethingDefault()


import utils from 'utils'
utils() // (Case A: undefined, Case B: doSomethingDefault)

import * as utils from 'utils'
utils // (Case A: utils = { doSomething: function }, Case B: utils = { doSomething: function, default: function })

import { doSomething } from 'utils'
doSomething() // (both Case A and Case B: doSomething = doSomething)

The difference between Case A and Case B is that, in Case A import utils from 'utils', utils will be undefined because there is no default export. In case B, utils will refer to doSomethingDefault.

With import * as utils from 'utils', in Case A utils will have one method (doSomething), while in Case B utils will have two methods (doSomething and default).

Saturday, September 11, 2021
Jan Gassen
answered 3 Months ago

You can omit the default export and use import as syntax:

import * as Mod from './my-module'
import { funcA, funcB } from './my-module'

console.log('A', Mod.funcA(), funcA()); // A a a
console.log('B', Mod.funcB(), funcB()); // B b b
export function funcA() { return 'a'; };
export function funcB() { return 'b'; };
Wednesday, November 3, 2021
Alex Chernilov
answered 1 Month ago
Only authorized users can answer the question. Please sign in first, or register a free account.
Not the answer you're looking for? Browse other questions tagged :