# eslint-plugin-simple-import-sort sorts each blank-line-separated chunk on its own > An ESLint autofix plugin that orders imports and exports into five fixed groups, with one option and no ability to change the order inside a group. The manifest checked into the repository is a private dev file with no package name or version, and the published metadata lives in a second file. **lydell/eslint-plugin-simple-import-sort** — Easy autofixable import sorting. - Repository: https://github.com/lydell/eslint-plugin-simple-import-sort - Stars: 2,459 · Forks: 75 - Language: JavaScript - License: MIT - Published: 2026-09-28 · Updated: 2026-09-28 · Language: en - Canonical page: https://hysenlabs.com/projects/lydell-eslint-plugin-simple-import-sort ## The manifest in the repository is private and carries no package metadata The package.json at the root opens with private set to true and type set to commonjs. It has no name, no version, no main, no exports field and no dependencies key at all, only scripts and devDependencies. That absence is what backs the claim of no dependencies: there is nothing for consumers to install alongside the plugin. The published metadata therefore lives somewhere else, and the second file in the root, package-real.json, is the obvious candidate. The build step is a plain node build.js, so the two files are reconciled by a script rather than by hand. The script chain also puts the build after the tests, with posttest running npm run build, which means a full npm test compiles the package as its last action rather than leaving that to a separate publish step. Installation for a consumer is one command: ``` npm install --save-dev eslint-plugin-simple-import-sort ``` The dev flag is deliberate, since the plugin is meant to run inside the toolchain rather than as a runtime library. ## Each blank-line-separated chunk is sorted on its own Before grouping happens, the plugin finds chunks. A chunk is a sequence of import statements with only comments and whitespace between them, and each chunk is sorted separately. That means the blank lines already in your file decide how the work is divided, and the project says so directly: use import/first if you want every import to end up in the same chunk. Five groups follow inside each chunk. Side effect imports first, then Node.js builtins carrying the node: prefix, then packages, which is npm packages plus Node builtins written without that prefix, then absolute imports including Vue style aliases such as @/foo, and finally relative imports. The third group is the one to watch: import fs from "fs" is a builtin but lands with the packages, not with node:fs. ## Order inside a group and the order of side effect imports are fixed The plugin has one option and the text says so plainly, under a heading called Not for everyone. Two behaviours are called out as unconfigurable. The sorting within each group is described as what it is, with a pointer to the sort order section rather than an option. Sorting of side effect imports is listed as always staying in the original order, which is the safe default for module side effects but means those lines never move. For anything else the project points at import/order from eslint-plugin-import, noting that its maintainers seem interested in expanding it where it makes sense. The stated reason for keeping the plugin small is that adding options would leave it no longer simple, and that effort would be better spent contributing to the other rule. The author also states plainly that the plugin was made for personal use. ## The rule was renamed in 6.0.0 and no GitHub release records it The rule this plugin is known for is called simple-import-sort/imports. There used to be a rule called simple-import-sort/sort, and since version 6.0.0 it carries the name imports instead. A configuration carried over from an older setup will reference a rule name that no longer exists, and nothing in the usage sections shows the old spelling except that one note. This repository publishes no GitHub releases at all, so the tag history is not a place to look the change up. What remains is a CHANGELOG.md at the root and the published package versions on npm. The naming also encodes the two halves of the plugin: the imports rule for import statements and a separate exports rule, which the usage examples enable alongside each other in both configuration styles. ## The project lints its own tests with its own rules through a legacy flag The dogfood script runs eslint with rulesdir pointing at src and a dedicated config file, applied to the test directory. That is the plugin checking its own test suite using the rule implementations sitting in src, before the package is built. The same flag shape appears in the examples script, which adds no-ignore, a fix-dry-run, a JSON formatter, unused disable directive reporting and four extensions covering js, ts, vue and md. ESLint itself is pinned at 8.56.0 in the devDependencies, and rulesdir belongs to that CLI generation. Consumers are pointed at two configuration styles, the eslintrc format with a plugins array and parserOptions enabling import syntax, and the flat config file where import syntax is on by default and the plugin goes into a plugins object instead. ## The examples directory is the real map of the option surface The examples folder is larger than the documentation and reads as a behaviour matrix. Grouping has four fixtures: groups.none, groups.custom, groups.default-reverse and groups.no-blank-lines. Blank line handling has three, numbered in order as spaces.just-sort, spaces.eslint-builtin and spaces.prettier, so the naming states which tool's convention each one matches. Type imports get six, pairing first and last placement with plain, sorted and one-per-group variants. Then there are fixtures for comments, for markdown, for ignored files, and several prefixed readme, meaning the plugin's own documentation examples are linted as test cases. The examples script passes no-ignore because these fixtures are deliberately wrong and would otherwise be skipped. It also lints vue files, and eslint-plugin-vue is a devDependency, though the feature list claims only TypeScript friendliness. ## Thirteen devDependencies, twelve pinned exactly and one with a caret The manifest mixes eras of tooling. ESLint is held at 8.56.0 while vitest and its coverage package are at 4.1.8, the coverage package being the single caret range in the list. Twelve of the thirteen are exact pins, including prettier 3.2.5, typescript 5.3.3 and @typescript-eslint/parser 6.21.0, which is the parser the README names. Two Babel packages are pinned alongside a Babel parser: one for import attribute syntax and one for stripping Flow types, so two additional syntaxes are exercised that the feature list does not mention. The coverage package behind the 100 percent claim is @vitest/coverage-v8. The pretest step runs a prettier check and an eslint pass with unused disable directive reporting before the tests themselves, so formatting failures and lint failures both block the run. ## Conclusion This fits a codebase that wants one agreed import order with no per-project debate, and it deliberately will not fit anyone who needs configurable grouping, custom alphabetisation or sorting of require calls. Two practical points. The groups are applied per chunk, so a file with stray blank lines gets sorted differently from the same file with them removed, and enabling import/first is what makes the outcome deterministic. Second, the manifest in the repository is marked private and holds no name or version, so read package-real.json or the changelog before pinning a version, since no GitHub release records the 6.0.0 rename. ## FAQ ### How do I enable eslint-plugin-simple-import-sort with flat config? Import the plugin, place it in the plugins object, and add the two rules for imports and exports. Import syntax is enabled by default under flat config, so the parserOptions block shown for the eslintrc format is not needed there. ### Does eslint-plugin-simple-import-sort sort require calls? No. It is listed explicitly as not supporting require. The plugin works on import syntax and on export declarations, and it is designed to be run through eslint --fix. ### Can I change how imports are grouped in eslint-plugin-simple-import-sort? Not the order within a group, and not the order of side effect imports, which always keep their original order. For configurable grouping the project points at the import/order rule from eslint-plugin-import instead. ### What is the difference between the sort and imports rules? There used to be a rule called simple-import-sort/sort. Since version 6.0.0 the same rule is called simple-import-sort/imports, so an older configuration naming the previous rule will not resolve. ### How does eslint-plugin-simple-import-sort handle comments and type imports? Both are named as handled in the feature list. The examples directory carries dedicated fixtures, including several that place type imports first or last, sorted or one per group, plus others for comment handling and for markdown files. ## Sources - [Issues](https://github.com/lydell/eslint-plugin-simple-import-sort/issues) - [License: MIT](https://github.com/lydell/eslint-plugin-simple-import-sort/blob/main/LICENSE) - [lydell/eslint-plugin-simple-import-sort on GitHub](https://github.com/lydell/eslint-plugin-simple-import-sort) - [README](https://github.com/lydell/eslint-plugin-simple-import-sort/blob/main/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/lydell-eslint-plugin-simple-import-sort