eslint-plugin-simple-import-sort: A Practical Security Guide

eslint-plugin-simple-import-sort is a small, autofixable ESLint plugin that groups and alphabetizes your import statements so nobody argues about import order in code review again. It is not a security scanner, and it will not find a vulnerable dependency for you. But import ordering has a real, if quiet, connection to code security: when imports are sorted deterministically, a malicious or accidental import change stands out in a diff instead of hiding inside a reshuffled block. This guide covers what the plugin does, how to configure it, and how to add any lint plugin like it without quietly expanding your attack surface.

What eslint-plugin-simple-import-sort actually does

The plugin, maintained by Simon Lydell, has one job: it finds every "chunk" of imports (a run of import statements separated only by comments and whitespace) and rewrites them into a fixed order. It first splits imports into groups separated by a blank line, then sorts alphabetically within each group. The default grouping is side-effect imports first, then Node builtins and npm packages, then absolute and relative imports. It exposes two rules, simple-import-sort/imports and simple-import-sort/exports, and both are fully autofixable.

That last part is the whole point. The plugin is designed to be run with eslint --fix, ideally on save in your editor. You are not meant to manually satisfy it. If you find yourself hand-editing import order to make the linter happy, you have configured it wrong.

Compared to the older eslint-plugin-import (which people search for as "npm eslint-plugin-import"), the trade is deliberate. eslint-plugin-import does far more — it can detect unresolved modules, cyclic dependencies, and duplicate imports — but its import/order rule is slower and more configurable than most teams need. eslint-plugin-simple-import-sort intentionally has almost no options. That is a feature: fewer knobs means fewer per-repo disagreements.

Installing and configuring it

Add it as a dev dependency and enable the two rules. With a flat config (eslint.config.js, ESLint 9+):

import simpleImportSort from "eslint-plugin-simple-import-sort";

export default [
  {
    plugins: { "simple-import-sort": simpleImportSort },
    rules: {
      "simple-import-sort/imports": "error",
      "simple-import-sort/exports": "error",
    },
  },
];

With a legacy .eslintrc:

{
  "plugins": ["simple-import-sort"],
  "rules": {
    "simple-import-sort/imports": "error",
    "simple-import-sort/exports": "error"
  }
}

Install it the boring way:

npm install --save-dev eslint-plugin-simple-import-sort

The "eslint simple import sort" custom-grouping option lets you define your own section order via a regex array. Most teams should leave it at the default until they have a concrete reason to change it. Every custom group you add is a rule someone else on the team has to learn.

Why import order is a review-hygiene control, not just cosmetics

Deterministic import order is a small piece of a larger idea: make diffs boring so anomalies are loud. When import blocks are sorted the same way every time, adding a new dependency produces a clean one-line insert at a predictable spot. A reviewer scanning a pull request sees exactly which module was pulled in. When import order is freeform, a contributor can bury a new import — say a lookalike typosquat of a common package — in the middle of a reordered block, and it reads as noise.

This matters because install-time and import-time supply-chain attacks in the npm ecosystem often depend on a new dependency slipping through review unnoticed. Sorted imports do not stop a malicious package, but they raise the odds that a human notices the line import x from "reqeust" (note the typo) before it ever ships. An SCA tool such as Safeguard can flag a suspicious or vulnerable dependency transitively, but the cheapest control is a reviewer who can actually see what changed.

What this plugin does not do

Be clear about the boundary. Import sorting will not:

• Detect an unresolved or missing module (that is eslint-plugin-import or the TypeScript compiler).
• Remove unused imports (use eslint-plugin-unused-imports or the no-unused-vars rule with its TypeScript variant).
• Tell you a dependency has a known CVE (that is software composition analysis).
• Stop dependency confusion or typosquatting on its own.

Treat it as one input to good hygiene, sitting alongside a lockfile, npm ci in CI, and a real dependency scanner. If you present it as a security tool to a security team, you will lose credibility fast. It is a linting convenience with a modest secondary benefit for reviewability.

Adding any lint plugin without expanding your attack surface

Here is the part most import-sort tutorials skip. Every dev dependency you add, including this one, runs on developer machines and in CI, often with credentials in scope. A linter plugin is code you execute. So apply the same discipline you would to any dependency:

1. Pin it in the lockfile and install with npm ci. Reproducible installs mean a compromised registry cannot silently swap the tarball behind a version string you already vetted.
2. Check maintenance and provenance before adding. eslint-plugin-simple-import-sort is single-maintainer, which is fine for a widely used, stable tool — but note it, because single-maintainer packages are a recurring supply-chain risk vector. Watch for lookalike scoped forks; several @scope/eslint-plugin-simple-import-sort copies exist on npm, and you want the real lydell package, not a fork you found by accident.
3. Run npm install --ignore-scripts where you can. Lint plugins should have no install scripts; if one suddenly does after an update, that is a signal worth investigating.
4. Watch the changelog on major bumps. Version 6.0.0 and later track ESLint's flat-config and version-support changes, so a major upgrade of the plugin may coincide with an ESLint upgrade. Read the notes rather than blindly running npm audit fix --force.

None of this is specific to import sorting. It is the price of every line in your devDependencies, and it is worth internalizing on a low-stakes package like this one so the habit is automatic when the stakes are higher. For a deeper walkthrough of these habits, see our npm security best practices.

A sensible rollout

Turning the rule to error on an existing large codebase produces a huge one-time diff. Do it in a single dedicated commit that touches nothing but import order, so git blame stays clean and reviewers do not have to read a reformatting change mixed with logic. Add the autofix to your pre-commit hook or editor-on-save so nobody has to think about it again, and wire eslint into CI so the rule is enforced rather than optional. If you use Prettier, note that Prettier does not sort imports, so the two tools are complementary rather than in conflict.

Once it is in, forget about it. That is the intended end state: import order becomes a solved problem, your diffs get quieter, and your reviewers get a slightly better chance of catching the import that should not be there.

FAQ

Is eslint-plugin-simple-import-sort a security tool?

No. It is a code-style plugin that sorts imports. Its only security-adjacent benefit is that consistent import order makes diffs easier to review, so a suspicious new import is more likely to be noticed. Use a real SCA scanner for actual vulnerability detection.

How is it different from eslint-plugin-import?

eslint-plugin-import does much more — module resolution, cycle detection, duplicate detection — but its ordering rule is heavier and more configurable. eslint-plugin-simple-import-sort does one thing (sort and group imports) with almost no options, which is why many teams use both: import for resolution checks and simple-import-sort for ordering.

Will it remove my unused imports?

No. It only reorders. Pair it with eslint-plugin-unused-imports or the no-unused-vars rule if you want dead imports removed automatically.

Should I worry about the plugin being single-maintainer?

It is worth noting but not alarming for a stable, widely used dev tool. Pin it in your lockfile, install with npm ci, verify you are pulling the genuine lydell package rather than a lookalike fork, and read the changelog on major version bumps.