question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Do not reorder side effect imports

See original GitHub issue

Apologies 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:open
  • Created 2 years ago
  • Reactions:12
  • Comments:18 (5 by maintainers)

github_iconTop GitHub Comments

7reactions
IanVScommented, Feb 26, 2022

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.

4reactions
IanVScommented, Jul 25, 2022

@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.

Read more comments on GitHub >

github_iconTop Results From Across the Web

Ep. 128 – Module side effects and import order - YouTube
Sam and Ryan talk about how module side effects can expose order-dependent code, and why its worth ensuring your modules work regardless of...
Read more >
Everything you never wanted to know about side effects
As we've seen, side effects are code that runs simply by virtue of importing a module, and has an external influence of some...
Read more >
Does Python import order matter - Stack Overflow
Import order can matter if the __init__ behavior of the module has side-effects. For example, importing TensorFlow will consume the total of GPU ......
Read more >
Sorting your imports with ESLint - DEV Community ‍ ‍
This is an ESLint plugin that enables not only sorting with some nice ... Package imports should come next, sorted by alphabetical order...
Read more >
Tree Shaking - webpack
A "side effect" is defined as code that performs a special behavior when imported, other than exposing one or more exports. An example...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found