10. 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.
// bad
const AirbnbStyleGuide = require('./AirbnbStyleGuide');
module.exports = AirbnbStyleGuide.es6;
// ok
import AirbnbStyleGuide from './AirbnbStyleGuide';
export default AirbnbStyleGuide.es6;
// best
import { es6 } from './AirbnbStyleGuide';
export default es6;10.2 Do not use wildcard imports.
Why? This makes sure you have a single default export.
// bad
import * as AirbnbStyleGuide from './AirbnbStyleGuide';
// good
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.
// bad
// filename es6.js
export { es6 as default } from './AirbnbStyleGuide';
// good
// filename es6.js
import { es6 } from './AirbnbStyleGuide';
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.
// bad
import foo from 'foo';
// … some other imports … //
import { named1, named2 } from 'foo';
// good
import foo, { named1, named2 } from 'foo';
// good
import foo, {
named1,
named2,
} 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.
// bad
let foo = 3;
export { foo };
// good
const foo = 3;
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.
// bad
export function foo() {}
// good
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.
// bad
import foo from 'foo';
foo.init();
import bar from 'bar';
// good
import foo from 'foo';
import bar from 'bar';
foo.init();10.8 Multiline imports should be indented just like multiline array and object literals.
eslint: object-curly-newline
Why? The curly braces follow the same indentation rules as every other curly brace block in the style guide, as do the trailing commas.
// bad
import {longNameA, longNameB, longNameC, longNameD, longNameE} from 'path';
// good
import {
longNameA,
longNameB,
longNameC,
longNameD,
longNameE,
} 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.
// bad
import fooSass from 'css!sass!foo.scss';
import barCss from 'style!css!bar.css';
// good
import fooSass from 'foo.scss';
import barCss from 'bar.css';10.10 Do not include JavaScript filename extensions
eslint: import/extensions
Why? Including extensions inhibits refactoring, and inappropriately hardcodes implementation details of the module you're importing in every consumer.
// bad
import foo from './foo.js';
import bar from './bar.jsx';
import baz from './baz/index.jsx';
// good
import foo from './foo';
import bar from './bar';
import baz from './baz';