---
url: /docs/guide/usage/linter/rules/eslint/no-duplicate-imports.md
---

### What it does

Disallow duplicate module imports.

### Why is this bad?

Using a single import statement per module will make the code clearer because you can see
everything being imported from that module on one line.

### Examples

Examples of **incorrect** code for this rule:

In the following example the module import on line 1 is repeated on line 3. These can be
combined to make the list of imports more succinct.

```js
import { merge } from "module";
import something from "another-module";
import { find } from "module";
```

Examples of **correct** code for this rule:

```js
import { merge, find } from "module";
import something from "another-module";
```

## Configuration

This rule accepts a configuration object with the following properties:

### allowSeparateTypeImports

type: `boolean`

default: `false`

When `true`, imports with only type specifiers (inline types or type imports) are
considered separate from imports with value specifiers, so they can be imported from the
same module on separate import statements.

Examples of **correct** code when `allowSeparateTypeImports` is set to `true`:

```js
import { foo } from "module";
import type { Bar } from "module";
```

```js
import { type Foo } from "module";
import type { Bar } from "module";
```

### includeExports

type: `boolean`

default: `false`

When `true` this rule will also look at exports to see if there is both a re-export of a
module as in `export ... from 'module'` and also a standard import statement for the same
module. This would count as a rule violation because there are in a sense two statements
importing from the same module.

Examples of **incorrect** code when `includeExports` is set to `true`:

```js
import { merge } from "module";

export { find } from "module"; // re-export which is an import and an export.
```

Examples of **correct** code when `includeExports` is set to `true`:

If re-exporting from an imported module, you should add the imports to the
`import` statement, and export that directly, not use `export ... from`.

```js
import { merge } from "lodash-es";
export { merge as lodashMerge };
```

```js
import { merge, find } from "module";

// cannot be merged with the above import
export * as something from "module";

// cannot be written differently
export * from "module";
```

## How to use

## Version

This rule was added in v0.13.2.

## References