eslint-plugin-simple-import-sort

This release adds a short meta.docs.description to each rule. Thanks to fisker Cheung (@fisker)!

This release adds TypeScript type definitions for the plugin itself. This is useful when you use TypeScript to check your ESLint configuration. It assumes that you install @types/eslint yourself. Thanks to @Logicer16!

This release removes the support for import assignments added in version 11.0.0:

• Turns out it was broken in some cases.
• The suggested fix went past my complexity tolerance for such an esoteric feature.
• I also learned that they aren’t really imports, and that I don’t understand their semantics well enough to know how sorting them affects your program.

If you miss the support for import assignments, I suggest you write your own ESLint rule which moves them out of the way from the actual imports, sorting them or not.

This release adds support for TypeScript import assignments (import A = B.C and import A = require("module")). Thanks to Szabolcs Kurdi (@szku01) and Svyatoslav Zaytsev (@MillerSvt)!

It’s only a breaking change if you use TypeScript import assignments, and only in the form that you need to autofix your files.

In other news, this release adds the meta plugin property in preparation for ESLint Flat Config, and avoids the deprecated context.getSourceCode() method (while still being backwards compatible).

This release might move some imported items with type around. This is a breaking formatting change (that only affects TypeScript and Flow), but only in the form of that you need to autofix your files.

In previous versions, type specifiers came first:

import { type B, a } from "a";
export { type B, a } from "a";

Now, all specifiers are sorted alphabetically, regardless of type:

import { a, type B } from "a";
export { a, type B } from "a";

Motivation:

You might import a class for a type annotation using:

<!-- prettier-ignore -->

import {
  type MyClass,
  coolFunction,
} from "example";

Later, you also start instantiating that class in the same file (new MyClass()), so you remove type.

Previously, this resulted in a messy diff due to the class moving:

 import {
-  type MyClass,
   coolFunction,
+  MyClass,
 } from "example";

Now, the sorting with the type keyword would be:

<!-- prettier-ignore -->

import {
  coolFunction,
  type MyClass,
} from "example";

Now there’s no reordering diff, just the type keyword being removed:

 import {
   coolFunction,
-   type MyClass,
+   MyClass,
 } from "example";

This is consistent with [“Why sort on from?”][sort-from].

Thanks to Jake Bailey (@jakebailey) for reporting and suggesting the fix!

This version adds support for [eslint-plugin-svelte], and for declare module in TypeScript.

More generally, imports and exports are now supported anywhere, by finding the set of parents of all imports and exports and working with those. Previously, the plugin only sorted imports and exports directly inside a Program node. For eslint-plugin-svelte and declare module that didn’t cut it.

This is only a breaking change if you imports or exports in declare module in TypeScript, and only in the form of that you need to autofix your files.

Node.js builtin modules prefixed with node: are now in a separate group by default (regex: ^node:), above the packages group. (Node.js builtins without node: are still sorted together with npm packages like before.)

Before:

import fs from "fs";
import _ from "lodash-es";
import { rmSync } from "node:fs";

After:

import { rmSync } from "node:fs";

import fs from "fs";
import _ from "lodash-es";

This is only a breaking change if you use the node: prefix in imports, and only in the form of that you need to autofix your files.

You can now customize where type imports (import type { X } from "x") go, via the groups option. Type imports have \u0000 at the end.

This is only a breaking change if you use the groups option and your regexes care about what the last character is. If so, you now need to account for the fact that the last character of type imports is \u0000.

• Fixed: as default in exports no longer results in invalid code.

• Renamed: simple-import-sort/sort is now called simple-import-sort/imports.
• Added: simple-import-sort/exports for sorting (some) exports. Big thanks to Remco Haszing (@remcohaszing) for the suggestion and great feedback, and to @JCrepin for the initial implementation!
• Fixed: ../.. imports are now sorted properly based on directory hierarchy.
• Improved: The default regexes for the groups option can now be reordered freely without causing imports to unexpectedly end up in other groups than before.
• Removed: Support for Node.js 8.

• Improved: Reduced package size by 50%.

• Fixed: The plugin now works with TypeScript 3.8 type imports. Thanks to Liwen Guo (@Livven) and Brandon Chinn (@brandon-leapyear)!

• Fixed: Side effect imports now correctly keep their original order in Node.js <12. Thanks to Irvin Zhan (@izhan)!

• Added: The groups option for [custom sorting].
• Changed: Due to the new groups option, the default grouping is ever so slightly different. Now, not only valid npm package names are placed in the “packages” group, but also things that look like npm package names, such as @ui/Section. And anything starting with . is now considered to be a relative import. See [custom sorting] for more information.
• Removed: Built-in support for webpack loader syntax. It didn’t fit well with the new groups option, and since I don’t use it myself I decided to remove it. Please open an issue if you have something to say about this!

• Changed: Sorting is now more human – it is case insensitive (matching the default behavior of TSLint, as well as many IDEs) and numbers are sorted by their numeric values. This might cause some churn but feels a lot nicer. See [#7] for more discussion.
• Improved: from paths ending with dots in various ways used to be treated specially. This has now been simplified, which gives a more consistent sorting. Now, "." and ".." are treated as "./" and "../" – and those are the only special cases for “dotty” paths. For example, you might see import x from "." now sorting before import y from "./y".
• Fixed: ".x" is no longer considered to be a relative import. Only from paths equal to "." or "..", or that start with "./" or "../" are truly relative. This is a bit of an edge case, but if you do have “weird” imports starting with dots in unusual ways you might notice them jumping up to another group of imports.
• Fixed: import {} from "a" is no longer considered a side-effect import. Only imports completely lacking the {...} from part are. Remove {} from if you relied on this from earlier versions.
• Improved: Trailing spaces after imports are now preserved. Before, if you accidentally added some trailing spaces it would result in a “Run autofix to sort these imports!” error, but the autofix wouldn’t actually sort anything – it would only remove some spaces. That was a bit weird. Now, those spaces are preserved. It is up to other rules or [Prettier] to take care of trailing spaces.

• Fixed: Semicolon-free code style is now supported. The plugin now leaves a semicolon at the start of a line of code after an import alone.

• Added: Support for indentation in Vue <script> tags.

• Changed: @/foo imports and similar are now treated as absolute imports. This is a common convention in Vue to avoid ../../../foo imports. Previously, @/foo ended up among npm packages. This was fixed by turning the absolute imports group into the “rest / trash can” group instead of the packages group. The packages group now only contain valid npm package names and Node.js builtins. The new grouping logic is:

  1. import "./setup": Side effect imports. (These are not sorted internally.)
  2. import react from "react": Packages (npm packages and Node.js builtins).
  3. import Error from "@/components/error.vue": Absolute imports, full URLs and other imports (such as Vue-style @/foo ones).
  4. import a from "./a": Relative imports.

• Added: [TypeScript] support, via [@typescript-eslint/parser].

• Changed: [Flow type imports] are no longer put in their own group at the top. Type imports from npm packages are grouped among regular npm imports, relative type imports are group among regular relative imports, and so on. The reason for this change is the same as for [sorting on from] – to avoid import “jumps” when they change. Previously, changing import type { User } from "./user" into import { type User, getUser } from "./user" caused the line to jump from the top of the file (the type imports group) to further down (the relative imports group). Now it stays in the relative imports group in both cases.

• Update readme.

• Update readme.

• Initial release.