---
url: /docs/guide/usage/linter/rules/unicorn/import-style.md
---

### What it does

Enforce specific import styles per module.

### Why is this bad?

Some modules are easier to read when imported in a consistent way.
For example, utility modules often work better with named imports,
while modules that expose one primary interface are clearer as default imports.

### Examples

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

```js
import util from "node:util";
```

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

```js
import { promisify } from "node:util";
```

## Configuration

This rule accepts a configuration object with the following properties:

### checkDynamicImport

type: `boolean`

default: `true`

Whether dynamic import expressions are checked.

Set this to `false` to skip calls such as `await import("module")`.

With the default configuration, examples of **incorrect** code:

```js
async () => {
  const { red } = await import("chalk");
};
```

Examples of **correct** code:

```js
async () => {
  const { default: chalk } = await import("chalk");
};
```

### checkExportFrom

type: `boolean`

default: `false`

Whether export-from declarations are checked.

This is disabled by default. Set this to `true` to check declarations like
`export ... from "module"`.

With `{ "checkExportFrom": true }`, examples of **incorrect** code:

```js
export * from "node:util";
```

Examples of **correct** code:

```js
export { promisify } from "node:util";
```

### checkImport

type: `boolean`

default: `true`

Whether static import declarations are checked.

Set this to `false` to skip `import ... from "module"` and side-effect imports like
`import "module"`.

With the default configuration, examples of **incorrect** code:

```js
import { red } from "chalk";
```

Examples of **correct** code:

```js
import chalk from "chalk";
```

### checkRequire

type: `boolean`

default: `true`

Whether CommonJS `require()` calls are checked.

Set this to `false` to skip `require("module")` calls completely.

With the default configuration, examples of **incorrect** code:

```js
const util = require("node:util");
```

Examples of **correct** code:

```js
const { promisify } = require("node:util");
```

### extendDefaultStyles

type: `boolean`

default: `true`

Whether `styles` extends or replaces the built-in module preferences.

When this is `true`, entries in `styles` are merged with the default preferences. For
example, `{ "styles": { "path": { "named": true } } }` allows named imports from
`path` while leaving its default import style allowed. When this is `false`, only modules
configured in `styles` are checked.

With `{ "extendDefaultStyles": false, "styles": {} }`, examples of **correct** code:

```js
import { red } from "chalk";
```

### styles

type: `object`

default: `{}`

Per-module import style preferences.

Each key is a module specifier. Set the value to `false` to disable checking for the
module, or to an object that allows one or more import styles. The available styles are
`unassigned`, `default`, `namespace`, and `named`. When `extendDefaultStyles` is `true`,
these entries extend the built-in defaults instead of replacing them.

The default module preferences are default imports for `chalk`, `path`, and `node:path`,
and named imports for `util` and `node:util`.

With `{ "styles": { "node:util": { "named": true, "default": false } } }`,
examples of **incorrect** code:

```js
import util from "node:util";
```

Examples of **correct** code:

```js
import { promisify } from "node:util";
```

## How to use

## Version

This rule was added in v1.67.0.

## References