eslint-plugin-simple-import-sort: autofixable import sorting with almost no knobs

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

Import order drifts in every repository that has more than one contributor. Someone adds a line at the top, someone else pastes a block from a scratch file, and after a year the first twenty lines of a component are a random walk. The usual response is a style guide paragraph that nobody reads, or a manual review comment that gets ignored. This plugin takes the third route: it makes wrong order a lint error and lets eslint --fix rewrite the file.

The target audience is narrow and stated in the README. It is for people who use eslint --fix a lot and want to forget about sorting imports entirely. If your workflow is running ESLint only in CI and fixing reports by hand, the autofix is still useful, but the plugin loses most of its value. The README is explicit that this is not for everyone, and that the maintainer wrote it for personal use across many small projects.

Two rules, one option, a fixed sort order

The plugin exposes two rules, simple-import-sort/imports and simple-import-sort/exports. The exports rule sorts re-export sequences where the code shape allows it. The imports rule does the work most people come for.

Sorting happens in two passes. First the plugin collects chunks: a chunk is a sequence of import statements separated only by comments and whitespace. Each chunk is sorted independently, which is why the README suggests import/first if you want every import to land in a single chunk. Then each chunk is split into sections with a blank line between them, in this order: side effect imports such as import "./setup", Node.js builtins prefixed with node:, packages, absolute imports and things like Vue-style @/foo, and relative imports. Within a group the order is alphabetical, and the README describes the grouping as very loosely defined.

Two details matter more than they look. Side effect imports are never sorted internally, so their execution order survives. Type imports and exports are handled, which is what makes the plugin usable in TypeScript projects through @typescript-eslint/parser. The README also notes that the rule was called simple-import-sort/sort before version 6.0.0, so older blog posts and configs may reference a name that no longer exists.

Installing eslint-plugin-simple-import-sort and wiring up flat config

The package is installed as a dev dependency. The README gives a single npm command and points at the ESLint getting started guide, since this is a plugin and not a standalone tool.

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

For the newer flat config, import the plugin, put it in the plugins object, and enable both rules. The README notes that with flat config, import syntax is enabled by default, so no parserOptions block is needed.

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",
    },
  },
];

If you are still on eslintrc, the README shows the same two rules under a plugins array, plus parserOptions with sourceType set to module and ecmaVersion set to latest, because ESLint does not parse import syntax by default in that configuration.

{
  "plugins": ["simple-import-sort"],
  "rules": {
    "simple-import-sort/imports": "error",
    "simple-import-sort/exports": "error"
  },
  "parserOptions": {
    "sourceType": "module",
    "ecmaVersion": "latest"
  }
}

After that, run eslint --fix on a file with messy imports. The expected result is the transformation the README demonstrates: third-party packages first in alphabetical order, then a blank line, then relative imports sorted by path, with named specifiers inside braces also sorted.

The recommended companion rules, and why they are not optional in practice

The README's example configuration pairs this plugin with eslint-plugin-import and three of its rules. That is optional in the sense that the plugin works alone, but the combination closes gaps the sorting rule cannot.

{
  "plugins": ["simple-import-sort", "import"],
  "rules": {
    "simple-import-sort/imports": "error",
    "simple-import-sort/exports": "error",
    "import/first": "error",
    "import/newline-after-import": "error",
    "import/no-duplicates": "error"
  }
}

import/first forces every import into one chunk so the sorting rule sees a single block instead of several. import/newline-after-import keeps the blank line after the import block, which the grouping pass produces. import/no-duplicates merges imports from the same file, described in the README as mostly autofixable. Without these, a file that scatters imports between statements will be sorted chunk by chunk, and the result may look inconsistent even though the plugin did exactly what it promises.

The README also warns against running other sorting rules at the same time, naming sort-imports and import/order. Two rules that both want to reorder the same lines will fight, and the fix output becomes unstable.

Where eslint-plugin-simple-import-sort is the wrong tool

The plugin has one option, for custom grouping, and the README is direct about why: projects differ too much for a one-size-fits-all grouping, but adding more options would make it no longer simple, and the maintainer argues effort would be better spent on import/order.

The consequences are concrete. The sorting within each group is fixed; the README says it is what it is. You cannot define your own sort comparator, cannot put type imports in a separate group by default through configuration alone, and cannot reorder side effect imports, which always stay in their original order. If your codebase depends on a house style such as React first, then internal aliases, then everything else, this plugin will not express it.

The other hard boundary is require(). The README states plainly that the plugin does not support require, so CommonJS codebases get nothing from it. And because sorting is chunk-based, a file with imports interleaved with executable statements will be sorted in pieces unless import/first is enabled. That is a real failure mode: the fix runs, the linter passes, and the file still does not match the ordering you expected.

import/order versus eslint-plugin-simple-import-sort

The README points at import/order from eslint-plugin-import as the alternative for anyone who wants more control, and the difference is not cosmetic.

import/order is configuration-driven. It exposes many options for groups, path patterns, alphabetize settings and newline requirements, and the README notes that its maintainers seem interested in expanding that surface. You describe the order you want and the rule enforces it. That flexibility is also the cost: the config grows, and every new project shape needs another adjustment.

This plugin inverts the trade. It ships a fixed, opinionated order, one grouping option, and no dependencies. The README's own framing is that if options keep being added, the plugin eventually has no reason to exist. So the choice is between expressing your existing convention in configuration, and adopting the plugin's convention and letting autofix enforce it everywhere. Teams with a strong existing import style should pick import/order. Teams with no strong opinion, or teams willing to let the tool decide, get more value from the smaller package.

Maintenance status, licence and upgrade cost

The repository is not archived, and the last push was on 2026-09-03, which is recent. The package.json in the repository is marked private, which is normal for a plugin whose published package is built by build.js from the src directory; the test script runs vitest, and posttest runs the build, so a release involves a build step rather than publishing source directly.

The plugin is MIT licensed, which permits commercial and private use with the usual requirement to keep the licence and copyright notice. That is a statement about the licence text, not legal advice; check with your own counsel if the distinction matters to your organisation.

Upgrade cost is low by design. There are no runtime dependencies, so there is nothing to audit transitively. The one historical break worth knowing is the rule rename in version 6.0.0, from simple-import-sort/sort to simple-import-sort/imports. The README does not document a rollback path or a migration tool, so a rename in a large config set is a manual find-and-replace. The repository also carries a CHANGELOG.md, which is the place to check before bumping the version.

Editorial conclusion

Adopt eslint-plugin-simple-import-sort if your team already runs eslint --fix, wants imports sorted without a second tool, and accepts the fixed grouping and sorting rules. Skip it if you need per-project group definitions, custom sort order, or require() support, and use import/order instead. Before rolling it out, run the plugin over your codebase with the two rules enabled, confirm that side effect imports stay put, and check that no other sorting rule such as sort-imports or import/order is enabled at the same time.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. lydell/eslint-plugin-simple-import-sort on GitHub
4. README