← Back to rules

unicorn/import-style Restriction

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:

import util from "node:util";

Examples of correct code for this rule:

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:

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

Examples of correct code:

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:

export * from "node:util";

Examples of correct code:

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:

import { red } from "chalk";

Examples of correct code:

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:

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

Examples of correct code:

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:

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:

import util from "node:util";

Examples of correct code:

import { promisify } from "node:util";

How to use

To enable this rule using the config file or in the CLI, you can use:

Config (.oxlintrc.json)

{
  "rules": {
    "unicorn/import-style": "error"
  }
}

Config (oxlint.config.ts)

import { defineConfig } from "oxlint";

export default defineConfig({
  rules: {
    "unicorn/import-style": "error",
  },
});

CLI

oxlint --deny unicorn/import-style

Version

This rule was added in vnext.

References

• Rule Source
• Open rule in Oxc Playground