[DRAFT]

This blog is about the pros and cons of these two module export styles:

// default exports
export default class Foo { }

// named exports
export class Bar { }

Some statistics

TODO: This is actually quite hard to analyze, because it is hard to determine how to do a regex search for a named export and it is hard to distinguish build and bundle results from source code.

Number of *.ts files that contain a single default export or a single named export.


                                          single default export     single named export
github.com:Microsoft/vscode/src               
github.com:Microsoft/TypeScript/src
github.com:angular/angular/some-dir
github.com:angular/angular-cli/some-dir

Quotes in favor of default exports

If you’re only exporting a single class or function, use export default... This makes both importing and actually using the import a little easier... This is optimal for consumers. They can name your type whatever they want... and don’t have to do any excessive dotting to find your objects. (Modules - TypeScript, n.d.)

Red Flags... A file that has a single export class or export function (consider using export default). (Modules - TypeScript, n.d.)

The module syntax suggesting that the default export “is” the module may seem a bit strange, but it makes sense if you consider that one major design goal was to make default exports as convenient as possible. (Rauschmayer, 2014)

Quotes in favor of named exports

...why do we need named exports if we could simply default-export objects (like CommonJS)? The answer is that you can’t enforce a static structure via objects and lose all of the associated advantages. (Rauschmayer, 2014)

export default can lead to problems... There are a few maintainability concerns here... If you refactor Foo in foo.ts it will not rename it in bar.ts. If you end up needing to export more stuff from foo.ts (which is what many of your files will have) then you have to juggle the import syntax. (Syed, n.d.)

Bonus points: You even get autocomplete at this import {/here/} from "./foo"; cursor location. Gives your developers a bit of wrist relief. (Syed, n.d.)

Bonus points: Better commonJs experience. With default there is horrible experience for commonjs users who have to const {default} = require('module/foo'); instead of const {Foo} = require('module/foo'). (Syed, n.d.)

Bonus points: You don't get typos like one dev doing import Foo from "./foo"; and another doing import foo from "./foo"; (Syed, n.d.)

Bonus points: Auto import quickfix works better. You use Foo and auto import will write down import { Foo } from "./foo"; caus its a well defined name exported from a module. (Syed, n.d.)

Bonus points: Reexporting is unnecessarily hard. Reexporting is common for the root index file in npm packages e.g. import Foo from "./foo"; export { Foo } (with default) vs. export * from "./foo" (with named exports). (Syed, n.d.)

References

Microsoft (n.d) Modules - TypeScript. Retrieved from https://www.typescriptlang.org/docs/handbook/modules.html on 2017, August 25

Rauschmayer, A (2014, September 07) ECMAScript 6 modules: the final syntax [Blog post]. Retrieved from http://2ality.com/2014/09/es6-modules-final.html on 2017, August 25

Syed, B (n.d) Avoid Export Default - TypeScript. Retrieved from https://basarat.gitbooks.io/typescript/docs/tips/defaultIsBad.html on 2017, August 25

ECMAScript Discussion Archives (n.d.) ModuleImport. Retrieved from https://esdiscuss.org/topic/moduleimport on 2017, Auguest 25.

APA reference style: http://blog.apastyle.org/apastyle/2010/11/how-to-cite-something-you-found-on-a-website-in-apa-style.html)