Skip to main content
The import rule file enforces consistent module usage patterns using eslint-plugin-import. Rules are grouped into four categories: static analysis, helpful warnings, module system constraints, and style. Source: eslint-config-airbnb-base/rules/imports

​
Resolver configuration

The config pre-configures the import resolver for Node.js module resolution. The following file extensions are recognized: 
extensions: ['.mjs', '.js', '.jsx']
Imports from the following locations are ignored:
  • node_modules
  • Files matching \.(coffee|scss|css|less|hbs|svg|json)$

​
Static analysis

These rules verify that imports actually resolve at lint time.
Severity: errorImport paths must resolve to an actual file or module. Both CommonJS and case-sensitive resolution are enforced.
// Bad — typo in module name
import foo from './fro';

// Good
import foo from './foo';
Severity: errorNamed imports must correspond to actual named exports in the target module.
// Given: export const foo = 1;

// Bad
import { bar } from './module'; // 'bar' is not exported

// Good
import { foo } from './module';
Severity: errorAbsolute file system paths are not portable across machines and environments.
// Bad
import foo from '/home/user/project/src/foo';

// Good
import foo from '../src/foo';
Severity: errorDynamic require() calls (with a variable or expression as the argument) cannot be statically analyzed and make tree-shaking impossible.
// Bad
const mod = require(moduleName);

// Good
const mod = require('./specific-module');

​
Helpful warnings

Severity: errorCatches invalid export patterns such as multiple default exports in a single file.
Severity: errorIf a module has a named export called foo, importing it as the default (import foo from './module') is likely a mistake.
Severity: errorAccessing a property on a default import that matches a named export is usually a mistake.
Severity: errorImports must only reference packages listed in dependencies or devDependencies in package.json. Dev dependencies are permitted in:
  • Test files (test/**, **/__tests__/**, **/*.test.js, etc.)
  • Config files (jest.config.js, webpack.config.js, rollup.config.js, .eslintrc.js, etc.)
Severity: errorExporting let or var declarations allows callers to mutate the exported binding, which is almost never intentional.
// Bad
export let counter = 0;

// Good
export const counter = 0;
Severity: errorA module that imports itself will always cause an infinite loop or an empty object.
Severity: error (unlimited depth)Circular imports are analyzed at all depths. Circular dependencies make code harder to understand and can cause runtime issues with module initialization order.

​
Module system

Severity: errorAMD define() and require([]) calls are not allowed. Use ES module syntax instead.
Severity: errorUsing ES import statements alongside CommonJS module.exports in the same file is not allowed. Choose one module system per file.
// Bad
import foo from './foo';
module.exports = foo;

​
Style

Severity: errorAll import statements must appear at the top of the file, before any other code.
// Bad
const setup = require('./setup');
import React from 'react';

// Good
import React from 'react';
const setup = require('./setup');
Severity: errorMultiple imports from the same module must be merged into a single import statement.
// Bad
import { foo } from './module';
import { bar } from './module';

// Good
import { foo, bar } from './module';
Severity: error (ignorePackages)File extensions for .js, .mjs, and .jsx files must be omitted from import paths. Extensions for other file types (e.g., .json, .png) are still required.
// Bad
import foo from './foo.js';

// Good
import foo from './foo';
Severity: errorImports must be grouped with builtin, external, and internal imports all together in the first group (no required separation between them by default).
// Good
import fs from 'fs';
import express from 'express';
import myLib from '../../lib/my-lib';
Severity: errorA blank line must follow the last import or require statement in the import block.
// Good
import React from 'react';
import PropTypes from 'prop-types';

function MyComponent() { ... }
Severity: errorModules with a single export should use a default export rather than a named export.
// Bad
export const foo = 1;

// Good
const foo = 1;
export default foo;
Severity: error
// Bad
import { default as foo } from './module';

// Good
import foo from './module';
Severity: errorWebpack loader syntax (import foo from 'loader!./file') couples source code to the build tool configuration.
// Bad
import styles from 'css-loader!./styles.css';
Severity: errorPath segments like ./ or ../ that do not change the resolved path must be removed.
// Bad
import foo from './../foo';
import bar from './bar/../baz';

// Good
import foo from '../foo';
import bar from './baz';
Severity: errorIn monorepos, importing another package via a relative path bypasses that package’s public API and build output. Import the package by its published name instead.

Build docs developers (and LLMs) love

Get started for freeTalk to us