Skip to main content
interlace
Plugin: import-nextRules

enforce-import-order

Enforces a specific order for import statements

šŸ’¼ This rule is enabled in the following configs: recommended, typescript. šŸ”§ This rule is automatically fixable by the --fix CLI option.

Rule Details

Import declarations follow the configured group order, are alphabetized inside a group, and groups are separated as configured. The fix rewrites the import block in order.

Groups, in the default order builtin, external, internal, parent, sibling, index, side-effect:

  • builtin: a Node.js builtin in any spelling - Node's own builtin list, subpaths included (fs, crypto, fs/promises), or the node: scheme;
  • internal: a specifier matching an internalPatterns regular expression (default ^@/);
  • parent: .. or ../x; sibling: ./x; index: the directory's own index (., ./, ./index, ./index.js);
  • side-effect: an import that binds nothing (import './setup');
  • type: a statement-level import type, only when groups lists type - otherwise a type import is grouped by its path;
  • external: everything else. A group missing from groups sorts after the listed ones.

alphabetize.order (asc default, desc, ignore) orders imports of one group by specifier; alphabetize.caseInsensitive (default true) compares lowercased, false compares code units (Zed before react). newlinesBetween: always (default) wants a blank line between groups, never forbids one, ignore checks neither. Imports separated by other code are reported once, as not contiguous, and not reordered.

āŒ Incorrect

import react from 'react';
import crypto from 'crypto';
import sib from './sib';
import up from '..';

āœ… Correct

import crypto from 'crypto';
import fs from 'node:fs';

import react from 'react';

import up from '..';

import sib from './sib';

Options

[
  {
    "type": "object",
    "properties": {
      "groups": {
        "type": "array",
        "items": {
          "type": "string",
          "enum": [
            "builtin",
            "external",
            "internal",
            "parent",
            "sibling",
            "index",
            "object",
            "type",
            "side-effect"
          ]
        }
      },
      "internalPatterns": {
        "type": "array",
        "items": {
          "type": "string"
        }
      },
      "alphabetize": {
        "type": "object",
        "properties": {
          "order": {
            "type": "string",
            "enum": [
              "asc",
              "desc",
              "ignore"
            ]
          },
          "caseInsensitive": {
            "type": "boolean"
          }
        },
        "additionalProperties": false
      },
      "newlinesBetween": {
        "type": "string",
        "enum": [
          "always",
          "never",
          "ignore"
        ]
      }
    },
    "additionalProperties": false
  }
]

Implementation

OWASP Foundation

  • Category: A00:2021 - General Security

Use this rule

npm install -D oxlint-plugin-import-next
.oxlintrc.json
{  "jsPlugins": ["oxlint-plugin-import-next"],  "rules": {    "import-next/enforce-import-order": "error"  }}
vite.config.ts
import { defineConfig } from 'vite-plus';export default defineConfig({  lint: {    jsPlugins: ['oxlint-plugin-import-next'],    rules: {      'import-next/enforce-import-order': 'error',    },  },});

oxlint-plugin-import-next re-exports eslint-plugin-import-next/oxlint: the same rules under the same IDs, and no ESLint install. Why oxlint.

Did this rule catch something? Star the repo to get new CWE coverage as we ship it — or follow the AI-code-security benchmarks behind these rules.