Modules

  • 10.1 Always use modules (import/export) over a non-standard module system. You can always transpile to your preferred module system.

    Why? Modules are the future, let’s start using the future now.

    1. // bad
    2. const AirbnbStyleGuide = require('./AirbnbStyleGuide');
    3. module.exports = AirbnbStyleGuide.es6;
    5. // ok
    6. import AirbnbStyleGuide from './AirbnbStyleGuide';
    7. export default AirbnbStyleGuide.es6;
    9. // best
    10. import { es6 } from './AirbnbStyleGuide';
    11. export default es6;

  • 10.2 Do not use wildcard imports.

    Why? This makes sure you have a single default export.

    1. // bad
    2. import * as AirbnbStyleGuide from './AirbnbStyleGuide';
    4. // good
    5. import AirbnbStyleGuide from './AirbnbStyleGuide';

  • 10.3 And do not export directly from an import.

    Why? Although the one-liner is concise, having one clear way to import and one clear way to export makes things consistent.

    1. // bad
    2. // filename es6.js
    3. export { es6 as default } from './AirbnbStyleGuide';
    5. // good
    6. // filename es6.js
    7. import { es6 } from './AirbnbStyleGuide';
    8. export default es6;

  • 10.4 Only import from a path in one place.
    eslint: no-duplicate-imports

    Why? Having multiple lines that import from the same path can make code harder to maintain.

    1. // bad
    2. import foo from 'foo';
    3. // … some other imports … //
    4. import { named1, named2 } from 'foo';
    6. // good
    7. import foo, { named1, named2 } from 'foo';
    9. // good
    10. import foo, {
    11.   named1,
    12.   named2,
    13. } from 'foo';

  • 10.5 Do not export mutable bindings.
    eslint: import/no-mutable-exports

    Why? Mutation should be avoided in general, but in particular when exporting mutable bindings. While this technique may be needed for some special cases, in general, only constant references should be exported.

    1. // bad
    2. let foo = 3;
    3. export { foo };
    5. // good
    6. const foo = 3;
    7. export { foo };

  • 10.6 In modules with a single export, prefer default export over named export.
    eslint: import/prefer-default-export

    Why? To encourage more files that only ever export one thing, which is better for readability and maintainability.

    1. // bad
    2. export function foo() {}
    4. // good
    5. export default function foo() {}

  • 10.7 Put all imports above non-import statements.
    eslint: import/first

    Why? Since imports are hoisted, keeping them all at the top prevents surprising behavior.

    1. // bad
    2. import foo from 'foo';
    3. foo.init();
    5. import bar from 'bar';
    7. // good
    8. import foo from 'foo';
    9. import bar from 'bar';
    11. foo.init();

  • 10.8 Multiline imports should be indented just like multiline array and object literals.

    Why? The curly braces follow the same indentation rules as every other curly brace block in the style guide, as do the trailing commas.

    1. // bad
    2. import {longNameA, longNameB, longNameC, longNameD, longNameE} from 'path';
    4. // good
    5. import {
    6.   longNameA,
    7.   longNameB,
    8.   longNameC,
    9.   longNameD,
    10.   longNameE,
    11. } from 'path';

  • 10.9 Disallow Webpack loader syntax in module import statements.
    eslint: import/no-webpack-loader-syntax

    Why? Since using Webpack syntax in the imports couples the code to a module bundler. Prefer using the loader syntax in webpack.config.js.

    1. // bad
    2. import fooSass from 'css!sass!foo.scss';
    3. import barCss from 'style!css!bar.css';
    5. // good
    6. import fooSass from 'foo.scss';
    7. import barCss from 'bar.css';