Do not reorder side effect imports
See original GitHub issueApologies if this has been mentioned already, I did not find any issue for, though.
Is your feature request related to a problem?
A side effect import is an import that only imports a module for its side effects, without importing any values (i.e. where ImportDeclaration.specifiers is an empty array). These are currently sorted just like any other imports. Since those imports are explicitly used for side-effects, changing the order will usually result in a different behavior.
Now side effects are something that should be avoided if possible, and library code should have side effects. However, there are some valid use cases, such as loading mocks for tests, mock-fs or loading global libraries in an index file of a wep app, etc. For example:
import "./setup-test-environment"; // setup some required globals on which some module rely unfortunately
import { something } from "./a-module-to-test";
The above would be re-ordered, which breaks the test.
Describe the solution you’d like
Side effect imports should not be reordered. eslint-plugin-import does not reorder them either, for the same reason.
Since it is hard to know which side effect imports affect which other imports, I would suggest the following solution: treat a side effect import as a boundary that splits the imports into two groups, the imports before the the side effect import and the imports after the side effect import. Then only sort the imports before and after the side effect import as you would normally. This is I think the easiest to implement and also the safest. If users want to have side effect at the top, they can just move the side effect imports to the top, and the formatter will leave them there.
I made this a feature, but I would almost consider it a bug. By default, side effect imports should not be reordered. An option could be added for sorting these imports too, but I’m not sure if that’s really necessary. It also goes against prettier’s philosophy of limiting the options as much as possible.
So for example:
// Side effect import 1
import "S1";
// Start group 1
import {} from "b";
import * as A from "c";
// End group 1
// Side effect import 2
import "S2";
// Start group 2
import foo from "d";
import { bar } from "e";
// End group 2
// Side effect import 3
import "S3";
In the example above, keep the side effect imports as they are. Sort the imports in group 1 and group 2 using whatever options are set. Do not move any import from group 1 to group 2 or vice-versa.
Describe alternatives you’ve considered
Another alternative I can think of is to simply keep the relative ordering of the side effect imports, but allow moving non side effect imports anywhere. Or always just put side effect imports at the top. Both of this possibilities have the disadvantage they the may be unsafe: putting an import from before a side effect import after it may break it because it does not expect that side effect; putting an import from after a side-effect before it may break it because it relies on the side effect. It’s also unclear how imports with and without side effects should be ordered relatively to each other.
Issue Analytics
- State:
- Created 2 years ago
- Reactions:12
- Comments:18 (5 by maintainers)

 Top Related Medium Post
Top Related Medium Post Top Related StackOverflow Question
Top Related StackOverflow Question
I think that #111 is an important bugfix, and that this plugin is not suitable for production use without it. So, I’ve published a fork which is currently the same as this package, but with https://github.com/trivago/prettier-plugin-sort-imports/pull/111 included (without any kind of option necessary). It can be found at https://www.npmjs.com/package/@ianvs/prettier-plugin-sort-imports for anyone else who might find it useful.
@Morriz FWIW, my fork now has a few features that this project does not have, and gets a fair number of npm downloads. I use it in a few of my own projects, and continue to maintain it. In case that eases your mind about using a fork.