Export-ing conventions

[zurfyx]

Airbnb style guides [10] do not define any specific export style, other than:

10.6 In modules with a single export, prefer default export over named export.

Which one is the preferred style in the following cases (feel free to suggest better ones):

Single export

• Inline export

export default foo = () => { ... }

• Separate export (after definition)

const foo = () => { ... };
export default foo;
const other = () => { ... };

• Separate export (at the end of file)

const foo = () => { ... };
const boo = () => { ... };
export default foo;

Multiple exports

• Inline exports

export foo = () => { ... }
export boo = () => { ... }

• Separate export (after definition)

const foo = () => { ... }
export foo;
const boo = () => { ... }
export boo;

• Separate export (at the end of file)

const foo = () => { ... }
const boo = () => { ... }
export { foo, boo };

• Wrapper export

export const wrapper = {
  foo: () => { ... }
  boo: () => { ... }
}

[ljharb]

In most cases, you should be exporting one conceptual thing from a module. In other words, if you have both "foo" and "boo", those are two modules and thus should be export defaulted from two separate files.

If you insist on having them in the same file (there are some use cases where this makes sense, but not many), then you should be using multiple named exports.

When exporting one thing, and inline export is nicer because it ensures that you can not change the binding later (ie, export default function foo() {}; is better than function foo() {} ; export default foo;)

As far as positioning, there will soon be a linter rule in eslint-plugin-import that will require that all export statements are grouped together - so I'd recommend grouping them together and putting them at the bottom of the file.

[alex-mitchem]

The only problem with limiting yourself to one export is it severely limits your ability to use TDD.

[ljharb]

@AMitchemTW that doesn't make any sense to me; how does it limit your ability to use TDD? (not that using TDD is necessarily a good thing)

[alex-mitchem]

If I limit myself to only the default export, I can only test the function from end to end. Ideally, I want to be separating my function into smaller, more testable blocks that are called by my default export. It isn't specifically a problem for TDD, but testing in general.

[ljharb]

Sure; but those smaller blocks a) don't have to be exported at all, and b) absolutely can be imported from other modules.

[ljharb]

However yes, all tests should only be "end to end"; mocking things out makes tests more brittle.

TDD doesn't require mocking things out; it just requires testing your interface.

[alex-mitchem]

Tests should absolutely not only be end to end, its the entire reason smaller functions are considered best practise, because its easier to test a small function than a large function. As for you previous comment, I'm not sure I understand. They don't have to be exported but can be imported?

[ljharb]

If you need to test them, you should export them (if they're not exported, they don't need tests).

Whether you export them as named exports from the module, or as default exports from their own modules, the only thing that changes is the import path/syntax - their testability is identical.